[Idr] Shepherd's report on draft-ietf-idr-car-05 (with additions from authors) -

[Susan Hares <[e-mail]>]

The attached file is a shepherd's review for draft-ietf-idr-car-05 (taking into account changes authors have mentioned).

Status: Has issues,
Issues: 12 technical, 44 editorial changes
The technical issues are listed below.   The editorial issues are attached in the file.  The authors have discussed all the technical issues with the shepherd and are addressing these in upcoming drafts.

The attached text has the original Shepherd's report prior to the discussion with the authors (1/26/2024).

Cheerily, Sue Hares
===========
Technical issues

#1 - Clarity in section 2.5 - BGP CAR Route Resolution

Your procedures for Route resolution:

Old Text:/

   A BGP color-aware route (E2, C1) from N is automatically resolved
   over a color-aware route (N, C1) by default.  The color-aware route
   (N, C1) is provided by color aware mechanisms such as IGP Flex-Algo,
   SR policy or recursively by BGP CAR.  When multiple producers of (N,
   C1) are available, the default preference is: IGP Flex-Algo, SR
   Policy, BGP CAR.


    Local policy SHOULD provide additional control:

   *  A BGP color-aware route (E2, C1) from N may be resolved over a
      color-aware route (N, C2): i.e. the local policy maps the
      resolution of C1 over a different color C2.

      -  For example, in a domain where resource R is known to not be
         present, the inter-domain intent C1="low delay and avoid R" may
         be resolved over an intra-domain path of intent C2="low delay".

      -  Another example is, if no (N, C1) path is available, and the
         user has allowed resolution to fallback via C2.

 /

Problem:
Is N always setting BGP self-next-hop?  If so, this must be stated.
If N is not always setting BGP self-next-hop, what is the Next Hop
and how does it related to "N in the procedures?"
------------
#2 - Missing procedures for replacement of RFC9012 procedure (Section 8, Section 60
     for application in presence of BGP Color-EC in the CAR route.

Old Text: /

    A BGP CAR route may recursively resolve over a BGP route carrying
   Tunnel Encapsulation attribute (TEA).  Procedures of section 8 of
   [RFC9012] apply in presence of BGP Color-EC in the CAR route.  They
   are extended to use LCM-EC and Color in CAR route NLRI as per above
   and Section 2.9.4 in absence of BGP Color-EC.  Among other options, a
   BGP CAR BR may advertise a CAR route to an ingress BR with a specific
   BGP next hop per color, with a TEA or Tunnel Encapsulation EC.
 /

If you state the procedures of RFC9012 section 8 are extended, you must specify how.
Section 2.9.4 does not provide the extension text to section 8.

Resolution: The authors have indicated that they are simply applying existing procedures to
CAR solution SAFIs (CAR SAFI and VPN CAR SAFI).

---------------
#3 - Lack of operational procedures for BGP CAR Signaling through different domains

Section 2.8 in the following text provides an example, but not procedures
for the BGP CAR signaling through different domains.

Current text:/
   The solution works as follows:

   *  Within domain 2, the BGP CAR route is (E2, C2) via E2.

   *  B signals to A the BGP CAR route as (E2, C2) via B with Local-
      Color-Mapping-Extended-Community (LCM-EC) of color C2.

   *  A is aware (classic peering agreement) of the intent-to-color
      mapping within domain 2 ("low-delay" in domain 2 is C2).

   *  A maps C2 in LCM-EC to C1 and signals within domain 1 the received
      BGP CAR route as (E2, C2) via A with LCM-EC(C1).

   *  The nodes within the receiving domain 1 use the local color
      encoded in the LCM-EC for next-hop resolution and service
      steering.
/

Text is needed to indicate the exact procedures as well as the example.

Here's a few things that must be included:

1. Procedures for BGP peer sending route at the edge of Color Domain (e.g. Color Domain 2 above)
    Scope is missing:  What SAFIs applies to, NLRI Route types applies to.
    detection procedure:  How it will be detected at the policy barrier.
   Actions:  What is set in the route.  What is set in forwarding policy.


2. BGP Peer receiving a BGP CAR route with LCM -
    Scope is missing:  What SAFIs applies to, NLRI Route types applies to.
    Detection procedure:  How it will be detected in Route? Is there validation of LCM versus Color?
  What happens if these are the same.

Resolution: Authors will improve text.

#4 - Section 2.9.2, Please improve procedures

 Question that the procedures should answer:

 a) error handling for Transitive - What happens if the T bit requirements are not obeyed
   And an unrecognized non-Transive TLV is propagated. (Obviously an error)
   Is it a treat as withdrawl?

b) What does it mean that "the prefix is routable" where BGP transport is deployed?
    How is this given as a procedure for a BGP Peer?

 What is the processing of the NLRI?

 One could assume:
 1) parse the fields to validate,
 2) validate non-key fields
 3) check the color to see if we hit a domain boundary

Resolution: Authors will improve text.

---------------------
#5 Section 2.9.2.1 - Procedure step missing

Under what circumstances does the CAR speaker propagate the route and set self as the "next hop"?

Resolution:  CAR is using normal procedures, but will work on text.

-----------------------
#6. Section 2.9.2.2 - definitions + procedures

Definitions:
1. What does it mean that "2 octet field that maps to the flag field of
the Label Index TLV of the BGP Prefix-SID Attribute ([RFC8669])?
Do you mean you use the same definition from section 3.1 of RFC8669?
If so state this fact.  When quoting from RFC8669 for a definition, please specify the section.

Procedures:
1. What happens if the Label Index TLV and the BGP Prefix-SID attribute are
both in the BGP update packet?  The procedures need to cover this.

2. Is the CAR speaker setting itself as next a normal part of the procedure?
Or is it an occasional part of the procedure?

Note: When quoting from the procedures, please give the section the procedure is using.

Resolution:  Authors have a fix for the text.

------------------------
#7. Section 2.9.4, what is the correct procedure for Type-2?

Please provide both procedures.  An example is also useful.

Section 2.10 gives an example with two LCM-EC in the text:

Text in 2.10/
   Example: BGP CAR route (E, C1) from
   color domain D1, with LCM-EC C2 in color domain D2, may also carry
   Color-EC C3 and next hop N in a transit network domain within D2
   where C2 is being resolved via an available intra-domain intent C3
   (Appendix B.2 and Appendix B.3 combined).

Resolution: This issue may be fixed by earlier issues, but we'll review after improved text.


#8 - Technical Section 2.9.4 and 2.10, clarify procedures for type 2

Old text in 2.9.4/
   LCM-EC Color is used instead of the Color in CAR route NLRI for
   procedures described in earlier sections such as route validation,
   resolution, AIGP calculation and steering.
/

Old Text in 2.10 /
   Default order of processing for resolution in presence of LCM-EC is
   local policy, then BGP Color-EC color, and finally LCM-EC color.

   /

For Type-1, the precedence is clear.

  *   For type-1, your presentations indicated that it replaces the Color in the NLRI within a color domain (AS or multiple ASes) that set LCM-EC.
  *   For Type-2, what happens if the originator specifies LCM-EC  and then the route passes through a different color domain?

Do you rewrite the LCM-EC? How do you keep the original color tagged by LCM-EC?
The procedures need clarification.

Resolution:  LCM-EC is being rewritten.  The original LCM-EC color value is overwritten.

#9 Section 3 - resolution

Old text:/
   An egress PE may request intent through the transport for service
   routes by allocating the SRv6 Service SID from a routed intent-aware
   locator prefix (Section 3.3 of [RFC8986]).  Steering at an ingress PE
   is via resolution of the Service SID over CAR Type-2 IP Prefix NLRI.
   Service Steering over BGP CAR SRv6 transport is described in
   Section 7.
/

New text:/
   An egress PE may request intent through the transport for service
   routes by allocating the SRv6 Service SID from a routed intent-aware
   locator prefix (Section 3.3 of [RFC8986]).  Steering at an ingress PE
   is via resolution of the Service SID over a route passed in
   an CAR Type-2 IP Prefix NLRI. Service Steering over BGP CAR SRv6
   transport is described in Section 7.
/

This is flagged as technical because I want to make sure we
are resolving the forwarding IP Next Hop to the CAR type-2 IP Prefix NLRI
via the SR routing pathways identified in by a Service SID

Note: It may be already working correctly, but we need to check.

#11 - Does section 5 apply to both SAFIs
The scaling in section 5 apply to both CAR SAFIs (BGP CAR SAFI and BGP VPN SAFI) with both NLRI types (Type 1 and Type 2)?

Note: It may be clearer to put this at the end of the text.

#12 - Verify the use of Extended Communities:
LCM-EC - Defined in [draft-ietf-idr-bgp-car]
Color-EC - created in RFC9012, Associated with type 2 as originating color.

See: From Section 8, paragraph 4

Text:/
   For specific intents, color may be signaled with the CAR Type-2 route
   for purposes such as intent-aware SRv6 SID or BGP next-hop selection
   at each transit BR, color based routing policies and filtering, and
   intent-aware next-hop resolution (Section 2.5), same as with Type-1
   routes.  For such purposes, color associated with the CAR IP Prefix
   route is signaled using LCM-EC./

Is Color-EC [RFC9012] or LCM-EC associated during origination of Type-2 NLRI
for BGP CAR SAFI and VPN CAR SAFI?

>From Section 9, paragraph4
Text:/
   Further, all CAR SAFI procedures described in Section 2 above apply
   to CAR SAFI enabled within a VRF.  Since CE and PE are typically in
   different administrative domains, LCM-EC is attached to CAR routes.
   VPN CAR SAFI routes follow color based steering as described in
   Section 3 and illustrated in example above.
/

#12 - Informative References

I've asked Spring chairs about the status of the following documents:
   [I-D.agrawal-spring-srv6-mpls-interworking]
   [I-D.hr-spring-intentaware-routing-using-color]

If you know if these have been adopted, please let me know.