Re: [bess] PFN questions in rfc4732bis

[Luc André Burdet <[e-mail]>]

Hi,

I would not mix the definition (bitfield, placement, in new section 7.11.1) from the usage requirements (section 18).

Section 7.11.1 simply defines the location of the flag in an Ext Community – I am not in favour of mixing bitfield definitions with use/conditions for setting those bits. Why is CW special here vs. other flags that have sections describing their use below?

All updates on usage of CW should be in section 81


Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]


From: BESS <[e-mail]> on behalf of Menachem Dodge <[e-mail]>
Date: Sunday, March 31, 2024 at 11:33
To: Greg Mirsky <[e-mail]>
Cc: Jorge Rabadan (Nokia) <[e-mail]>, [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
Hello Greg,

Please see inline. Indicated with MD>>

Thanks,
Best Regards,
Menachem

From: Greg Mirsky <[e-mail]>
Date: Friday, 29 March 2024 at 22:07
To: Menachem Dodge <[e-mail]>
Cc: Jorge Rabadan (Nokia) <[e-mail]>, [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 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]<mailto:[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?

MD>> I am in favor with compliance to the draft, assuming that it will be published as an RFC. However we need to receive agreement from the WG.



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.11.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.


MD>> If you look at th efirst paragraph of section 7.11.1 it says “the L2-Attr Extended
   Community, specified in [RFC8214], is partitioned and a subset of
   information is carried over each Ethernet A-D per EVI and Inclusive
   Multicast routes.”

In this message they are not carried – so ignored if you prefer.


============
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?

MD>> I agree.

===============

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]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Friday, 22 March 2024 at 3:07
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, MPLS Working Group <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Hi Greg,

Thanks for getting back.
My comments in line with [jorge].

Jorge

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 21, 2024 at 2:41 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, MPLS Working Group <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.




________________________________

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=53616c7465645f5f5c51e59877b35ee407ea832879b5f992f2600d6602819b640bbff26eb0be864523f24991443fe59ea293f4fe52f9cf3873e8ecaddbdc704138478f84bd1e808cba282839e7663438729c56e78907b6be4bf37ac311b0b4abffadd921edc517b42c595df9c8b41f5491a5533d4e18400fcae4e14be3ff4e3b92fbafa1e438d6030324d810149293f0b7f62f2d154857bc87b2835b1c39d671> to report this email as spam.