Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Keyur, gentle reminder –

Could you please take a look at the recent version:

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-22

pls check and Ack, whether your comments are all taken care of?

Thanks
Kaliraj



Juniper Business Use Only
From: Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Sunday, January 21, 2024 at 10:10 PM
To: Kaliraj Vairavakkalai <[e-mail]>, Keyur Patel <[e-mail]>, Susan Hares <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Reshma Das <[e-mail]>
Cc: Jeff Haas <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
[External Email. Be cautious of content]

Keyur, I incorporated these comments in draft version -20.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-20<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-20__;!!NEt6yMaO-gk!BrSTorDT7Bb1kWChlxKgUnosFXZY1pAx6tBrmfJ0CeivP2XxHuva47iHSd_i0LCZrSwpAPEvTQoTK13HQtANRsmQs0FJTCrn$>

Please take a look.

Thanks
Kaliraj


Juniper Business Use Only


Juniper Business Use Only
From: Idr <[e-mail]> on behalf of Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Sunday, January 21, 2024 at 4:14 AM
To: Keyur Patel <[e-mail]>, Susan Hares <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Reshma Das <[e-mail]>
Cc: Jeff Haas <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
[External Email. Be cautious of content]

Hi Keyur,

Happy new year. Pls see inline for responses KV2>

Thanks
Kaliraj



Juniper Business Use Only


Juniper Business Use Only
From: Keyur Patel <[e-mail]>
Date: Thursday, January 11, 2024 at 3:43 PM
To: Kaliraj Vairavakkalai <[e-mail]>, Susan Hares <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Reshma Das <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>, Jeffrey Haas <[e-mail]>, Jeff Haas <[e-mail]>
Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
[External Email. Be cautious of content]

Hi Kaliraj,

HNY! Thanks for the note and apologies for the delayed response. My responses are inlined #Keyur




Juniper Business Use Only
From: Kaliraj Vairavakkalai <[e-mail]>
Date: Saturday, December 16, 2023 at 2:13 AM
To: Susan Hares <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Reshma Das <[e-mail]>
Cc: Keyur Patel <[e-mail]>, "Dongjie (Jimmy)" <[e-mail]>, Jeffrey Haas <[e-mail]>, Jeff Haas <[e-mail]>
Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

Hi Susan, Keyur, please see inline for responses. KV>

Thanks
Kaliraj




Juniper Business Use Only
From: Susan Hares <[e-mail]>
Date: Thursday, December 14, 2023 at 3:32 PM
To: Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <[e-mail]>, Reshma Das <[e-mail]>
Cc: Keyur Patel <[e-mail]>, Dongjie (Jimmy) <[e-mail]>, Jeffrey Haas <[e-mail]>, Jeff Haas <[e-mail]>
Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
[External Email. Be cautious of content]

Kaliraj, Nats, and Reshma:

Here’s the review that Keyur created on 12/8/2023.  Please send me comments on the review.  You should also  reply to Keyur’s when he sends it to [e-mail]<mailto:[e-mail]>.

Sue

From: Susan Hares
Sent: Thursday, December 14, 2023 8:17 AM
To: Keyur Patel <[e-mail]>
Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

Keyur:

I apologize for not sending this on Monday.  Please send this to the IDR list as your review comments (chair).

Cheerily, Sue

From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 11, 2023 9:19 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Fwd: Review on - draft-ietf-idr-bgp-ct-18





Begin forwarded message:
From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Date: December 8, 2023 at 12:13:37 PM PST
To: [e-mail]<mailto:[e-mail]>
Subject: Re: Review  on - draft-ietf-idr-bgp-ct-18

Forgot to mention that I will send it to authors as well (as have been chatting with them).

I haven’t told them but the draft does need serious work.

From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 8, 2023 at 12:12 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Review on - draft-ietf-idr-bgp-ct-18

Comments attached. Apologies for typos and any other issues. 😊


1)

Section 1.

 <snip>

The mechanisms defined in this document are agnostic to the tunneling

   technologies.  These can be applied homogeneously to intra-domain

   tunneling technologies used in brownfield networks as well as

   greenfield networks.  E.g.  MPLS Traffic Engineering (TE) or Segment

   Routing (SR)).

 <snip>

#Keyur: SRv6 is not supported. GRE and Vxlan not support so really not agnostic to  tunneling. Can we replace agnostic?



KV> Tunnels like SRv6, GRE, VxLan etc are also supported in the architecture. The architecture supports any kind of tunnels.

KV> The tunneling mechanism is made transport-class aware and they install their tunnel route in corresponding TRDB, as explained in Sec 4.1.

KV> SRv6 support is specifically explained in detail in draft-ietf-idr-bgp-ct-srv6-00, referenced in Sec 7.13 in BGP-CT draft-v18.



#Keyur: Can you call out in that case that the architecture supports all tunnels and has not tunnel based limitations?



KV2> That is what ‘agnostic to the tunneling  technologies’ means.

KV2> I will reword it to:

The mechanisms defined in this document are agnostic to the tunneling

Technologies, which makes the architecture apply to any kind of tunnel.



2)

Section 1.

<snip>

The constructs defined in this document are used to classify and

   group these intra-domain tunnels based on their TE characteristics

   (e.g., low latency), into identifiable classes, thus making them

   "intent-aware".

<snip>

#Keyur: Is it TE characteristics or more Services specific intent?



KV> It is TE characteristics. The tunnels have specific TE characteristics. The service-intent maps to some such TE-characteristics.

KV> Operators consider a set of TE characteristics to denote a certain TransportClass. The Service Intent is what TC to use as primary

KV> and what TC to use as fallback.. etc.



#Keyur: But the draft doesn’t list out TE characteristics. Infact your service intent could be broader than just mapping to TE-characteristics (i.e providing internet or an ipsec as a service over a common backbone).



KV2> Sec 4.1 gives examples of TE characteristics that are used to classify tunnels into Transport Classes.

KV2> the specific TE characteristics theselves don’t need to be defined in BGP CT, because they are properties

KV2> of the underlying tunneling mechanism. CT is just using those existing characteristics to classify into TCs.





3) Minor nit

Section 2.1.

<snip>

BGP Community Like Attribute (CLA)

<snip>

#Keyur: The use of "Like" in the attribute naming is confusing. Can we choose a better name please?



KV> It is used to suggest all BGP attributes that carry community/extended-community/large-community

KV> This term is used in draft-zzhang-idr-bgp-rt-constrains-extension-03

KV> Please suggest a different name. “Community Carrying Attribute”?



#Keyur: Ok with Community Carrying Attribute. 😊



KV2> Ok, will change.



4) Minor Nits

Section 3.0.

#Keyur: Please Define L1, L2, L3, L4.

                Please Define IP1, IP2, IP3, IP4 (BGP-LU/underlay prefixes)



KV> IP1, IP2, IP3 are Service family Prefixes (e.g. AFI/SAFI: 1/1). It is shown in the figure as ‘INET Service’. I can clarify this in the text.

#Keyur: Thanks.



5)

Section 3.0.

<snip>

BGP CT family carries transport prefixes across tunnel domain

   boundaries (e.g., in inter-AS Option C networks), which is parallel

   to BGP LU (AFI/SAFIs 1/4 or 2/4).

<snip>

#Keyur: Please consider removing (e.g., in inter-AS Option C networks).



KV> it is helpful in clarifying BGP CT is applicable to option-C networks.

KV> This was added based on suggestions in some previous reviews.



#Keyur: I was suggesting broader scope that includes option-C as well.



KV2> when BGP CT routes cross tunnel domain boundaries, that specific scenario is option-C

KV2> that is what the above statement scope is. I will note “BGP CT family (SAFI-76)”.

KV2> anyway, I see this comment was taken care of in -19.



6)

Section 3.0.

<snip>

It disseminates "Transport Class"

   information for the transport prefixes across the participating

   domains, which is not possible with BGP LU.

<snip>

#Keyur:This line is confusing. The confusion to me is as to why BGP LU doesn’t do it.



KV> BGP LU doesn’t do it, because of Path-hiding (it doesn’t have a distinguisher in NLRI)

KV> And it doesn’t carry something like a TC-RT, which plays the role of RT as-well as Mapping community.

KV> we could use some community and user configured policies to achieve all that, but CT automates it.



#Keyur: And that is why (community and user configured policies is one way to achieve) its confusing. Maybe consider removing the line “which is not possible with BGP LU”.



KV2> I will clarify the sentence as: “It disseminates "Transport Class" information for the transport prefixes across the participating domains while avoiding the need of per transport class loopback, which is not possible with BGP LU.”.



7)

Section 3.0.

IP1, IP2, IP3 and IP4 are BGP-LU color routes. They are typically used for creating

the slice/intent based forwarding as described.



KV> IP1, IP2, IP3 are AFI/SAFI:1/1 routes, as explained above. Not BGP LU.



<snip>

Overlay routes carry sufficient indication of the desired Transport

   Classes using a BGP community which assumes the role of as a "Mapping

   Community".  A Resolution Scheme is identified by its "Mapping

   Community", where its configuration can either be auto-generated

   based on TC ID or done manually.

<snip>

#Keyur: This part is collapsed in the picture and so is confusing. Maybe some clarifying text can help.



KV> The pic is an eye candy summary of the various pieces in the architecture.

KV> And this text introduces and explains those pieces. If you have any suggestion text

KV> with imrpvoed clarity, pls share. I will also try to improve it..



#Keyur: Thanks.



8)

Section 3.0.

#Keyur: Minor Nits- Define Tunnel Endpoint Address (EP) in the section 2



KV> OK. Will do.



9) Clarification

Section 4.2.

<snip>

An implementation may realize the TRDB e.g., as a "Routing Table"

   referred in Section 9.1.2.1 of RFC4271 (https://www.rfc-<https://urldefense.com/v3/__https:/www.rfc-__;!!NEt6yMaO-gk!H5xAizYTbAscjeaCZzXyuDEPMfXGGucLysbOf6O7E5VALFr-EWE7Oeem9uTtl8FiTalIqoT6jJSK8ik$>

   editor.org/rfc/rfc4271#section-9.1.2.1) which is "only" used for

   resolving next hop reachability in control plane with no footprint in

   forwarding plane.  However, an implementation may choose a different

   methodology to realize this logical construct while still adhering to

   the procedures defined in this document.

<snip>

#Keyur: This seems very rsvp specific? In case of pure segment routing where the control plane does carry nexthop specific information, this won’t be correct. Suggest removing everything from "with no footprint..."



KV> Its not RSVP specific. Even SRTE routes in a TRDB don’t need to be installed to FIB as a FEC/destination. Only if they are resolved over by another overlay route,

KV> it will be installed as nexthop. I can try to clarify this in the text.



10)

Section 4.2.

<snip>

SNs or BNs originate routes for 'Classful Transport' address family

   from the TRDB.  These routes have NLRI "RD:Endpoint", Transport Class

   RT and an MPLS label (or an identifier that represents an equivalent

   of a label in a different forwarding architecture).

<snip>

#Keyur: It could be more than an identifier (Tunnel class and tunnel parameters). Curious as to why mention the text in ()?



KV> text in () refers to other encaps like SID in SR forwarding architecture. It is denote support for different forwarding architectures.



#Keyur: Can we remove the text in question for better readability?



KV2> would like to leave it there for completeness.



11) Major Comment

Section 4.3.

<snip>

A BGP speaker that implements RT Constraint Route Target Constraints

   [RFC4684] MUST apply the RT Constraint procedures to the Transport

   Class Route Target Extended community as well.

<snip>

#Keyur:

1) This text needs to be augment to account bunch of SAFIs defined in this draft.



KV> Following text mentions that:

“Constrained Route Distribution mechanisms as specified in Route Target Constraints<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-18.html*RFC4684__;Iw!!NEt6yMaO-gk!H2lcpwRG381uji2MprQIi_eJFGahDo4DFF3Ls3GCrEOGcpMthzVfn0U7ozdml5UlPAH_5C7dyqCLiQ$> [RFC4684<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-18.html*RFC4684__;Iw!!NEt6yMaO-gk!H2lcpwRG381uji2MprQIi_eJFGahDo4DFF3Ls3GCrEOGcpMthzVfn0U7ozdml5UlPAH_5C7dyqCLiQ$>] can be applied to BGP CT routes using its Transport Class Route Target Extended community.”.

KV> May be I can add SAFI 76 value specifically in it.



#Keyur: Ack.





2) If these routes need to be leaked into EBGP domains.. RTC doesn’t provide multi-paths by default and so implementation should give some guidance.



KV> RTC has number of external-paths config control. Which is used for CT routes also.



#Keyur: You may still need text as RTC doesn’t provide multi-paths?



KV2> will add following text: “A BGP speaker that implements Route Target Constrain<https://ttqc-web01.juniper.net/~kaliraj/draft-ietf-idr-bgp-ct.html#RFC4684> [RFC4684<https://ttqc-web01.juniper.net/~kaliraj/draft-ietf-idr-bgp-ct.html#RFC4684>] MUST also apply the RTC procedures to the Transport Class Route Target Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 and 2/76). Further, when processing RT membership NLRIs received from external BGP peers, it is necessary to consider multiple EBGP paths for a given RTC prefix, for building the outbound route filter, and not just the best path. An implementation MAY provide configuration to control how many EBGP RTC paths are considered.”



3) Also guidance should be provided about filtering of this community where needed (as it is defined as a transitive community).



KV> Since CT follows RFC8212 by default, explicit import/export policies are needed to send/receive CT routes with this community across EBGP boundaries.

KV> and the routes propagate only until the sessions where CT SAFI is negotiated, and don’t intermix with other SAFIs. I think these sections cover this aspect?



#Keyur: RFC8212 doesn’t provide guidance on stripping transitive communities. You may have to provide it as part of this draft?

KV2> will add following text: “The Transport Class Route Target Extended community is carried on Classful Transport family routes and is used to associate them with appropriate TRDBs at receiving BGP speakers. Transport Target is carried unaltered on the BGP CT route across BGP CT negotiated sessions except for scenarios described in Section 11.2.2. Implementations should provide policy configuration to perform match, strip or rewrite operations on Transport Target just like any other BGP community.”



12)

Section 5.1.

#Keyur: I like the concept in section 5.1 but any reason why mapping community is not preferred to be one of color, transport target, or a RT? If the mapping community is preferred (as it seems) then some descriptive text would help.



KV> Mapping community is not a IANA type, it is a role. So yes, either of these communities (color-ext-community, transport-class-RT) can be used as a Mapping-community.

KV> This is what is described in Sec 5.1. Not sure what I am missing..



#Keyur: The text here is generic. What happens if multiple communities are carried in a single attribute? Any guidance on which one to be used first?



KV2> The order does not matter. As explained by text in 5.1: “If a route contains more than one Mapping Community, it indicates that the route considers these distinct Mapping Communities as equivalent in Intent.Overlay routes SHOULD NOT contain more than one Mapping Community. Conflicting multiple Mapping Communities may result in inconsistent route selection.If more than one distinct Mapping Communities on an overlay route map to multiple Resolution Schemes with dissimilar Intents at a receiving node, it is considered a configuration error.”



13)

Section 6.2.

#Keyur: What are error conditions in cases the nexthop length is other than specified? Will these routes accepted or still ignored?



KV> rfc7606 Sec 7.11 talks about nexthop length error in MP_REACH. I don’t think bgp-ct draft needs to redefine that. Same logic should apply here also, since we are using the same MP_REACH attribute.



#Keyur: As part of this draft you have specified behavior of 4, 16, 32, 24, 48, 12.  Possible to add a line that says “anything else is an error and error handling should be done according to 7606 w treat as withdraw” ?



KV2> this was addressed in -19. Further clarified the text to: “If the length of the Next hop Address field contains any other values, it is considered an error and is handled as per RFC 7606 Section 7.11.”

RFC-7606 specifies ‘session-reset for nexthop length errors.



14) Major Comment

Section 6.4.

<snip>

In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI

   128 (BGP VPN) for AFIs 1 or 2 to carry these transport routes because

   it is operationally advantageous to segregate transport and service

   prefixes into separate address families.  For e.g., such an approach

   allows operators to safely enable "per-prefix" label allocation

   scheme for Classful Transport prefixes, typically with a space

   complexity of O(1K) to O(100K), without affecting SAFI 128 service

   prefixes, with a space complexity of O(1M).  The "per prefix" label

   allocation scheme keeps the routing churn local during topology

   changes.

<snip>

#Keyur:

1) This suggest don’t use L3VPN safis. But if L3VPN SAFI is enabled, what are the implications? Some text to that point would be useful.

KV> No, it doesn’t suggest not to use L3VPN SAFI. It is just explaining why a new SAFI 76 was created instead of overloading SAFI-128 for carrying Transport-layer routes.

KV> SAFI 128 is indeed used with SAFI 76.





#Keyur: You could try and make text a bit more clear. Also what happens if L3vpn is enabled in the network. Some text to that point would be helpful as well.



KV2> this was addressed in -19 by following text: “Service routes continue to be carried in their existing AFI/SAFIs without any change, e.g., L3VPN (AFI/SAFI: 1/128 and 2/128), EVPN (AFI/SAFI: 25/70 ), VPLS (AFI/SAFI: 25/65), Internet (AFI/SAFI: 1/1 or 2/1). And resolve over BGP CT (AFI/SAFI: 1/76 and 2/76) transport routes.”



2) What about other VPN SAFIs (Layer2/EVPN)? Either it has to be out of scope or defined?

KV> Yes all service families (EVPN, L2VPN, VPLS) are used with SAFI 76. Just like SAFI 4. All of this is implemented and qualified.



#Keyur: Can you please change text? 128 is ONLY BGP MPLS VPN safi. 😊 EVPN is 70 😊



KV2> above mentioned text has these values only. Pls clarify.



15)

Section 7.2.

<snip>

this route SHOULD NOT be advertised to the IBGP core that contains

      the tunnel, using policy configuration.  Impact of not prohibiting

      such advertisements is outside the scope of this document.

<snip>

#Keyur: I am assuming this line has an exception to a RR and Confeds?



KV> No, it doesn’t exclude RR-peers/IBGP-peers-in-Confed. Basically, Tunnels in a domain need to be exported out in BGP to other adjacent domains only, not the same domain that contains the tunnel.



#Keyur: I am confused. Are you suggesting that such route announcements SHOULD not be done by a RR for example? Can you clarify please?



KV2> No. an ASBR should not redistribute a RSVP-TE/SRTE tunnel to a RR in the same domain.



16)

Section 7.3.

<snip>

The resolution scheme for a Transport Class RT with

      Transport Class ID "C1" contains TRDB for Transport Class with

      same ID.  In cases where Transport Class "C1" tunnels are not

      available in a domain, the administrator MAY customize the

      resolution scheme to map to a different set of transport classes

      available in that domain.

<snip>

#Keyur: How does this work with section 4.3 where RT Constrain is enabled?



KV> RTC will work for both the TCs C1 and availble-TC-ID. Because both those TCs are configured, RTC membership request will be advertised for both TC-RTs.

KV> Rules specified in RTC RFC apply for these cases also..



#Keyur: I didn’t see any text to that point you cited?



 KV2> rfc4684 sec 3.2 : “As indicated above, the inter-AS VPN route distribution graph, for a
   given route-target, is constructed by creating a directed arc on the
   inverse direction of received Route Target membership UPDATEs
   containing an NLRI of the form {origin-as#, route-target}.”
KV2> Basically for each imported RT, the RTC routes are generated. Similarly, for each imported Transport-Target, the RTC routes are generated.


17)

Section 7.3

<snip>

RD is stripped by the ingress node

      from the BGP CT NLRI prefix RD:EP when a BGP CT route is added to

      a TRDB.  So that service routes can resolve over this BGP CT

      tunnel route for EP.  This step applies only if the Transport

      Class RT is received on a BGP route in address family with SAFI

      76.

<snip>

#Keyur: Isn’t this an implementation specific text?



KV> No. TRDB only contains the IP prefix without RD. And these IP routes are used to resolve BGP NHs. So RD should not be there.



#Keyur: But there is no reason why an implementation has to strip RD? it can keep it if it wants? Hence my comment of being implementation specific text.



KV2> BGP CT procedures require stripping the RD, so that nexthop resolution works on a pure IP-prefix, irrespective of which TC is used to resolve. RD must not be used in the nexthop resolution process.



18)

Section 7.4.

#Keyur: What is the purpose of this paragraph. It suggests implicitly that third party nexthops shouldn’t be supported?



KV> No. It just explains how label-swap happens when doing nexthop-self. BGP practices like third-party nexthop or nexthop-unchanged are not prohibited.



#Keyur: Then I suggest either making it clear or removing the text.



KV2> removed ‘nexthop self’ from heading and clarified it in body text.



19) Major Comment

Section 7.7. & 7.7.1.

#Keyur: The looping issue define in 7.7 and 7.7.1 is well understood? The solutions to these looping issues are also well understood. What is the purpose of these sections? The text in 7.7.1 is now updating a Route Reflector RFC for this SAFI? IMHO this text SHOULD be pulled out.



KV> It is tribal knowledge that is not documented in any draft/RFC (I was actualy surprised), And it is very important to document this, because customers may hit it in the field when deploying CT, which uses RRs with nexthop-self. So, documenting it in this draft.



#Keyur: How is the deployment of CT with nexthop-self going to be any different from other SAFI routes with nexthop-self? Btw the tribal knowledge is well understood across industry and you could write a separate draft if you feel strongly about it. 😊



KV2> We cannot take it for granted. It needs to be documented somewhere. Currently it is this draft.



20)

Section 7.8.

#Keyur: Does the Mapping community need to be tied with RTC?



KV> No. Mapping-community doesn’t interact with RTC. Only the TC-RT interacts with RTC because it is a RT.





21) Major Comment

Section 7.10.

<snip>

It should be noted that in such cases "Transport Class ID/Color" can

   exist in multiple places on the same route, and a precedence order

   needs to be established to determine which Transport Class the

   route's next hop should resolve over.  This document suggests the

   following order of precedence, more specific scoping of Color

   preferred to less specific scoping:



      Transport Class ID SubTLV, in MultiNexthop Attribute.



      Color SubTLV, in Tunnel Encapsulation Attribute.



      Transport Target Extended community, on BGP CT route.



      Color Extended community, on BGP service route.



<snip>

#Keyur: This draft has MNH in informative section. :)



KV> It is mentioned to provide comprehensive and unambiguous rules wrt deciding ‘effective color’. I think this kind of reference is OK for informative?



#Keyur: Section 7.10 talks about Interaction with BGP Attributes specifying Nexthop Address and Color. As part of this section the document suggest the order of precedence which has rules. If you want multinexthop attribute there you want the draft as a normative (and not as an informative). I will let Jeff chime in here. 😊



KV2> Sure. I think Sue had also responded to this.



22)

Section 7.13.

#Keyur: SRv6 support. Not sure what the section is trying to say from the normative pov?



KV> It is pointing to the document that explains in detail the SRv6 procedures for BGP CT.

#Keyur: You could simply says it is covered in a separate doc and out of scope. Instead you have a normative language for SRv6. Any reason to keep it in this section?



KV2> I think giving an informational pointer to the document is better than hand waving it as out of scope.



23)

Section 7.14.

#Keyur: Error handling may need more serious look.


KV> I cant think of any other error-handling scenarios. Pls send suggestions or text.

KV> Thanks for the detailed review!.

#Keyur: Ack. Will do one more pass soon.

     KV2> Thanks.

[EXTERNAL]