Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)

["Dhananjaya Rao (dhrao)" <[e-mail]>]

Hi Sue,

Please see inline (DR#)

From: Susan Hares <[e-mail]>
Date: Wednesday, July 19, 2023 at 12:31 AM
To: Dhananjaya Rao (dhrao) <[e-mail]>, Kaliraj Vairavakkalai <kaliraj=[e-mail]>, Moshiko Nayman <[e-mail]>, [e-mail] <[e-mail]>, Ketan Talaulikar <[e-mail]>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)
DJ:

Would it be valid to restate your reason for the CAR AFI/SAFI as: “The CAR SAFI is intended to update the BGP transport functions in BGP-LU (applicable to just MPLS) for new transports (such as SRv6).  It maintains the exact flat routing semantics of BGP-LU/IP without any need for VPN-like import.”

DR# Sure that would be fine.

How would you state your reason for the CAR VPN AFI/SAFI?
(This AFI/SAFI contains a spot for the RDs) see section 10.2.  Why support RD?

DR# As stated below and for the use-cases in draft-hr-spring-intentaware-routing-using-color-02, BGP CAR can be enabled between PE-CE. To advertise the customer’s CAR routes between PEs, VPN CAR is required. The semantics are as per RFC 4364, the RD uniquely distinguishes CAR routes from different customers (VRFs).

DR# This is already described in section 8 of the CAR draft. It’s not new, was present in earlier revisions and discussed during adoption.

You have two NLRI types:  Color-Aware Route NLRI, IP-Prefix NLRI.
The color-aware route NLRI  Intent (E,C) has been discussed for 2 years in IDR and SPRING.  The concept of Intent has been defined in the IRTF.
The IP-Prefix NLRI is new.

DR# It may be new in the draft but semantically its same as an BGP IPv4/BGP IPv6/LU IP prefix. Hence not a new behavior.

DR# The key difference is operational – as the CAR SAFI enables a clear separation between transport routes and service routes by not overloading the SAFIs that also carry service routes such as SAFI 1 or 4 - as already stated in Section 9.3.

You state: “The IP prefix route type is an extension for the specific case where IP Prefix == intent or color, such as in SRv6 where a locator is assigned for a given intent. Here there is no requirement to have multiple instances of the prefix with different colors.

(For WG Note: Jeff Haas already asked about whether the color = 0 would have been useful.
https://mailarchive.ietf.org/arch/msg/idr/P4hCavFklsH5zQ5y4kMOc4_Xrck/
https://mailarchive.ietf.org/arch/msg/idr/xTpg9qBDRJM7EmAB64E6wjScd-Q/)

DR#  I have responded to Jeff. Please let me know if you have any additional concerns.

draft-wang-idr-cpr-02 gives some deployment insights from a set of operators and vendors.  Did insights from this draft cause you to add the IP-Prefix?  If so, which insights or customer deployments?

DR# Not at all. The precedence for distributing SRv6 locator prefixes in routing is well established in IGPs (IGP-FlexAlgo - RFC 9350) and BGP (https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/ )

DR# It is a natural outcome of the definition of the routed SID (https://datatracker.ietf.org/doc/html/rfc8986#name-sid-reachability) and its usage for steering is described in RFC 9252 (https://www.rfc-editor.org/rfc/rfc9252.html#name-bgp-based-l3-service-over-s)

DR# BGP CAR just follows the established model. This was one of the use-cases for defining a route-type.

Thanks for helping the WG understand the intent of your design.

DR# Hope the above clarifications are helpful.

Regards,
-Dhananjaya

Sue


From: Dhananjaya Rao (dhrao) <[e-mail]>
Sent: Tuesday, July 18, 2023 9:06 AM
To: Kaliraj Vairavakkalai <kaliraj=[e-mail]>; Moshiko Nayman <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; Ketan Talaulikar <[e-mail]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)


Hi Kaliraj,


There are a number of subjective and rhetorical statements in your message, but to clarify some technical comments w.r.t the referred text inline (please look for DR#)

From: Kaliraj Vairavakkalai <kaliraj=[e-mail]<mailto:kaliraj=[e-mail]>>
Date: Tuesday, July 18, 2023 at 3:57 AM
To: Moshiko Nayman <[e-mail]<mailto:[e-mail]>>, Dhananjaya Rao (dhrao) <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)
WG, IDR-Chairs, CAR-authors,

A few meta comments, and a couple questions follow.

> This route type and it’s uses are also applicable to the VPN layer, hence to VPN CAR.

              *  Traditional IP prefix advertisement, such as BGP IPv6 or BGP-LU  (https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-10)

So, CAR is subsuming other BGP families (VPN, IPv6-Unicast, LU) into itself?
But without specifying clearly how the business logic of those families will work inside CAR.
All procedures specified in car draft are for E,C NLRI.


DR# There is no change in scope compared to previous versions of the CAR draft. Since there is a new route-type, it’s applicability DR# is specified where necessary.  For instance, it does apply to the PE-CE peering similar to the (E,C) route, hence it’s specified as DR# above.

DR# Similarly, to restate what’s been addressed many times, by definition, the CAR SAFI is intended to be an evolution of BGP DR# transport routing (for instance provided by BGP-LU for MPLS); to modernize it for extensibility and support for newer
DR# transport deployments/encapsulations. It maintains the exact flat routing semantics of BGP-LU/IP without any need for VPN-DR# like import.

DR# W.r.t the above text, BGP-LU SAFI can of course be run in parallel for a best-effort path. However, the new route-type allows DR# it to supported inherently in BGP CAR SAFI in a simpler way.

There is no clarity on whether CAR is a Service family or Transport family, or the procedures thereof.

e.g., VPN-CAR (https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-10.2) has no procedures specified.

DR# The VPN CAR semantics and procedures are same as already specified in section 8, this section is just specifying the new route-type. But we can explicitly state it too.

DR# The use-case as before is to establish an intent-aware path across multiple domains over which service routes (and traffic) DR# can be steered over. These paths can extend not just PE-PE but also extend to customer networks.

DR# This is described in the problem statement draft:
https://www.ietf.org/archive/id/draft-hr-spring-intentaware-routing-using-color-02.html#name-vpn-service-layer-network-i


Also, like Moshiko points out below, there is confusion on whether Color should be in the NLRI or not.
See   https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-2.9.2
And  https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-10.1

Sec 10.1, removed Color from Type 2 NLRI, and is left with no Distinguisher to avoid path-hiding in path-selection pinch points.

DR# I’ve responded to Moshiko’s message. But to reiterate,
DR# The IP prefix route type is an extension for the specific case where IP Prefix == intent or color, such as in SRv6 where a locator DR# is assigned for a given intent. Here there is no requirement to have multiple instances of the prefix with different colors,
DR# hence no need to have the color in the NLRI.
DR# For other cases, the (E,C) route is still applicable.

Things seem to be done in a hurry, and got added ad-hoc, with the original problem of intent-driven service mapping lost.

DR# Entirely subjective and ad-hoc opinion with incorrect conclusion.

DR# It’s ironic given that the CT draft has undergone a large number of recent revisions and content updates, including significantly divergent solutions in the SRv6 sections in different revisions.

DR# https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgp-ct-01&url2=draft-ietf-idr-bgp-ct-02&difftype=--html

DR# https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgp-ct-03&url2=draft-ietf-idr-bgp-ct-04&difftype=--html

DR# https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgp-ct-04&url2=draft-ietf-idr-bgp-ct-05&difftype=--html


I think there is not enough clarity in the document that we can do a more detailed review wrt Part 3 questions. But we’re trying.

DR# Not sure you are. If you have any more specific questions, we’d be happy to clarify or update the text if needed.

Also, as per the Implementation report:

https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-car

Following constructs have no implementation: VPN CAR, Type 2 Prefix Route-type, LCM EC

These things bring me to ask the following questions for the WG, to save everyone’s time:


-          Are we rushing towards a LC for a completely new set of extensions in car-02 with no/incomplete procedures?

-          Should we go back to the drawing board, and reset the LC (for CAR only)?

-          Do we really want a family that subsumes other existing families (VPN, IPv4-Unicast, IPv6-Unicast, LU)?

DR# Preconceived conclusions where you didn’t even bother waiting for a response or clarifications to your comments.
DR# Thanks for making your motivations clear.

DR# I’ve tried to respond to technical comments. It’s worth restating that the semantics and procedures used by the CAR SAFI
DR# are consistently aligned with existing SAFIs such as BGP-LU and BGP IPv6, and the draft has described the specific extensions as needed.

DR# On the other hand, given the number of recent changes to the CT draft as well as the reliance on completely new and still in progress non-adopted extension drafts such as the ones below , one could say your comments should apply to  CT draft 😊

DR# https://datatracker.ietf.org/doc/draft-salih-spring-srv6-inter-domain-sids/ , https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/ , https://datatracker.ietf.org/doc/draft-kaliraj-bess-bgp-sig-private-mpls-labels/



considering the security implications and filtering problems that come with it? There is no walled garden anymore.

DR# You have it in reverse 😊  CAR SAFI being a separate SAFI, precludes the need to overload existing SAFIs such as BGP IPv6 that carry internet prefixes with transport routes. (See section 9.3).

Regards,
-Dhananjaya

Thanks
Kaliraj



Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Moshiko Nayman <mnayman=[e-mail]<mailto:mnayman=[e-mail]>>
Date: Monday, July 17, 2023 at 12:47 PM
To: Dhananjaya Rao (dhrao) <dhrao=[e-mail]<mailto:dhrao=[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)
[External Email. Be cautious of content]

So far CAR has advocated having Color in the NLRI. Here in the new prefix in Section 10, there is no Color in the NLRI. Which seems like a major change in ideology.
Is there any problem with Color in the NLRI that you now want it in BGP community?


Moshiko.



Juniper Business Use Only


Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of "Dhananjaya Rao (dhrao)" <dhrao=[e-mail]<mailto:dhrao=[e-mail]>>
Date: Thursday, July 13, 2023 at 4:01 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)

[External Email. Be cautious of content]

Hello Sue,

The Prefix NLRI is in Section 10 as it not limited to SRv6 but applies to other cases of distribution of specific IP prefixes; for example best effort as described there.

This route type and it’s uses are also applicable to the VPN layer, hence to VPN CAR.

Regards,
-Dhananjaya

From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 13, 2023 at 7:53 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/23/2023)
Swadesh, DJ, and Ketan:

Would you explain why you add
Section 9 on CAR SRV6 and a new
NLRI in section 10?

How does this expand upon
Ketan’s comments on Intent
At the service (e.g. VPN) layer.

https://mailarchive.ietf.org/arch/msg/idr/hHto6CYV6zWeTju7gHWLH1qRsOA/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/hHto6CYV6zWeTju7gHWLH1qRsOA/__;!!NEt6yMaO-gk!GSuBYHH2vYgFwuLfvqlvU-MdySc1GkHEnrqtaVAWkRp2sl21lWWJWdOVaJCBu1fyAynTHU_EpfrA6pKzlQLG4bBaLxyJaUE$>

Thank you,
Sue