Re: [bess] PFN questions in rfc4732bis

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Friday, 22 March 2024 at 3:07
> *To: *Jorge Rabadan (Nokia) <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, MPLS Working Group <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *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) <
> [e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Thanks for getting back.
>
> My comments in line with [jorge].
>
>
>
> Jorge
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, March 21, 2024 at 2:41 AM
> *To: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, MPLS Working Group <
> [e-mail]>, [e-mail] <[e-mail]>
> *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.
>