Hi Stephane, should note that "setting the MPLS Label field to zero" may be also interpreted as a valid label, IPv4 Explicit Null Label.
Regards, Greg On Mon, Oct 22, 2018 at 6:47 AM <[email protected]> wrote: > Hi, > > Does anyone disagree with the additional Jakob's statement proposal ? > " The lower order 4 bits SHOULD be sent as 0 and ignored on receipt." > > As an example, in MVPN for PMSI tunnel attribute, we have the following > statement which does not tell anything about the lower order bits: > " If the MPLS Label field is non-zero, then it contains an MPLS label > encoded as 3 octets, where the high-order 20 bits contain the label > value. Absence of an MPLS Label is indicated by setting the MPLS > Label field to zero." > > > Brgds, > > > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Ali Sajassi > (sajassi) > Sent: Tuesday, October 16, 2018 19:30 > To: Jakob Heitz (jheitz); Zhuangshunwan; BESS > Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field. > > > Yes, just the encoding of label value needs to be clear. > > Cheers, > Ali > > > > On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" < > [email protected] on behalf of [email protected]> wrote: > > How about: > The lower order 4 bits SHOULD be sent as 0 and ignored on receipt. > > Regards, > Jakob. > > > -----Original Message----- > From: Zhuangshunwan <[email protected]> > Sent: Monday, October 15, 2018 6:02 PM > To: Jakob Heitz (jheitz) <[email protected]>; BESS <[email protected]> > Subject: RE: Encoding a 20 bit label in a 24 bit field. > > It is good to make this explicit. This ambiguity has led to some > unnecessary interworking problems. > > Should we also need to explicitly define the "bottom of stack" bit in > the low-order bit of the 3-octet label field? > > Thanks, > Shunwan > > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, October 16, 2018 4:21 AM > To: BESS <[email protected]> > Subject: [bess] Encoding a 20 bit label in a 24 bit field. > > We have proposed the following erratum for RFC 7432. > > Opinions? > > Regards, > Jakob. > > > -----Original Message----- > From: RFC Errata System <[email protected]> > Sent: Friday, October 12, 2018 12:37 PM > To: Ali Sajassi (sajassi) <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Giles Heron (giheron) > <[email protected]>; [email protected] > Cc: Krishnamoorthy Arumugham (karumugh) <[email protected]>; > [email protected]; [email protected] > Subject: [Technical Errata Reported] RFC7432 (5523) > > The following errata report has been submitted for RFC7432, "BGP > MPLS-Based Ethernet VPN". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5523 > > -------------------------------------- > Type: Technical > Reported by: Krishnamoorthy Arumugham <[email protected]> > > Section: 7 > > Original Text > ------------- > Clarifications to following sub-sections: > Section 7.1 > Section 7.2 > Section 7.5 > > > Corrected Text > -------------- > Section 7.1: > Add below text to the section 7.1 regarding the encoding of MPLS label: > > "The value of the 20-bit MPLS label is encoded in the high-order 20 > bits of the 3 bytes MPLS Label field." > > Section 7.2: > Add below text to the section 7.2 regarding the encoding of both the > MPLS label fields: > > "The value of the 20-bit MPLS label is encoded in the high-order 20 > bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2.." > > Section 7.5: > Add below text to the section 7.5 regarding the encoding of ESI Label > fields: > > "The value of the 20-bit MPLS label is encoded in the high-order 20 > bits of the ESI Label field." > > > Notes > ----- > MPLS label is a 20-bit value and is stored in a 3 bytes field in a > packet. The 20-bit MPLS label value is generally stored in higher order 20 > bits of the 3 byte label field. The exact encoding to be followed for > storing MPLS label values are not explicitly mentioned in the RFC 7432 > under section 7.1, 7.2 and 7.5 for different types of EVPN routes. This > lead to ambiguity in different implementations. Hence a clarification is > required. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7432 (draft-ietf-l2vpn-evpn-11) > -------------------------------------- > Title : BGP MPLS-Based Ethernet VPN > Publication Date : February 2015 > Author(s) : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. > Isaac, J. Uttaro, J. Drake, W. Henderickx > Category : PROPOSED STANDARD > Source : Layer 2 Virtual Private Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
