Hi Greg,

In order to ensure that the text in 
draft-ietf-mpls-1stnibble<https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/>
 is consistent with the text in rfc7432bis, I would suggest something along the 
lines of the following changes for your document:

<Although there are scenarios where control word may not be needed for Ethernet 
embedded packets, for simplicity and ease of implementation, this document 
requires that a control word MUST  always be inserted as a PSH for such 
packets. If a document wants to relax this requirement from “MUST” to “SHOULD”, 
then it shall describe such scenarios.>

Cheers,
Ali

From: Greg Mirsky <gregimir...@gmail.com>
Date: Friday, June 7, 2024 at 2:09 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>, mpls <m...@ietf.org>, MPLS 
Working Group <mpls-cha...@ietf.org>, Adrian Farrel <adr...@olddog.co.uk>
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 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<mailto: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<mailto:gregimir...@gmail.com>>
Date: Thursday, June 6, 2024 at 9:07 AM
To: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
<draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, 
draft-ietf-mpls-1stnib...@ietf.org<mailto:draft-ietf-mpls-1stnib...@ietf.org> 
<draft-ietf-mpls-1stnib...@ietf.org<mailto: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<mailto: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<mailto:gregimir...@gmail.com>>
Date: Wednesday, June 5, 2024 at 2:06 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
<draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, 
draft-ietf-mpls-1stnib...@ietf.org<mailto:draft-ietf-mpls-1stnib...@ietf.org> 
<draft-ietf-mpls-1stnib...@ietf.org<mailto: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<mailto: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<mailto:gregimir...@gmail.com>>
Date: Thursday, May 30, 2024 at 8:20 PM
To: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
<draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Cc: 
draft-ietf-mpls-1stnib...@ietf.org<mailto:draft-ietf-mpls-1stnib...@ietf.org> 
<draft-ietf-mpls-1stnib...@ietf.org<mailto: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<mailto: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<mailto:bess-boun...@ietf.org>> on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: Friday, 3 May 2024 at 7:42
To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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<mailto: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<mailto: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

Reply via email to