+1
On Thu, Feb 17, 2022 at 1:11 PM Rabadan, Jorge (Nokia - US/Sunnyvale) < [email protected]> wrote: > 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]> 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] > 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
