Re: [Idr] IETF 117 - IDR Chair slides: CAR, Question-2

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

Hi Kaliraj,

Please see inline (DR#)

From: Idr <[e-mail]> on behalf of Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Tuesday, August 1, 2023 at 1:32 AM
To: Susan Hares <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Idr] IETF 117 - IDR Chair slides: CAR, Question-2
Hi Sue, IDR-Chairs,

Quick response to Question 2 on IDR Chair slides, Page 4:

https://datatracker.ietf.org/meeting/117/materials/slides-117-idr-sessa-01-chairs-introduction-slides-to-carct


·         CAR

o   Question-2: Do new sections need more review?


Yes. The new sections need more review. They don’t have an implementation either.

Actually following items have “no implementation” as-per the implementation report<https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-car>:

-   LCM EC

-   Type 2 NLRI

-   VPN CAR (Type 1 or Type 2)

This list includes items which are new in car-02 and also some existing items in car-01.

Implementation experience may show us that some changes may be required in procedures.

Most procedures present in the draft are for CAR SAFI Type 1 NLRI (E,C), where Color is in NLRI.

(e.g. 2.1<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-2.1>.  Data Model, section 3<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-3> Service route Automated Steering on Color-Aware path)



Procedures are missing for the other NLRI types (VPN-CAR and Type 2 NLRI).

DR# As I’d  responded in a previous email thread on this topic, Section 8 specifies the necessary behavior.

DR# To elaborate a bit here, the procedures for CAR SAFI between PE-CE follows the base CAR procedures already specified in the rest of the document,
the difference being its in a VRF. As specified, these routes are distributed across the provider network using VPN CAR SAFI which follows exactly RFC 4364 semantics. For instance, a type-1 route with MPLS would function just like MPLS CsC. There aren’t specific additional procedures are necessary to be called out.

DR# These sections and definitions for VPN CAR have been present since before adoption call, there isn’t anything new. The same semantics and procedures also apply to the Type-2 route, which is just an IP prefix, as specified in Section 10.1.

DR# We can add some descriptive text; hopefully that helps.


Procedures are missing on how the different route types and SAFIs interoperate with each other:

-   Type 1 CAR

-   Type 1 VPN-CAR

-   Type 2 CAR

-   Type 2 VPN-CAR
As all of these route-types intend to provide solution to the same problem of “end-to-end intent-aware paths”,
some customers may choose one NLRI variant and some others may chose a different one. How do they work together?

DR# Please see above.
DR# The use-case and requirement drives a customer’s selection of the route-type to use, exactly as for the base CAR SAFI in the provider network, which is already described in detail in the spec.
DR# There isn’t any mixing of the route-types; just like there isn’t for the base CAR SAFI.


For VPN-CAR (Sec 8 and Sec 10.2), Procedures are missing on

-   How RD and RT usage happens in transport layer.

DR# CAR SAFI does not use RDs and RTs, hence no specific procedures related to them.
DR# If you’re referring to VPN RD/RT for VPN CAR SAFI, it is identical to RFC 4364 as specified.


-   How collision with RT used at Service layer (e.g. SAFI 128) is handled.


  *   DR# There is no collision, as VPN CAR SAFI is a different SAFI than SAFI 128, hence the routes are separate. RD and RT assignment is done by the operator just like any other VPN SAFI.


-   How BNs work for VPN-CAR. See Topology in Sec 8<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02#section-8>, it has no BNs. Only ingress and egress PEs.

DR# It is just like RFC 4364.


-   Interaction between service-families and vpn-car routes.

DR# There is no interaction
DR# We can add some illustrative text to clarify the relationships.

Regards,,
-Dhananjaya

We will try to send more comments on review of the draft text. But time is of essence.

As noted by Susan, it can be seen the solution is still evolving as new types are being added for scenarios that
have been in discussion since 2021, and they lack implementation.

I hope other WG memebers (specifically who are ‘supporters of CAR’) are reviewing the draft to
ensure it is correct, complete and solves their problems.

Thanks,
Kaliraj


Juniper Business Use Only