[bess] Re: Ketan Talaulikar's No Objection on draft-ietf-bess-mvpn-evpn-sr-p2mp-16: (with COMMENT)
Got it. Will clarify. Rishabh. On Tue, Nov 11, 2025 at 5:59 PM Ketan Talaulikar wrote: > Hi Rishabh, > > I was simply suggesting to switch the ordering of text so that the > non-Transposition case is explained first and then the transposition one > (with the reasoning of BGP efficient encoding). It might perhaps help > clarify the usage of the MPLS Label field. And like I said, up to the > authors since there is nothing technically wrong or unclear in this matter. > > Thanks, > Ketan > > > On Tue, Nov 11, 2025 at 5:39 PM Rishabh Parekh wrote: > >> Ketan, >> We will add normative reference to RFC 9819. As for the "MPLS Label" >> field value, RFC 9252 Section 5 (VPN/IP) specifies Implicit NULL when the >> Transposition scheme is not used, but Section 6.3 (EVPN IMET) already has >> text stating "... it is set as defined in RFC 6514" when the Transposition >> Scheme is not used; however, we can add the clarifying text. >> >> Thanks, >> Rishabh. >> >> On Tue, Nov 11, 2025 at 3:36 PM Ketan Talaulikar via Datatracker < >> [email protected]> wrote: >> >>> Ketan Talaulikar has entered the following ballot position for >>> draft-ietf-bess-mvpn-evpn-sr-p2mp-16: No Objection >>> >>> 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-bess-mvpn-evpn-sr-p2mp/ >>> >>> >>> >>> -- >>> COMMENT: >>> -- >>> >>> Thanks to the authors and the WG for their work on this document. >>> >>> I am updating this ballot following the latest document update which >>> addresses >>> my comments. My thanks to the authors for this very helpful update. >>> >>> I would like to share the following further comments on v16 of the >>> document: >>> >>> 1) Please introduce normative reference to rfc9819 in addition to >>> rfc9252 when >>> referencing ESI filtering for EVPN with SRv6 (i.e., End.DT2M with >>> Arg.FE2) >>> since that RFC updates the base rfc9252. >>> >>> 2) For all use of the "MPLS Label" field in the PTA for SRv6, it would >>> be good >>> to say that the value 0 is put in that field per RFC6514 and the SRv6 >>> SID is >>> placed in the BGP Prefix SID appropriate TLV. And then state that only >>> when >>> transposition scheme is used for efficient BGP encoding, that the whole >>> or >>> portion of the function part of the SRv6 SID is encoded in the MPLS Label >>> field. This is just a suggestion to clarify - I leave it to the authors. >>> >>> >>> >>> ___ >>> BESS mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
[bess] Re: Ketan Talaulikar's No Objection on draft-ietf-bess-mvpn-evpn-sr-p2mp-16: (with COMMENT)
Hi Rishabh, I was simply suggesting to switch the ordering of text so that the non-Transposition case is explained first and then the transposition one (with the reasoning of BGP efficient encoding). It might perhaps help clarify the usage of the MPLS Label field. And like I said, up to the authors since there is nothing technically wrong or unclear in this matter. Thanks, Ketan On Tue, Nov 11, 2025 at 5:39 PM Rishabh Parekh wrote: > Ketan, > We will add normative reference to RFC 9819. As for the "MPLS Label" field > value, RFC 9252 Section 5 (VPN/IP) specifies Implicit NULL when the > Transposition scheme is not used, but Section 6.3 (EVPN IMET) already has > text stating "... it is set as defined in RFC 6514" when the Transposition > Scheme is not used; however, we can add the clarifying text. > > Thanks, > Rishabh. > > On Tue, Nov 11, 2025 at 3:36 PM Ketan Talaulikar via Datatracker < > [email protected]> wrote: > >> Ketan Talaulikar has entered the following ballot position for >> draft-ietf-bess-mvpn-evpn-sr-p2mp-16: No Objection >> >> 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-bess-mvpn-evpn-sr-p2mp/ >> >> >> >> -- >> COMMENT: >> -- >> >> Thanks to the authors and the WG for their work on this document. >> >> I am updating this ballot following the latest document update which >> addresses >> my comments. My thanks to the authors for this very helpful update. >> >> I would like to share the following further comments on v16 of the >> document: >> >> 1) Please introduce normative reference to rfc9819 in addition to rfc9252 >> when >> referencing ESI filtering for EVPN with SRv6 (i.e., End.DT2M with Arg.FE2) >> since that RFC updates the base rfc9252. >> >> 2) For all use of the "MPLS Label" field in the PTA for SRv6, it would be >> good >> to say that the value 0 is put in that field per RFC6514 and the SRv6 SID >> is >> placed in the BGP Prefix SID appropriate TLV. And then state that only >> when >> transposition scheme is used for efficient BGP encoding, that the whole or >> portion of the function part of the SRv6 SID is encoded in the MPLS Label >> field. This is just a suggestion to clarify - I leave it to the authors. >> >> >> >> ___ >> BESS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
[bess] Re: Ketan Talaulikar's No Objection on draft-ietf-bess-mvpn-evpn-sr-p2mp-16: (with COMMENT)
Ketan, We will add normative reference to RFC 9819. As for the "MPLS Label" field value, RFC 9252 Section 5 (VPN/IP) specifies Implicit NULL when the Transposition scheme is not used, but Section 6.3 (EVPN IMET) already has text stating "... it is set as defined in RFC 6514" when the Transposition Scheme is not used; however, we can add the clarifying text. Thanks, Rishabh. On Tue, Nov 11, 2025 at 3:36 PM Ketan Talaulikar via Datatracker < [email protected]> wrote: > Ketan Talaulikar has entered the following ballot position for > draft-ietf-bess-mvpn-evpn-sr-p2mp-16: No Objection > > 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-bess-mvpn-evpn-sr-p2mp/ > > > > -- > COMMENT: > -- > > Thanks to the authors and the WG for their work on this document. > > I am updating this ballot following the latest document update which > addresses > my comments. My thanks to the authors for this very helpful update. > > I would like to share the following further comments on v16 of the > document: > > 1) Please introduce normative reference to rfc9819 in addition to rfc9252 > when > referencing ESI filtering for EVPN with SRv6 (i.e., End.DT2M with Arg.FE2) > since that RFC updates the base rfc9252. > > 2) For all use of the "MPLS Label" field in the PTA for SRv6, it would be > good > to say that the value 0 is put in that field per RFC6514 and the SRv6 SID > is > placed in the BGP Prefix SID appropriate TLV. And then state that only when > transposition scheme is used for efficient BGP encoding, that the whole or > portion of the function part of the SRv6 SID is encoded in the MPLS Label > field. This is just a suggestion to clarify - I leave it to the authors. > > > > ___ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
