[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

IDR Working Group                                                L. Chan
Internet-Draft                                          R. Szarecki, Ed.
Intended status: Standards Track                        Juniper Networks
Expires: January 8, 2020                                    July 7, 2019


Inter-Domain Traffic Steering with BGP Labeled Colored Unicast (BGP-LCU)
             draft-szarecki-idr-bgp-lcu-traffic-steering-00

Abstract

   This document describes technology that enables for Inter-Domain
   signaling of existence of E2E path that satisfy high-level traffic
   treatment behavior intent.  The inter-domain path is built by the BGP
   protocol, as a concatenation of per TE-domain internal paths
   (segments), provisioned by one of existing intra-domain techniques.
   The traffic treatment behavior is encoded as an integer value called
   as "COLOR".  The domain internal paths/tunnels are marked as
   satisfying given traffic treatment behavior.  Then the tunnel
   destination and its COLOR are exchanged between TE-Domains using a
   new BGP LABELED-COLORED-UNICAST NLRI (BGP-LCU) defined in this
   document.

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 https://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 January 8, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Chan & Szarecki          Expires January 8, 2020                [Page 1]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Traffic treatment behavior intent (T-intent)  . . . . . . . .   5
     3.1.  COLOR . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  COLOR name spaces . . . . . . . . . . . . . . . . . . . .   6
   4.  Scaling Consideration . . . . . . . . . . . . . . . . . . . .   6
   5.  BGP labeled-colored-unicast NLRI  . . . . . . . . . . . . . .   6
     5.1.  BGP capability negotiation  . . . . . . . . . . . . . . .   6
     5.2.  BGP UPDATE message MP_REACH_NLRI  . . . . . . . . . . . .   7
     5.3.  BGP explicit  WITHDRAWN message . . . . . . . . . . . . .   9
     5.4.  Some BGP attribute considerations . . . . . . . . . . . .  10
       5.4.1.  BGP Next-Hop  . . . . . . . . . . . . . . . . . . . .  10
       5.4.2.  Prefix SID  . . . . . . . . . . . . . . . . . . . . .  10
       5.4.3.  Color Extended Community  . . . . . . . . . . . . . .  10
       5.4.4.  Tunnel encapsulation  . . . . . . . . . . . . . . . .  10
   6.  BGP operation . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Injection of labeled colored unicast route to BGP . . . .  11
       6.1.1.  Injecting from colored routes . . . . . . . . . . . .  11
       6.1.2.  Injections from non-colored labeled routes  . . . . .  13
       6.1.3.  Injections from non-colored non-labeled routes  . . .  13
     6.2.  Receiving BGP-LCU from eBGP (single hop)  . . . . . . . .  14
     6.3.  Receiving BGP-LCU from iBGP or multihop-eBGP  . . . . . .  14
     6.4.  Advertising BGP-LCU over eBGP session and iBGP session
           with BGP NH changed (NH-self) . . . . . . . . . . . . . .  15
     6.5.  Advertising BGP-LCU over iBGP session when BGP NH remain
           unchanged.  . . . . . . . . . . . . . . . . . . . . . . .  15
     6.6.  Label value assignment procedure  . . . . . . . . . . . .  16
   7.  Deployment and Operation Consideration  . . . . . . . . . . .  16
     7.1.  Building label stack  . . . . . . . . . . . . . . . . . .  16
       7.1.1.  Purpose of multiple-label stack . . . . . . . . . . .  16
       7.1.2.  Ingress recursive resolution  . . . . . . . . . . . .  17
     7.2.  Handling BGP-LCU ingress PEs with limited label
           imposition depth capabilities . . . . . . . . . . . . . .  19
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  20
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21



Chan & Szarecki          Expires January 8, 2020                [Page 2]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


     11.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The networks of today grow to high 10,000's - 100,000's of nodes
   (routers) and beyond.  This trend continues.  To operate such a large
   topology, the common practice is to divide it into domains (see
   Figure 1) and integrate through layered routing protocol
   infrastructure in order to secure end-to-end (E2E) connectivity.
   Please see [I-D.ietf-mpls-seamless-mpls].

   The nowadays critical and demanding applications rely on network
   infrastructure, and plain connectivity becomes an insufficient
   service level.

   While the Differentiated Services architecture [RFC2475] allows for
   multiple service levels across same connectivity path, it does not
   address topological differentiation such as latency, non-fate-
   sharing, encryption or bandwidth.  These challenges are addressed by
   existing Traffic Engineering (TE)techniques such RSVP, SR-TE or
   multi-topology IGPs (e.g.  Maximally Redundant Tree [RFC7811],
   Segment Routing IGP FlexAlgo [I-D.ietf-lsr-flex-algo])in the scope of
   a limited size domain (TE-DOMAIN).

   This document describes technology that enables signaling of
   existence of E2E path that satisfy high-level traffic treatment
   behavior intent.  The inter-domain path is built by the BGP protocol,
   as a concatenation of per TE-domain internal paths (segments),
   provisioned by one of existing intra-domain techniques mentioned
   above.  This way, inter-domain paths for a variety of traffic
   treatment intents are established without even need to expose the
   topology of any domain to any of the other domains.


















Chan & Szarecki          Expires January 8, 2020                [Page 3]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


                     BGP
   <-----------><-----------><--><--------->

   +-----------+ +----------+    +---------+
   |domain 1   | |  domain 2|----|domain 3 |
   |(e.g.      .-.     (e.g.|  /-|  (e.g.  |
   |FlexAlgo) ( R )    RSVP)|-/  |  SR-TE  |
   |           `-'          |----| w/ PCE) |
   +-----------+ +----------+    +---------+

   <--------->    <--------->    <--------->
   TE-domain      TE-domain      TE-domain
   <-------- cooperating domains ---------->

                          Cooperating TE-domains

                                 Figure 1

   The traffic treatment behavior (T-intent) is encoded as an integer
   value called as "COLOR".  The TE-domain internal paths/tunnels are
   marked as satisfying given traffic treatment behavior as defined in
   Segment Routing Policy Architecture
   [I-D.ietf-spring-segment-routing-policy].  Then reachability of the
   tunnel destination and its COLOR are exchanged between TE-Domains
   using a new BGP LABELED-COLORED-UNICAST NLRI (BGP-LCU) defined in
   this document.  The procedures of stitching/nesting intra domain
   tunnels advertised in BGP-LCU resulting in inter-domain E2E path is
   also specified 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 RFC 2119 [RFC2119].

2.  Conventions used in this document

   TE-DOMAIN - Continuous set of links and nodes that allow establishing
   tunnels that satisfy T-intent between each edge node without using
   BGP-LCU (defined in this document).  Typically TE-domain is 1:1
   mapped to IGP area (flooding domain),and intra-TE-domain tunnels are
   instantiated by RSVP (w/ or w/o assistance of PCE), SR/SRv6 w/ IGP
   FlexAlgo, static or PCE controlled SRTE/SRv6TE policies.  A
   deployment when TE-domain comprises few connected IGP flooding
   domains is also possible.

   COLOR - the integer value of 32bits representing given traffic
   treatment behavior intent (T-intent).



Chan & Szarecki          Expires January 8, 2020                [Page 4]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   BGP-LCU - BGP Labeled Colored Unicast.  Name given to SAFI(s) that
   carries traffic treatment intent toward destination system together
   with label(s)used to forward traffic across TE-DOMAINS.  Defined in
   this document.

   <COLOR,DESTINATION> - colored BGP-LCU prefix, where COLOR is integer
   encoding traffic treatment intent and DESTINATION is IPv4 or IPv6
   subnet address (not necessary host address).

   [Label1,Label2,<COLOR,DESTINATION>] - notation used for the labeled
   colored unicast NLRI

   SR-DOMAIN - continuous set of nodes and links that support SR and
   have at minimum single, shared prefix SID space.  So, prefix SID
   (incl.  Node SID and Anycast SID) values are unique in SR-DOMAIN.

   BSID - Binding SID.  The local label allocated for TE tunnel (RSVP-
   LSP, SR Policy, etc)

3.  Traffic treatment behavior intent (T-intent)

   The service traffic, while traversing network(s) consumes resources
   from those networks.  The path provided by network to service traffic
   could be optimized according to needs of the service.  A simple
   example is a real-time communication application that would benefit
   from being placed on low-latency path.  On the other hand, video
   streaming would best benefit from a low-loss path.  Another example
   is sensitive data like personal health data, which would benefit from
   a taking path over encrypted links.

   It is granted that ability of network to provide distinct path
   (tunnels) that satisfy treatment intended by application (or class of
   application) would provide best possible balance between application
   performance and network resource utilization.

   The T-intent is high-level description of traffic treatment.
   Examples of T-intent are: "low-latency transport", "transport over
   encrypted infrastructure", "transport path that is topologically
   disjoined then other path", "transport path over encrypted links/
   segments", etc.  It is up to the discretion of the network operator
   (or co-operating operators) to define a set of T-intents that have
   sense for them.

3.1.  COLOR

   The T-intents defined by operator are encoded in control plane as
   32-bit integer value called COLOR, in such way that color-to-T-intent
   mapping is of monotonic.  Therefore, based on COLOR value the



Chan & Szarecki          Expires January 8, 2020                [Page 5]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   T-intent could be identified without ambiguity.  The designation and
   mapping of COLOR value used for inter-domain operation to T-intent
   requires agreement of all operators of cooperating domains.

   COLOR value of zero (0x00000000) is restricted and MUST NOT be used.

3.2.  COLOR name spaces

   The concept of COLOR as defined above is not specific to inter-domain
   network slicing, and it actually was introduced in
   [I-D.ietf-spring-segment-routing-policy] and is used by SR-TE and SR
   IGP FlexAlgo (called there algorithm) in scope of single TE-domain.

   Authors recognizes possibility that color-code values used inside
   given TE-domain may be not the same as agreed between TE-domains.
   Furthermore, it is possible that same color value is mapped to
   different T-intents inside TE-domain and for inter-TE-domain context.

   It is recommended for network designers to adjust both color-code
   schemas to be identical in order to simplify operation.  It is
   assumed in this specification, that color-code schema used for inter-
   TE-domain as well in each TE-domain is identical

4.  Scaling Consideration

   The BGP-LCU path scale grow with product of number of COLORS
   supported by multi-domain network system and number of DESTINATIONS
   in this system.  It become obvious that for some network there is a
   risk of exhausting available MPLS label space.

   For large deployments, stacking of labels would be necessary to
   achieve desired scalability.

5.  BGP labeled-colored-unicast NLRI

   This document defines new SAFI for labeled, colored, unicast (IPv4
   and IPv6), and corresponding BGP NLRI that carries label(s) sequence
   binding to colored prefix - the <COLOR,DESTINATION> tuple.  The SAFI
   value is [[TBD]].

   For easy reading BGP instance/session supporting above new SAFI, we
   will reference it as "BGP-LCU" (Labeled-Colored-Unicast).

5.1.  BGP capability negotiation

   In addition to AFI/SAFI negotiation on the opening of BGP session, in
   order to send NLRI with more than one label on stack the Multiple
   Labels Capability (MLC) MUST be successfully negotiated for the



Chan & Szarecki          Expires January 8, 2020                [Page 6]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   session in order to carry multiple label sequence in BGP-LCU NLRI.
   If MLC is not negotiated or negotiation failed, BGP-LCU NLRI MUST
   carry only one label.

   The Multiple Labels Capability is defined in chapter 2.1 of BGP
   Labeled Unicast [RFC8277].  The BGP speaker supporting BGP-LCU MUST
   follow procedure defined there.

   Implementation SHOULD send withdraw of <COLOR,DESTINATION> if length
   of labels sequence in (to be advertised) NLRI would exceed peers
   capability.

5.2.  BGP UPDATE message MP_REACH_NLRI

   The procedure described in BGP Labeled Unicast[RFC8277] is used to
   encode the <COLOR,DESTINATION> tuple as prefix into NLRI with
   exception of NLRI length field.  The Length field is encoded in one
   or two octets, in order to accommodate large sequence of labels.  The
   Length field encoding follows BGP FlowSpec [RFC5575] encoding of
   length.

   The <COLOR,DESTINATION> tuple form colored-IPv4 or colored-IPv6
   prefix.  The new sub-address family of SAFI [[TBD]] is allocated for
   labeled <COLOR,DESTINATION>.  The AFI 1 and 2 are used for
   destination of IPv4 and IPv6 families respectively.  The NLRI
   structure of SAFI [[TBD]] is shown below on Figure 2 for single label
   and Figure 3 for multiple labels (note: the color and destination
   elements of prefix are shown explicitly).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |                 Label                 |Rsrv |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          color                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       destination                             ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           NLRI with One Label.

                                 Figure 2








Chan & Szarecki          Expires January 8, 2020                [Page 7]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length(1 or 2 octetx) ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Label                 |Rsrv |S~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                 Label                 |Rsrv |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          color                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       destination                             ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                NLRI encoding with more then one label bind

                                 Figure 3

   o  Length: The Length field consists of a single or two octets.  It
      specifies the length in bits of the remainder of the NLRI field.
      Note that for each label, the length is increased by 24 bits.  The
      length of color is fixed and is always 32bits.  In an
      MP_REACH_NLRI attribute whose AFI/SAFI is 1/[[TBD]], the length of
      destination element of prefix will be 32 bits or less.  In an
      MP_REACH_NLRI attribute whose AFI/SAFI is 2/[[TBD]], the length of
      destination element of prefix will be 128 bits or less.  For NLRI
      shorter than 240 bits (30 octets) the Length is encoded is single
      octet.  For NLRI of 240 bits or longer, two octets are used and
      the firs nibble is set to value 0xF.  Therefore, maximum size of
      NLRI is 4095b.See [RFC5575].  As specified in MP-BGP [RFC4760],
      the actual length of the NLRI field will be the number of bits
      specified in the Length field rounded up to the nearest integral
      number of octets.

   o  Label: The Label field is a 20-bit field containing an MPLS label
      value (see MPLS Label Encoding [RFC3032]).  The null labels
      (values: 0, 2, 3) are allowed only as last label (or as only
      labels) in NLRI.

   o  Rsrv: This 3-bit field SHOULD be set to zero on transmission and
      MUST be ignored on reception.

   o  S: In all labels except the last (i.e., in all labels except the
      one immediately preceding the prefix), the S bit MUST be 0.  In
      the last label, the S bit MUST be 1.  Note that failure to set the
      S bit in the last label will make it impossible to parse the NLRI
      correctly.  See Section 3, paragraph j of Revised Error Handling



Chan & Szarecki          Expires January 8, 2020                [Page 8]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


      for BGP UPDATE Messages [RFC7606] for a discussion of error
      handling when the NLRI cannot be parsed.

   Note that the UPDATE message not only advertises the binding between
   the <COLOR,DESTINATION> and the label(s), it also advertises a path
   to the prefix via the node identified in the Next Hop field of the
   MP_REACH_NLRI attribute.

   If the procedures of BGP ADD-PATHs [RFC7911] are being used, a four-
   octet "path identifier" (as defined in Section 3 of [RFC7911]) is
   part of the NLRI and precedes the Length field.

5.3.  BGP explicit WITHDRAWN message

   The withdrawal methodology follows the one described in chapter 2.4
   of [RFC8277].  For convenience short description is given below.

   The label(s) binding to <COLOR,DESTINATION> could be explicitly
   withdrawn by sending BGP UPDATE message with MP_UNREACH_NLRI
   attribute.  The NLRI field of MP_UNREACH_NLRI is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |        Compatibility                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           color                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       destination                             ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            NLRI for Withdrawal

                                 Figure 4

   Where:

   o  Compatibility: Compatibility field SHOULD be set to 0x800000.
      Upon reception, the value of the Compatibility field MUST be
      ignored.

   If the procedures of [RFC7911] are being used, a four-octet "path
   identifier" (as defined in Section 3 of [RFC7911]) is part of the
   NLRI and precedes the Length field.






Chan & Szarecki          Expires January 8, 2020                [Page 9]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


5.4.  Some BGP attribute considerations

5.4.1.  BGP Next-Hop

   The next-hop network address field in LABELED-COLORED-UNICAST SAFI
   updates may be either a IPv4 address or a IPv6 address(es)
   independent of the LABELED-COLORED-UNICAST AFI.  This is in
   accordance to existing specfication in [RFC4760], MP-BGP for
   IPv6[RFC2545] and IPv4 NLRI with IPv6 Next-Hop[RFC5549]

5.4.2.  Prefix SID

   In the deployment when multiple TE-domains forms single SR-domain,
   and therefore prefix SIDs (incl.  Node SIDs and Anycast SIDs) are
   unique in entire multi-domain scope, BGP prefix SID attribute
   [I-D.ietf-idr-bgp-prefix-sid] may be attached to BGP-LCU NLRI, and
   SHOULD be honored.

   Implementation SHOULD allow for disabling prefixSID processing by
   local configuration, and in such case tread this attribute as
   unsupported (therefore advertised without modification, since BGP
   prefix SID attribute is of transitive optional type).  Implementation
   SHOULD allow, via local configuration, for removing BGP prefix SID
   attribute from BGP path.

5.4.3.  Color Extended Community

   The Color Extended Community, defined in Tunnel Encapsulation
   Attribute[I-D.ietf-idr-tunnel-encaps], MAY be attached to BGP-LCU
   NLRI.

   The purpose of attaching this community is to provide a hint to BGP-
   LCU update receiver on how BGP Next-Hop attribute shall be resolved.
   Giving such hint could be useful e.g. for case when colors values
   used for given T-intent for inter-domain and intra-domain contexts
   are not equal (see chapter 3.2. ).  Exact procedure to handle this
   case is out of scope of this specification.

   In order to avoid ambiguity and simplify implementation, it is
   recommended to do not attach more than one Color Extended Community.

5.4.4.  Tunnel encapsulation

   The tunnel encapsulation attribute (23)[I-D.ietf-idr-tunnel-encaps]
   SHOULD NOT be attached to BGP-LCU NLRI.

   If tunnel encapsulation attribute is attached, it MUST NOT conflict
   with intent of particular BGP path and its NLRI.



Chan & Szarecki          Expires January 8, 2020               [Page 10]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   It is recommended for implementation to not process this attribute
   and pass it, if needed, as unsupported optional transitive attribute.

6.  BGP operation

6.1.  Injection of labeled colored unicast route to BGP

6.1.1.  Injecting from colored routes

   The ingress border node (BN12)of given TE-domain (domain2 on
   Figure 5)is provisioned by means out of scope of this document with
   multiple colored tunnels to endpoints in this domain.

                +------------+   +----------------+   +---------+
                |           ++---+-+  domain 2  +-+---++        |
                |           |      |----red---->|      |        |
                |           | BN12 |----blue--->| BN2n |        |
                |  domain 1 |      |--blue--+   |      |        |
                |           |      |-red-+  |   |      |        |
                |           ++---+-+     |  |   +-+---++        |
                |            |   |       v  v     |   |domain N |
                |            |   |     +------+   |   |         |
                +------------+   +-----+ PE2  +---+   +---------+
                                       +------+

                       Injection form colored routes

                                 Figure 5

   The tunnel type is irrelevant for further discussion as long as MPLS
   frames can be encapsulated over it.  Tunnels could be of MPLS, MPLS-
   SR, SRv6, MPLSoUDP, etc.  Each of above tunnels has associated one or
   more intra-domain colors encoding traffic treatment provided by given
   tunnel, as per [I-D.ietf-spring-segment-routing-policy].

   The color-code schema used for Inter-domain is assumed to be the same
   as one used internally by TE-domain.

   Let assume following color schema for domain 2, domain 1 and Inter-
   domain as shown in Table 1.











Chan & Szarecki          Expires January 8, 2020               [Page 11]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


                          +------------+-------+
                          |            | COLOR |
                          +------------+-------+
                          | T-intent 1 |  red  |
                          | T-intent 2 |  blue |
                          +------------+-------+

          Table 1: COLOR code schema - intra- and inter-TE-domain

   The BGP speaker (BN12 in Figure 5 ) injects into BGP-LCU four routes
   with the NLRI fields and BGP attributes values as follow:

   o  NLRI DESTINATION := intra-domain tunnel destination IP prefix
      address (e.g.  IP of loopback of BN2n and PE2 in Figure 5).

   o  NLRI COLOR := the color code value for T-intent the original
      tunnel satisfy inside given domain (e.g. red or blue).

   o  Exactly one label of value derived according to procedure describe
      in chapter 6.6.  In this case this label MUST be non-null label.

   o  S:=1

   o  Length := 56 + length of tunnel destination prefix

   o  The BGP Next-Hop attribute is set to "self".

   Other BGP attributes may also be added as needed by network
   configuration.

   The BGP speaker may crates also MPLS forwarding entries for local
   label values advertised in NLRI of they do not exist previously.

   Please note:

   o  This operation does not create any IP RIB entry nor
      <COLOR,DESTINATION> RIB entry.

   o  This operation does not create any IP entry in FIB

   o  This operation may create one or more MPLS entry in FIB if needed.
      The entry's key would be local label allocated as described in
      chapter 6.6. and advertised in NLRI.  The associated action
      depends on tunnel type but could be generalized as popping label,
      pushing header(s) of tunnel given BGP route is originating form,
      forwarding trough egress interface of this tunnel.





Chan & Szarecki          Expires January 8, 2020               [Page 12]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


6.1.2.  Injections from non-colored labeled routes

   The injection of <COLOR,DESTINATION> into BGP from non-colored routes
   is similar to one from labeled colored routes, except there is no
   COLOR of original route to inherit.  Therefore, local configuration
   MUST provide COLOR value that is used for NLRI construction.

   o  Implementation MUST support specification of one or more COLOR(s)
      that would be used for all DESTINATIONS when injected to BGP as
      LABELED-COLORED-UNICAST NLRI (of SAFI [[TBD]]).  If multiple
      colors are specified, multiple NLRI is injected into BGP.

   o  Implementation MAY support specification of COLOR in dependency on
      (original) route destination, attributes and/or session on which
      given <COLOR,DESTINATION> are injected to BGP as LABELED-COLORED-
      UNICAST NLRI (of SAFI [[TBD]].

   Similarly, to case described in chapter 6.1.1. , label value MUST be
   non-null label.

   Please note:

   o  This operation does not create any IP RIB entry nor
      <COLOR,DESTINATION> RIB entry.

   o  This operation does not create any IP entry in FIB

   o  This operation creates one or more MPLS entry in FIB.  The entry's
      key would be local label allocated as described in chapter 6.6.
      and advertised in NLRI.  The associated action depends on tunnel
      type but could be generalized as popping label, pushing header(s)
      of tunnel given BGP route is originating form, forwarding trough
      egress interface of this tunnel.

6.1.3.  Injections from non-colored non-labeled routes

   The injection of <COLOR,DESTINATION> into BGP from non-labeled, non-
   colored routes is similar to one from labeled non-colored routes,
   except that explicit or implicit null label shall be used in
   advertisement.

   Please note:

   o  This operation does not create any IP RIB entry nor
      <COLOR,DESTINATION> RIB entry.

   o  This operation does not create any IP entry in FIB




Chan & Szarecki          Expires January 8, 2020               [Page 13]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   o  This operation does not create any MPLS entry in FIB, since
      explicit null labels are already pre-programmed in FIB.

6.2.  Receiving BGP-LCU from eBGP (single hop)

   The path for <COLOR,DESTINATION> received is experiencing normal BGP
   process - the sanity is checked first, then configured policies.
   Finally, path is installed in BGP Loc-RIB and path selection process
   kick in.  Since BGP Next Hop attribute value is IP address of
   connected subnet, it is used w/o further processing (resolution).

   Please note:

   o  This operation does create <COLOR,DESTINATION> entry in RIB.

   o  This operation does not create any IP RIB entry.

   o  This operation does not create any IP entry in FIB

   o  This operation does not create any MPLS entry in FIB

6.3.  Receiving BGP-LCU from iBGP or multihop-eBGP

   The path for <COLOR,DESTINATION> received is experiencing normal BGP
   process - the sanity is checked first, then configured policies.
   Finally, path is installed in BGP Loc-RIB and path selection process
   kick in.  Since BGP Next Hop attribute value is not a IP address of
   connected subnet, it needs to be resolved.  Since the intention is to
   provide continuous transport that satisfy T-intent encoded in COLOR,
   the intra-domain tunnel used for resolution need also satisfy this
   T-intent.  Therefore:

   1.  If BGP route for <COLOR,DESTINATION> is carrying Color Extended
       Community, The BGP NextHop attribute shall be resolved by tunnel
       of color carried in this community (which may be different then
       value of COLOR carried in NLRI.  See chapter 3.2.  above).
       Please see [I-D.ietf-spring-segment-routing-policy]

   2.  ElseIf BGP route for <COLOR,DESTINATION> is NOT caring Color
       Extended Community, The BGP NextHop attribute shall be resolved
       over tunnel of color equal to COLOR carried in NLRI

   The fallback to resolution over other tunnels - other color or non-
   colored - is subject of local configuration policy on the node and/or
   value of "CO" bits of Color Extended Community.

   Please note:




Chan & Szarecki          Expires January 8, 2020               [Page 14]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   o  This operation does create <COLOR,DESTINATION> entry in RIB.

   o  This operation does not create any IP RIB entry.

   o  This operation does not create any IP entry in FIB

   o  This operation does not create any MPLS entry in FIB

6.4.  Advertising BGP-LCU over eBGP session and iBGP session with BGP NH
      changed (NH-self)

   Whenever BGP path to <COLOR,DESTINATION> is re-advertised and BGP
   Next Hop attribute is changed, the label(s) portion of NLRI is
   modified.  On the Next-Hop-change the BGP speaker replaces all
   label(s) in NLRI by single local label.  The local label identifies
   <COLOR, DESTINATION>.  The value of local labels is derived as
   described in chapter 6.6.

   Any BGP speaker supporting LABELED-COLORED-UNICAST (SAFI=[[TBD]])
   MUST support above behavior on Next-hop-change.

   Please note:

   o  This operation does not create <COLOR,DESTINATION> entry in RIB.

   o  This operation does not create any IP RIB entry.

   o  This operation does not create any IP entry in FIB

   o  This operation may create or modify MPLS entry in RIB and FIB.

      *  New RIB and FIB entries are created if no label was allocated
         to <COLOR,DESTINATION> previously.

      *  The RIB and FIB entries are modified if given path is best and
         active. (or 2nd to best and BGP PIC EDGE is enabled)

      *  The RIB entry is modified if given path is best.

6.5.  Advertising BGP-LCU over iBGP session when BGP NH remain
      unchanged.

   Whenever BGP path to <COLOR,DESTINATION> is re-advertised but BGP
   Next-Hop attribute remains unchanged, the label(s) portion of NLRI
   MUST NOT be modified.






Chan & Szarecki          Expires January 8, 2020               [Page 15]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


6.6.  Label value assignment procedure

   The selection of local label value MUST follow below procedure.

   1.  If BGP speaker is provided (e.g. by local configuration) with
       explicit label value binding for given <COLOR, DESTINATION>, it
       SHOULD be honored and used.

   2.  If BGP speaker is injecting <COLOR,DESTINATION> into BGP-LCU from
       other protocol or family, and Binding SID (BSID) as per Segment
       Routing Architecture [RFC8402] is assigned to original tunnel,
       then local label SHOULD be set to be equal to BSID value.

   3.  If BGP path carries BGP prefix-SID attribute, and given BGP
       speaker is enabled to process this attribute (e.g. by mean of
       local configuration), then this BGP speaker SHOULD allocate local
       label form it's SRGB [RFC8402].

   4.  If, given BGP speaker has local label already allocated for given
       <COLOR, DESTINATION> as result of processing earlier routing
       events, this same value MUST be used.

   5.  Else, BGP speaker allocates label from free labels of it's
       dynamic label block.

   Please note that above procedure could result with local label value
   shared among multiple <COLOR,DESTINATION> prefixes, or unique label
   value for each <COLOR,DESTINATION>.  It depends on particular network
   scenario and both possibilities are valid and legitimate.

7.  Deployment and Operation Consideration

7.1.  Building label stack

7.1.1.  Purpose of multiple-label stack

   Due to potential large scale of colored prefixes, the BGP-LCU speaker
   may run out of label space, if 1:1 relationship between
   <COLOR:DESTINATION> and local label would be established.

   Sharing label among multiple <COLOR:DESTINATION> prefixes could be
   not always possible and reduction of needed labels is hard to predict
   and is changing together with intra-domain tunnels path changes.

   To predictably address this scaling challenge, the topmost label of
   packet incoming on ASBR/ABR shall represents immediate downstream
   intra-domain tunnel in the connected TE-domain rather than entire




Chan & Szarecki          Expires January 8, 2020               [Page 16]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   end-to-end path.  Consequently, ingress PE need to push appropriate
   label stack on outgoing data packets.

   This chapter describes how BGP-LCU could be configured and used on
   various nodes of multi-domain network system to instruct ingress PE
   to build and push label stack onto outgoing packets.

   If network scale, in terms of number of DESTINATIONS and COLORS, do
   not requires usage of label stack, it is perfectly valid design to
   simply swap label in NLRI on every domain border and use one label on
   ingress PE for inter-TE-domain tunnel.

7.1.2.  Ingress recursive resolution

   The Recursive resolution of BGP-LCU NH attributes on ingress PE
   provides ability to construct label stack and relief transit BGP
   speakers (ASBRs and ABRs)label space pressure.  Recursive resolution
   is matter of network design and ingress PE capability and is
   inherently supported by BGP-LCU.

   The below description is provided to the reader for convenience.

   To provide ingress PE with sufficient information for building and
   pushing label stack onto packet, in addition to signal path for every
   <COLOR,EGRESS-PE> combination, would require signaling (in BGP-LCU)
   also path for <COLOR,ASBR/ABR> combination.  Please note that
   typically number of ASBRs/ABRs is two or three orders of magnitude
   lower than PEs.  Also, note that if given node is ASBR and PE, is
   should not be double-counted.  Therefor impact on BGP-LCU path scale
   is expected to be < 1%. and therefore negligible.

   Please note that when BGP-LCU path is re-advertised to another BGP-
   LCU session, BGP Next-Hop attribute is changed, or not, according to
   following rules.  This rules do not represent default BGP behavior
   but could be implemented via local configuration of BGP speaker.

   1.  If path is advertised to eBGP and has AS-PATH empty, then BGP
       Next-Hop attribute MUST be changed.  This is default BGP
       behavior.

   2.  If path is learned from eBGP from AS that originated
       <COLOR,DESTINATION> prefix (is last on AS-PATH), then Next-Hop
       attribute should be changed.  This is observed common practice to
       change BGP Next-Hop attribute to self in this scenario.

   3.  In every other case, including re-advertising to eBGP sessions,
       BGP-LCU Next-Hop attribute, and consequently label(s) sequence in
       NLRI, should stay unmodified.



Chan & Szarecki          Expires January 8, 2020               [Page 17]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   Example below (Figure 6) shows BGP-LCU update flow across domains.
   The BGP Next-Hop attribute manipulation and resolution are also shown
   in Table 2.  Finally, MPLS FIB entries are also displayed.

   <-------AS 1-------->   <---AS 2--->  <---AS 3--->
     +------+ +------+        +------+      +------+
     |domain| |domain|        |domain|      |domain|
    .+. 1   .-.  2   .-.    .-.  3 .-.    .-.  3  .+.
   ( I )   ( A )    ( B )--( C )  ( D )--( E )   ( Z )
    '+'     '-'      '-'    '-'    '-'    '-'     '+'
     +------+ +------+        +------+      +------+

                  Label stack build on ingress - topology

                                 Figure 6

   The Table 2 below, shows flow BGP-LCU Updates for DESTINATION "I"

            +------+----+----------------+--------+-----------+
            | From | to |      NLRI      | BGP NH |  AS-path  |
            +------+----+----------------+--------+-----------+
            |  A   | B  | [L1 ,<red,I>]  |   A    |           |
            |  B   | C  | [L1' ,<red,I>] |   B    |   [AS1]   |
            |  C   | D  | [L1",<red,I>]  |   C    |   [AS1]   |
            |  D   | E  | [L1" ,<red,I>] |   C    | [AS1 AS2] |
            |      |    | [L2 ,<red,C>]  |   E    |   [AS2]   |
            |  E   | Z  | [L1",<red,I>]  |   C    | [AS1 AS2] |
            |      |    | [L2',<red,C>]  |   E    |   [AS2]   |
            +------+----+----------------+--------+-----------+

          Table 2: COLOR code schema - intra- and inter-TE-domain

   The Table 3 below shows RIB entry on node "Z" after recursive
   resolution

   +------------+-----------------------------------+------------------+
   | Prefix/key |          encap. operation         | egress interface |
   +------------+-----------------------------------+------------------+
   |  <red,I>   | push: L1", L2', [red-tunnel-to-E] |        X         |
   +------------+-----------------------------------+------------------+

              Table 3: Ingress label stack build - RIB entry

   Please note that ASBRs "D" and "E" do not modify BGP Next-Hop
   attribute for prefix <red,I>, therefore no label is changed.
   Consequently there is no MPLS FIB entry created for this prefix.





Chan & Szarecki          Expires January 8, 2020               [Page 18]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   The above described method allows to build label stack on ingress PE,
   thus address high scale of <COLOR,DESTINATION> prefix while reducing
   data-plane states on domains border nodes.

7.2.  Handling BGP-LCU ingress PEs with limited label imposition depth
      capabilities

   The consequence of design in which inter-domain tunnel is represented
   as multiple labels stack, is that ingress PE would need to push even
   more labels onto the packet:

   1.  service label,

   2.  perhaps ELI/EL or FAT label(s)

   3.  sequence of labels for inter-domain tunnel (learned form BGP-LCU
       and recursively resolved as per chapter 7.1. above)

   4.  and finally, sequence of one or more labels used by given ingress
       PE to reach egress ASBR/ABR while satisfying T-intent.  The
       sequence of label could be significantly long if SRTE policy is
       used.

   Authors of this document acknowledges that currently there is
   equipment in field and in development, that have limited capability
   in pushing deep label stack (Legacy-PE).

   To support such devices in ingress role, egress ASBR/ABR (node "E" on
   Figure 6) of ingress TE-DOMAIN comprising such PE (node "Z" on
   Figure 6)have to "reduce" stack depth.

   Provided that egress ASBR (node "E") learns all BGP-LCU
   <COLOR,DESTINATION> prefixes (e.g from Route Server), it advertises
   this BGP-LCU path to iBGP session toward (set of) ingress Legacy-PE,
   with BGP Next-Hop attribute change to self.  As result, path would be
   re-advertised with only one label.  This reduce required label push
   depth on legacy ingress PE.

   In the very high scale environment, by doing above, egress ASBR/ABR
   would consume large number of labels.  Therefore, network designer
   needs to take this into consideration and if needed take appropriate
   action, which could be for example:

   o  filter colored prefixes that are send to (all) legacy ingress PEs
      to smaller subset.  This technique is specifically effective if
      ingress PEs are part of backhaul solution and provide transport to
      limited set of centralized service-aware nodes (vEPC, BNG, Video
      caches)



Chan & Szarecki          Expires January 8, 2020               [Page 19]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   o  replace ingress PE hardware or software to enable deeper label
      push.

8.  Contributors

   The following people have contributed to this document:

   Jeff Haas, Juniper Networks

   Shraddha Hedge, Juniper Networks

   Santosh Kolenchery, Juniper Networks

   Shihari Sangli, Juniper Networks

   Krzysztof Szarkowicz, Juniper Networks

9.  IANA Considerations

   This document defines a new SAFI in the registry "Subsequent Address
   Family Identifiers (SAFI) Parameters" that has been assigned by IANA:

       +-----------+------------------------------+---------------+
       | Codepoint |         Description          |   Reference   |
       +-----------+------------------------------+---------------+
       |  [[TBD]]  | Labeled colored unicast SAFI | This document |
       +-----------+------------------------------+---------------+

                                  Table 4

10.  Security Considerations

   The security considerations of BGP (as specified in BGP-4 [RFC4271])
   apply.

   This document specifies that certain data packets be "tunneled" from
   one BGP speaker to another across single TE-domain.  This requires
   that the packets be encapsulated while in flight.  This document does
   not specify the encapsulation to be used, except it need to be able
   to carry MPLS packet as payload.  However, if a particular
   encapsulation is used, the security considerations of that
   encapsulation are applicable.

   If a particular intra-TE-domain tunnel encapsulation does not provide
   integrity and authentication, it is possible that a data packet's
   label stack can be modified, through error or malfeasance, while the
   packet is in flight.  This can result in misdelivery of the packet.
   It should be that the tunnel encapsulation (MPLS), expected to be



Chan & Szarecki          Expires January 8, 2020               [Page 20]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   most commonly used in deployments of this specification, does not
   provide integrity or authentication.

   There are various techniques one can use to constrain the
   distribution of BGP UPDATE messages.  If a BGP UPDATE advertises the
   binding of a particular label or set of labels to a particular
   address <COLOR,DESTINATION>, such techniques can be used to control
   the set of BGP speakers that are intended to learn of that binding.
   However, if BGP sessions do not provide privacy, other routers may
   learn of that binding.

   When a BGP speaker processes a received MPLS data packet whose top
   label it advertised, there is no guarantee that the label in question
   was put on the packet by a router that was intended to know about
   that label binding.  If a BGP speaker is using the procedures of this
   document, it may be useful for that speaker to distinguish its
   "internal" interfaces from its "external" interfaces and to
   "remember" label binding advertised over each "external" interfaces.
   Then, a data packet received on give "external" interface can be
   discarded if its top label was not advertised over this "external"
   interface.  This reduces the likelihood of forwarding packets whose
   labels have been "spoofed" by untrusted sources.

11.  References

11.1.  Normative References

   [I-D.ietf-idr-bgp-prefix-sid]
              Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
              and H. Gredler, "Segment Routing Prefix SID extensions for
              BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
              June 2018.

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
              BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
              tunnel-encaps-12 (work in progress), May 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

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



Chan & Szarecki          Expires January 8, 2020               [Page 21]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
              DOI 10.17487/RFC2545, March 1999,
              <https://www.rfc-editor.org/info/rfc2545>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
              Layer Reachability Information with an IPv6 Next Hop",
              RFC 5549, DOI 10.17487/RFC5549, May 2009,
              <https://www.rfc-editor.org/info/rfc5549>.

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/info/rfc8277>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

11.2.  Informative References

   [I-D.ietf-lsr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
              A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
              algo-03 (work in progress), July 2019.

   [I-D.ietf-mpls-seamless-mpls]
              Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
              M., and D. Steinberg, "Seamless MPLS Architecture", draft-
              ietf-mpls-seamless-mpls-07 (work in progress), June 2014.






Chan & Szarecki          Expires January 8, 2020               [Page 22]


Internet-Draft Inter-Domain Traffic Steering with BGP-LCU      July 2019


   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
              <https://www.rfc-editor.org/info/rfc5575>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [RFC7811]  Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
              Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
              Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
              DOI 10.17487/RFC7811, June 2016,
              <https://www.rfc-editor.org/info/rfc7811>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

Authors' Addresses

   Louis Chan
   Juniper Networks
   Cityplaza One, 1111 King's Road
   Taikoo Shing
   Hong Kong

   Phone: +8522587665
   Email: louisc@juniper.net


   Rafal J. Szarecki (editor)
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   United States of America

   Phone: +14089365629
   Email: rafal@juniper.net





Chan & Szarecki          Expires January 8, 2020               [Page 23]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/