Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Kaliraj Vairavakkalai <[e-mail]>]

Robert,

https://datatracker.ietf.org/doc/html/rfc4364#section-10

     c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes
         between source and destination ASes, with EBGP redistribution
         of labeled IPv4 routes from AS to neighboring AS.

         In this procedure, VPN-IPv4 routes are neither maintained nor
         distributed by the ASBRs.

As described above, main difference between option (c) and (b) is that
there is no service-route (SAFI 128) state at ASBRs. The ASBRs are
“Transport ASBRs” that carry BGP-LU (SAFI 4) or BGP-CT (SAFI 76) routes.

So, there is no ambiguity that SAFI 76 is a Transport-layer family, that
enables Inter-AS option (c) solution.

Further, Ref: https://datatracker.ietf.org/doc/html/rfc8277#section-3.2.2

RFC 8277 does define how nexthop-self for SAFI-4 and SAFI-128 routes
achieve option-C or option-B label-swap forwarding at the BGP speakers
re-advertising these routes with nexthop-self. Irrespective of
whether it is SAFI-4, SAFI-128 or SAFI-76, the same procedures apply. Viz.


  *   Nexthop-self creates new label route for MPLS transit-forwarding,

this label is advertised to BGP peers in the 8277 family.

  *   Those labels cross-connect the tunnels that the advertised BGP

routes resolved over.

A BGP family is classified as service-family or transport-family based on what prefixes
it carries. Transport-family (used in option-c) carries prefixes that are used as
Nexthops in service-families. SAFI 4, SAFI 76 are examples of Transport families.
Service-families carry prefixes that appear in destination-field in the PDU on wire.
This is described in the following section:

https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-9


   A new family also facilitates having a different readvertisement path

   of the transport family routes in a network than the service route

   readvertisement path.  Service routes (Inet-VPN) are exchanged over

   an EBGP multihop session between Autonomous systems with nexthop

   unchanged; whereas Classful Transport routes are readvertised over

   EBGP single hop sessions with "nexthop self" rewrite over inter-AS

   links.



   The Classful Transport family is similar in vein to BGP LU, in that

   it carries transport prefixes.  The only difference is that it also

   carries in Route Target, an indication of which Transport Class the

   transport prefix belongs to and uses RD to disambiguate multiple

   instances of the same transport prefix in a BGP Update.


> But CT does not like ADD-PATHs - so how are you planning to solve this original L3VPN distribution issue ?

Further, about Addpath, CT doesn’t dislike Addpath 😊. BGP-CT does use Addpath to avoid
the redundant ASBR path-hiding problem you describe, as stated in the following sections:

https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-10.6


https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes-17#section-18.3


   Addpath is enabled for BGP CT family on the sessions between RR27 and

   ASBRs, ABRs such that routes for 1.1.1.1:10:1.1.1.1 with the nexthops

   ASBR21 and ASBR22 are reflected to ABR23, ABR24 without any path

   hiding.  Thus giving ABR23 visibiity of both available nexthops for

   Gold SLA.

We just don’t think Add-path-ID is a good end-to-end distinguisher. Because it is per-session scoped.
RD plays a better role of being an end-to-end distinguisher.

Thanks
Kaliraj

From: Idr <[e-mail]> on behalf of Robert Raszuk <[e-mail]>
Date: Thursday, July 14, 2022 at 3:44 PM
To: Reshma Das <[e-mail]>
Cc: Susan Hares <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences
[External Email. Be cautious of content]

Hi Reshma,

>  It is known SAFI 4 (BGP-LU) in option C at BN does Next hop self.

Options for Inter-as route distribution are *ONLY* defined in RFC4364 section 10.

Neither RFC3107 nor RFC8277 define Inter-as options. So you should not confuse anyone using terminology reserved for SAFI 128.

But nomenclature aside .. you realize that this was just to set the stage.

The real question I would like to ask is how do deal in BGP-CT with day one L3VPN specification bug in the Inter-as scenario ? As everyone deploying SAFI 128 across Inter-AS ASBRs is aware when you set next hop self (do SAFI 128 option B) you are losing redundancy.

This is due to the fact that for any set of RDs from original ASN ASBR is overwriting their different next hops. Then ASBRs are sending those routes over IBGP to RRs which now chooses closest (or random) ASBR as exit for routes received from a pair (or more) of ASBRs. So effectively ingress PE is receiving multiple NLRIs but they all are going to the single ASBR !

The only defined solution today is to use ADD-PATHs on top of SAFI 128 to force propagation of all paths (all ASBRs next hops). But CT does not like ADD-PATHs - so how are you planning to solve this original L3VPN distribution issue ?

Thx a lot,
R.



















On Fri, Jul 15, 2022 at 12:30 AM Reshma Das <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Please find my replies inline:

Thanks & Regards,
Reshma Das




Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Thursday, July 14, 2022 2:14 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[External Email. Be cautious of content]

Hi Sue,

Many thx for starting Part3 of this saga.

Question:

CT draft says in abstract:

 Though BGP CT family is used only in the option-C inter-AS neworks,

[Reshma] This is True SAFI 76 is only used in inter-AS option C.


CT draft also says in many sections that next hop is rewritten (example section 9:

   whereas Classful Transport routes are readvertised over
   EBGP single hop sessions with "nexthop self" rewrite over inter-AS
   links.


So for SAFI 76 how can the draft say that it is used only in option-C where it is evident that CT really uses option-B model with next hop rewrite ?


[Reshma] It is known SAFI 4 (BGP-LU) in option C at BN does Next hop self.
Stating an example from Cisco learning network:
https://learningnetwork.cisco.com/s/question/0D53i00000Ksqy9CAB/interas-option-c<https://urldefense.com/v3/__https:/learningnetwork.cisco.com/s/question/0D53i00000Ksqy9CAB/interas-option-c__;!!NEt6yMaO-gk!CAbQvoouRPiRAEsd7Shuc0CrZ7iPDYHPKfausT4Yrm4sTJAI0dTCb-51FbYFESEhn-UrU3alOurXOUZ9$>
Similarly for SAFI 76 at BN, if  RD1:EP1 (transport-target:0:100 - gold) has a gold path to reach EP1 then RD1:EP1 is advertised upstream with Next hop self.

Thx,
R.









On Thu, Jul 14, 2022 at 10:17 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
The IDR Adoption call for CAR and CT technologies is extended for an extra week
(7/14/2022 to 7/27/2022).

The IDR adoption call on Q2 has brought many discussions on pro/cons of the CAR
and CT BGP technologies:
https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/__;!!NEt6yMaO-gk!GBH220zFF4NqlZMkF672a20Oz09oJIvDXFIa1O6CHxfCjPHLq7U8ngBC1F7e1lqhJZvMJIGCXnEih1s$>

Since the IDR chairs agree with the summary of Jeff Haas (IDR Co-chair) posted on March 21, 2022 –
that for route resolution and route origination/propagation, BGP-CAR and BGP-CT
are functionally identical, but operationally different.
    ( https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/__;!!NEt6yMaO-gk!GBH220zFF4NqlZMkF672a20Oz09oJIvDXFIa1O6CHxfCjPHLq7U8ngBC1F7e1lqhJZvMJIGCrfuZyb8$>

This forum (Part 3) is place to discuss operational differences between the CAR and CT drafts.

These procedures for this mail thread are:


A.      On original discussion on point in a draft

1.       Text in either the CAR or CT draft that is applicable to the operational difference.

2.       Provide a sample topology.

3.       Discuss the pros/cons clearly stating whether your post is a: pro, con, or clarifying question.
Try to split clarifying question posts away from pro/con posts. Remember, you can post to this forum several times.
In your technical discussion, define your terms and avoid value judgement.



B.      On a discussion based on message in Q2 or Q1 mail list:

1.       Quote and link to Q1 or Q2 forum’s message.

2.       Text in either the CAR or CT draft that is applicable to the problem
      (Either provide the text or give specific reference (section, paragraph, and line(s)).

3.       Provide a sample topology.

4.       Summarize your viewpoint as: correction, clarifying question, pro, or con.

5.       Discuss the pro/con or text giving technical discussion.
In your technical discussion avoid define terms, give specific
examples in terms of draft text, sample topology, and facts.
If you state an opinion, back it up with technical facts.

If you are making a correction, assume the other person either misunderstood
or has a difference of opinion.  Respect each other as each IDR member is
entitled to their opinion. As a group we are working toward excellent BGP
in deployed technology.

In your delightful passion on these two technology additions to BGP (CAR and CT), please adhere to these rules.

Thank you, Susan Hares

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!GBH220zFF4NqlZMkF672a20Oz09oJIvDXFIa1O6CHxfCjPHLq7U8ngBC1F7e1lqhJZvMJIGCW4Cu_Xg$>


Juniper Business Use Only