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 <mdo...@drivenets.com> 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 <gregimir...@gmail.com> > *Date: *Thursday, 6 June 2024 at 19:07 > *To: *Ali Sajassi (sajassi) <saja...@cisco.com> > *Cc: *Menachem Dodge <mdo...@drivenets.com>, > draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>, > bess@ietf.org <bess@ietf.org>, draft-ietf-mpls-1stnib...@ietf.org < > draft-ietf-mpls-1stnib...@ietf.org> > *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) <saja...@cisco.com> > 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 <gregimir...@gmail.com> > *Date: *Wednesday, June 5, 2024 at 2:06 PM > *To: *Ali Sajassi (sajassi) <saja...@cisco.com> > *Cc: *Menachem Dodge <mdo...@drivenets.com>, > draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>, > bess@ietf.org <bess@ietf.org>, draft-ietf-mpls-1stnib...@ietf.org < > draft-ietf-mpls-1stnib...@ietf.org> > *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) <saja...@cisco.com> > 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 <gregimir...@gmail.com> > *Date: *Thursday, May 30, 2024 at 8:20 PM > *To: *Menachem Dodge <mdo...@drivenets.com>, > draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>, > bess@ietf.org <bess@ietf.org> > *Cc: *draft-ietf-mpls-1stnib...@ietf.org < > draft-ietf-mpls-1stnib...@ietf.org> > *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 <mdo...@drivenets.com> > 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 <bess-boun...@ietf.org> on behalf of internet-dra...@ietf.org > <internet-dra...@ietf.org> > *Date: *Friday, 3 May 2024 at 7:42 > *To: *i-d-annou...@ietf.org <i-d-annou...@ietf.org> > *Cc: *bess@ietf.org <bess@ietf.org> > *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 > BESS@ietf.org > > 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 > BESS@ietf.org > 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. >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
