Hi Menachem, thank you for sharing your thoughts on the proposed updates. Please find my follow-up notes below tagged GIM2>>.
Regards, Greg On Fri, Mar 29, 2024 at 6:17 AM Menachem Dodge <mdo...@drivenets.com> wrote: > Hello Greg, Jorge, All, > > > > I support these changes. > > > > In section 7.11.1 it is the previos reference to the Control Word that > needs to be modified: > > > > > > *OLD TEXT* > > The EVPN L2-Attr Extended Community, when added to Inclusive > > Multicast route: > > * per-EVI attributes MTU, Control Word and Flow Label are conveyed, > > and; > > > > * per-ESI-and-EVI attributes P, B MUST be zero. > > > > *NEW TEXT* > > > > The EVPN L2-Attr Extended Community, when added to Inclusive > > Multicast route: > > * per-EVI attributes MTU, Control Word (SHOULD be set to 1) and Flow > Label are conveyed, > > and; > > > > * per-ESI-and-EVI attributes P, B MUST be zero. > > GIM2>> Thank you for proposing the update. I have a question about the use of the normative language. The intention of draft-ietf-mpls-1stnibble is to deprecate the use of non-CW encapsulations of non-IP payload. Do you think that the note can be changed to '(MUST be set to 1)' to conform to draft-ietf-mpls-1stnibble? > > > > > As Jorge mentioned, when the EVPN L2-Attr Extended Community is included on > Ethernet A-D per > > EVI route then the MTU, Control Word and Flow Label are not in use so that > is why “they MUST be zero”, > > in the second reference to these bits in Section 7.1.1 > > GIM2>> Could you kindly help me understand this case? Does "Control Word is not in use" mean that it is not checked, i.e., ignored? If that is the case, then I agree with Jorge and you. > > > ============ > > In addition to what you have written below on Section 18: > > > > In my opinion, the following sentence should either be removed or updated: > > > > > > *OLD TEXT* > > > > If a network (inclusive of all PE and P nodes) uses entropy labels > > per [RFC6790] for ECMP load balancing, then the control word MAY > > NOT be used. > > > > *NEW TEXT* > > If a network (inclusive of all PE and P nodes) uses entropy labels > > per [RFC6790] for ECMP load balancing, then the control word SHOULD > still > > be used. > > GIM2>> Thank you for pointing this out. I think that the source of entropy information, e.g., entropy label, PW FAT, label stack, or something else, must not be linked to the use of CW. I think that the sentence can be removed altogether without loss of any value. WDYT? > > > > > =============== > > > > In addition RFC 8214 needs to be addressed. This was also mentioned at the > IETF Meeting in Brisbane. > > > > > > Thank you kindly. > > > > Best Regards, > > Menachem > > > > > > > > *From: *BESS <bess-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Friday, 22 March 2024 at 3:07 > *To: *Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > *Cc: *draft-ietf-bess-rfc7432...@ietf.org < > draft-ietf-bess-rfc7432...@ietf.org>, draft-ietf-mpls-1stnib...@ietf.org < > draft-ietf-mpls-1stnib...@ietf.org>, MPLS Working Group < > mpls-cha...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, > bess@ietf.org <bess@ietf.org> > *Subject: *Re: [bess] PFN questions in rfc4732bis > > CAUTION: External E-Mail - Use caution with links and attachments > > > > Hi Jorge, > > thank you for your expedient feedback to the proposed updates. I have > several follow-up notes logged below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Fri, Mar 22, 2024 at 9:30 AM Jorge Rabadan (Nokia) < > jorge.raba...@nokia.com> wrote: > > Hi Greg, > > > > Thanks for getting back. > > My comments in line with [jorge]. > > > > Jorge > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, March 21, 2024 at 2:41 AM > *To: *draft-ietf-bess-rfc7432...@ietf.org < > draft-ietf-bess-rfc7432...@ietf.org>, draft-ietf-mpls-1stnib...@ietf.org < > draft-ietf-mpls-1stnib...@ietf.org>, MPLS Working Group < > mpls-cha...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org> > *Subject: *PFN questions in rfc4732bis > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > <https://urldefense.proofpoint.com/v2/url?u=http-3A__nok.it_ext&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=f9mqEJ1P1fyT-GceDqOAwZOtLN9vYtkDjjIhXGhqATDiV_HIDj6ioNdEIGZ1iG6E&s=qeFSRuebBlU8uRxuQl7EpShgZo-ty14SWIfLtA9OWLQ&e=> > for additional information. > > > > Dear All, > > following the presentation of our work on the Post-stack First Nibble > (PFN) to the BESS WG at IETF-119, I took an AP to come with questions and > proposals for the authors of rfc4732bis. I thought that once the authors of > the respective drafts converge on the updates, we share them with the BESS > WG. Below, please find my notes: > > · rfc4732bis recognizes MPLS Entropy label as a source of entropy > for load-balancing. 1stnibble draft also refers to RFC 6391 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6391_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=f9mqEJ1P1fyT-GceDqOAwZOtLN9vYtkDjjIhXGhqATDiV_HIDj6ioNdEIGZ1iG6E&s=5OAGJEbhyQZ_lv9PWvOvDTUQ7LGgMT9hpw9B5wXj4VQ&e=> > as another optional source of the entropy for load-balancing. Would it be > helpful adding a refgerence to RFC 6391 in the discussion of the > load-balancing in rfc4732bis? > > [jorge] that should be fine. > > · The definition of the C flag in Section 7.11 is as follows: > > C If set to 1, a control word [RFC4448] MUST be present > > when sending EVPN packets to this PE. It is > > recommended that the control word be included in the > > absence of an entropy label [RFC6790]. > > To reflect the position expressed in the 1stnibble draft, perhaps the > following update is appropriate: > > NEW TEXT: > > C If set to 1, a control word [RFC4448] MUST be present > > when sending EVPN packets to this PE. > > END > > [jorge] I personally see no issue with the above update if the other > co-authors are ok too. > > · Furthermore, the following update may be considered in Section > 7.11.1: > > OLD TEXT: > > * per-ESI-and-EVI attributes P, B are conveyed, and; > > > > * per-EVI attributes MTU, Control Word and Flow Label MUST be zero. > > NEW TEXT: > > * per-ESI-and-EVI attributes P, B are conveyed; > > > > * per-EVI attributes MTU, and Flow Label MUST be zero, and; > > > > * per-EVI attribute Control Word MUST be set. > > [jorge] I don’t think the above change is correct. The reason is this > refers to the L2 attributes extended community sent along with the AD per > EVI routes in EVPN ELAN services (not EVPN VPWS), and this route is purely > used for multi-homing. The non-multihoming related attributes MUST be zero, > since they are signaled along with the inclusive multicast ethernet tag > route. So the current text is correct. > > GIM>> I acknowledge that the use of the Control Word in this scenario that > I am not familiar with. The motivation for proposing this update is based > on my itnerpretation of the definition of the C flag in Section 7.11 (see > above) and the intention of the draft-ietf-mpls-1stnibble to deprecate the > use of non-PSH encapsulations of non-IP payload. As I understand the > current text in question, by setting the Control Word to zero the control > plane will produce packets without PSH (PW CW). If that is correct, then > that is precisely what our work on the PFN aims to exclude. > > > > · The text in Section 18, following the first paragraph, may be > replaced with the following text: > > NEW TEXT: > > In order to avoid frame misordering described in the above paragraph, > > and following conclusions of [I-D.ietf-mpls-1stnibble], the control word > > MUST be used in all use cases. > > END > > [jorge] so basically you are suggesting to use CW always and use MUST as > normative language, irrespective of a) the underlaying transport, b) > whether entropy label is used and c) whether deep packet inspection for > ECMP is used. The only problem that I see is that, till now, > implementations not supporting CW were still compliant with RFC7432 and > this bis draft. Now it would not be the case anymore. > > I personally think it might be better to use a SHOULD, e.g.: > > NEW: > > In order to avoid frame misordering described in the above paragraph, > > the control word SHOULD be used in all use cases > [I-D.ietf-mpls-1stnibble]. > > END > > > > But I’d like to hear from other coauthors and the BESS WG to see if this > is ok. > > Finally, if we were to add [I-D.ietf-mpls-1stnibble] as a reference, it > would be an informative reference. > > GIM>> We've used SHOULD in RFC 8469 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc8469&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=f9mqEJ1P1fyT-GceDqOAwZOtLN9vYtkDjjIhXGhqATDiV_HIDj6ioNdEIGZ1iG6E&s=TWTOL85TMzc33zd31_A7GIj_GuBBrPesJZflBXCJ3DQ&e=>, > and believe that it is time to deprecate the practice of non-PSH > encapsulation of non-IP payload in MPLS altogether, and use PSH/CW in all > scenarios for non-IP payload. I'll note that the deprecation, as defined in > draft-ietf-mpls-1stnibble, applies only to new deployments and > implementations. (I believe that an intellegent implementation that > supports non-PSH(non-CW) encapsulation is also capable of using PW CW > encapsulation.) > > > > Please share you questions, comments, and suggestions. > > > > Regards, > > Greg > > > ------------------------------ > > This email has been scanned for spam and viruses by Proofpoint Essentials. > Click here > <https://eu1.proofpointessentials.com/app/report_spam.php?mod_id=11&mod_option=logitem&report=1&type=easyspam&k=k1&payload=53616c7465645f5f60f15747fb7908c8fb419e6513cfbff7920b0b9e085ea8edb750e951101ff33b78e0d566c522e35822e84da92e6bddb9373b86988e5d48ac73c1da256dabdf430c04ed8f22e3ee0dea91c3199bcd5841a6f323bb9c65b5303a5da056a39c428f4643cbb70c35570ecd4ef00e69183d89fbc772c0af4012ac4d97510c46cc5bde0aeff7b5d895c00bad8201f91e4f2776a1e6ef1846392848> > to report this email as spam. >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
