I agree with Vasilenko. The meaning of the label is given by the encapsulation, e.g. for the EVPN family, label=VNI if the bgp encapsulation extended community indicates VXLAN, and label=MPLS-label if the encapsulation indicates MPLS.
In this document, the label is a transposed function if the encapsulation indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with the approach used by SAFIs that support different identifiers in the label field. Thanks. Jorge From: Vasilenko Eduard <[email protected]> Date: Thursday, February 17, 2022 at 8:30 AM To: Warren Kumari <[email protected]>, Ron Bonica <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10 Hi all, About this point: 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This is surprising because MPLS appears nowhere in the forwarding plane. Maybe we shouldn't advertise an MPLS label? I have seen in some BESS documents that this field is called “Service Label”, not “MPLS label”. Because MPLS does not exist in VxLAN too, but the same label is used. Hence, 1) is easy to resolve. It is just a terminology correction that makes sense in principle for all BESS documents. Eduard From: BESS [mailto:[email protected]] On Behalf Of Warren Kumari Sent: Thursday, February 17, 2022 4:37 AM To: Ron Bonica <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10 On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker <[email protected]<mailto:[email protected]>> wrote: Reviewer: Ron Bonica Review result: Not Ready I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>. Major issues: 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This is surprising because MPLS appears nowhere in the forwarding plane. Maybe we shouldn't advertise an MPLS label? 2) In Section 3.2.1 the draft says: BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in MPLS label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification SHOULD provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document. Much thanks to Ron for this OpsDir review -- I'd completely missed the above points, and they are important to address. W s/BGP speakers that do not support this specification/Legacy BGP implementations It seems that this isn't backwards compatible unless either: - the SHOULD becomes a MUST - the mechanism is described in this document 3) I concur with Warren Kumari's DISCUSS -- last-call mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/last-call -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
