[bess] Re: FW: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Greg Mirsky <[e-mail]>]

Hi Menachem,
Thank you for a great explanation of the risk of not using the Control Word
to transport non-IP payloads over the MPLS network. Although very
reasonable, the processing you described might be one possible
implementation of selecting the load-balancing mechanism. But, if I
understand it correctly, the presence of the Control Word is the key and is
a requirement to avoid the possibility of misinterpreting the payload for
IPvX. WDYT?

Regards,
Greg

On Thu, Jun 6, 2024 at 1:13 PM Menachem Dodge <[e-mail]> wrote:

> Hello Greg, Ali,
>
>
>
> I know that there is existing equipment that perform deep packet
> inspection based on the content of the first nibble and not on whether
> there is an entropy label present in the MPLS stack.
>
>
>
> Without a control word, and when the payload is a non-IP packet, such
> equipment may misinterpret the first nibble of the MAC address, if that
> nibble contains a 4 or a *6*, as being an IPv4 or IPv6 payload. This
> equipment would then perform deep packet inspection wrongly and cause
> packets of the same flow to be sent on different paths and arrive out of
> order.
>
>
>
> If the control word is present this equipment will base its load balancing
> on the MPLS stack without deep packet inspection, and then the Entropy
> Label will ensure that correct load balancing is performed, and all packets
> will arrive in order.
>
>
>
> The control word must always be recommended, whether or not Entropy Label
> is present, in order to cater for all types of equipment in the network.
>
>
>
> Kind Regards,
>
> Menachem
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, 6 June 2024 at 19:07
> *To: *Ali Sajassi (sajassi) <[e-mail]>
> *Cc: *Menachem Dodge <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [bess] FW: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
>
> CAUTION: External E-Mail - Use caution with links and attachments
>
>
>
> Hi Ali,
>
> thank you for the detailed response. Please find my follow up notes
> inlined below under the GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jun 5, 2024 at 10:51 PM Ali Sajassi (sajassi) <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> The questions that was asked initially are different that your questions.
> But let me answer them all here.
>
>
>
> The initial question was why not use the control word even when entropy
> label is used by all network nodes and my answer is that I don’t see a need
> for it and if you do, can you explain why we need the control word when
> there is no possibility of out of order delivery in the presence of ECMP
> when the network uses entropy label.
>
> GIM>> I agree, if it is certain that all the PEs and Ps are capable of
> handling an Entropy label and all the PEs apply it in the EVPN
> encapsulation, then the use of the Control Word is optional. But I cannot
> find in the draft that that is explicitly explained.
>
>
>
> The text in 7.11 says that the control word should be used in absence of
> entropy label.
>
> GIM>> And that is not a requirement but only a recommendation concerns me.
> I believe that based on draft-ietf-mpls-1stnibble
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2D1stnibble_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=aOCSuFd_bCQBCzyP6SgvBbSAx4Jq9VosWvd_j8YgkpnNtpEVodJoPk1FvbeR_0tS&s=1twIXWICelUOVaOEnnq8GXTIMBjlu_ESYzHlub4r5VI&e=> it
> must be a requirement.
>
>
>
> Regarding your suggestion of the control word must be enabled always, it
> should not and it should be per operator control. Imagine that the PE (and
> the network) can do both entropy label and control word and the operator
> wants to use entropy label, therefore, it disables the control word locally!
>
> GIM>> If an implementation interprets the administrative state of Control
> Word in this way, then I agree with you. But the draft doesn't tell the
> reader that if the local state of Control Word is disabled, that means that
> the PE node uses the Entropy label for load-balancing. Personally, I would
> refer to these states as Use Control Word/Use Entropy Label.
>
>
>
> Regarding why using “SHOULD” instead of “MUST” because it is just a
> recommendation and the packet flow can work without it (i.e., without
> having out-of-order delivery).
>
> GIM>> And that seems to contradict draft-ietf-mpls-1stnibble
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2D1stnibble_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=aOCSuFd_bCQBCzyP6SgvBbSAx4Jq9VosWvd_j8YgkpnNtpEVodJoPk1FvbeR_0tS&s=1twIXWICelUOVaOEnnq8GXTIMBjlu_ESYzHlub4r5VI&e=>
> .
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Wednesday, June 5, 2024 at 2:06 PM
> *To: *Ali Sajassi (sajassi) <[e-mail]>
> *Cc: *Menachem Dodge <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [bess] FW: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
>
> Hi Ali,
>
> thank you for your question. Section 7.11, as I understand it, states:
>
>                 It is
>
>                 recommended that the control word be included in the
>
>                 absence of an entropy label [RFC6790].
>
> If I understand correctly, the CW SHOULD be used, thus allowing for
> sending EVPN packets without the Control Word if node doesn't support the
> Entropy label. Correct?
>
> Furthermore, I have a concern regarding the local control of the Control
> Word, as described in
>
>    When the L2-Attr Extended Community is received from a remote PE, the
>
>    control word C flag MUST be checked against local control word
>
>    enablement.
>
> I believe that local policy must always enable the Control Word.
>
> Also, I have questions about rules 2 and 3 listed in Section 18 (rule 1
> is, IMHO, correct):
>
>    *  If a network uses deep packet inspection for its ECMP, then the
>
>       the following rules for "Preferred PW MPLS Control Word" [RFC4385]
>
>       apply:
>
>       -  It MUST be used with the value 0 (e.g., a 4-octet field with a
>
>          value of zero) when sending unicast EVPN-encapsulated packets
>
>          over an MP2P LSP.
>
>
>
>       -  It SHOULD NOT be used when sending EVPN-encapsulated packets
>
>          over a P2MP or P2P RSVP-TE LSP.
>
>
>
>       -  It SHOULD be used with the value 0 when sending EVPN-
>
>          encapsulated packets over a mLDP P2MP LSP.  There can be
>
>          scenarios where multiple links or tunnels can exist between two
>
>          nodes and thus it is important to ensure that all packets for a
>
>          given flows take the same link (or tunnel) between the two
>
>          nodes.
>
> Why are cases listed in these two rules not using MUST?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jun 4, 2024 at 10:00 PM Ali Sajassi (sajassi) <[e-mail]>
> wrote:
>
> Hi Greg, Menachem:
>
>
>
> I believe during the Greg’s presentation at the BESS WG (which I was
> attending remotely), I voiced my concerns regarding mandating control word
> for all cases. So, let me repeat it in context of your comment:
>
>
>
> Why do we need to mandate control word when all nodes in a network use
> entropy label for ECMP load balancing?
>
>
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, May 30, 2024 at 8:20 PM
> *To: *Menachem Dodge <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>
> *Subject: *Re: [bess] FW: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
>
> Dear All,
>
> I share Menachem's concerns and welcome feedback from the authors.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, May 5, 2024 at 12:33 AM Menachem Dodge <[e-mail]>
> wrote:
>
> Hello Authors,
>
>
>
> Just wondering why none of the discussion held at Brisbane meeting in
> March and subsequently on the emailing list regarding the PFN ( see the
> emails with subject: “Re: [bess] PFN questions in rfc4732bis” )  requesting
> changes in setion 7.11.1 and section 18 , were not included in the latest
> draft update.
>
>
>
> I think the last email on this subject was sent on 15th April 2024.
>
>
>
> In section 7.11 following the discussions I think that the following sentence *should be removed*:
> “It is recommended that the control word be included in the absence of an entropy label [RFC6790].”
>
>
>
>  In section 18 “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.
>
>
>
> *Should be changed to:*  “If a network (inclusive of all PE and P nodes) uses entropy labels
>
>       per [RFC6790] for ECMP load balancing, then the control word should
>
>       be used, refer to draft-ietf-mpls-1stnibble
>
>
>
>
>
> Thank you kindly,
>
>
>
> Best Regards,
>
> Menachem Dodge
>
>
>
>
>
> *From: *BESS <[e-mail]> on behalf of [e-mail]
> <[e-mail]>
> *Date: *Friday, 3 May 2024 at 7:42
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *[bess] I-D Action: draft-ietf-bess-rfc7432bis-09.txt
>
> CAUTION: External E-Mail - Use caution with links and attachments
>
>
> Internet-Draft draft-ietf-bess-rfc7432bis-09.txt is now available. It is a
> work item of the BGP Enabled ServiceS (BESS) WG of the IETF.
>
>    Title:   BGP MPLS-Based Ethernet VPN
>    Authors: Ali Sajassi
>             Luc Andre Burdet
>             John Drake
>             Jorge Rabadan
>    Name:    draft-ietf-bess-rfc7432bis-09.txt
>    Pages:   73
>    Dates:   2024-05-02
>
> Abstract:
>
>    This document describes procedures for Ethernet VPN (EVPN), a BGP
>    MPLS-based solution which addresses the requirements specified in the
>    corresponding RFC - "Requirements for Ethernet VPN (EVPN)".  This
>    document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates
>    RFC8214 (Virtual Private Wire Service Support in Ethernet VPN).
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Drfc7432bis_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh&s=Xt33XJv3urxYTFARXBfpdw-RopowitrC7SWSv-L-QBY&e=
>
> There is also an HTMLized version available at:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Drfc7432bis-2D09&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh&s=oBT0K_2O-jJC2YfcS2X7Srom1ebB2VtVjfyN0CSBZpw&e=
>
> A diff from the previous version is available at:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dbess-2Drfc7432bis-2D09&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh&s=qjFH58VBc_cT930wv8yqvpU4plxuyfST4kkQHhRr5q4&e=
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh&s=4yKmOpDzDXQKtaAvqAg7SgerPvw_i4yaPZHnS0nl7vE&e=
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=aOCSuFd_bCQBCzyP6SgvBbSAx4Jq9VosWvd_j8YgkpnNtpEVodJoPk1FvbeR_0tS&s=dqYK8TX-xSh1T1m5hg5mIJhksAwMpHGbJLipQ6MjBKQ&e=>
>
>
> ------------------------------
>
> 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=53616c7465645f5fcb544aef136866797d63a2a7af865da3971501ed630e2534c4b288f260deb4015207fad8ff2bfb04299758373cf70493914663b5dcb66076a6c128f519342f7559e6a88dd41c4655e9c3586274281eb84e129a6b2d6dbb86a673aaa10810f49b6be453290172d46b3eecb00e978be43ec176586949d1c38406c0180d419ff271a1b7b530cc1b814a98eda4f78a0e94e36a477ee5f4d09172>
> to report this email as spam.
>