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

[Greg Mirsky <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]>
> *Date: *Thursday, June 6, 2024 at 9:07 AM
> *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 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://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 <[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
>
>