[Idr] Re: Roman Danyliw's Discuss on draft-ietf-idr-bgp-car-14: (with DISCUSS and COMMENT)

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

Hi Roman,

Thank you for your review. Please see inline (DR#) for responses.

From: Roman Danyliw via Datatracker <[e-mail]>
Date: Wednesday, February 19, 2025 at 7:51 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Dhananjaya Rao (dhrao) <[e-mail]>, [e-mail] <[e-mail]>, Clarence Filsfils (cfilsfil) <[e-mail]>, luay.jalil <[e-mail]>, yitai.syc <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, im8327 <[e-mail]>, [e-mail] <[e-mail]>
Subject: Roman Danyliw's Discuss on draft-ietf-idr-bgp-car-14: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for
draft-ietf-idr-bgp-car-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-car/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 10.4.1 and 10.4.2.  How is the designated expert supposed to use
this section? Both sections are titled as “Additional suggestions …”.  This
suggests that that conformance is not required for allocating a code point.

-- If conformance is not mandatory, what is the DE supposed to do with this
guidance?

-- If this is a mandatory criteria, please make the language clearer.

** Section 10.4
   If the request comes from within the IETF,
   it should be documented in an Internet-Draft.

Can the WG please clarify the intent of this text.  I see there is similar
language in RFC9256.

Based on different interpretations of “within the IETF”, I see the following
scenarios: (1) IETF stream, WG document (2) IETF stream, AD sponsored document
(3) no stream, I-D

Which subset of scenarios is being assumed by the “comes from the IETF”?

If it is only situation(1) or (2) apply, Section 2 of RFC7120 states that “The
code points must be from a space designated as "RFC Required", "IETF Review",
or "Standards Action".  Additionally, requests for early assignment of code
points from a "Specification Required" registry are allowed if the
specification will be published as an RFC.”  Therefore, if the intent is an RFC
with a WG I-D, early allocation and permanent allocation is already possible
without the above cited language.  AD sponsorship inherently assumes an RFC
publication route.  The only residual case is for WGs to be requesting
permanent allocations with an I-D that isn’t intended for publication.  Why
would this occur?

If situation (3) is applicable and the intent is to allow permanent
registration with an unadopted I-D, please be explicit.  It is in the grey area
of whether this qualifies for “coming from the IETF”.  I will note that the
forthcoming IANABIS WG is intended to resolve whether an I-D alone meet the
threshold for “specification required”.  Different registries already allow
this to occur without this text.  I acknowledge absent guiding text of some
form, there is some community controversy on this position.

With John Scudder’s help, if the sole intent of this language is to be clear
that unadopted I-Ds are accepted references for this specification required
registry consider using the following instead:

NEW
An Internet-Draft that has not been adopted by an IETF working group is
considered acceptable documentation. For adopted and AD-sponsored documents,
the normal process documented in RFC 7120 and RFC 8126 should be followed

DR# Thank you for the suggestion. I see the ongoing discussion with Sue. I will follow up with her and update the draft as needed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Joel Halpern for the GENART review.

** (as Joel noted in his GENART review) What’s the experiment to motivate the
experimental status?  What does success look like?
DR# Sue has tried to address this question for all the relevant drafts in this area.

** Section 1.
   Color is a non-zero 32-bit numerical value
   associated with a network intent (low-cost, low-delay, avoid some
   resources, 5G network slice, etc.) as defined in Section 2.1 of
   [RFC9256].

Section 2.1 of RFC9256 says that a color is an integer, not a “numeric value”
(“The color is an unsigned non-zero 32-bit integer value”).  Perhaps s/32-bit
numerical value/non-zero 32-bit integer value/.  Same recommendation for
Section 1.1 where color is defined again.

DR# Will update, thanks.

** Section 1
   BGP CAR fulfills the transport and VPN problem statement and
   requirements described in
   [I-D.hr-spring-intentaware-routing-using-color].

With due respect to this reference, what is the significance of meeting a set
of requirements specified in an unadopted I-D?
DR# I hope Sue’s response addressed your question. The statement is informational.

** Section 1.1
Color re-mapping and filtering |
    |             | may happen at color domain boundaries.  Refer to  |
    |             | [I-D.hr-spring-intentaware-routing-using-color].

Why is the concept of color remapping being explained by an informative
reference?  Which is an unadopted draft?  Is it important to implemented this
specification?

DR# Sue answered this. Just to add that the reference is informative as the problem statement draft describes use-cases to illustrate the concept. There is no dependency.

** Section 2.5
   Local policy SHOULD provide additional control:

   *  A BGP color-aware route (E2, C1) with next hop N may be resolved
      over a color-aware route (N, C2):
…
   *  Route resolution may be driven by an egress node.

I’m having trouble understand the intent of this normative guidance on local
policy providing additional control.  For example, is this saying that local
policy could allow route resolution to be driven by an egress node, but is
isn’t required?

DR# Depending on the scenario, one or more mechanisms may apply. The guidance is that implementations should provide configuration options to the user.

** Section 2.5
   BGP CAR resolution in one network domain is independent of resolution
   in another domain.

What scopes or bounds a “network domain” here?

DR# It is typically one or more IGP domains. The statement just indicates that route resolution can be different at each BGP hop through the network.

** Section 2.7
   BGP ADD-PATH [RFC7911] SHOULD be enabled for BGP CAR to signal
   multiple next hops through a transport RR.

Is there any guidance on when ADD-PATH SHOULD NOT be enabled?
DR# There isn’t such a restriction.



** Section 2.9.2.1
     It is used for
      encoding a single label or a stack of labels for usage as
      described in [RFC8277].
…
      3-bit Rsrv and 1-bit S field SHOULD be set to zero on
      transmission and MUST be ignored on reception.

-- When would the Rsrv and S field be set to something other than 0?  What
value should be used?
DR# In the context of it’s usage along with CAR SAFI routes, it would always be set to 0.

-- I’m not sure which section in RFC8277 is applicable but all instances have a
mandatory value set (uses MUST to set either 1 or 0 depending on context)

** Section 2.9.3
   The prefix is unique across the administrative domains where BGP
   transport CAR is deployed.

Are the “administrative domains” referenced here the same as the “transport
network”?
DR# Yes.


** Section 2.11.  Editorial

      An implementation SHOULD provide a knob that
      controls the RR unrecognized route type propagation behavior and
      possibly at the granularity of route type values allowed.

Consider if there is a less colloquial way to say “provide a knob”.

DR# We could fix it as ‘…provide configuration that controls …’ . Same for another instance where ‘knob’ is used.


** Section 11.  Editorial.
   Extended communities (LCM-EC/Color-EC) carried in BGP CAR and Service
   routes MUST not be filtered, otherwise the desired intent will not be
   achieved.

IDnits reports:
  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).

     Found 'MUST not' in this paragraph:

DR# Thank you, will fix it.


** Clarity on domains

-- Section 1.1 says:
    | Color       | A set of nodes which share the same Color-to-     |
    | Domain      | Intent mapping, typically under single            |
    |             | administration.

-- Section 1.1 says:
    | Transport   | A network that comprises of multiple cooperating  |
    | Network     | domains managed by one or more operators, and     |
    |             | uses routing technologies such as IP, MPLS and    |
    |             | Segment Routing to forward packets for            |
    |             | connectivity and other services.  Where the       |
    |             | network uses SRv6, the operators have agreed to   |
    |             | trust each other's specification of SRv6 SIDs.    |

-- Section 11 says:
   Color assignments in a multi-domain network operating under a common
   or cooperating administrative control (i.e., a color domain) should
   be managed similar to transport layer IP addresses, and ensure a
   unique and non-conflicting color allocation across the different
   network domains in that color domain.  This is a logical best
   practice in a single color or administrative domain, which is the
   most typical deployment scenario.

These three sections appear to be providing qualifying scope on what
constitutes a domain in the SR context.  To confirm, are they consistent with
RFC8402, Section 8’s “By default, SR operates within a trusted domain.  Traffic
MUST be filtered at the domain boundaries.”? The domain boundary specified in
DR# Yes, they are.

this document is the union of all coordinating operators who “have agreed to
trust each other's specification of SRv6 SIDs”?  Is there a security
consideration to mention about this dependency?  Also, perhaps something about
negotiating that trust is outside the scope of this document?

DR# The security section already states that RFC9252 Section 9.3 applies, since that document has a comprehensive description of the various considerations. Is that sufficient ?

Regards,
-Dhananjaya