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

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

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]>
Date: Tuesday, July 18, 2023 at 3:57 AM
To: Moshiko Nayman <[e-mail]>, Dhananjaya Rao (dhrao) <[e-mail]>, Susan Hares <[e-mail]>, [e-mail] <[e-mail]>, Ketan Talaulikar <[e-mail]>, [e-mail] <[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]> on behalf of Moshiko Nayman <mnayman=[e-mail]>
Date: Monday, July 17, 2023 at 12:47 PM
To: Dhananjaya Rao (dhrao) <dhrao=[e-mail]>, Susan Hares <[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)
[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]> on behalf of "Dhananjaya Rao (dhrao)" <dhrao=[e-mail]>
Date: Thursday, July 13, 2023 at 4:01 PM
To: Susan Hares <[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)

[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]> on behalf of Susan Hares <[e-mail]>
Date: Thursday, July 13, 2023 at 7:53 AM
To: [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)
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