Internet DRAFT - draft-dwpz-pce-domain-diverse

draft-dwpz-pce-domain-diverse







PCE Working Group                                               D. Dhody
Internet-Draft                                                     Q. Wu
Intended status: Experimental                                   U. Palle
Expires: November 18, 2017                                      X. Zhang
                                                     Huawei Technologies
                                                            May 17, 2017


                    PCE support for Domain Diversity
                    draft-dwpz-pce-domain-diverse-07

Abstract

   The Path Computation Element (PCE) may be used for computing path for
   services that traverse multi-area and multi-AS Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE)
   networks.

   Path computation should facilitate the selection of paths with domain
   diversity.  This document examines the existing mechanisms to do so
   and further propose some extensions to Path Computation Element
   Protocol (PCEP).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 18, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Dhody, et al.           Expires November 18, 2017               [Page 1]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Domain Diversity  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Per Domain Path Computation . . . . . . . . . . . . . . .   4
     3.2.  Backward-Recursive PCE-based Computation  . . . . . . . .   4
     3.3.  Hierarchical PCE  . . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  End to End Path . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Domain-Sequence . . . . . . . . . . . . . . . . . . .   5
   4.  Extension to PCEP . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  SVEC Object . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Minimize Shared Domains . . . . . . . . . . . . . . . . .   7
     4.3.  Relationship between SVEC Diversity Flags and OF  . . . .   7
   5.  Other Considerations  . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Transit Domain Identifier . . . . . . . . . . . . . . . .   8
     5.2.  Diversity v/s Optimality  . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
     7.1.  Control of Function and Policy  . . . . . . . . . . . . .   9
     7.2.  Information and Data Models . . . . . . . . . . . . . . .   9
     7.3.  Liveness Detection and Monitoring . . . . . . . . . . . .   9
     7.4.  Verify Correct Operations . . . . . . . . . . . . . . . .   9
     7.5.  Requirements On Other Protocols . . . . . . . . . . . . .   9
     7.6.  Impact On Network Operations  . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The ability to compute shortest constrained TE LSPs in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
   multiple domains has been identified as a key requirement.  In this
   context, a domain is a collection of network elements within a common
   sphere of address management or path computational responsibility



Dhody, et al.           Expires November 18, 2017               [Page 2]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   such as an Interior Gateway Protocol (IGP) area or an Autonomous
   Systems (AS).

   In a multi-domain environment, Domain Diversity is defined in
   [RFC6805].  A pair of paths are domain-diverse if they do not
   traverse any of the same transit domains.  Domain diversity may be
   maximized for a pair of paths by selecting paths that have the
   smallest number of shared domains.  Path computation should
   facilitate the selection of domain diverse paths as a way to reduce
   the risk of shared failure and automatically helps to ensure path
   diversity for most of the route of a pair of LSPs.

   The main motivation behind domain diversity is to avoid fate sharing,
   but it can also be because of some geo-political reasons and
   commercial relationships that would require domain diversity.  for
   example, a pair of paths should choose different transit Autonomous
   System (AS) because of some policy considerations.

   In case when full domain diversity could not be achieved, it is
   helpful to minimize the common shared domains.  Also it is
   interesting to note that other scope of diversity (node, link, SRLG
   etc) can still be applied inside the common shared domains.

   This document examine a way to achieve domain diversity with existing
   inter-domain path computation mechanism like per-domain path
   computation technique [RFC5152], Backward Recursive Path Computation
   (BRPC) mechanism [RFC5441] and Hierarchical PCE [RFC6805].  This
   document also considers synchronized as well as non-synchronized
   dependent path computations.  Since independent and synchronized path
   computation cannot be used to apply diversity, it is not discussed in
   this document.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   The terminology is as per [RFC5440].

3.  Domain Diversity

   As described in [RFC6805], a set of paths are considered to be domain
   diverse if they do not share any transit domains, apart from ingress
   and egress domains.




Dhody, et al.           Expires November 18, 2017               [Page 3]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   Some additional parameters to consider would be -

   Minimize shared domain:  When a fully domain diverse path is not
      possible, PCE could be requested to minimize the number of shared
      transit domains.  This can also be termed as maximizing partial
      domain diversity.  Other scope of diversity (node, link, SRLG etc)
      can still be applied inside the common shared domains.

   Boundary Nodes:  Diversity in boundary node selection can be achieved
      by node diversity.

3.1.  Per Domain Path Computation

   The per domain path computation technique [RFC5152] defines a method
   where the path is computed during the signaling process (on a per-
   domain basis).  The entry Boundary Node (BN) of each domain is
   responsible for performing the path computation for the section of
   the LSP that crosses the domain, or for requesting that a PCE for
   that domain computes that piece of the path.

   Non-Synchronized Path Computation:  Path computations are performed
      in a serialized and independent fashion.  After the setup of
      primary path, a domain diverse path can be signaled by encoding
      the transit domain identifiers in exclude route object (XRO) or
      explicit exclusion route subobject (EXRS) using domain sub-objects
      defined in [RFC7898] and [RFC3209] in RSVP-TE.  Note that the head
      end LSR should be aware of transit domain identifiers of the
      primary path to be able to do so.  Also a head end label switching
      router (LSR) can signal a path by using a domain diverse domain
      sequence known in priori and encoded in explicit route object
      (ERO) in path message.

   Synchronized Path Computation:  Not Applicable.

3.2.  Backward-Recursive PCE-based Computation

   The BRPC [RFC5441] technique involves cooperation and communication
   between PCEs in order to compute an optimal end-to-end path across
   multiple domains.  The sequence of domains to be traversed maybe
   known before the path computation, but it can also be used when the
   domain path is unknown and determined during path computation.

   Non-Synchronized Path Computation:  Path computations are performed
      in a serialized and independent fashion.  After the path
      computation of the primary path, a domain diverse path computation
      request is sent by PCC to the PCE, by encoding the transit domain
      identifiers in XRO or EXRS using domain sub-objects defined in
      [RFC7897] and [RFC3209] in PCEP.  Note that the PCC should be



Dhody, et al.           Expires November 18, 2017               [Page 4]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


      aware of transit domain identifiers of the primary path to be able
      to do so.  Also a PCC can request a path by using a domain diverse
      domain sequence known in priori and encoded in include route
      object (IRO) in path request message.

   Synchronized Path Computation:  Not Applicable.  [Since different
      transit domain PCEs may be involved , there is difficulty to
      achieve synchronization for domain diverse path computation].
      Note that [RFC5440] describes other diversity parameters (node,
      link, SRLG etc) that may be applied.

3.3.  Hierarchical PCE

   In H-PCE [RFC6805] architecture, the parent PCE is used to compute a
   multi-domain path based on the domain connectivity information.  The
   parent PCE may be requested to provide a end to end path or only the
   sequence of domains.

3.3.1.  End to End Path

   Non-Synchronized Path Computation:  Path computations are performed
      in a serialized and independent fashion.  After the path
      computation of the primary path, a domain diverse path computation
      request is sent to the parent PCE, by encoding the transit domain
      identifiers in XRO or EXRS using domain sub-objects defined in
      [RFC7897] and [RFC3209] in PCEP.  Note that the PCC should be
      aware of transit domain identifiers of the primary path to be able
      to do so.  The parent PCE should provide a domain diverse end to
      end path.

   Synchronized Path Computation:  Child PCE should be able to request
      dependent and synchronized domain diverse end to end paths from
      its parent PCE.  A new flag is added in synchronized vector (SVEC)
      object for this (Refer Section 4.1).

3.3.2.  Domain-Sequence

   Non-Synchronized Path Computation:  Path computations are performed
      in a serialized and independent fashion.  After the primary path
      computation using H-PCE (involving domain-sequence selection by
      parent PCE and end-to-end path computation via BRPC or Per-Domain
      mechanisms), a domain diverse path computation request is sent to
      the parent PCE, by encoding the transit domain identifiers in XRO
      or EXRS using domain sub-objects defined in [RFC7897] and
      [RFC3209] in PCEP.  Note that the PCC should be aware of transit
      domain identifiers of the primary path to be able to do so.  The
      parent PCE should provide a diverse domain sequence.




Dhody, et al.           Expires November 18, 2017               [Page 5]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   Synchronized Path Computation:  Child PCE should be able to request
      dependent and synchronized diverse domain-sequence(s) from it's
      parent PCE.  A new flag is added in SVEC object for this (Refer
      Section 4.1).  The parent PCE should reply with diverse domain
      sequence(s) encoded in ERO as described in [RFC7897].

4.  Extension to PCEP

   [Editor's Note: It has been requested to move this section to the
   HPCE-Extension document - draft-ietf-pce-hierarchy-extensions.  This
   section would be removed from this document once that is done.]

4.1.  SVEC Object

   [RFC5440] defines SVEC object which includes flags for the potential
   dependency between the set of path computation requests (Link, Node
   and SRLG diverse).  This document proposes a new flag O for domain
   diversity.

   The format of the SVEC object body is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Reserved    |                   Flags           |O|P|D|S|N|L|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Request-ID-number #1                      |
      //                                                             //
      |                     Request-ID-number #M                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: SVEC Body Object Format

   Following new bit is added in the Flags field:

   * O (Domain diverse) bit:  when set, this indicates that the computed
      paths corresponding to the requests specified by the following RP
      objects MUST NOT have any transit domain(s) in common.

   The Domain Diverse O-bit can be used in Hierarchical PCE path
   computation to compute synchronized domain diverse end to end path or
   diverse domain sequences as described in Section 3.3.

   When domain diverse O bit is set, it is applied to the transit
   domains.  The other bit in SVEC object (N, L, S etc) is set, should
   still be applied in the ingress and egress domain.





Dhody, et al.           Expires November 18, 2017               [Page 6]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


4.2.  Minimize Shared Domains

   In case when full domain diversity could not be achieved, it maybe
   helpful to minimize the common shared domains.  It's interesting to
   note that diversity (node, link etc) can still be applied inside the
   common shared transit domains as well as for ingress and egress
   domain via the bits in SVEC object (N, L, S etc).

   A new Objective function (OF) [RFC5541] code for synchronized path
   computation requests is proposed:

   MCTD

   *  Name:  Minimize the number of Common Transit Domains.

   *  Objective Function Code:  TBD

   *  Description:  Find a set of paths such that it passes through the
      least number of common transit domains.

   The MCTD OF can be used in Hierarchical PCE path computation to
   request synchronized domain diverse end to end paths or diverse
   domain sequences as described in Section 3.3.

   [Editor's Note: A new document is created for the OF for minimizing
   shared node, links, SRLGs inside the domain -
   [I-D.dhody-pce-of-diverse].]

   For non synchronized diverse domain path computation the X bit in XRO
   or EXRS [RFC5521] sub-objects can be used, where X bit set as 1
   indicates that the domain specified SHOULD be excluded from the path
   computed by the PCE, but MAY be included subject to PCE policy and
   the absence of a viable path that meets the other constraints and
   excludes the domain.

4.3.  Relationship between SVEC Diversity Flags and OF

   [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe
   the potential disjointness between the set of path computation
   requests used in PCEP protocol.  This document further extends by
   adding domain-diverse O-bit in SVEC object and a new OF Code for
   minimizing the number of shared transit domain.

   Further [I-D.dhody-pce-of-diverse] defines three new OF codes to
   maximize diversity as much as possible, in other words, minimize the
   common shared resources (Node,Link or SRLG) between a set of paths.





Dhody, et al.           Expires November 18, 2017               [Page 7]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   It may be interesting to note that the diversity flags in the SVEC
   object and OF for diversity can be used together.  Some example of
   usage are listed below -

   o  SVEC object with domain-diverse bit=1 - ensure full domain-
      diversity.

   o  SVEC object with domain-diverse bit=1 and node/link diverse bit=1
      - ensure full domain-diversity, as well as node/link diverse in
      ingress and egress domain.

   o  SVEC object with domain-diverse bit=0 and OF=MCTD - domain-
      diversity as much as possible.

   o  SVEC object with domain-diverse bit=0;node/link diverse bit=1 and
      OF=MCTD - domain-diversity as much as possible, as well as node/
      link diverse in ingress, egress and shared transit domains.

   o  SVEC object with domain-diverse bit=1 and OF=MCTD - ensure full
      domain-diversity.

5.  Other Considerations

5.1.  Transit Domain Identifier

   In case of non-synchronized path computation, Ingress node (i.e. a
   PCC) should be aware of transit domain identifiers of the primary
   path.  So during the path computation or signaling of the primary
   path, the transit domain should be identified.

   A possible solution for path computation could be a flag in RP object
   requesting domain identifier to be returned in the PCEP path reply
   message.

   [Editor's Note: There should be a mechanism in signaling and path
   computation to obtain the domain information.  Further details - TBD]

5.2.  Diversity v/s Optimality

   In case of non-synchronized path computation, PCE may be requested to
   provide an optimal primary path first and then PCC requests for a
   backup path with exclusion.  Note that this approach does not
   guarantee diversity compared to disjoint path computations for
   primary and backup path in a synchronized manner.

   A synchronized path computation with diversity flags and/or objective
   function is used to make sure that both the primary path and the
   backup path can be computed simultaneously with full diversity or



Dhody, et al.           Expires November 18, 2017               [Page 8]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   optimized to be as diverse as possible.  In the latter case we may
   sacrifice optimal path for diversity, thus there is a trade-off
   between the two.

   An implementation may further choose to analyze the trade-off i.e. it
   may send multiple request to PCE asking to optimize based on
   diversity as well as say, cost and make an intelligent choice between
   them.

6.  Security Considerations

   This document add a new bit to SVEC object and define a new object
   function.  The security of the procedures described in this document
   depends on PCEP [RFC5440].  [RFC6007] describe security
   considerations when SVEC are supported.

7.  Manageability Considerations

7.1.  Control of Function and Policy

   In addition to [RFC5440], the PCC should construct the SVECs to
   identify and associate domain diverse SVEC relationships.
   Considerations for use of objective functions are mentioned in
   [RFC5541].

7.2.  Information and Data Models

   The PCEP MIB Module defined in [RFC7420], there are no additional
   parameters identified in this document.

7.3.  Liveness Detection and Monitoring

   The domain-diverse path computation in this document allows PCEs to
   compute optimal sets of diverse paths.  This type of path computation
   and cooperation may require more time to obtain its results.
   Therefore, it is recommended for PCEP to support the PCE monitoring
   mechanism specified in [RFC5886].

7.4.  Verify Correct Operations

   [RFC5440] provides a sufficient description for this document.  There
   are no additional considerations.

7.5.  Requirements On Other Protocols

   There should be a mechanism in signaling and path computation to
   obtain the domain information during primary path computation.
   Details to be added in future revision.



Dhody, et al.           Expires November 18, 2017               [Page 9]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


7.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440] and
   [RFC6007].

8.  IANA Considerations

   TBD.

9.  Acknowledgments

   We would like to thank Qilei Wang for starting this discussion in the
   mailing list.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5152]  Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
              Per-Domain Path Computation Method for Establishing Inter-
              Domain Traffic Engineering (TE) Label Switched Paths
              (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
              <http://www.rfc-editor.org/info/rfc5152>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <http://www.rfc-editor.org/info/rfc5441>.

   [RFC6007]  Nishioka, I. and D. King, "Use of the Synchronization
              VECtor (SVEC) List for Synchronized Dependent Path
              Computations", RFC 6007, DOI 10.17487/RFC6007, September
              2010, <http://www.rfc-editor.org/info/rfc6007>.





Dhody, et al.           Expires November 18, 2017              [Page 10]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <http://www.rfc-editor.org/info/rfc6805>.

10.2.  Informative References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
              2009, <http://www.rfc-editor.org/info/rfc5521>.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <http://www.rfc-editor.org/info/rfc5541>.

   [RFC5886]  Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
              Monitoring Tools for Path Computation Element (PCE)-Based
              Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
              <http://www.rfc-editor.org/info/rfc5886>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <http://www.rfc-editor.org/info/rfc7420>.

   [RFC7897]  Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
              for the Path Computation Element Communication Protocol
              (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016,
              <http://www.rfc-editor.org/info/rfc7897>.

   [RFC7898]  Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
              "Domain Subobjects for Resource Reservation Protocol -
              Traffic Engineering (RSVP-TE)", RFC 7898,
              DOI 10.17487/RFC7898, June 2016,
              <http://www.rfc-editor.org/info/rfc7898>.






Dhody, et al.           Expires November 18, 2017              [Page 11]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   [I-D.dhody-pce-of-diverse]
              Dhody, D. and Q. Wu, "PCE support for Maximizing
              Diversity", draft-dhody-pce-of-diverse-06 (work in
              progress), October 2016.















































Dhody, et al.           Expires November 18, 2017              [Page 12]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


Appendix A.  Contributor Addresses

   Ramon Casellas
   CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
   Av. Carl Friedrich Gauss n7
   Castelldefels, Barcelona  08860
   Spain

   EMail: ramon.casellas@cttc.es

   Avantika
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: s.avantika.avantika@gmail.com

Authors' Addresses

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com


   Qin Wu
   Huawei Technologies
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   EMail: bill.wu@huawei.com


   Udayasree Palle
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: udayasreereddy@gmail.com






Dhody, et al.           Expires November 18, 2017              [Page 13]

Internet-Draft               DOMAIN-DIVERSE                     May 2017


   Xian Zhang
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R.China

   EMail: zhang.xian@huawei.com












































Dhody, et al.           Expires November 18, 2017              [Page 14]