Hi Ali, thank you for your response. I have to admit that I still cannot find the relationship between the label distribution protocol and topology of an LSP, on the one hand, and the load-balancing mechanism of a P node in the MPLS data plane. To the best of my understanding, draft-ietf-mpls-1stnibble <https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/> is in the WG LC <https://mailarchive.ietf.org/arch/msg/mpls/SvSx0_ACHOsJ6R9LG-2XxB60H58/>. I think that it is best to share comments and concerns about the requirement to use Control Word for the encapsulation of a non-IP payload in the MPLS networks formulated in draft-ietf-mpls-1stnibble <https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/>.
Regards, Greg On Thu, Jun 6, 2024 at 10:14 PM Ali Sajassi (sajassi) <saja...@cisco.com> wrote: > Hi Greg, > > > > Section 18 of RFC7432bis has been carefully worded to ensure its accuracy > specially wrt “SHOULD” and “MUST” keywords. We cannot blindly require the > use of control word for all non-IP payloads (e.g., Ethernet payload) as it > depends on a) type of tunnels used (TE vs. non-TE), b) unicast vs. > multicast (MP2P vs. P2MP), and c) usage of entropy label network wide. So, > if there is a contradiction between draft-ietf-mpls-1stnibble > <https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/> and > RFC7432bis, I would suggest changing draft-ietf-mpls-1stnibble > <https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/>. > > > > Cheers, > > Ali > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, June 6, 2024 at 9:07 AM > *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 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://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/> 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://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/>. > > > > 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 > >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
