Subject: [Idr] BGP routes with color, Question 2: Route origination and propagation

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Feb 2022 10:43:26 -0500

As promised during the recent IDR interim, we want to start a set of threads
to the IDR mailing list to clarify points discussed during that interim
about the BGP routes with color proposals.  These questions are directed to
the authors of those proposals.  The responses to those questions will be
used to drive Working Group discussion about the solution space.

Question 2: Route origination and propagation.

A point of strong discussion during the recent IDR interim covering BGP
routes with color was related to where routes within a given proposal were
originated, and what their expected propagation was within the proposal.

Two examples during the discussion:
1. Origination of a route with color at an Autonomous System Border Router
(ASBR) for a domain containing an endpoint address.

2. Origination at the Provider Edge device hosting the endpoint.

There may be other scenarios.

A route-selection "pinch point" is any place in the BGP topology wherein
multiple paths for the same NLRI may be received, only one is selected, and
is propagated.  There is a loss of forwarding-diversity at such points under
some circumstances.  Mechanisms that permit additional BGP routes to be
propagated can address such loss of forwarding diversity.

With regard to propagation through route-selection pinch-points, the interim
discussion illustrated that there were differences of opinion as to when it
made sense at an ASBR to use next-hop-self or propagate more than one path
across the peering session.

The above inputs to the scenario(s) culminate in an ingress device having
one or more than one instances of the received path.

What is the default scenario you expect your proposal to use?

Are there situations where you may want to have origination or propagation
behave differently than your default scenario?  If so, how does that work?

Please illustrate the scenarios with a topology for discussion.

-- Jeff

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Sat, 19 Feb 2022 01:26:26 +0000

Hi Jeff,

BGP-CT route origination is described in https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-10

    Origination of Classful Transport route:

      At the ingress node of the tunnel's home domain, the tunneling
      protocols install routes in the Transport RIB associated with the
      Transport Class the tunnel belongs to.

      The ingress node then advertises this tunnel destination into BGP
      as a Classful Transport family route with NLRI RD:TunnelEndpoint,
      attaching a 'Transport Class' Route Target that identifies the
      Transport Class.  This BGP CT route is advertised to EBGP peers
      and IBGP peers which are RR-clients.  This route MUST NOT be
      advertised to the IBGP peers who are not RR-clients.

      Alternatively, the egress node of the tunnel i.e. the tunnel
      endpoint can originate the same BGP Classful Transport route, with
      NLRI RD:TunnelEndpoint and PNH TunnelEndpoint, which will resolve
      over the tunnel route at the ingress node.  When the tunnel is up,
      the Classful Transport BGP route will become usable and get re-
      advertised.

So originating at either Egress-PE or the ASBR is allowed and supported.

Example topology: https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-13#section-15.1

                   [RR26]      [RR27]                    [RR16]
                    |            |                        |
                    |            |                        |
                    |+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+
                    ||          |||          `  /        |||          |
   [CE41]--[PE25]--[P28]       [P29]          `/        [P15]     [CE31]
                    |           | |           /`         | |          |
                    |           | |          /  `        | |          |
                    |           | |         /    `       | |          |
                    +--[ABR24]--+ +--[ASBR22]---[ASBR14]-+ +--[PE12]--+

          |                |                  |                    |
          +                +                  +                    +
       CE |     region-1   |   region-2       |                    |CE
      AS4              ...AS2...                       AS1          AS3

41.41.41.41------------ Traffic Direction ---------->   31.31.31.31

  1.  When originating at Egress-PE (PE11, PE22 in example topology)

·         RD:PE11 will be the NLRI in BGP-CT route, with transport-target extended community as an attribute to denote the Color.
Typical use-case: egress PE PE11 will originate one BGP-CT route RD1:PE11 with a Color C extended community.

·         However, use-cases that may need multiple routes with distinct forwarding semantics, but same Color is also possible. E,g,
RD1:PE11, Color C extended community, community ‘stats-group1’, advertised to ASBR13, with UHP label L1
RD2:PE11, Color C extended community, community ‘stats-group2’, advertised to ASBR14, with UHP label L2

        This method can provide labeled traffic statistics to PE11 on a per BN basis. Viz.. PE11 can know how much traffic is coming from ASBR13 (Label L1) and how much from ASBR14 (Label L2).

  1.  When originating at ASBRs, use of RD allows for two sub cases:

·         ASBR13, ASBR14 using unique-RDs to originate BGP-CT route for a “PE11, Color”.
In this mode, ingress PE can know which ASBR originated the CT route in question.

·         ASBR13, ASBR14 using same-RD to originate BGP-CT route for a “PE11, Color”.
Using same-RD will be equivalent to ‘origination at egress-PE’ scenario.
Ingress PE can know the route was originated at the egress-PE and not the ASBRs.

  We expect the “Origination at Egress-PE” (1 above) to be the default scenario that most deployments will use.

  But it is totally the user’s choice. As explained above, the protocol procedures allow for all variations. Using RDs provides better
  network-wide visibility.

  For troubleshooting purposes, it is valuable to be able to pin-point easily which node originated a route. More so in a huge inter-domain option-C network.

The subsequent text in draft (sections 10, 11) explain propagation of BGP-CT routes thru ASBRs, RRs. Some key points listed below:

·         Regular BGP procedures for route advertisement is followed.
·         RD is used to pass thru path selection pinch points, like RR.
·         IBGP-Addpath is also used at RR, to not hide redundant BNs (transport ASBRs/ABRs).
·         RFC 8212 is followed, preventing unintended propagation across EBGP boundaries.
·         Rules of RFC4684 (RTC) work with BGP-CT routes also. Thus providing “on demand nexthop”.

 If there are any specific questions on text in these sections in the draft, please let us know.

Thanks
Kaliraj

From: Idr <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Date: Friday, February 18, 2022 at 7:44 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] BGP routes with color, Question 2: Route origination and propagation
[External Email. Be cautious of content]

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R9RsTowEM7HFet-gvC92y9UjIz2kTg_hv34q30qDAurlTZYekgc--dJA_A0rhSn5$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R9RsTowEM7HFet-gvC92y9UjIz2kTg_hv34q30qDAurlTZYekgc--dJA_A0rhSn5$>

Juniper Business Use Only