[bess] Re: Port-Based Service Interface in draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Sasha, Jorge:

I agree with you both that the clarification should be done wrt “data” traffic  
and  the detailed handling of L2CP is outside of the scope of 7432bis as 
already covered in MEF documents.

Wrt data traffic on a port, we have two uses cases:

  1.  Access ports where the data traffic over such ports are untagged
  2.  Trunk ports where the data traffic over such ports are tagged

- (a) Should be covered under vlan-based service interface and (b) should be 
covered under vlan-bundle service interface.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Wednesday, June 19, 2024 at 12:09 AM
To: Jorge Rabadan (Nokia) , 
draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org 
Subject: RE: Port-Based Service Interface in draft-ietf-bess-rfc7432bis
Jorge,
Again, lots of thanks for a prompt response.

I fully agree that my second bullet is effectively covered by the relevant MEF 
technical specifications (MEF45.1).
IMHO an Informational reference to these documents would be useful.

As for my first bullet: from my POV the text of Section 6.2.1 of the original 
RFC 7432 has left the behavior of the port-based service interface regarding 
untagged customer traffic open to interpretations.
Closing this gap in 7432bis would be most useful IMHO.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Wednesday, June 19, 2024 12:00 AM
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Port-Based Service Interface in 
draft-ietf-bess-rfc7432bis

Hi Sasha,

I don’t have a strong opinion on your first bullet, if there are no objections. 
Although it could be interpreted as if RFC7432 didn’t support untagged traffic 
on port-based service interfaces, which is not the case.

About the second bullet, we are not defining L2CP behavior in any of the BESS 
specs, my understanding is that this is more an MEF matter. So I wouldn’t 
understand why we need to add the second bullet. I don’t think we should.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, June 18, 2024 at 10:50 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
draft-ietf-bess-rfc7432...@ietf.org 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: Re: Port-Based Service Interface in draft-ietf-bess-rfc7432bis

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Jorge,
Lots of thanks for a prompt and most helpful response.

IMHO the text is Section 6.2.1 should explicitly state your interpretation, i 
e.:
Untagged customer traffic is encapsulated and forwarded "as is"
Untagged Layer 2 control protocols traffic (identified by carrying well-known 
multicast destination MAC addresses is handled in accordance with appropriate 
local configuration for each specific protocol. They may be forwarded, 
discarded, or peered.
Does this make sense to you?

Regards,
Sasha

Get Outlook for Android


From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, June 18, 2024 7:36:22 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-ietf-bess-rfc7432...@ietf.org 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: [EXTERNAL] Re: Port-Based Service Interface in 
draft-ietf-bess-rfc7432bis

Hi Sasha,

The implementations I know, all the traffic – tagged and untagged – is mapped 
to the EVPN broadcast domain, for that type of service. Since no pop/push is 
done of the vlan tags, untagged traffic would be encapsulated into the EVPN 
packet and forwarded as is. My interpretation in this case of “The 
MPLS-encapsulated frames MUST remain tagged with the originating VID” is 
no-tagging for those packets, since the originating VID was non-existent.

I don’t see any issues with LACP and multihoming, since LACP PDUs are punted to 
the control plane on the PEs, and not forwarded.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, June 18, 2024 at 5:54 AM
To: 
draft-ietf-bess-rfc7432...@ietf.org 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: Port-Based Service Interface in draft-ietf-bess-rfc7432bis

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi,
I have a question regarding Section 6.2.1 of 
7432bis.

This section defines Port-based Service Interface in EVPN as “a special case of 
the VLAN bundle service 

[bess] Re: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn

[Ali Sajassi (sajassi)]

Linda,

There are two scenarios to consider with SRv6 IPsec encapsulation:


  1.  VPN-ID/Service-ID is not part of the SRH
  2.  VPN-ID/Service-ID is part of the SRH


  1.  is already covered in the document and I don’t believe we need to do much 
except adding a sentence or two mentioning that IPv6 EH can be SRH.
  2.  Implies that VPN-ID/Service-ID is carried in the open and this 
compromises security aspects. So far, if you look at MACsec or IPsec, 
VPN-ID/Service-ID has always been encrypted with ESP; however, now you are 
talking about deviating from the prior practices. Because secure-evpn draft is 
a WG document, we cannot add (2) without WG consensus. So, it would be good to 
bring up this issue up in BESS and IPSECME and solicit input on this point ONLY.
Cheers,
Ali

From: Linda Dunbar 
Date: Wednesday, June 12, 2024 at 10:39 AM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , draft-ietf-bess-secure-e...@ietf.org 

Subject: RE: Suggested wording to merge the content from 
draft-wang-bess-secservice to draft-bess-secure-evpn
Ali,

Section 9 needs change to accommodate the standard ESP Transport for SRv6 
packets with SIDs outside the ESP header. Your current Section 9.1 (Standard 
ESP Encapsulation) emphasizes on encrypting NVO packets only.

Suggest adding a new subsection 9.3 (Standard ESP Encapsulation for SRv6). Here 
is the suggested wording for 9.3.
-
9.3. Standard ESP Transport Encryption for SRv6 Packets
In scenarios where traffic needs to be securely steered through an SRv6 domain, 
ESP transport encryption can be applied to SRv6 packets with SIDs outside the 
ESP header. This allows the packet to benefit from the security provided by ESP 
while leveraging the routing capabilities of SRv6.

Example of ESP Transport Encryption for SRv6 Packets:
Consider an SRv6 packet with three SIDs where the original transport layer 
packet (e.g., UDP) is encrypted by ESP. The SIDs remain outside the ESP header, 
allowing intermediate nodes to route the packet based on the SIDs.

Below is the detailed structure of such a packet:

++
| IPv6 Base Header   |
| Version = 6|
| Next Header = 43   | <- Indicates Routing Header (RH)
| Source Address |
| Destination Address|
++
| Routing Header | <- Segment Routing Header (SRH)
| Next Header = 50   | <- Indicates ESP header after SRH
| +-+
| | Segment Left = 3|
| | Last Entry  |
| | SID 1   |
| +-+
| | Segment Left = 2|
| | SID 2   |
| +-+
| | Segment Left = 1|
| | SID 3   |
| | Next Header = 17| <- Indicates UDP
| +-+
++
| ESP Header |
| SPI|
| Sequence Number|
| Initialization Vec |
++
| Encrypted Payload  |
| (Original IPv6 Hdr)|
| (UDP Header)   |
| (UDP Data) |
++
| ESP Trailer|
| (Padding, Pad Len, |
|  Next Header = 17) | <- Original payload was UDP
++
| ESP Authentication |
| (ICV, optional)|
++
-

Alternatively, you can modify the wording of Section 9.1. to include SRv6 and 
NVO payload as below:

9.1. Standard ESP Encapsulation
When standard IP Encapsulating Security Payload (ESP) is used (without outer 
UDP header) for encryption of IP packets, including NVO packets as well as SRv6 
packets with Segment Identifiers (SIDs) outside the ESP header, it is used in 
transport mode as depicted below.

(Give the SRv6 example above).

Thank you,

Linda

From: Ali Sajassi (sajassi) 
Sent: Thursday, June 6, 2024 9:53 PM
To: Linda Dunbar 
Cc: bess@ietf.org; draft-ietf-bess-secure-e...@ietf.org
Subject: Re: Suggested wording to merge the content from 
draft-wang-bess-secservice to draft-bess-secure-evpn

Hi Linda,

I don’t think we need to put too much explanation wrt SRv6 because with respect 
to IPsec, it is just a IPv6 encapsulation. So, let me expand on it with respect 
to your four points below:

  1.  Scenario description: The rational and the reasons for needing IPsec are 
basically the same whether it is for regular IPv6 or SRv6. So, such text is 
already covered in the draft.
  2.  Implementation Strategy: with respect to flow identification, policy 
configuration, etc. The draft already covers that and indicates different level 
of granularity (all the way at the flow level) for doing IPsec encap.
  3.  Security considerations and benefits: This is again applies to both IPv6+ 
VxLAN and SRv6. So, if we need to beef up some existing texts, we can do it.

So, I can add a sentence or two to sections 9.1 and 9.2 mentioning that IPv6 
can carry an extension header including SRv6.

Cheers,
Ali

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, May 6, 2024 at 12:40 PM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf

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

[Ali Sajassi (sajassi)]

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:



Cheers,
Ali

From: Greg Mirsky 
Date: Friday, June 7, 2024 at 2:09 PM
To: Ali Sajassi (sajassi) , mpls , MPLS 
Working Group , Adrian Farrel 
Cc: Menachem Dodge , draft-ietf-bess-rfc7432...@ietf.org 
, bess@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) 
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 mailto:gregimir...@gmail.com>>
Date: Thursday, June 6, 2024 at 9:07 AM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>
Cc: Menachem Dodge mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-mpls-1stnib...@ietf.org<mailto: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) 
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/>

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

[Ali Sajassi (sajassi)]

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 
Date: Thursday, June 6, 2024 at 9:07 AM
To: Ali Sajassi (sajassi) 
Cc: Menachem Dodge , draft-ietf-bess-rfc7432...@ietf.org 
, bess@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) 
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 mailto:gregimir...@gmail.com>>
Date: Wednesday, June 5, 2024 at 2:06 PM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>
Cc: Menachem Dodge mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-mpls-1stnib...@ietf.org<mailto: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 

[bess] Re: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn

[Ali Sajassi (sajassi)]

Hi Linda,

I don’t think we need to put too much explanation wrt SRv6 because with respect 
to IPsec, it is just a IPv6 encapsulation. So, let me expand on it with respect 
to your four points below:

  1.  Scenario description: The rational and the reasons for needing IPsec are 
basically the same whether it is for regular IPv6 or SRv6. So, such text is 
already covered in the draft.
  2.  Implementation Strategy: with respect to flow identification, policy 
configuration, etc. The draft already covers that and indicates different level 
of granularity (all the way at the flow level) for doing IPsec encap.
  3.  Security considerations and benefits: This is again applies to both IPv6+ 
VxLAN and SRv6. So, if we need to beef up some existing texts, we can do it.

So, I can add a sentence or two to sections 9.1 and 9.2 mentioning that IPv6 
can carry an extension header including SRv6.

Cheers,
Ali

From: Linda Dunbar 
Date: Monday, May 6, 2024 at 12:40 PM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , draft-ietf-bess-secure-e...@ietf.org 

Subject: Suggested wording to merge the content from draft-wang-bess-secservice 
to draft-bess-secure-evpn
Ali,

I am writing to follow up on our discussion during the IETF 119 BESS WG session 
regarding the draft-wang-bess-secservice. As you may recall, you endorsed 
Option 1 as the preferable approach for using SECURE-EVPN mechanism to encrypt 
selective SRv6 Flows into the Secure EVPN framework.
Option 1: Merge with Secure EVPN, directly incorporating the section into the 
main body of the document.
Additionally, consider adding a description of the necessary encapsulation 
methods in Section 9 and extending the discussion of new tunnel types in 
Section 10 to accommodate this feature.

Proposed Integration: I suggest adding a new subsection, "Encrypting Selective 
SRv6 Flows," to Section 3 of the Secure EVPN draft. This addition would detail 
the use case and requirements for selectively applying IPsec encryption to SRv6 
data flows within NSP-managed networks, addressing the need for heightened 
security measures for sensitive data.

The proposed content for the subsection "Encrypting Selective SRv6 Flows" would 
include:

Scenario Description: Highlighting environments where SRv6 is deployed and the 
types of data flows that require enhanced security measures.
Implementation Strategy: Outlining the steps for implementing IPsec encryption, 
including flow identification, policy configuration, and the encryption 
mechanism itself.
Security Considerations: Discussing the added complexity and necessary 
management adjustments to maintain performance and security.
Benefits: Explaining how this approach secures sensitive information and 
ensures compliance with various regulatory requirements.

Here is the wording proposal. You can modify them to fit the SECURE-EVPN style.

3.6 Encrypting Selective SRv6 Flows
While a Network Service Provider (NSP) managed SRv6 domain is often considered 
a trusted and secure domain as detailed in RFC 8754, RFC 8402, and RFC 8986, 
certain scenarios require an enhanced security model. Particularly in cases 
where data flows carry sensitive or confidential information, there is a 
compelling need for additional security measures. Encrypting selective SRv6 
flows caters to this need by providing robust protection even within a network 
environment presumed to be secure.

Scenario Description
In environments where SRv6 is deployed, data flows might include transactions 
requiring confidentiality, integrity, and authenticity assurances that exceed 
standard network security measures. Examples include financial transactions, 
personal data transmissions subject to privacy regulations, or corporate 
communications involving sensitive strategic content. In such cases, 
selectively encrypting specific SRv6 flows ensures that even if network 
breaches occur, the encrypted data remains secure.

Implementation Strategy
The implementation of IPsec for encrypting selective SRv6 flows involves the 
following steps:
Flow Identification: Define criteria for selecting which SRv6 flows require 
encryption. This could be based on the type of data, the source/destination of 
the flows, or preconfigured security policies.
Policy Configuration: Configure security policies that dictate the parameters 
for encryption, such as the algorithms used, the keys to be employed, and the 
duration of key validity. These policies are applied specifically to the 
identified SRv6 flows that require encryption.
Encryption Mechanism: Utilize IPsec in transport mode to encrypt the payload of 
identified SRv6 packets. The SRH (Segment Routing Header) remains unencrypted 
to allow for the routing of the packet, while the payload is encrypted, 
ensuring the confidentiality and integrity of the data.

Security Considerations
Encrypting selective SRv6 flows introduces additional complexity into the 
network management. It requires careful coordination betw

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

[Ali Sajassi (sajassi)]

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.

The text in 7.11 says that the control word should be used in absence of 
entropy label.

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!

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).

Cheers,
Ali

From: Greg Mirsky 
Date: Wednesday, June 5, 2024 at 2:06 PM
To: Ali Sajassi (sajassi) 
Cc: Menachem Dodge , draft-ietf-bess-rfc7432...@ietf.org 
, bess@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) 
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 mailto:gregimir...@gmail.com>>
Date: Thursday, May 30, 2024 at 8:20 PM
To: Menachem Dodge mailto:mdo...@drivenets.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Cc: 
draft-ietf-mpls-1stnib...@ietf.org<mailto: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 
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:

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

[Ali Sajassi (sajassi)]

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 
Date: Thursday, May 30, 2024 at 8:20 PM
To: Menachem Dodge , draft-ietf-bess-rfc7432...@ietf.org 
, bess@ietf.org 
Cc: 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 
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 mailto:bess-boun...@ietf.org>> on behalf of 
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>>
Cc: 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_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh=Xt33XJv3urxYTFARXBfpdw-RopowitrC7SWSv-L-QBY=

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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh=oBT0K_2O-jJC2YfcS2X7Srom1ebB2VtVjfyN0CSBZpw=

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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh=qjFH58VBc_cT930wv8yqvpU4plxuyfST4kkQHhRr5q4=

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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=gDpQwIZuZSEOcOuIUV_9_jeGv5m-aqXgzBMzkuCM8wBeIKaKwaQUthJPFuNNZ9Dh=4yKmOpDzDXQKtaAvqAg7SgerPvw_i4yaPZHnS0nl7vE=
___
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

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

[Ali Sajassi (sajassi)]

Wen, the blue text is the reverted text and the red text is the additional 
clarification:

“When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet segment
(including itself), in increasing numeric value. Each IP address
in this list is extracted from the "Originating Router's IP
address" field of the advertised Ethernet Segment route. In 
case of
the Ethernet Segment consisting of PEs with a mix of IPv4 and 
IPv6 Originating
Router's IP addresses, such list is sorted by IPv4 addresses 
first
and then followed by IPv6 addresses since the value of a unique 
IPv6 address
(regardless of its type - Unique Local Address or Globally 
Unique Address)
is always bigger than the value of an IPv4 address.”

Cheers,
Ali

From: Wen Lin 
Date: Monday, June 3, 2024 at 6:26 PM
To: Ali Sajassi (sajassi) , Luc André 
Burdet , Ali Sajassi (sajassi) , 
bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
@ Luc,  Thanks for the link.

@Ali,  I agree this implementation specific, it does not change the outcome of 
the DF election result. It seems to be better to revert to the original text to 
avoid confusion.

Thanks,
Wen



Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Monday, June 3, 2024 at 11:31 AM
To: Luc André Burdet , Wen Lin , Ali 
Sajassi (sajassi) , bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Luc,

That is the matter of implementation and in standards we don’t specify how the 
implementation should be done! A given standard should specify the outcome and 
the behavior in enough detailed level that there is no room for ambiguity or 
misinterpretation but not a specific implementation. You don’t need to know the 
type of the IPv6 address in order to perform the comparison. The point was that 
any valid IPv6 address type used for the Originating router’s IP address has 
the first byte as non-zero and thus the value of IPv6 address is always bigger 
than the value of IPv4 address.

Wen,

I will revert the text back to what it was before with the additional 
clarifications that I mentioned in my previous emails. As I mentioned 
previously, the modified text in section 8.5 is not a new algorithm or 
mechanism but rather was done only for clarifications; however, it apparently 
caused some confusion because of getting into a specific implementation.

Cheers,
Ali



Juniper Business Use Only
From: Luc André Burdet 
Date: Monday, June 3, 2024 at 6:08 AM
To: Wen Lin , Ali Sajassi (sajassi) 
, Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Wen, Ali,

The addition came from the following discussion:
https://mailarchive.ietf.org/arch/msg/bess/Afnejmi8rOkcrUY55E4YRGD2jkM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/Afnejmi8rOkcrUY55E4YRGD2jkM/__;!!NEt6yMaO-gk!COHTUv-jVa066HqrIQsQIob1VbKfG_QoO0azp2kkQfV85AyvY4rQ452vCZZUBtRnUwsxFodd-e7GrZ4gGddYlIX96nHYuA$>

In short, the question was how does one “compare” 4 octets to 16 octets.
> IPv4 read 4 octets as unsigned integer and IPv6 is considered as 16 octet 
> unsigned integer.

The update’s intent is to make explicit the comparison by stating all 4-octet 
values are “numerically smaller (4<16)” than any 16-octet Originating IP 
(regardless of known-values, ULA, GUA) before comparing like-to-like dimensions.

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Wen Lin 
Date: Thursday, May 30, 2024 at 23:31
To: Ali Sajassi (sajassi) , Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Thank you for the investigation.   I think it will be good to specify the 
followings:

  1.  changing the ordered list from IP address only to a tuple of IP address 
length and IP address does not change the DF election result.
  2.  the reason for introducing the above change.

Thanks,
Wen




Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin , Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

Both texts say basically the same thing and translate into the same outcome 
(7432bis is just a clarification). If you think they don’t, please explain why 
not or provide an example.  Basically both text say that if you have a mix of 
IPv4 and IPv6 addresses in a list, sort IPv4 addresses first and then IPv6 
addresses (as I said in my previous email). IPv4 values should always be less 
than IPv6 values for all three types of IPv6 addresses (i.e., ULA, LLA, and 
GUA).

Cheers,
Al

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

[Ali Sajassi (sajassi)]

Luc,

That is the matter of implementation and in standards we don’t specify how the 
implementation should be done! A given standard should specify the outcome and 
the behavior in enough detailed level that there is no room for ambiguity or 
misinterpretation but not a specific implementation. You don’t need to know the 
type of the IPv6 address in order to perform the comparison. The point was that 
any valid IPv6 address type used for the Originating router’s IP address has 
the first byte as non-zero and thus the value of IPv6 address is always bigger 
than the value of IPv4 address.

Wen,

I will revert the text back to what it was before with the additional 
clarifications that I mentioned in my previous emails. As I mentioned 
previously, the modified text in section 8.5 is not a new algorithm or 
mechanism but rather was done only for clarifications; however, it apparently 
caused some confusion because of getting into a specific implementation.

Cheers,
Ali

From: Luc André Burdet 
Date: Monday, June 3, 2024 at 6:08 AM
To: Wen Lin , Ali Sajassi (sajassi) 
, Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Wen, Ali,

The addition came from the following discussion:
https://mailarchive.ietf.org/arch/msg/bess/Afnejmi8rOkcrUY55E4YRGD2jkM/

In short, the question was how does one “compare” 4 octets to 16 octets.
> IPv4 read 4 octets as unsigned integer and IPv6 is considered as 16 octet 
> unsigned integer.

The update’s intent is to make explicit the comparison by stating all 4-octet 
values are “numerically smaller (4<16)” than any 16-octet Originating IP 
(regardless of known-values, ULA, GUA) before comparing like-to-like dimensions.

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Wen Lin 
Date: Thursday, May 30, 2024 at 23:31
To: Ali Sajassi (sajassi) , Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Thank you for the investigation.   I think it will be good to specify the 
followings:

  1.  changing the ordered list from IP address only to a tuple of IP address 
length and IP address does not change the DF election result.
  2.  the reason for introducing the above change.

Thanks,
Wen




Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin , Ali Sajassi (sajassi) 
, bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

Both texts say basically the same thing and translate into the same outcome 
(7432bis is just a clarification). If you think they don’t, please explain why 
not or provide an example.  Basically both text say that if you have a mix of 
IPv4 and IPv6 addresses in a list, sort IPv4 addresses first and then IPv6 
addresses (as I said in my previous email). IPv4 values should always be less 
than IPv6 values for all three types of IPv6 addresses (i.e., ULA, LLA, and 
GUA).

Cheers,
Ali



Juniper Business Use Only
From: Wen Lin 
Date: Thursday, May 30, 2024 at 11:46 AM
To: Ali Sajassi (sajassi) , bess@ietf.org 
, Ali Sajassi (sajassi) 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

Hi Ali,



Thanks for your explanation.



To illustrate the differences between RFC7432 and RFC7432-bis,  I have included 
excerpts from both documents below.   To constructing an ordered list under 
RFC7432, we only extract “Originating Router's IP address" field of the 
advertised Ethernet Segment route, while under RFC7432-bist, we extract both 
the "IP Address length" and "Originating Router's IP address" fields of the 
advertised Ethernet Segment route.   IMHO, some text to explain whether there 
is any interop issue will be helpful.



RFC7432:

“…each PE builds an ordered list of the IP addresses of all the PE nodes 
connected to the Ethernet segment (including itself), in increasing numeric 
value.  Each IP address in this list is extracted from the "Originating 
Router's IP address" field of the advertised Ethernet Segment route.  Every PE 
is then given an ordinal indicating its position in the ordered list, starting 
with 0 as the ordinal for the PE with the numerically lowest IP address. “


RFC7432-bis:
“… each PE builds an ordered list of the IP addresses of all the PE nodes 
connected to the Ethernet segment (including itself), in increasing numeric 
value. Each IP address in this list is extracted from the "IP Address length" 
and "Originating Router's IP address" fields of the advertised Ethernet Segment 
route. Every PE is then given an ordinal indicating its position in the ordered 
list, starting with 0 as the ordinal for the PE with the lowest IP address 
length and numeric value tuple. The tuple list is ordered by the IP address 
length first and IP address value second

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

[Ali Sajassi (sajassi)]

Hi Wen,

Both texts say basically the same thing and translate into the same outcome 
(7432bis is just a clarification). If you think they don’t, please explain why 
not or provide an example.  Basically both text say that if you have a mix of 
IPv4 and IPv6 addresses in a list, sort IPv4 addresses first and then IPv6 
addresses (as I said in my previous email). IPv4 values should always be less 
than IPv6 values for all three types of IPv6 addresses (i.e., ULA, LLA, and 
GUA).

Cheers,
Ali

From: Wen Lin 
Date: Thursday, May 30, 2024 at 11:46 AM
To: Ali Sajassi (sajassi) , bess@ietf.org 
, Ali Sajassi (sajassi) 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

Hi Ali,



Thanks for your explanation.



To illustrate the differences between RFC7432 and RFC7432-bis,  I have included 
excerpts from both documents below.   To constructing an ordered list under 
RFC7432, we only extract “Originating Router's IP address" field of the 
advertised Ethernet Segment route, while under RFC7432-bist, we extract both 
the "IP Address length" and "Originating Router's IP address" fields of the 
advertised Ethernet Segment route.   IMHO, some text to explain whether there 
is any interop issue will be helpful.



RFC7432:

“…each PE builds an ordered list of the IP addresses of all the PE nodes 
connected to the Ethernet segment (including itself), in increasing numeric 
value.  Each IP address in this list is extracted from the "Originating 
Router's IP address" field of the advertised Ethernet Segment route.  Every PE 
is then given an ordinal indicating its position in the ordered list, starting 
with 0 as the ordinal for the PE with the numerically lowest IP address. “


RFC7432-bis:
“… each PE builds an ordered list of the IP addresses of all the PE nodes 
connected to the Ethernet segment (including itself), in increasing numeric 
value. Each IP address in this list is extracted from the "IP Address length" 
and "Originating Router's IP address" fields of the advertised Ethernet Segment 
route. Every PE is then given an ordinal indicating its position in the ordered 
list, starting with 0 as the ordinal for the PE with the lowest IP address 
length and numeric value tuple. The tuple list is ordered by the IP address 
length first and IP address value second. “

Thanks,
Wen




Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Thursday, May 30, 2024 at 1:13 PM
To: Wen Lin , bess@ietf.org , Ali Sajassi 
(sajassi) 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

The text in RFC7432bis for section 8.5 is basically a clarification to RFC7432 
and has been around for several years (i.e., introduced in 2021) to ensure that 
the order list for DF election is uniformly formed among all the participating 
PEs in the redundancy group. The intention of RFC7432 was always to allow a mix 
of IPv4 and v6 in the DF list. So, if the RFC7432 was implemented as intended, 
then there is no interop or backward compatibility issue (i.e., sort the list 
based on v4 first and then v6 and further more based on the lowest value 
first). And if it wasn’t, then we would have an interop issue for those 
implementation of RFC7432 (i.e., it would be an interop issue and NOT backward 
compatibility issue!).

Cheers,
Ali



Juniper Business Use Only
From: Wen Lin 
Date: Thursday, May 30, 2024 at 7:32 AM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Under RFC7432,  the ordered list used for electing the DF/BDF is formed based 
solely on the numerical value of each router’s IP address, the originating 
router’s IP address.   RFC7432-bis introduces a refinement, i.e., the ordered 
list is now formed based on the tuple of each router’s IP address length and 
its numerical value.

It would be helpful to add some text to clarify whether there is any backward 
combability issue if we have a mixed of IPv4 and IPv6 addresses for the 
originating router’s IP addresses in the network and with some routers running 
DF election based on RFC7432 and others based on RFC7432-bis.

Thanks,
Wen




Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

There shouldn’t be any backward compatibility issue as section 8.5 states:


“Every PE is then given an ordinal
   indicating its position in the ordered list, starting with 0 as
   the ordinal for the PE with the lowest IP address length and
   numeric value tuple.  The tuple list is ordered by the IP address
   length first and IP address value second.”

Because IP address lengt

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

[Ali Sajassi (sajassi)]

Hi Wen,

The text in RFC7432bis for section 8.5 is basically a clarification to RFC7432 
and has been around for several years (i.e., introduced in 2021) to ensure that 
the order list for DF election is uniformly formed among all the participating 
PEs in the redundancy group. The intention of RFC7432 was always to allow a mix 
of IPv4 and v6 in the DF list. So, if the RFC7432 was implemented as intended, 
then there is no interop or backward compatibility issue (i.e., sort the list 
based on v4 first and then v6 and further more based on the lowest value 
first). And if it wasn’t, then we would have an interop issue for those 
implementation of RFC7432 (i.e., it would be an interop issue and NOT backward 
compatibility issue!).

Cheers,
Ali

From: Wen Lin 
Date: Thursday, May 30, 2024 at 7:32 AM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Under RFC7432,  the ordered list used for electing the DF/BDF is formed based 
solely on the numerical value of each router’s IP address, the originating 
router’s IP address.   RFC7432-bis introduces a refinement, i.e., the ordered 
list is now formed based on the tuple of each router’s IP address length and 
its numerical value.

It would be helpful to add some text to clarify whether there is any backward 
combability issue if we have a mixed of IPv4 and IPv6 addresses for the 
originating router’s IP addresses in the network and with some routers running 
DF election based on RFC7432 and others based on RFC7432-bis.

Thanks,
Wen




Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

There shouldn’t be any backward compatibility issue as section 8.5 states:


“Every PE is then given an ordinal
   indicating its position in the ordered list, starting with 0 as
   the ordinal for the PE with the lowest IP address length and
   numeric value tuple.  The tuple list is ordered by the IP address
   length first and IP address value second.”

Because IP address length is factored into sorting the list, both IPv4 and IPv6 
are allowed to be in the list. This is the expected behavior because in a 
simple of dual-homing, an ES can span across two ASes with different address 
families.

Cheers,
Ali





Juniper Business Use Only
From: Wen Lin 
Date: Wednesday, May 29, 2024 at 12:47 PM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Thank you for providing the following text.

I think it will be helpful to mention the backward compatibility issue 
regarding the change introduced in DF election (Section 8.5) as we need to 
consider the possibility of originating router’s IP addresses coming in with 
different IP address families.

Thanks,
Wen





Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Wednesday, May 15, 2024 at 1:55 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

I am thinking of adding  the following paragraph as a clarification for the 
originating router’s IP address.


“The Originating Router’s IP address does not need to be a routable address and 
its purpose is to identify the originator of that EVPN route uniquely. It can 
be either IPv4 or IPv6 address independent of the BGP next hop address type for 
that NLRI and it must remain the same for all EVPN routes advertised by that 
PE.”



Cheers,

Ali



Juniper Business Use Only
From: Wen Lin 
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org , i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Thank you for the updated draft.

I think we need to explicitly specify how we set the Originating Router’s IP 
address – when it will be to IPv6 or IPv4 address for both Ethernet Segment 
Route and Inclusive Multicast Ethernet Tag Route.  Today, there is no 
mentioning about it in the draft.
7.4. 
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*section-7.4__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOSj3vUNqw$>
 Ethernet Segment 
Route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*name-ethernet-segment-route__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOQZKTSEyg$>
+---+
|  

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

[Ali Sajassi (sajassi)]

Hi Wen,

There shouldn’t be any backward compatibility issue as section 8.5 states:


“Every PE is then given an ordinal
   indicating its position in the ordered list, starting with 0 as
   the ordinal for the PE with the lowest IP address length and
   numeric value tuple.  The tuple list is ordered by the IP address
   length first and IP address value second.”

Because IP address length is factored into sorting the list, both IPv4 and IPv6 
are allowed to be in the list. This is the expected behavior because in a 
simple of dual-homing, an ES can span across two ASes with different address 
families.

Cheers,
Ali



From: Wen Lin 
Date: Wednesday, May 29, 2024 at 12:47 PM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,

Thank you for providing the following text.

I think it will be helpful to mention the backward compatibility issue 
regarding the change introduced in DF election (Section 8.5) as we need to 
consider the possibility of originating router’s IP addresses coming in with 
different IP address families.

Thanks,
Wen





Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Wednesday, May 15, 2024 at 1:55 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]

Hi Wen,

I am thinking of adding  the following paragraph as a clarification for the 
originating router’s IP address.


“The Originating Router’s IP address does not need to be a routable address and 
its purpose is to identify the originator of that EVPN route uniquely. It can 
be either IPv4 or IPv6 address independent of the BGP next hop address type for 
that NLRI and it must remain the same for all EVPN routes advertised by that 
PE.”



Cheers,

Ali



Juniper Business Use Only
From: Wen Lin 
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org , i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Thank you for the updated draft.

I think we need to explicitly specify how we set the Originating Router’s IP 
address – when it will be to IPv6 or IPv4 address for both Ethernet Segment 
Route and Inclusive Multicast Ethernet Tag Route.  Today, there is no 
mentioning about it in the draft.
7.4. 
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*section-7.4__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOSj3vUNqw$>
 Ethernet Segment 
Route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*name-ethernet-segment-route__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOQZKTSEyg$>
+---+
|  RD (8 octets)|
+---+
|Ethernet Segment Identifier (10 octets)|
+---+
|  IP Address Length (1 octet)  |
+---+
|  Originating Router's IP Address  |
|  (4 or 16 octets) |
+---+

We need to add definition or reference for the Originating Router’s IP Address.
7.3. 
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*section-7.3__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pORjQTaKBA$>
 Inclusive Multicast Ethernet Tag 
Route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*name-inclusive-multicast-etherne__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOSIekbGxQ$>

+---+

|  RD (8 octets)|

+---+

|  Ethernet Tag ID (4 octets)   |

+---+

|  IP Address Length (1 octet)  |

+---+

|  Originating Router's IP Address  |

|  (4 or 16 octets) |

+---+



For IMET route, we have the following definition in section 11.1:

“The Originating Router's IP Address field value MUST be set to an IP address 
of the PE that should be common for all the EVIs on the PE (e.g., this address 
may be the PE's loopback address). The IP Address Length field is in bits.”



A router may have both IPv4 and IPv6 addresses con

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

[Ali Sajassi (sajassi)]

Hi Wen,

I am thinking of adding  the following paragraph as a clarification for the 
originating router’s IP address.


“The Originating Router’s IP address does not need to be a routable address and 
its purpose is to identify the originator of that EVPN route uniquely. It can 
be either IPv4 or IPv6 address independent of the BGP next hop address type for 
that NLRI and it must remain the same for all EVPN routes advertised by that 
PE.”



Cheers,

Ali

From: Wen Lin 
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org , i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Thank you for the updated draft.

I think we need to explicitly specify how we set the Originating Router’s IP 
address – when it will be to IPv6 or IPv4 address for both Ethernet Segment 
Route and Inclusive Multicast Ethernet Tag Route.  Today, there is no 
mentioning about it in the draft.
7.4. 

 Ethernet Segment 
Route
+---+
|  RD (8 octets)|
+---+
|Ethernet Segment Identifier (10 octets)|
+---+
|  IP Address Length (1 octet)  |
+---+
|  Originating Router's IP Address  |
|  (4 or 16 octets) |
+---+

We need to add definition or reference for the Originating Router’s IP Address.
7.3. 

 Inclusive Multicast Ethernet Tag 
Route

+---+

|  RD (8 octets)|

+---+

|  Ethernet Tag ID (4 octets)   |

+---+

|  IP Address Length (1 octet)  |

+---+

|  Originating Router's IP Address  |

|  (4 or 16 octets) |

+---+



For IMET route, we have the following definition in section 11.1:

“The Originating Router's IP Address field value MUST be set to an IP address 
of the PE that should be common for all the EVIs on the PE (e.g., this address 
may be the PE's loopback address). The IP Address Length field is in bits.”



A router may have both IPv4 and IPv6 addresses configured for the loopback.  We 
need to specify when IPv6 address will be used based on whether EVPN is used 
IPv4 or IPv6 underlay.
Thanks,
Wen



Juniper Business Use Only
From: BESS  on behalf of internet-dra...@ietf.org 

Date: Friday, May 3, 2024 at 12:42 AM
To: i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]


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.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-rfc7432bis/__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrAUK3PyL$

There is also an HTMLized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrD-_D2Jy$

A diff from the previous version is available 

Re: [bess] Genart early review of draft-ietf-bess-rfc7432bis-08

[Ali Sajassi (sajassi)]

Hi Stewart,

Thanks for your review and your comments. I have incorporated them in the next 
revision of this draft (rev09). Please refer to my comments marked with “Ali>” 
below for more details:

From: Stewart Bryant via Datatracker 
Date: Monday, April 29, 2024 at 8:49 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-rfc7432bis@ietf.org 

Subject: Genart early review of draft-ietf-bess-rfc7432bis-08
Reviewer: Stewart Bryant
Review result: Ready with Issues

This is a well written document with a few issues that are editorial in nature.

Firstly id-nits picks up a number of issues that need to be addressed:

== Missing Reference: 'RFC4448' is mentioned on line 1115, but not defined
Ali> Done

== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
 is not defined in RFC 2119, and should not be used.  Consider using 'MUST
 NOT' instead (if that is what you mean).

 Found 'MAY NOT' in this paragraph:

 *  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.
Ali> Change it to lower case

 -- The draft header indicates that this document obsoletes RFC7432, but the
 abstract doesn't seem to mention this, which it should.
Ali> Added it to the abstract

  -- The draft header indicates that this document updates RFC8214, but the
 abstract doesn't seem to mention this, which it should.
Ali> Added it to the abstract

===
1.1.  Summary of changes from RFC 7432
I wondered if the authors planned to keep this section or whether it was just
used for development purposes? If it is planned to keep it it might be less
intrusive to the flow of the text if it were made an appendix with a forward
reference.
Ali> Done


   This means that for a given , a given MAC address is only
   reachable only via the PE announcing the associated MAC/IP
SB> too many onlys
Ali> Removed the first one.


18.1.  Flow Label
SB> There are many flow labels in different IETF protocols and so it took a few
moments to figure out what was going on here. I gather that this is essentially
a FAT label and given that what follows is a PW structure I wonder why the name
was changed.

Ali> Since FAT(Flow Aware Transport) is defined in context of PWs in RFC 6391, 
we wanted to avoid any confusion since we are not using PWs. Also, the authors 
thought the concept of flow label is simple enough to be covered by itself in 
that section.

SB> In any case I thing that it would be helpful to the user to include a stack
diagram to show how it works rather than requiring the reader to figure it it
out form some mildly dense text.



   IANA has allocated the following EVPN Extended Community sub-types in
   [RFC7153], and this document is the only reference for them, in
   addition to [RFC7432].
SB> Given that this RFC obsoletes RFC7432 it seems wrong to call that up in the
IANA section as a reference. Once this document is published RFC7432 cases to
exist as normative text so it cannot be referred to as a definitive reference.

  0x00 MAC Mobility [RFC7432]
  0x01 ESI Label[RFC7432]
  0x02 ES-Import Route Target   [RFC7432]
Ali> Updated the text accordingly to remove [RFC7432].

SB> Also the registries are already created so the IANA section of this
document should I would have thought be an instruction to change the defining
reference from RFC7432 to this document. SB> Again the following language is
strange relative to an existing registry and my previous comments apply to this
text.
   This document creates a registry called "EVPN Route Types".  New
   registrations will be made through the "RFC Required" procedure
   defined in [RFC8126].  The registry has a maximum value of 255.
   Registrations carried forward from [RFC7432] are as follows:

  0 Reserved   [RFC7432]
  1 Ethernet Auto-discovery[RFC7432]
  2 MAC/IP Advertisement   [RFC7432]
  3 Inclusive Multicast Ethernet Tag   [RFC7432]
  4 Ethernet Segment   [RFC7432]
Ali> Updated the text accordingly


SB> The acknowledgements section is very strange.
Appendix A.  Acknowledgments for This Document (2022)
Ali> Removed “2022”, so that it implies the acknowledgement is for this 
document.

SB> It is not clear what version this applies to, if you keep it should have an
RFC reference Appendix B.  Contributors for This Document (2021)

   In addition to the authors listed on the front page, the following
   co-authors have also contributed to this document:
SB> No names are in this section. Is it needed?
Ali> You’re right. This section is not needed and it is removed.

Appendix C.  Acknowledgments from the First Edition (2015)
SB> Why not do the acknowledgements in narrative text rather than a set of
appendixes?
Ali>  moved the new acknowledgement 

Re: [bess] [Errata Verified] RFC9135 (7683)

[Ali Sajassi (sajassi)]

Hi John

I agree that there is a typo and that needs to be corrected (i.e., s/PE2/PE1 in 
line 4).
With respect to “Notes”, I am not sure if I am reading it incorrectly:

> Notes
> -
> PE1 will use ARP table for forwarding traffic to PE2 - seems like typo

I am reading it as there is a “typo” in the statement but the above statement 
is correct! So, I don’t know why the commentator added “- seems like typo”!

Cheers,
Ali

From: John Scudder 
Date: Monday, February 12, 2024 at 10:14 AM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , The IESG , 
rfc-edi...@rfc-editor.org 
Subject: Re: [Errata Verified] RFC9135 (7683)
Hi Ali,

I already verified this. I can request that the note be revised, but I wanted 
to double-check if you really disagree with it, or if you were just reading 
fast. The note says:

   "PE1 will use ARP table for forwarding traffic to PE2”

You say:

   "PE1 does use the ARP table for forwarding traffic to PE2”

Those statements are equivalent (the note says “will use”, and you say “does 
use the”, there is no other difference), so I guess either you mistakenly read 
the note as saying “will not”, or you left out a “not” in your statement, is in 
“does not”. For now, I am assuming it was a mistaken reading and the note is 
not wrong.

Thanks,

—John

> On Feb 11, 2024, at 3:23 PM, Ali Sajassi (sajassi) 
>  wrote:
>
> Yes, there is a typo in the 4th line and “PE2” needs to be replaced with 
> “PE1” as reflected in “Corrected text”.  However the note that says: “PE1 
> will use ARP table for forwarding traffic to PE2 - seems like typo”, is 
> incorrect. PE1 does use the ARP table for forwarding traffic to PE2 since the 
> IRB is asymmetric.
>  Cheers,
> Ali
>  From: RFC Errata System 
> Date: Friday, February 9, 2024 at 1:23 PM
> To: vrkic.de...@gmail.com , Ali Sajassi (sajassi) 
> , Samer Salam (ssalam) , Samir Thoria 
> (sthoria) , jdr...@juniper.net , 
> jorge.raba...@nokia.com 
> Cc: j...@juniper.net , i...@ietf.org , 
> bess@ietf.org , i...@iana.org , 
> rfc-edi...@rfc-editor.org 
> Subject: [Errata Verified] RFC9135 (7683)
> The following errata report has been verified for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7683
>
> --
> Status: Verified
> Type: Technical
>
> Reported by: Denis Vrkic 
> Date Reported: 2023-10-19
> Verified by: John Scudder (IESG)
>
> Section: 4.2.
>
> Original Text
> -
>   2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
>advertise TS4 MAC/IP information in a MAC/IP Advertisement route
>with a zero Label2 field and no Route Target identifying IP-VRF1.
>In this case, PE2 will install TS4 information in its ARP table
>and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
>prefix match on IP-VRF1's route table will yield the local IRB
>interface to BT1, where a subsequent ARP and bridge table lookup
>will provide the information for an asymmetric forwarding mode to
>PE2.
>
> Corrected Text
> --
>   2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
>advertise TS4 MAC/IP information in a MAC/IP Advertisement route
>with a zero Label2 field and no Route Target identifying IP-VRF1.
>In this case, PE1 will install TS4 information in its ARP table
>and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
>prefix match on IP-VRF1's route table will yield the local IRB
>interface to BT1, where a subsequent ARP and bridge table lookup
>will provide the information for an asymmetric forwarding mode to
>PE2.
>
> Notes
> -
> PE1 will use ARP table for forwarding traffic to PE2 - seems like typo
>
> --
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --
> Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date: October 2021
> Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Technical Errata Reported] RFC8365 (7735)

[Ali Sajassi (sajassi)]

Hi John,


RFC8365 relies heavily on base MPLS-EVPN RFC (i.e., RFC7432/RFC7432bis) and 
assumes the reader is very familiar with RFC7432/7432bis. ESI label as 
described in RFC7432/RFC7432bis is used for split-horizon filtering; however, 
VxLAN-EVPN (RFC8365) doesn’t use split-horizon filtering but instead uses 
local-bias procedure which doesn’t need ESI label. This has already been 
captured in RFC7432bis in section 7.5 (ESI Label Extended Community) that 
says:” The ESI label value MAY be zero if no split-horizon filtering procedures 
are required …”

So, I don’t think we need to repeat that in RFC8365 because whatever changes 
needed to RFC7432/7432bis, has been explicitly captured in this RFC8365 and if 
it is not covered, then it is assumed applicability of RFC7432bis including RED 
field setting in ESI Label Extended Community.

Regards,
Ali

From: John Scudder 
Date: Friday, February 9, 2024 at 1:18 PM
To: bess@ietf.org 
Cc: Ali Sajassi (sajassi) , nabil.bi...@nokia.com 
, rshek...@juniper.net , 
wim.henderi...@nokia.com , Alvaro Retana 
, Andrew Alston - IETF , 
matthew.bo...@nokia.com , slitkows.i...@gmail.com 
, Jeffrey (Zhaohui) Zhang , Gaurav 
Sinha , Jim Uttaro , John Drake 

Subject: Re: [Technical Errata Reported] RFC8365 (7735)
Hi All,

I started to look at this and pretty quickly got lost in a maze of twisty 
passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all, I 
suppose it gets dragged in through the reliance on RFC 7432 as an underlying 
mechanism. Since the erratum proposes a new requirement ("The "ESI Label" 
field, in the "ESI Label" Extended Community, is set to all zeros in case of 
VxLAN encapsulation”) I think the most it can be verified as is Hold For 
Document update. Soliciting feedback.

—John

> On Dec 19, 2023, at 4:32 AM, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC8365,
> "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$>
>
> --
> Type: Technical
> Reported by: Gaurav Sinha 
>
> Section: 8.3.1
>
> Original Text
> -
> Since VXLAN and NVGRE encapsulations do not include the ESI label, other 
> means of performing the split-horizon filtering function must be devised for 
> these encapsulations.
>
> Corrected Text
> --
> The "ESI Label" field, in the "ESI Label" Extended Community, is set to all 
> zeros in case of VxLAN encapsulation.
> Since even though the VXLAN and NVGRE encapsulations send the "ESI Label" 
> Extended Community, yet they do not set the "ESI label" field in it. 
> Therefore, other means of performing the split-horizon filtering function 
> must be devised for these encapsulations.
>
> Notes
> -
> It should be mentioned somewhere in this RFC document that the "ESI Label" 
> Extended Community is sent with VxLAN encapsulation too, just like it is used 
> with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.
>
> Otherwise, it gives rise to the unanswered question in mind, about the value 
> of that field, given that there are no labels in VxLAN.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8365 (draft-ietf-bess-evpn-overlay-12)
> --
> Title   : A Network Virtualization Overlay Solution Using 
> Ethernet VPN (EVPN)
> Publication Date: March 2018
> Author(s)   : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, 
> J. Uttaro, W. Henderickx
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Technical Errata Reported] RFC9135 (7686)

[Ali Sajassi (sajassi)]

Hi John,

I am inclined to reject this errata for the following reasons:


  1.  The original text in section 6.1 is correct and the proposed text is 
incorrect. When a MAC/IP pair is learned a result of local ARP/ND procedure, 
the local IP-VRF table is populated. If it is not populated, then local routing 
from one VLAN/subnet to another one in the same PE won’t work!
  2.  The description in 4.2 is misunderstood. The operation of asymmetric IRB 
is simpler because there is no glean procedure as the one for symmetric IRB. 
Also, there are no RT-5 route advertisement for asymmetric IRB and thus they 
are not installed in route table (IP-VRF) for asymmetric IRB. I think the 
errata author has confused the subnet routes with individual host IP addresses.

Cheers,
Ali

From: John Scudder 
Date: Friday, February 9, 2024 at 1:30 PM
To: bess@ietf.org 
Cc: Ali Sajassi (sajassi) , Samer Salam (ssalam) 
, Samir Thoria (sthoria) , Jorge Rabadan 
(Nokia) , Alvaro Retana , 
Andrew Alston - IETF , matthew.bo...@nokia.com 
, slitkows.i...@gmail.com , 
Jeffrey (Zhaohui) Zhang , vrkic.de...@gmail.com 
, John Drake 
Subject: Re: [Technical Errata Reported] RFC9135 (7686)
Hi Authors and all,

While we are looking at RFC 9135, please look at this one too. Looks reasonable.

Thanks and happy Friday,

—John

> On Oct 20, 2023, at 10:39 AM, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7686__;!!NEt6yMaO-gk!Bv40CvO596tIrUqB8Ny93blSg-Ou7E6QfK7hNtizTCvfc_Dtl8A83hkLnmj8y6nqZy7mVbWMztGjuGmjA0e6QA$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7686__;!!NEt6yMaO-gk!Bv40CvO596tIrUqB8Ny93blSg-Ou7E6QfK7hNtizTCvfc_Dtl8A83hkLnmj8y6nqZy7mVbWMztGjuGmjA0e6QA$>
>
> --
> Type: Technical
> Reported by: Denis Vrkic 
>
> Section: 6.1
>
> Original Text
> -
> 6.1.  Control Plane - Advertising PE
>
>   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
>   of an attached TS (e.g., via an ARP request or ND Neighbor
>   Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP table or
>   NDP cache just as in the case for symmetric IRB.
>
> Corrected Text
> --
> 6.1.  Control Plane - Advertising PE
>
>   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
>   of an attached TS (e.g., via an ARP request or ND Neighbor
>   Solicitation), it populates its MAC-VRF/BT and ARP table or
>   NDP cache.
>
> Notes
> -
> - advertising PE  (egress PE)  is not advertising Label2 ("the MPLS Label2 
> field MUST NOT be included in this route.")
> - so this must be asymmetric egress PE
> - in 4.2 is stated that: "the asymmetric IRB mode simplifies the forwarding 
> model
>   and saves space in the IP-VRF route table, since host routes are not   
> installed in the route table."
> - so i guess that,  advertising  PE  in asymmetric mode, is NOT 
> leaning/storing local IP to IP-VRF table only ARP (bound to IP-VRF) and MAC 
> into MAC-VRF
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --
> Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date: October 2021
> Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Errata Verified] RFC9135 (7683)

[Ali Sajassi (sajassi)]

Yes, there is a typo in the 4th line and “PE2” needs to be replaced with “PE1” 
as reflected in “Corrected text”.  However the note that says: “PE1 will use 
ARP table for forwarding traffic to PE2 - seems like typo”, is incorrect. PE1 
does use the ARP table for forwarding traffic to PE2 since the IRB is 
asymmetric.

Cheers,
Ali

From: RFC Errata System 
Date: Friday, February 9, 2024 at 1:23 PM
To: vrkic.de...@gmail.com , Ali Sajassi (sajassi) 
, Samer Salam (ssalam) , Samir Thoria 
(sthoria) , jdr...@juniper.net , 
jorge.raba...@nokia.com 
Cc: j...@juniper.net , i...@ietf.org , 
bess@ietf.org , i...@iana.org , 
rfc-edi...@rfc-editor.org 
Subject: [Errata Verified] RFC9135 (7683)
The following errata report has been verified for RFC9135,
"Integrated Routing and Bridging in Ethernet VPN (EVPN)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7683

--
Status: Verified
Type: Technical

Reported by: Denis Vrkic 
Date Reported: 2023-10-19
Verified by: John Scudder (IESG)

Section: 4.2.

Original Text
-
  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
   advertise TS4 MAC/IP information in a MAC/IP Advertisement route
   with a zero Label2 field and no Route Target identifying IP-VRF1.
   In this case, PE2 will install TS4 information in its ARP table
   and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
   prefix match on IP-VRF1's route table will yield the local IRB
   interface to BT1, where a subsequent ARP and bridge table lookup
   will provide the information for an asymmetric forwarding mode to
   PE2.

Corrected Text
--
  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
   advertise TS4 MAC/IP information in a MAC/IP Advertisement route
   with a zero Label2 field and no Route Target identifying IP-VRF1.
   In this case, PE1 will install TS4 information in its ARP table
   and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
   prefix match on IP-VRF1's route table will yield the local IRB
   interface to BT1, where a subsequent ARP and bridge table lookup
   will provide the information for an asymmetric forwarding mode to
   PE2.

Notes
-
PE1 will use ARP table for forwarding traffic to PE2 - seems like typo

--
RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
--
Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
Publication Date: October 2021
Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
Category: PROPOSED STANDARD
Source  : BGP Enabled ServiceS
Area: Routing
Stream  : IETF
Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Technical Errata Reported] RFC8365 (7735)

[Ali Sajassi (sajassi)]

Hi John,

RFC8365 relies heavily on base MPLS-EVPN RFC (i.e., RFC7432/RFC7432bis) and 
assumes the reader is very familiar with RFC7432/7432bis. ESI label as 
described in RFC7432/RFC7432bis is used for split-horizon filtering; however, 
VxLAN-EVPN (RFC8365) doesn’t use split-horizon filtering but instead uses 
local-bias procedure which doesn’t need ESI label. This has already been 
captured in RFC7432bis in section 7.5 (ESI Label Extended Community) that 
says:” The ESI label value MAY be zero if no split-horizon filtering procedures 
are required …”

So, I don’t think we need to repeat that in RFC8365 because whatever changes 
needed to RFC7432/7432bis, has been explicitly captured in this RFC8365 and if 
it is not covered, then it is assumed applicability of RFC7432bis including RED 
field setting in ESI Label Extended Community.

Regards,
Ali


From: John Scudder 
Date: Friday, February 9, 2024 at 1:18 PM
To: bess@ietf.org 
Cc: Ali Sajassi (sajassi) , nabil.bi...@nokia.com 
, rshek...@juniper.net , 
wim.henderi...@nokia.com , Alvaro Retana 
, Andrew Alston - IETF , 
matthew.bo...@nokia.com , slitkows.i...@gmail.com 
, Jeffrey (Zhaohui) Zhang , Gaurav 
Sinha , Jim Uttaro , John Drake 

Subject: Re: [Technical Errata Reported] RFC8365 (7735)
Hi All,

I started to look at this and pretty quickly got lost in a maze of twisty 
passages. RFC 8365 doesn’t mention the "ESI Label" Extended Community at all, I 
suppose it gets dragged in through the reliance on RFC 7432 as an underlying 
mechanism. Since the erratum proposes a new requirement ("The "ESI Label" 
field, in the "ESI Label" Extended Community, is set to all zeros in case of 
VxLAN encapsulation”) I think the most it can be verified as is Hold For 
Document update. Soliciting feedback.

—John

> On Dec 19, 2023, at 4:32 AM, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC8365,
> "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7735__;!!NEt6yMaO-gk!DJ230uma4G4hxiFjp6qUOeiX8H6oLKgKOaS-1Tm7La77-DewSFRo0SzansDz_hUnOG9xGOaicVISO8JHw_lvGQ$>
>
> --
> Type: Technical
> Reported by: Gaurav Sinha 
>
> Section: 8.3.1
>
> Original Text
> -
> Since VXLAN and NVGRE encapsulations do not include the ESI label, other 
> means of performing the split-horizon filtering function must be devised for 
> these encapsulations.
>
> Corrected Text
> --
> The "ESI Label" field, in the "ESI Label" Extended Community, is set to all 
> zeros in case of VxLAN encapsulation.
> Since even though the VXLAN and NVGRE encapsulations send the "ESI Label" 
> Extended Community, yet they do not set the "ESI label" field in it. 
> Therefore, other means of performing the split-horizon filtering function 
> must be devised for these encapsulations.
>
> Notes
> -
> It should be mentioned somewhere in this RFC document that the "ESI Label" 
> Extended Community is sent with VxLAN encapsulation too, just like it is used 
> with MPLS, but with the "MPLS Label" field set to all zeros in case of VxLAN.
>
> Otherwise, it gives rise to the unanswered question in mind, about the value 
> of that field, given that there are no labels in VxLAN.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8365 (draft-ietf-bess-evpn-overlay-12)
> --
> Title   : A Network Virtualization Overlay Solution Using 
> Ethernet VPN (EVPN)
> Publication Date: March 2018
> Author(s)   : A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, 
> J. Uttaro, W. Henderickx
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Menachem,

The use of control word is not mandatory and it is situation dependent. Both 
RFC 7432 (and now bis) and RFC 8469 (which is basically elaboration of section 
18 of RFC7432/bis) mention that the control word is not needed when there is no 
chance of packet re-ordering – e.g., when underlay tunnel is RSVP-TE. Also, 
when the network (inclusive of all PE and P nodes) uses Entropy Label, then 
there is no chance of re-ordering either. So, we are just saying that in 
scenarios where there is no chance of packet re-ordering, then control word is 
not needed (to avoid packet re-ordering) – i.e. no need to tax the packet with 
additional 4 bytes.

So, I was suggesting the text to be clarified as follow:


  *   If a network (inclusive of both PE and P nodes) uses entropy labels per 
[RFC6790] for ECMP load balancing, then the control word MAY NOT be used.

This means if the operators still want to use the control word with EL, then 
they still can!

Cheers,
Ali


From: Menachem Dodge 
Date: Monday, February 5, 2024 at 5:55 AM
To: Ali Sajassi (sajassi) , Matthew Bocci (Nokia) 
, draft-ietf-bess-rfc7432...@ietf.org 

Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: Mail regarding draft-ietf-bess-rfc7432bis
Hello Ali,

Thank you kindly for your response.

The question that Mathew and I raised, is why make the control-word dependent 
on the presence of the Entropy Label (per RFC6790)?

Transit Routers may or may not perform their load balancing based on the 
Entropy Label.
Some transit routers do perform deep packet inspection whether or not the 
Entropy Label is present (whether or not it is needed),
in which case the presence of the control-word is important.

Why not let the network administrator decide whether a control-word should be 
present?

Mathew wrote as follows, see also that the CW can be included for additional 
reasons and the reference to RFC8649:
“The head end PE has no idea what hashing mechanism is actually used 
downstream, regardless of whether the entropy label is inserted by it. The 
entropy label is just there to provide additional flow information if the 
downstream P router is load balancing based on the label stack, but it does not 
in itself prevent the P router from scanning below the bottom of stack and 
instead load balancing on the payload after checking the MPLS first nibble. 
This also seems to be superseded by RFC8469 and all the discussion over the 
years about making CW mandatory for MPLS-based services . It is also worth 
noting that CW is not just to prevent aliasing between IP and Ethernet traffic, 
but can be used to indicate OAM or other types of maintenance packets.”

So, we were suggesting that the text be removed, to remove the dependency 
between the Entropy label and the control-word.


And then, we would need an errata for RFC 8214 to remove the following text:

  “If a network uses entropy labels per 
[RFC6790<https://datatracker.ietf.org/doc/html/rfc6790>], then the C Flag
   MUST NOT be set, and the control word MUST NOT be used when sending 
EVPN-encapsulated packets over a P2P LSP.”

Appreciate your inputs in understanding if there is indeed a reason for the 
dependency between the Entropy Label (per RFC6790) and the CW.

Thank you kindly.

Best Regards,
Menachem


From: Ali Sajassi (sajassi) 
Date: Monday, 5 February 2024 at 7:52
To: Menachem Dodge , Matthew Bocci (Nokia) 
, draft-ietf-bess-rfc7432...@ietf.org 

Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: Mail regarding draft-ietf-bess-rfc7432bis
CAUTION: External E-Mail - Use caution with links and attachments

Hi Matthew, Menachem:

The text in the yellow says: “If a network uses entropy labels per [RFC6790]” …
It should be noted that the word “network” is used which is inclusive of all 
the PE and P nodes in that network. So, if the network uses entropy labels and 
does ECMP based on that, then there shouldn’t be a need for control word. 
However, I don’t mind changing it from “SHOULD NOT” to “MAY NOT”.

Cheers,
Ali

From: Menachem Dodge 
Date: Sunday, February 4, 2024 at 12:39 AM
To: Matthew Bocci (Nokia) , 
draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: Mail regarding draft-ietf-bess-rfc7432bis
Hello Mathew,

Just wondering if you received a response to your email, as I have not seen any 
responses to either of our emails on the list.

Thank you kindly.

Best Regards,
Menachem

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Tuesday, 30 January 2024 at 17:42
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis
CAUTION: External E-Mail - Use caution with links and attachments

Hi Authors

Resending this and including the WG. I believe this is a similar question to 
the one posted by Menachem on RFC8214.

Thanks in advance

Matthew

From: Matthew Bocci (Nokia) 
Date: Monday, 15 January 2024 at 12:40
To: draft-ietf-bess-rfc7432...@ie

Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Matthew, Menachem:

The text in the yellow says: “If a network uses entropy labels per [RFC6790]” …
It should be noted that the word “network” is used which is inclusive of all 
the PE and P nodes in that network. So, if the network uses entropy labels and 
does ECMP based on that, then there shouldn’t be a need for control word. 
However, I don’t mind changing it from “SHOULD NOT” to “MAY NOT”.

Cheers,
Ali

From: Menachem Dodge 
Date: Sunday, February 4, 2024 at 12:39 AM
To: Matthew Bocci (Nokia) , 
draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: Mail regarding draft-ietf-bess-rfc7432bis
Hello Mathew,

Just wondering if you received a response to your email, as I have not seen any 
responses to either of our emails on the list.

Thank you kindly.

Best Regards,
Menachem

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Tuesday, 30 January 2024 at 17:42
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis
CAUTION: External E-Mail - Use caution with links and attachments

Hi Authors

Resending this and including the WG. I believe this is a similar question to 
the one posted by Menachem on RFC8214.

Thanks in advance

Matthew

From: Matthew Bocci (Nokia) 
Date: Monday, 15 January 2024 at 12:40
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Mail regarding draft-ietf-bess-rfc7432bis
Hi Authors

There is there following restriction (highlighted in yellow) on the use of the 
control word in EVPN where the EL/ELI is used. I know this was inherited from 
RFC7432, but do you know why this is the case (in particular a SHOULD NOT)?

The head end PE has no idea what hashing mechanism is actually used downstream, 
regardless of whether the entropy label is inserted by it. The entropy label is 
just there to provide additional flow information if the downstream P router is 
load balancing based on the label stack, but it does not in itself prevent the 
P router from scanning below the bottom of stack and instead load balancing on 
the payload after checking the MPLS first nibble. This also seems to be 
superseded by RFC8469 and all the discussion over the years about making CW 
mandatory for MPLS-based services . It is also worth noting that CW is not just 
to prevent aliasing between IP and Ethernet traffic, but can be used to 
indicate OAM or other types of maintenance packets.

Can we just remove the text in yellow?

Thanks

Matthew


In order to avoid frame misordering described above, the following
   network-wide rules are applied:

   *  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.

   *  If a network uses entropy labels per [RFC6790], then the control
  word SHOULD NOT be used.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A minor issue with draft-sajassi-bess-evpn-l3-optimized-irb

[Ali Sajassi (sajassi)]

Thank you Sasha for catching this error. We will address it in the next rev 
along with a few other things.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Thursday, December 21, 2023 at 4:40 AM
To: draft-sajassi-bess-evpn-l3-optimized-...@ietf.org 

Cc: bess@ietf.org 
Subject: A minor issue with draft-sajassi-bess-evpn-l3-optimized-irb
Hi all,
I have looked up the latest revision of the 
draft,
 and I see he following minor issue with it:


·   On one hand, Section 2 of the draft defines a new flag in the EVPN 
ARP/ND Extended Community called L3-Optimized IRB flag (Bit 16 of the Extended 
Community)

·   On the other hand, Section 6 of the draft says that “This document 
requests no actions from IANA”.

The flags used in the EVPN ARP/ND Extended Community are defined in the  IANA 
Registry for flags in the ARP/ND Extended 
Community,
  and, as of his moment, it does not include the definition of the L3-Optimized 
IRB flag.

This issue should be trivial to handle, and asking early allocation for this 
flag would be most helpful.

Regards, and lots of thanks n advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Ali Sajassi (sajassi)]

I support adoption of this document as a WG draft and I am not aware of any 
undisclosed IPR.

Cheers,
Ali

From: Jeffrey (Zhaohui) Zhang 
Date: Monday, November 13, 2023 at 3:51 AM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' , 
draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09
Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

This poll for adoption closes on Monday, 27th of November, 2023.

Thanks.
Jeffrey

Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

[Ali Sajassi (sajassi)]

Hi Sasha,

Your understanding is correct. With respect to your two minor issues below, we 
will take care of them in the next rev along with enhancement to the proxy 
procedure to avoid gleaning of IP traffic. The draft already mentions the 
latter one.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Monday, November 6, 2023 at 11:17 PM
To: Ali Sajassi (sajassi) , Neeraj Malhotra 

Cc: draft-sajassi-bess-evpn-l3-optimized-...@ietf.org 
, bess@ietf.org 
, Nitsan Dolev , Ali Sajassi (sajassi) 

Subject: RE: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Ali, Neeraj and all,
Lots of thanks for prompt responses and clarifications.

My reading of your responses looks as following:

  1.  An optimized IRB is a Symmetric EVPN IRB:

 *   It advertises an RT-2 with the Label2 field present and RTs of both 
MAC-VRF and IP-VRF attached for each IP-->MAC pair it locally learns
 *   The Label2 field carries the label that identifies the IP-VRF that 
contains the EVPN IRB in question

  1.  Traditional Proxy ARP for the subnet of the of this IRB (making it 
respond with its own MAC address to ARP requests for any ARP requests to 
addresses from its subnet is enabled
  2.  An dedicated Extended Community is attached to RT-2 mentioned above and 
indicating that this route MUST be installed (as a host route) in IB and FIB of 
IP-VRF with matching Import RT and in the “RIB” but not in the FDB of the 
MAC-VRF with matching Import RT.

If this understanding is correct, I see a minor issue with this draft (the 
relevant text is highlighted for clarity):
Section 2.1.1 of the 
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-l3-optimized-irb-00#section-2.1.1>
 says that the PE operating in the optimized IRB mode “advertises a MAC/IP 
Advertisement route (aka route-type 2) along with a flag (via BGP extended 
community) to indicate this mode of operation so that the receiving PE adds the 
received MAC address to the L2RIB table but not the L2FIB”.  However:

  1.  AFAIK, no such flag has, so far, been defined in any Extended Community 
used in EVPN
  2.  Section 6 “IANA considerations” of the draft says, “This document 
requests no actions from IANA”.

Should be trivial to fix in the next revision of the draft, I think.

My 2c,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Tuesday, November 7, 2023 3:41 AM
To: Neeraj Malhotra ; Ali Sajassi (sajassi) 

Cc: Alexander Vainshtein ; 
draft-sajassi-bess-evpn-l3-optimized-...@ietf.org; bess@ietf.org; Nitsan Dolev 

Subject: [EXTERNAL] Re: [bess] A question about 
draft-sajassi-bess-evpn-l3-optimized-irb

Hi Neeraj,

Exactly! And I mentioned this during my presentation at BESS. It Is also 
explicitly described in section 2.1.1 of the draft:


“  Since there is no L2 forwarding, there is no need
   for populating L2FIB; however, L2RIB needs to be populated for host
   mobility procedures because host mobility in EVPN is based on MAC
   mobility which is tracked in L2RIB.”

Cheers,
Ali
From: Neeraj Malhotra mailto:neeraj.i...@gmail.com>>
Date: Monday, November 6, 2023 at 4:13 PM
To: Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, 
draft-sajassi-bess-evpn-l3-optimized-...@ietf.org<mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

Hi Ali, Sasha,

minor comment in case it wasn't already clear - each PE still learns all MACs 
in the control plane (for mobility procedures to work) but only locally 
connected MACs are installed in the forwarding plane. Hence the optimization. 
Ali, please confirm.

Thanks,
Neeraj

On Mon, Nov 6, 2023 at 11:37 AM Ali Sajassi (sajassi) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Sasha,

Each PE only learns local MAC addresses and NOT remote ones. So, lets says you 
have a subnet that is stretched across 10 PEs and each PE has 100 locally 
connected hosts. So, the total number of MAC addresses for the subnet is 1000 
(10X100) but each PE ONLY learns 100 MAC addresses. This is in contrast with 
the traditional EVPN-IRB where each PE learns all 1000 MAC addresses.

Cheers,
Ali

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, November 6, 2023 at 5:31 AM
To: 
draft-sajassi-bess-evpn-l3-optimized-...@ietf.org<mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Hi

Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

[Ali Sajassi (sajassi)]

Hi Neeraj,

Exactly! And I mentioned this during my presentation at BESS. It Is also 
explicitly described in section 2.1.1 of the draft:


“  Since there is no L2 forwarding, there is no need
   for populating L2FIB; however, L2RIB needs to be populated for host
   mobility procedures because host mobility in EVPN is based on MAC
   mobility which is tracked in L2RIB.”

Cheers,
Ali

From: Neeraj Malhotra 
Date: Monday, November 6, 2023 at 4:13 PM
To: Ali Sajassi (sajassi) 
Cc: Alexander Vainshtein , 
draft-sajassi-bess-evpn-l3-optimized-...@ietf.org 
, bess@ietf.org 
, Nitsan Dolev 
Subject: Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

Hi Ali, Sasha,

minor comment in case it wasn't already clear - each PE still learns all MACs 
in the control plane (for mobility procedures to work) but only locally 
connected MACs are installed in the forwarding plane. Hence the optimization. 
Ali, please confirm.

Thanks,
Neeraj

On Mon, Nov 6, 2023 at 11:37 AM Ali Sajassi (sajassi) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Sasha,

Each PE only learns local MAC addresses and NOT remote ones. So, lets says you 
have a subnet that is stretched across 10 PEs and each PE has 100 locally 
connected hosts. So, the total number of MAC addresses for the subnet is 1000 
(10X100) but each PE ONLY learns 100 MAC addresses. This is in contrast with 
the traditional EVPN-IRB where each PE learns all 1000 MAC addresses.

Cheers,
Ali

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, November 6, 2023 at 5:31 AM
To: 
draft-sajassi-bess-evpn-l3-optimized-...@ietf.org<mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Hi,
This the question I have tried to ask during the meeting.

The Introduction to draft in 
question<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-l3-optimized-irb-00#section-1>
  claims “improving MAC scalability of customer bridges and PE devices 
significantly”.
The first of these claims is easy to understand: each specific CE switch has to 
learn just one MAC address (that of the optimized IRB) in addition to MAC 
addresses of its locally attached hosts.

But I have doubts about the second of these claims: to the best of my 
understanding, each PE attached to the subnet in question will learn MAC 
addresses of all attached hosts in the subnet.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

[Ali Sajassi (sajassi)]

Hi Sasha,

Each PE only learns local MAC addresses and NOT remote ones. So, lets says you 
have a subnet that is stretched across 10 PEs and each PE has 100 locally 
connected hosts. So, the total number of MAC addresses for the subnet is 1000 
(10X100) but each PE ONLY learns 100 MAC addresses. This is in contrast with 
the traditional EVPN-IRB where each PE learns all 1000 MAC addresses.

Cheers,
Ali

From: BESS  on behalf of Alexander Vainshtein 

Date: Monday, November 6, 2023 at 5:31 AM
To: draft-sajassi-bess-evpn-l3-optimized-...@ietf.org 

Cc: bess@ietf.org , Nitsan Dolev 
Subject: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb
Hi,
This the question I have tried to ask during the meeting.

The Introduction to draft in 
question
  claims “improving MAC scalability of customer bridges and PE devices 
significantly”.
The first of these claims is easy to understand: each specific CE switch has to 
learn just one MAC address (that of the optimized IRB) in addition to MAC 
addresses of its locally attached hosts.

But I have doubts about the second of these claims: to the best of my 
understanding, each PE attached to the subnet in question will learn MAC 
addresses of all attached hosts in the subnet.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt

[Ali Sajassi (sajassi)]

Also, I am not aware of a publicly-released implementation for this draft.


From: Ali Sajassi (sajassi) 
Date: Sunday, November 5, 2023 at 8:34 AM
To: Jeff Tantsura , BESS 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt
Hi Folks,

I am not aware of any undisclosed IPR for this draft.

Cheers,
Ali

From: Jeff Tantsura 
Date: Wednesday, November 1, 2023 at 4:04 PM
To: BESS 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt
Sami and team,

Friendly reminder, would appreciate your response.

Given no changes between last couple of versions, are we ready to go towards 
WGLC?

Thanks,
Jeff

> On May 27, 2023, at 3:20 AM, Jeff Tantsura  wrote:
>
> Dear authors,
>
> Are there any known implementations of the draft?
>
> Thanks,
> Jeff
>
>> On May 27, 2023, at 1:48 AM, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the BGP Enabled ServiceS
>> (BESS) WG of the IETF.
>>
>> Title   : EVPN control plane for Geneve
>> Authors : Sami Boutros
>>  Ali Sajassi
>>  John Drake
>>  Jorge Rabadan
>>  Sam Aldrin
>> Filename: draft-ietf-bess-evpn-geneve-06.txt
>> Pages   : 10
>> Date: 2023-05-26
>>
>> Abstract:
>> This document describes how Ethernet VPN (EVPN) control plane can be
>> used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
>> Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
>> solutions.
>>
>> EVPN control plane can also be used by Network Virtualization Edges
>> (NVEs) to express Geneve tunnel option TLV(s) supported in the
>> transmission and/or reception of Geneve encapsulated data packets.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-06
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-geneve-06
>>
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt

[Ali Sajassi (sajassi)]

Hi Folks,

I am not aware of any undisclosed IPR for this draft.

Cheers,
Ali

From: Jeff Tantsura 
Date: Wednesday, November 1, 2023 at 4:04 PM
To: BESS 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-06.txt
Sami and team,

Friendly reminder, would appreciate your response.

Given no changes between last couple of versions, are we ready to go towards 
WGLC?

Thanks,
Jeff

> On May 27, 2023, at 3:20 AM, Jeff Tantsura  wrote:
>
> Dear authors,
>
> Are there any known implementations of the draft?
>
> Thanks,
> Jeff
>
>> On May 27, 2023, at 1:48 AM, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the BGP Enabled ServiceS
>> (BESS) WG of the IETF.
>>
>> Title   : EVPN control plane for Geneve
>> Authors : Sami Boutros
>>  Ali Sajassi
>>  John Drake
>>  Jorge Rabadan
>>  Sam Aldrin
>> Filename: draft-ietf-bess-evpn-geneve-06.txt
>> Pages   : 10
>> Date: 2023-05-26
>>
>> Abstract:
>> This document describes how Ethernet VPN (EVPN) control plane can be
>> used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
>> Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
>> solutions.
>>
>> EVPN control plane can also be used by Network Virtualization Edges
>> (NVEs) to express Geneve tunnel option TLV(s) supported in the
>> transmission and/or reception of Geneve encapsulated data packets.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-06
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-geneve-06
>>
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Ali Sajassi (sajassi)]

As a co-author , I support the WG adoption of this draft.

From: Matthew Bocci (Nokia) 
Date: Thursday, October 5, 2023 at 3:46 AM
To: bess@ietf.org 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 

Subject: WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16
WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

Please review the draft and post any comments to the BESS mailing list.

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question regarding sections 15.2 and 15.3 of draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Sasha,

As always thanks for your insightful comments and questions and sorry for the 
delayed response. Please refer to my responses inline marked with [AS].

From: BESS  on behalf of Alexander Vainshtein 

Date: Tuesday, September 26, 2023 at 2:56 AM
To: draft-ietf-bess-rfc7432bis.auth...@ietf.org 

Cc: bess@ietf.org 
Subject: [bess] A question regarding sections 15.2 and 15.3 of 
draft-ietf-bess-rfc7432bis
Hi all,
I have a question regarding sections 15.2 and 15.3 of the 7432bis 
draft.

Section 15.2 (which is copied from the parallel section of RFC 
7432) defines 
“sticky” MAC addresses as addresses that are configured as static and therefore 
are not subject to MAC Moves.
It defines how these addresses can be identified, and requires that if such a 
MAC address is seen as the Source MAC address in a locally received Ethernet 
frame, the PE MUST alert the operator. No other actions for this case (be it 
the EVPN CP or EVPN DP actions)  are specified.

[AS] We should add an optional action for dropping such frames. So, we will 
change the sentence to: “If a PE receives such advertisements and later learns 
the same MAC address(es) via local learning, then the PE MUST alert the 
operator and MAY program to drop any received frames with that MAC SA.”

Section 15.3 is a new section that extends the CP mechanisms defined in Section 
15.1 with DP mechanisms breaking Ethernet loops. Such loops can be created by 
backdoor connectivity between L2 customer sites attached to different EVPN PEs.

However, neither these sections nor RFC 9135 seem to discuss the situation when 
an EVPN Broadcast Domain is configured with an IRB and an Ethernet Frame with 
the Source MAC address matching the MAC address of this IRB is locally received 
by one of the PEs in which this Broadcast Domain is instantiated. Such a 
situation may be encountered, e.g., if the EVPN IRB in question is configured 
with anycast MAC address as suggested in Section 4.1 of RFC 
9135, and backdoor 
connectivity exists between different customer sites that are attached to the 
Broadcast Domain in question.

[AS] That is fair and it can happen.

I would highly appreciate your answers to the following questions:

  1.  Should anycast MAC addresses configured on EVPN IRB be treated as 
“sticky”?
[AS] Yes, I think it should and the updated procedure for the sticky MAC 
(highlighted above) can take care of the loop and it can drop the looping 
packets.


  1.  If the answer to the previous question is “Yes”:

 *   Should IP-->MAC pairs of EVPN IRBs be advertised with MAC Mobility 
Extended Community attached and the sticky bit set? To the best of my 
understanding, currently only advertisement with the Default Gateway Extended 
Community attached is required
[AS] Yes.

 *   Should a Broadcast Domain that is used by an EVPN IRB and that locally 
receives an Ethernet frame with the Source MAC address matching the MAC address 
of its IRB perform, in addition to report to the operator, perform any Loop 
Protection actions?
[AS] Yes, per modified sticky MAC address procedure.

Cheers,
Ali

Your timely feedback would be highly appreciated.

IMHO and FWIW it would be nice if your answers (whatever they are) could be 
added in the next revision of the 7432bis draft.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

[Ali Sajassi (sajassi)]

Hi Sasha,

The point that I was trying to make in my response to Brian is that the 
mechanism for checking L2 Attribute (e.g., MTU) is independent of 
physical/virtual nature of ES and whatever procedure(s) that applies to 
physical ES, also applies to virtual ES.

Now, if you have a question or issue with respect to why we are using IMET 
route for some L2 attributes and Ethernet-AD per EVI route for some other L2 
attributes, then this question/issue needs to be raised (and subsequently) 
addressed in context to 7432bis draft.

Cheers,
Ali

From: BESS  on behalf of Alexander Vainshtein 

Date: Sunday, September 24, 2023 at 2:05 AM
To: Ali Sajassi (sajassi) , Brian Haberman 
, int-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
, last-c...@ietf.org 

Subject: Re: [bess] Intdir telechat review of 
draft-ietf-bess-evpn-virtual-eth-segment-13
Ali and all,
Just to make it clear:
I support advancing the draft "as is".

My earlier comments are just about the responses to one if Brian's comments.

My 2c,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>


From: Alexander Vainshtein 
Sent: Sunday, September 24, 2023 11:33:17 AM
To: Ali Sajassi (sajassi) ; Brian Haberman 
; int-...@ietf.org 
Cc: bess@ietf.org ; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
; last-c...@ietf.org 

Subject: Re: Intdir telechat review of 
draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all,
More of the same...
IMHO and FWIW even the usage of EVPN L2 -Attributes Extended Community for 
"bridging" EVPN shall not address the issue raised by Brian because:

  1.  Just one IMET route is advertised per BD and so the information it 
carties cznnot be associated with any specific ES
  2.  With "bridging EVPN, per-EVI Ethernet A-D routes are advertised just for 
multi-homed ES, therefore they cannot be used to distribute any information 
about singke-homed vES.
My 2c,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>


From: Alexander Vainshtein 
Sent: Sunday, September 24, 2023 9:05:18 AM
To: Ali Sajassi (sajassi) ; Brian Haberman 
; int-...@ietf.org 
Cc: bess@ietf.org ; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
; last-c...@ietf.org 

Subject: Re: Intdir telechat review of 
draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all,

I am concerned about Ali's response to one of Bryan's comments (copied below):


MTU size, control word, flow label, and other L2 attributes are carried in EVPN 
L2-Attribute Extended Community which is sent along with IMET route or Ether 
A-D per EVI route. These are independent of whether an Ethernet Segment is 
physical or virtual.

EVPN L2-Attributes Extended Community has been introduced in RFC 8214 for usage 
with EVPN-VPWS and per-EVI Ethernet A-D routes only.

Its extension to "bridging" EVPN and its usage with IMET routes has been 
proposed in 7432bis, but the Virtual Ethernet Segment draft does not reference 
this document.

My 2c,
Sasha



Get Outlook for Android<https://aka.ms/AAb9ysg>

________________
From: BESS  on behalf of Ali Sajassi (sajassi) 

Sent: Saturday, September 23, 2023 11:07:23 PM
To: Brian Haberman ; int-...@ietf.org 

Cc: bess@ietf.org ; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
; last-c...@ietf.org 

Subject: [EXTERNAL] Re: [bess] Intdir telechat review of 
draft-ietf-bess-evpn-virtual-eth-segment-13

Hi Brian,

Thanks for the review and your comments. I have incorporated your comments into 
the rev14 of this draft. Please refer to my inline responses below marked with 
[AS].

From: Brian Haberman via Datatracker 
Date: Wednesday, September 6, 2023 at 11:49 AM
To: int-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
, last-c...@ietf.org 

Subject: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
Reviewer: Brian Haberman
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-virtual-eth-segment. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/.

Major Issues:

Minor Issues:

* Section 1.2 talks about this document defining extensions for RFCs 7432 and
7623. Should this document formally update those RFCs?
[AS] The draft does not update the procedures for RFC7432 and RFC7623 but 
rather it defines the concept of a vES and the extensions needed to support a 
vES. I have changed the text in section 1.2 to reflect this clarification.


* I am by no means an EVPN expert, so I am curious if there is additional
functio

Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

[Ali Sajassi (sajassi)]

Hi Brian,

Thanks for the review and your comments. I have incorporated your comments into 
the rev14 of this draft. Please refer to my inline responses below marked with 
[AS].

From: Brian Haberman via Datatracker 
Date: Wednesday, September 6, 2023 at 11:49 AM
To: int-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org 
, last-c...@ietf.org 

Subject: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
Reviewer: Brian Haberman
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-virtual-eth-segment. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/.

Major Issues:

Minor Issues:

* Section 1.2 talks about this document defining extensions for RFCs 7432 and
7623. Should this document formally update those RFCs?
[AS] The draft does not update the procedures for RFC7432 and RFC7623 but 
rather it defines the concept of a vES and the extensions needed to support a 
vES. I have changed the text in section 1.2 to reflect this clarification.


* I am by no means an EVPN expert, so I am curious if there is additional
functionality needed to ensure consistency of ethernet-level configuration
options across the vES (e.g., Max Frame Size) given the mix of technologies
supported.
[AS] MTU size, control word, flow label, and other L2 attributes are carried in 
EVPN L2-Attribute Extended Community which is sent along with IMET route or 
Ether A-D per EVI route. These are independent of whether an Ethernet Segment 
is physical or virtual.

Nits:

* General
   - There are multiple instances of confusing sentence structure throughout
   the document. Highly recommend getting a native English speaker familiar
   with the technology to make an editorial pass through the document. - Are
   phrases such as "out-of-franchise customer sites" well-known in this
   community?
[AS] change the sentence for better clarification from “to reach 
out-of-franchise customer sites …” to “to reach remote customer sites …”


* Abstract
   - Using undefined acronyms in the Abstract is a bit confusing.
   - The second-half of the first sentence is difficult to parse.
[AS] expanded EVPN and PBB-EVPN acronyms.


* Introduction
   - The first sentence has the same parsing issues as the first sentence in
   the Abstract.
[AS] changed that as well.



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR, implementation poll for draft-ietf-bess-evpn-irb-extended-mobility

[Ali Sajassi (sajassi)]

I am not aware of any undisclosed IPRs.

Cheers,
Ali

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Tuesday, September 19, 2023 at 12:45 AM
To: bess@ietf.org , 
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: [bess] WGLC, IPR, implementation poll for 
draft-ietf-bess-evpn-irb-extended-mobility
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-irb-extended-mobility-14 [1]. Note that the document 
already had a WGLC and comments were raised by the WG. These comments are 
normally addressed by the Authors but feel free to review again and provide 
feedback.

This poll runs until Tuesday 3rd October.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.



Thank you,
Stephane, Matthew, Jeffrey

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12

[Ali Sajassi (sajassi)]

Hi Matthew,

A new version of the draft with the agreed upon changes has been published.

Regards,
Ali

From: Matthew Bocci (Nokia) 
Date: Thursday, August 17, 2023 at 2:26 AM
To: Ali Sajassi (sajassi) , bess@ietf.org 
Cc: bess-cha...@ietf.org , John Scudder 
Subject: Re: 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12
Authors, WG,

I think there is consensus to proceed with the publication of the draft as a 
standards track RFC.

Authors, please can you publish a new version with the changes as agreed during 
this WG LC so I can update the shepherd write up and request publication again.

Thanks

Matthew

From: Ali Sajassi (sajassi) 
Date: Saturday, 5 August 2023 at 23:55
To: Matthew Bocci (Nokia) , bess@ietf.org 

Cc: bess-cha...@ietf.org , John Scudder 
Subject: Re: 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Folks,

Just FYI – vast majority of changes for this new revision (rev12) have been 
made for clarification purposes including the new paragraph added in section 
5.5. The new paragraph describes fast convergence scenario for existing figure 
5 in this section.

Thanks to IESG for their review and feedback in tidiness of this document and 
specially to John Scudder for his thorough review as usual and valuable 
comments.

Please take a look at the diff below and if you have any questions/comments wrt 
new edits, please let us know:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-evpn-virtual-eth-segment-11=draft-ietf-bess-evpn-virtual-eth-segment-12=--html

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Wednesday, August 2, 2023 at 6:20 AM
To: bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: [bess] 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12
This email begins a two-week working group last call on 
draft-ietf-bess-evpn-virtual-eth-segment-12 
(draft-ietf-bess-evpn-virtual-eth-segment-12 - EVPN Virtual Ethernet 
Segment<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/>)

Please review the draft and post any comments to the BESS mailing list.

The primary purpose of this second last call is to double check that updates 
following AD review of the previous version of the draft did not change the 
meaning of the text, given that there are a number of known implementations of 
the draft. Please pay special attention to the changes which you can see using 
the diff tool on the history page of the datatracker.

This WG LC ends on Wednesday 16th August 2023.

Thanks

Matthew

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A comment about draft-ietf-bess-evpn-virtual-eth-segment

[Ali Sajassi (sajassi)]

Hi Sasha,

Thanks for the comment. I welcome any comment for better clarification of this 
draft. As such your comment is well taken and I’ll remove “multipoint” word 
from the sentence. So, the new sentence will read: “… a family of solutions for 
Ethernet services over MPLS/IP network …”

Regards,
Ali

From: Alexander Vainshtein 
Date: Tuesday, August 8, 2023 at 8:34 AM
To: draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org 

Cc: bess@ietf.org , Nitsan Dolev 
Subject: A comment about draft-ietf-bess-evpn-virtual-eth-segment
Hi,
I have a comment about the Virtual Ethernet Segment 
draft.

The first two sentences of the Introduction to this draft says (the problematic 
text is highlighted):

RFC7432] and 
[RFC7623] introduce a family of 
solutions for multipoint Ethernet services over MPLS/IP network with many 
advanced features among which their multi‑homing capabilities. These solutions 
introduce Single-Active and All-Active redundancy modes for an Ethernet Segment 
(ES), itself defined as a set of links between the multi‑homed device/network 
and a set of PE devices that they are connected to.

Thie highlighted text above can be interpreted as restricting multi-homing 
capabilities of EVPN (including capabilities provided by using multi-homed 
virtual Ethernet segments defined in the draft) as being limited to just 
multipoint Ethernet service but not to EVPN-VPWS as defined in RFC 
8214.

In fact, EVPN-VPWS is fully compatible with All-Active and Single-Active 
redundancy modes, and RFC 8214 is quite unambiguous about that. What’s more, 
IMHO and FWIW, multi-homing support in EVPN-VPWS is fully applicable to all 
aspects of virtual multi-homed Ethernet Segments.

May I suggest modifying the quoted text in the Introduction to prevent possible 
misunderstanding?

Regards, and lots of thanks in advance,
Sasha






Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12

[Ali Sajassi (sajassi)]

Hi Folks,

Just FYI – vast majority of changes for this new revision (rev12) have been 
made for clarification purposes including the new paragraph added in section 
5.5. The new paragraph describes fast convergence scenario for existing figure 
5 in this section.

Thanks to IESG for their review and feedback in tidiness of this document and 
specially to John Scudder for his thorough review as usual and valuable 
comments.

Please take a look at the diff below and if you have any questions/comments wrt 
new edits, please let us know:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-evpn-virtual-eth-segment-11=draft-ietf-bess-evpn-virtual-eth-segment-12=--html

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Wednesday, August 2, 2023 at 6:20 AM
To: bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: [bess] 2nd WG last call for draft-ietf-bess-evpn-virtual-eth-segment-12
This email begins a two-week working group last call on 
draft-ietf-bess-evpn-virtual-eth-segment-12 
(draft-ietf-bess-evpn-virtual-eth-segment-12 - EVPN Virtual Ethernet 
Segment)

Please review the draft and post any comments to the BESS mailing list.

The primary purpose of this second last call is to double check that updates 
following AD review of the previous version of the draft did not change the 
meaning of the text, given that there are a number of known implementations of 
the draft. Please pay special attention to the changes which you can see using 
the diff tool on the history page of the datatracker.

This WG LC ends on Wednesday 16th August 2023.

Thanks

Matthew

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-virtual-eth-segment-11: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Martin,

Elaborating a bit further to ensure there is no ambiguity …



(S1.2)
"In some cases, this aggregation of PWs that share the same LSP pair may not be
possible. For instance, if PW3 were terminated into a third PE, e.g. PE3,
instead of PE1, the vES would need to be defined on a per individual PW on each
PE, i.e. PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be
associated to ES-2."
 Indeed..corrected.

"defined on a per individual PW on each PE" is grammatically incorrect, but I
think you mean that each PW gets its own vES. But that would mean that you need
four ESs, not two.
 Not really since PW share common LSP.

Ali> A vES can consist of a group of PWs or group of LSPs (spread across two 
more PEs). In figure-2, the vES consists of two LSPs (LSP1 and LSP2) each with 
two PW2 (for a total of 4 PWs) spread across PE1 and PE2.  The new text 
clarifies this.


(S2) Please add EVI and Ethernet A-D to the glossary

 Done






___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Please send slot request for BESS IETF 117

[Ali Sajassi (sajassi)]

Hi Mankamana,

I want to request a 10 min slot for 
https://datatracker.ietf.org/doc/draft-sajassi-bess-rfc8317bis/

Cheers,
Ali

From: BESS  on behalf of Mankamana Mishra (mankamis) 

Date: Friday, June 30, 2023 at 7:33 AM
To: bess@ietf.org 
Subject: [bess] Please send slot request for BESS IETF 117
All,
Primary agenda has been posted. Please send me slot request for IETF 117.

Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-l2gw-proto (with correction on existing IPR)

[Ali Sajassi (sajassi)]

Support as a co-author. I am not aware of any undisclosed IPRs related to this 
draft.

Cheers,
Ali

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Wednesday, June 14, 2023 at 1:21 AM
To: bess@ietf.org 
Subject: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-l2gw-proto (with correction on existing IPR)

Hi WG,







This email starts a two-week Working Group Last Call on

draft-ietf-bess-evpn-l2gw-proto [1].







This poll runs until 6/30.







We are also polling for knowledge of any undisclosed IPR that applies to

this Document, to ensure that IPR has been disclosed in compliance with IETF

IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as an Author or a Contributor of this document, please

respond to this email and indicate whether or not you are aware of any

relevant undisclosed IPR. The Document won't progress without answers from

all the Authors and Contributors.



There is currently one IPR disclosed.







If you are not listed as an Author or a Contributor, then please explicitly

respond only if you are aware of any IPR that has not yet been disclosed in

conformance with IETF rules.







We are also polling for any existing implementation as per [2]. Please

indicate if you are aware of any implementations.







Thank you,



Matthew & Stephane







[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-l2gw-proto/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Ali Sajassi (sajassi)]

Hi Matthew,

Done and it is waiting for your check-in.

Cheers,
Ali

From: Matthew Bocci (Nokia) 
Date: Tuesday, June 20, 2023 at 2:24 AM
To: Ali Sajassi (sajassi) , Linda Dunbar 
, Lukas Krattiger (lkrattig) 
, bess-cha...@ietf.org 

Cc: bess@ietf.org , draft-sajassi-bess-secure-e...@ietf.org 

Subject: Re: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-secure-evpn-06
This email closes the WG adoption poll.

Authors: Please make the updates as agreed below and post a new WG version of 
the document:  draft-ietf-bess-secure-evpn-00.

Regards

Matthew


From: Ali Sajassi (sajassi) 
Date: Monday, 12 June 2023 at 07:17
To: Linda Dunbar , Lukas Krattiger (lkrattig) 
, Matthew Bocci (Nokia) 
, bess-cha...@ietf.org 
Cc: bess@ietf.org , draft-sajassi-bess-secure-e...@ietf.org 

Subject: Re: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-secure-evpn-06

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Linda,

Thanks for your comments. Please refer to my replies inline …

From: Linda Dunbar 
Date: Tuesday, May 30, 2023 at 9:36 AM
To: Lukas Krattiger (lkrattig) , Matthew 
Bocci (Nokia) , bess-cha...@ietf.org 

Cc: bess@ietf.org , draft-sajassi-bess-secure-e...@ietf.org 

Subject: RE: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-secure-evpn-06
I support the WG adoption with the following questions and comments:


  *   Section 5: How is the IPsec Databases (SPD, SAD, and generating Keying 
material for IPsec SAs) different from the traditional IPsec Data Base 
generation described in the RFC 4301? Can you please emphasize the differences?
IKE is P2P; whereas, key generation and re-keying describes is this document is 
adapted for P2MP BGP signaling. We will emphasize the differences in future 
revision.

  *   Section 8 Second paragraph states that the Device-Controller trust model 
is using the peer-to-peer protocol such as IKEv2. If the devices are already 
support EVPN, are they already have trust connection to their corresponding 
controller? Can TLS be used for Devices to exchange BGP messages with the 
controller?
Absolutely. TLS can also be used for devices-controller trust model for 
securing the exchange of BGP messages. I will mention that in the next rev.

  *   -  If a SA is required per pair of IP addresses on two separate PEs, why 
it is not enough to have the existing ESP tunnel mode encapsulation for the 
packet exchanged between the two PEs like the following?

Outer IP header:
+---+
|protocol = 50(IPsec ESP)   |
|src = source-PE   |
|dst = dest-PE  |
+---+  < --+
 |SPI(Security Parameter Idx)|Authenticated
+---+  |
|sequence number|  |
+---+   <-+|
| payload IP header:| ||
|  src =  source-ip | ||
|  dst =  dest-ip  | ||
+---+  Encrypted   |
|   TCP header +| ||
~payload (variable) ~ ||
|   | ||
+===+   <-+ ---+
|   Authentication Data |
+---+


Is it necessary to have any outer tunnel header (other than the IPsec's ESP 
encapsulation) wrapping around the payload?

Ali> I am guessing you are referring to figure 10, “per IP address”. If so, 
this is overlay IP address and thus they are defined in context of a VNI which 
means we need VxLAN header. Also, for encap consistency, across different level 
of granularity, we are keeping VxLAN header. The encap is not cast in stone and 
if we can improve efficiency without complicating data-plane processing, then 
we should discuss the options.

Cheers,
Ali

  *

Thank you very much

Linda


> On May 25, 2023, at 5:35 AM, Matthew Bocci (Nokia) 
> mailto:matthew.bo...@nokia.com>> wrote:
>
> Hello,
>  This email begins a two-week WG adoption poll for 
> draft-sajassi-bess-secure-evpn-06 [1].
> Please review the draft and post any comments to the BESS working group list.
>  We are also polling for knowledge of any undisclosed IPR that applies to 
> this document, to ensure that IPR has been disclosed in compliance with IETF 
> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as an author or a contributor of this document, please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR, copying the BESS mailing list. The document will 
> not progress without answers from all the authors and contributors.
> Currently, there is currently no IPR disclosure against this document.
> If you are not listed as an author or a contributor, then please explicitly 
> respond only if you a

Re: [bess] Mail regarding draft-sajassi-bess-secure-evpn

[Ali Sajassi (sajassi)]

Shunwan,

Good catch! ID length is in bytes and Nonce length is also in bytes. I will 
update the draft accordingly.

Cheers,
Ali

From: Zhuangshunwan 
Date: Monday, June 12, 2023 at 1:36 AM
To: draft-sajassi-bess-secure-e...@ietf.org 

Cc: bess@ietf.org 
Subject: Mail regarding draft-sajassi-bess-secure-evpn
Dear Co-Authors,

Thank you for contributing this very useful document! I support the adoption of 
this document.

One comment:
Regarding the “ID Length” and “Nonce Length” in the Base (Minimal Set) DIM 
Sub-TLV, Figure 6 shows the following:
0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ID Length   |   Nonce Length|I|   Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rekey |
   |Counter|
   +---+
   |   |
   ~  Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) ~
   |   |
   +---+
   |   |
   ~  Nonce Data   ~
   |   |
   +---+

  Figure 6


And the corresponding description is as follows:
“ID Length (16 bits) is the length of the Originator ID + (Tenant ID)
   + (Subnet ID) + (Tenant Address) in bytes.  Nonce Length (8 bits) is
…”

Question: Which is the right format we want?

Best Regards,
Shunwan
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Ali Sajassi (sajassi)]

Linda,

Thanks for your comments. Please refer to my replies inline …

From: Linda Dunbar 
Date: Tuesday, May 30, 2023 at 9:36 AM
To: Lukas Krattiger (lkrattig) , Matthew 
Bocci (Nokia) , bess-cha...@ietf.org 

Cc: bess@ietf.org , draft-sajassi-bess-secure-e...@ietf.org 

Subject: RE: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-secure-evpn-06
I support the WG adoption with the following questions and comments:


  *   Section 5: How is the IPsec Databases (SPD, SAD, and generating Keying 
material for IPsec SAs) different from the traditional IPsec Data Base 
generation described in the RFC 4301? Can you please emphasize the differences?
IKE is P2P; whereas, key generation and re-keying describes is this document is 
adapted for P2MP BGP signaling. We will emphasize the differences in future 
revision.

  *   Section 8 Second paragraph states that the Device-Controller trust model 
is using the peer-to-peer protocol such as IKEv2. If the devices are already 
support EVPN, are they already have trust connection to their corresponding 
controller? Can TLS be used for Devices to exchange BGP messages with the 
controller?
Absolutely. TLS can also be used for devices-controller trust model for 
securing the exchange of BGP messages. I will mention that in the next rev.

  *   -  If a SA is required per pair of IP addresses on two separate PEs, why 
it is not enough to have the existing ESP tunnel mode encapsulation for the 
packet exchanged between the two PEs like the following?

Outer IP header:
+---+
|protocol = 50(IPsec ESP)   |
|src = source-PE   |
|dst = dest-PE  |
+---+  < --+
 |SPI(Security Parameter Idx)|Authenticated
+---+  |
|sequence number|  |
+---+   <-+|
| payload IP header:| ||
|  src =  source-ip | ||
|  dst =  dest-ip  | ||
+---+  Encrypted   |
|   TCP header +| ||
~payload (variable) ~ ||
|   | ||
+===+   <-+ ---+
|   Authentication Data |
+---+


Is it necessary to have any outer tunnel header (other than the IPsec's ESP 
encapsulation) wrapping around the payload?

Ali> I am guessing you are referring to figure 10, “per IP address”. If so, 
this is overlay IP address and thus they are defined in context of a VNI which 
means we need VxLAN header. Also, for encap consistency, across different level 
of granularity, we are keeping VxLAN header. The encap is not cast in stone and 
if we can improve efficiency without complicating data-plane processing, then 
we should discuss the options.

Cheers,
Ali

  *

Thank you very much

Linda


> On May 25, 2023, at 5:35 AM, Matthew Bocci (Nokia) 
> mailto:matthew.bo...@nokia.com>> wrote:
>
> Hello,
>  This email begins a two-week WG adoption poll for 
> draft-sajassi-bess-secure-evpn-06 [1].
> Please review the draft and post any comments to the BESS working group list.
>  We are also polling for knowledge of any undisclosed IPR that applies to 
> this document, to ensure that IPR has been disclosed in compliance with IETF 
> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as an author or a contributor of this document, please 
> respond to this email and indicate whether or not you are aware of any 
> relevant undisclosed IPR, copying the BESS mailing list. The document will 
> not progress without answers from all the authors and contributors.
> Currently, there is currently no IPR disclosure against this document.
> If you are not listed as an author or a contributor, then please explicitly 
> respond only if you are aware of any IPR that has not yet been disclosed in 
> conformance with IETF rules.
>  This poll for adoption closes on June 9th 2023  Regards, Matthew and
> Stephane  [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-sajassi-bess-secure-evpn=05
> %7C01%7Clinda.dunbar%40futurewei.com%7Cad6059875d30470c56a908db6117f33
> d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638210527722676515%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DwjLIezroZxS%2Fw8vyDe6ypUP3RSGq
> hqOLuLcvsMAkho%3D=0
> ___
> BESS mailing list
> BESS@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fbess=05%7C01%7Clinda.dunbar%40fut
> urewei.com%7Cad6059875d30470c56a908db6117f33d%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C638210527722676515%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> 

Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

[Ali Sajassi (sajassi)]

Support as a co-author. Not aware of any undisclosed IPR(s).

Cheers,
Ali

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Wednesday, May 24, 2023 at 1:02 AM
To: bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless
Hello,


This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-vpws-seamless-07 [1].
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.
If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on June 7th.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Ali Sajassi (sajassi)]

Support as a co-author. There is an IPR associated with this draft and I have 
already asked our legal department to register it with IETF.

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, May 25, 2023 at 3:36 AM
To: bess@ietf.org 
Cc: draft-sajassi-bess-secure-e...@ietf.org 
, bess-cha...@ietf.org 

Subject: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06
Hello,

This email begins a two-week WG adoption poll for 
draft-sajassi-bess-secure-evpn-06 [1].
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.
If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on June 9th 2023

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis

[Ali Sajassi (sajassi)]

If you are talking about different VLAN IDs (VIDs) on the same physical 
interface of an ES is getting mapped to a BD, and the  is advertised 
via Eth AD per EVI route with Eth-tag of zero, then this is VLAN-bundle service 
interface. In VLAN bundle, it is assumed that the MAC addresses across 
different VIDs are unique and thus they all can be placed in a single BD!

Cheers,
Ali

From: wang.yub...@zte.com.cn 
Date: Wednesday, May 24, 2023 at 7:26 PM
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org 
Subject: Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis



Hi All,



I have encountered a use case that I don't know if it's VLAN-based service 
interface or VLAN-bundle service interface.

When two individual subinterfaces on the same ES are attached to the same BD 
which is the only one BD (whose Ethernet Tag ID is zero) of its EVI, which 
Service Interface should the EVI be called? VLAN-based service interface or 
VLAN-bundle service interface or none of those three service itnerfaces?

I noticed that there is just a single A-D per EVI route for that , thus 
these two ACs have to share the same A-D per EVI route in such case. So if one 
of them fails but the other is OK, should that A-D per EVI route be withdrawn 
or not?

When these two interfaces are merged into a single subinterface, I know there 
is no doubt that this is VLAN-bundle service interface. But here each VLAN has 
its individual interface.

Whether this use case is supported by rfc7432bis? If it is supported, should it 
be called VLAN-based service interface or VLAN-bundle service interface?



Thanks,

Yubao




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Question on symmetric EVPN IRB RFC 9135

[Ali Sajassi (sajassi)]

Hi Sami,

Please refer to my response inline in red …

From: BESS  on behalf of Boutros, Sami 

Date: Tuesday, May 23, 2023 at 2:31 PM
To: BESS 
Subject: [bess] Question on symmetric EVPN IRB RFC 9135
Hi,

Looking at section 5.2, it doesn’t address quite few cases like for example.


  *   What should the receiving PE do if it receives a non zero label2, but no 
IP VRF route target? Should we treat as asymmetric?

No, non-zero label2 means it is symmetric IRB and if it doesn’t receive the 
corresponding IP-VRF RT, then it should be treated as an error and not be 
imported (also logged an error message).


  *   What should the receiving PE do if the IP VRF route target import the 
route to a VRF different then the VRF the IRB interface belong to? will that 
even function?

I guess, you are asking what happens when IP-VRF RT doesn’t correspond to 
MAC-VRF RT. In this case, the wrong RT will be imported into the wrong table if 
the receiving has a match for that wrong RT. But this is the same as IP-VPN use 
case when the transmitter uses the wrong RT – i.e., the receiver imports it 
into the wrong table when there is a match.

The section seems to assume that the IP VRF route target must be present and 
must be related to the VRF the IRB interface belong too? If so, then why do we 
need to add an IP VRF route target to start with?

Because IP-VRF table is identified uniquely  via its own RT just like IP-VPN.

Cheers,
Ali

Thanks,

Sami
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Coverage of ERL label within LSP-Ping Mechanisms for EVPN

[Ali Sajassi (sajassi)]

Hi Nitsan,

There are a few other extensions that we have in mind for the bis version which 
Parag and I want to incorporate. However, we don’t want to rush that and want 
to allow time for the new RFC to soak (just like RFC7432) and gather all inputs 
before doing a bis. We welcome your input (and your collaboration) on the bis 
version.

BTW, draft-burdet-bess-evpn-fast-reroute-03 is just an individual draft. It is 
not even WG draft. So, even  writing an errata for lsp-ping RFC to cover an 
individual draft is NOT appropriate! And you should wait till that draft 
becomes at least a WG draft.

Cheers,
Ali

From: Nitsan Dolev 
Date: Thursday, May 18, 2023 at 12:20 AM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
Parag Jain (paragj) , Luc Andre Burdet (lburdet) 

Cc: Alexander Vainshtein , Ron Sdayoor 

Subject: RE: Coverage of ERL label within LSP-Ping Mechanisms for EVPN
Hi Ali,

Thanks for the prompt response.
I will file an errata for the published RFC.
And we will draft an extension to it in parallel to progress of 
draft-burdet-bess-evpn-fast-reroute-03

Much oblige,
Nitsan

From: Ali Sajassi (sajassi) 
Sent: Thursday, May 18, 2023 1:41 AM
To: Nitsan Dolev ; bess@ietf.org; Parag Jain (paragj) 
; Luc Andre Burdet (lburdet) 
Cc: Alexander Vainshtein ; Ron Sdayoor 

Subject: [EXTERNAL] Re: Coverage of ERL label within LSP-Ping Mechanisms for 
EVPN

Hi Nitsan,

This draft has gone through the WGLC as well as IESG review and we are very 
close to its publication (i.e., too late to make such changes). Once it is 
published, we welcome enhancements and expansion to this document when needed. 
IETF has a formal process of reporting “errata” on a published RFC. We 
encourage you to file an errata on this. We will compile all such errata and we 
will address them in the bis version of this document.

Cheers,
Ali

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Date: Wednesday, May 17, 2023 at 7:25 AM
To: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Parag Jain (paragj) mailto:par...@cisco.com>>, Luc Andre 
Burdet (lburdet) mailto:lbur...@cisco.com>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>
Subject: Re: [bess] Coverage of ERL label within LSP-Ping Mechanisms for EVPN
Dear authors of draft-ietf-bess-evpn-lsp-ping-09 and 
draft-burdet-bess-evpn-fast-reroute-03,

Your help with addressing the following question will be most appreciated,

As these two mentioned drafts seem to be under consensus; would not it be right 
to address the coverage of ERL label should within the LSP Ping enhancement for 
EVPN.
Looking forward to getting your answer,

Nitsan Dolev
Ribbon Communications

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Coverage of ERL label within LSP-Ping Mechanisms for EVPN

[Ali Sajassi (sajassi)]

Hi Nitsan,

This draft has gone through the WGLC as well as IESG review and we are very 
close to its publication (i.e., too late to make such changes). Once it is 
published, we welcome enhancements and expansion to this document when needed. 
IETF has a formal process of reporting “errata” on a published RFC. We 
encourage you to file an errata on this. We will compile all such errata and we 
will address them in the bis version of this document.

Cheers,
Ali

From: BESS  on behalf of Nitsan Dolev 

Date: Wednesday, May 17, 2023 at 7:25 AM
To: bess@ietf.org , Parag Jain (paragj) , Luc 
Andre Burdet (lburdet) 
Cc: Alexander Vainshtein , Ron Sdayoor 

Subject: Re: [bess] Coverage of ERL label within LSP-Ping Mechanisms for EVPN
Dear authors of draft-ietf-bess-evpn-lsp-ping-09 and 
draft-burdet-bess-evpn-fast-reroute-03,

Your help with addressing the following question will be most appreciated,

As these two mentioned drafts seem to be under consensus; would not it be right 
to address the coverage of ERL label should within the LSP Ping enhancement for 
EVPN.
Looking forward to getting your answer,

Nitsan Dolev
Ribbon Communications

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Draft draft-ietf-bess-7432bis-07 section 7.11.2

[Ali Sajassi (sajassi)]

From: Menachem Dodge 
Date: Saturday, April 1, 2023 at 11:58 PM
To: Ali Sajassi (sajassi) , bess@ietf.org 
Subject: Re: Draft draft-ietf-bess-7432bis-07 section 7.11.2
Hello Ali,

Thanks very much for your helpful response.

Referring to #2 below, I assume that the default behavior of RFC 7432 for the 
Flow Label would be “no flow label”.
Is that correct?

That’s correct.

Cheers,
Ali

Thank you kindly.

Best Regards,
Menachem

From: Ali Sajassi (sajassi) 
Date: Saturday, 1 April 2023 at 3:41
To: Menachem Dodge , bess@ietf.org 
Subject: Re: Draft draft-ietf-bess-7432bis-07 section 7.11.2
CAUTION: External E-Mail - Use caution with links and attachments

Please refer to my comments below in red …

From: BESS  on behalf of Menachem Dodge 

Date: Thursday, March 30, 2023 at 8:51 AM
To: bess@ietf.org 
Subject: [bess] Draft draft-ietf-bess-7432bis-07 section 7.11.2
Hello All,

Section 7.11.2 of the draft-ietf-bess-7432bis states that if there is a 
mismatch – either of the L2-MTU, the Flow Label, or the Control Word that





“the local PE MUST NOT add the remote PE as the EVPN destination for any of the 
corresponding service instances.”


  1.  Is the reasoning that all PEs of a particular instance must behave in the 
same manner with regard to including the Flow Label / Control word and the L2 
MTU size?
The granularity is either at the EVI level or EVI/ESI level and for ELAN, we 
have any to any connectivity which means the info needs to be consistent for 
that EVI or EVI/ESI. So, if there is a mismatch between local and remote info, 
then that connection is not established and operator should be notified. This 
way we will avoid any unpredictable behavior.


  1.  What should be the behavior if local configuration is enabling the Flow 
Label and/or Control word but the L2-ATTR extended community is not received 
from a remote PE? Is the absence of L2-ATTR taken as meaning disabled and the 
remote PE must not be added ? Or perhaps it should be interpreted as unknown 
and the PE should assume that the local configuration applies also with regard 
to the remote PE?
This needs to be analyzed wrt individual flags and the absence of L2 Attribute 
EC should mean the behavior is that of RFC7432 so that we have backward 
compatibility – i.e., if the local PE is configured with no control word and it 
receives the route without L2 attribute EC, then it should NOT establish 
connection for that EVI because the absence of EC means the remote PE should 
send packets with control word per RFC7432.


  1.  Is the same behavior intended regarding EVPN-VPWS service instances as 
RFC 8214 only mentions L2-MTU mismatch but not control word mismatches.
Yes, mismatch of control word should also apply to EVPN-VPWS.

Cheers,
Ali






Thank you kindly.

Best Regards,

Menachem Dodge
System Architect
[signature_3683755730]
+972-526175734
mdo...@drivenets.com<mailto:mdo...@drivenets.com>
follow us on 
Linkedin<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_drivenets=DwMGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0=ZOwlTeTzRwLFnZdUX1cu5e-N21FJb3VkN5kN0vdUb6o=>
www.drivenets.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.drivenets.com=DwQGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0=6dVpM7D8w3FEU564eePsbsF1IlVd3a5xNnLtukA91UQ=>
[DriveNets Network 
Cloud]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drivenets.com_products_=DwMGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E=7vc9kZQGwO-AuvuIpq-9R6fQ_1nzXOBC14weVS_T0X0=Wat92F_qqgdgBF-q1akiFxmtKBruieVNJheGxIJwcPI=>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Draft draft-ietf-bess-7432bis-07 section 7.11.2

[Ali Sajassi (sajassi)]

Please refer to my comments below in red …

From: BESS  on behalf of Menachem Dodge 

Date: Thursday, March 30, 2023 at 8:51 AM
To: bess@ietf.org 
Subject: [bess] Draft draft-ietf-bess-7432bis-07 section 7.11.2
Hello All,

Section 7.11.2 of the draft-ietf-bess-7432bis states that if there is a 
mismatch – either of the L2-MTU, the Flow Label, or the Control Word that



“the local PE MUST NOT add the remote PE as the EVPN destination for any of the 
corresponding service instances.”


  1.  Is the reasoning that all PEs of a particular instance must behave in the 
same manner with regard to including the Flow Label / Control word and the L2 
MTU size?
The granularity is either at the EVI level or EVI/ESI level and for ELAN, we 
have any to any connectivity which means the info needs to be consistent for 
that EVI or EVI/ESI. So, if there is a mismatch between local and remote info, 
then that connection is not established and operator should be notified. This 
way we will avoid any unpredictable behavior.


  1.  What should be the behavior if local configuration is enabling the Flow 
Label and/or Control word but the L2-ATTR extended community is not received 
from a remote PE? Is the absence of L2-ATTR taken as meaning disabled and the 
remote PE must not be added ? Or perhaps it should be interpreted as unknown 
and the PE should assume that the local configuration applies also with regard 
to the remote PE?
This needs to be analyzed wrt individual flags and the absence of L2 Attribute 
EC should mean the behavior is that of RFC7432 so that we have backward 
compatibility – i.e., if the local PE is configured with no control word and it 
receives the route without L2 attribute EC, then it should NOT establish 
connection for that EVI because the absence of EC means the remote PE should 
send packets with control word per RFC7432.


  1.  Is the same behavior intended regarding EVPN-VPWS service instances as 
RFC 8214 only mentions L2-MTU mismatch but not control word mismatches.
Yes, mismatch of control word should also apply to EVPN-VPWS.

Cheers,
Ali




Thank you kindly.

Best Regards,

Menachem Dodge
System Architect
[signature_3683755730]
+972-526175734
mdo...@drivenets.com
follow us on Linkedin
www.drivenets.com
[DriveNets Network Cloud]

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Request for WG LC on draft-ietf-bess-rfc7432bis-06.txt

[Ali Sajassi (sajassi)]

Hi Folks,

We have been revising this baseline EVPN RFC for sometime now and I believe all 
the comment resolutions have been incorporated. This latest revision 
incorporates two additional comments - one from Sasha for section 6.3 and 
another from Jeffrey on section 18.

Please take a look at this latest revision and let me know if you have any 
questions/comments. I will ask for the WG LC in the upcoming BESS meeting and 
just want to make sure there is no pending comment.

Cheers,
Ali

From: BESS  on behalf of internet-dra...@ietf.org 

Date: Thursday, January 5, 2023 at 2:33 PM
To: i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] I-D Action: draft-ietf-bess-rfc7432bis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP MPLS-Based Ethernet VPN
Authors : Ali Sajassi
  Luc Andre Burdet
  John Drake
  Jorge Rabadan
  Filename: draft-ietf-bess-rfc7432bis-06.txt
  Pages   : 73
  Date: 2023-01-05

Abstract:
   This document describes procedures for BGP MPLS-based Ethernet VPNs
   (EVPN).  The procedures described here meet the requirements
   specified in [RFC7209] -- "Requirements for Ethernet VPN (EVPN)".

Note to Readers

   _RFC EDITOR: please remove this section before publication_

   The complete and detailed set of all changes between this version and
   [RFC7432] may be found as an Annotated Diff (rfcdiff) here
   (https://tools.ietf.org/rfcdiff?url1=https://www.rfc-
   editor.org/rfc/rfc7432.txt=https://www.ietf.org/archive/id/
   draft-ietf-bess-rfc7432bis-05.txt).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc7432bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-rfc7432bis-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A doubt in the requirements pertaining to VLAN-aware service interface in draft-ietf-bess-rfc7432bis

[Ali Sajassi (sajassi)]

Hi Sasha,

Thanks for your insightful comments. A few comments:


  1.  The text that you provided, gives further clarification to the existing 
text and thus I will incorporate it with some modifications as below:
“In the case where a single VLAN is represented by a single VID and
   thus no VID translation is required for the operational duration of
   that VLAN , an MPLS-encapsulated packet MUST
   carry that VID and the Ethernet Tag ID in all EVPN routes advertised for 
this BD
   MUST be set to that VID.  The advertising PE SHOULD advertise the MPLS Label 
in the
   Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1
   in the MAC/IP Advertisement routes representing both the Ethernet Tag ID
   and the EVI but MAY advertise the labels representing ONLY the EVI.
   This decision is only a local matter by the advertising PE which
   is also the disposition PE) and doesn't affect any other PEs.”

  1.  For the use case that you provided where a single VLAN can be represented 
by multiple VIDs (although at the later time where the VLAN starts with a 
single VID and then additional VID is configured for the same VLAN), is more 
appropriate to the 2nd paragraph that you quoted below. Basically, if the 
operator knows that at some point, there will be multiple VIDs for a VLAN, then 
they should follow the 2nd para text.
  2.  I will clarify what normalized VID mean (i.e., a unique VID network wide 
in context of an EVI). Although this VID is not used explicitly in data plane, 
it is used implicitly because it identifies the BD and thus the bridge table 
for incoming packets at the ingress PE. Even though the tag translation is done 
at the egress PE.

Cheers,
Ali



From: Alexander Vainshtein 
Date: Tuesday, November 29, 2022 at 2:18 AM
To: draft-ietf-bess-rfc7432bis.auth...@ietf.org 

Cc: bess@ietf.org , Ron Sdayoor , Moti 
Morgenstern , Nitsan Dolev , 
Michael Gorokhovsky 
Subject: A doubt in the requirements pertaining to VLAN-aware service interface 
in draft-ietf-bess-rfc7432bis
Hi all,
I have some doubts in the following requirement for Ethernet Tag ID in Section 
6.3 of the 7432bis 
draft
 (the problematic text is highlighted):


   In the case where a single VLAN is represented by a single VID and
   thus no VID translation is required, an MPLS-encapsulated packet MUST
   carry that VID.  The Ethernet Tag ID in all EVPN routes MUST be set
   to that VID.  The advertising PE MAY advertise the MPLS Label in the
   Ethernet A-D per EVI and MPLS Label1 in the MAC/IP Advertisement
   routes representing ONLY the EVI or representing both the Ethernet
   Tag ID and the EVI.  This decision is only a local matter by the
   advertising PE (which is also the disposition PE) and doesn't affect
   any other PEs.


   In the case where a single VLAN is represented by different VIDs on

   different CEs and thus VID translation is required, a normalized

   Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes.

   Furthermore, the advertising PE advertises the MPLS Label1 in the

   MAC/IP Advertisement route representing both the Ethernet Tag ID and

   the EVI, so that upon receiving an MPLS-encapsulated packet, the

   advertising PE can identify the corresponding bridge table from the

   MPLS EVPN label and perform Ethernet Tag ID translation ONLY at the

   disposition PE -- i.e., the Ethernet frames transported over the

   MPLS/IP network MUST remain tagged with the originating VID, and VID

   translation is performed on the disposition PE.  The Ethernet Tag ID

   in all EVPN routes MUST be set to the normal

First of all, please note that the quoted text does not mention Inclusive 
Multicast Ethernet Tag routes and the labels advertised in them at all.

My doubts are based on the following scenario:

  1.  Suppose that originally all the BDs in an EVI that implements VLAN-aware 
Bundle service interface has been has been created with the same per BD VID 
delimiting all the attachment circuits network-wide (in all the PEs). In 
accordance with the highlighted requirement, Ethernet Tag ID in all EVPN routes 
advertised for this BD has been set to the VID in question and at least some 
(may be all) the PEs have allocated only per-EVI labels for these routes.
  2.  Suppose further that a new attachment circuit delimited by a different 
single VID (and configured with egress VLAN translation) is now added to this 
BD in one of the PEs:
 *   The highlighted requirements are now applicable, and the EVPN Type 2 
routes now must carry labels that represent both the Ethernet Tag ID and the 
EVI.
 *   This presumably means that all the previously advertised EVPN Type 2 
routes for this BD MUST be withdrawn, and new ones – carrying labels that 
represent both the EVI and the specific BD – advertised. The same applies to 
EVPN Type 3 routes for the affected BD. My guess that this would result in a 

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Ali Sajassi (sajassi)]

Hi Sasha,

Please refer to my comments below:



AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a 
separate draft. I will talk to Parag about a write-up of a short draft about 
EVPN-VPWS and put a clarification statement that this draft is limited to EVPN 
and EVPN-IRB.
[[Sasha]] Can you please clarify what limiting the current draft to just EVPN 
and EVPN with IRB means.
Suppose that an egress PE that has advertised a per EVI EVPN Type 1 route with 
a certain NLRI (RD, ESI, Ethernet Tag ID, Label) for an interface of an 
EVPN-VPWS instance it contains receives an LP Ping Echo request with the EVPN 
Ethernet A-D Sub-TLV in the Target FEC TLV that matches RD, ESI and Ethernet 
Tag ID of this route and with the top label that matches the label in the 
advertised route. Which return code should t use in its reply?

AS> We need to look at all the modes in EVPN-VPWS, if we can cover it easily in 
the existing draft, we’ll cover it. If not, we’ll do it in another draft. Since 
for LSP ping, we are talking about MPLS service path only and not end-to-end 
forwarding path, my guess would be we should be able to cover it in the 
existing draft.


AS>> When an EVPN is configured for symmetric IRB mode, then ARP/ND is 
terminated locally and thus there is no need to verify it remotely (actually 
you cannot verify it remotely!). However, for asymmetric IRB, ARP/ND is 
processed remotely and thus should be verify it remotely. That’s why I have the 
text the way I have written it.

[[Sasha]] Suppose that two PEs are attached to an All-Active MH ES, and both 
are configured with a MAC-VRF attached to this MH ES and configured with a 
Symmetric EVPN IRB with anycast IP and MAC address. Suppose further that one 
(and it typically would be just one) of these PEs receives an P message with a 
certain IP→MAC pair in its sender part and advertises this pair in an EVPN Type 
2 route with Labl1 and Label2. What prevents the other PE from sending an LSP 
Ping Echo request with the EVPN MACIP Sub-TLV in the Target FEC stack TLV and 
with the label it has received in the Label1 field of the advertised route to 
the PE that has advertised this route, and what, if anything, prevents it from 
responding with return code 3 to such a request?

AS> That’s perfectly fine and the egress PE responds with return code 3. This 
follows the clarification text that I had earlier: “When the remote PE receives 
MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN label 
points to a MAC-VRF, then it validates the MAC state and forwarding. If the 
remote PE is not configured in symmetric IRB mode, then it validates ARP/ND 
state as well.”

Cheers,
Ali
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Ali Sajassi (sajassi)]

< sent the previous email by accident w/o completing my replies …>

Hi Sasha,

Thanks for your comments. Please refer to my replies marked with “AS>>”

From: Alexander Vainshtein 
Date: Wednesday, November 23, 2022 at 11:54 PM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , Alexander Ferdman 
, Dmitry Valdman , Ron 
Sdayoor , Nitsan Dolev , 
draft-ietf-bess-evpn-lsp-p...@ietf.org 
Subject: RE: A question pertaining to validation of LSP Ping Echo requests in 
draft-ietf-bess-evpn-lsp-ping-08
Hi Ali,
Lots of thanks for a prompt and very detailed response, and my sincere 
apologies for a delayed response.
Please see a short comment to your response marked [[Sasha]] inline below.


Please note also that I have recently added yet another question to my list, I 
am copying here it for your convenience:

RFC 8214<https://tools.ietf.org/html/rfc8214> defines usage of per EVI EVPN A-D 
(Type 1) routes in EVPN-VPWS in addition to their usage for aliasing/backup 
path defined in RFC 7432.  Suppose that the operator tries to perform a 
connectivity check to the aliasing function of some EVI but the PE that 
receives an LSP Ping Echo request with the EVPN Ethernet AD sub-TLV in the 
target label stack and label has advertised this FEC and label for a specific 
Attachment Circuit of an EVPN-VPWS instance. Is there any way it can indicate 
in the Echo Reply message that the label matches the target FEC but this FEC 
and label are used for EVPN-VPWS and not for aliasing?

AS>> EVIs are distinct and thus EVI for EVPN-VPWS is different from EVPN EVI. 
So, the receiving PE when it receives an Echo request, it knows whether this 
message is for EVPN-VPWS or EVPN based on EVI (represented by RD).

I see that the current version of the draft does not even mention RFC 8214.

AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a 
separate draft. I will talk to Parag about a write-up of a short draft about 
EVPN-VPWS and put a clarification statement that this draft is limited to EVPN 
and EVPN-IRB.

AS>> more comments below …

Regards, and lots of thanks in advance,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Tuesday, November 22, 2022 2:15 AM
To: Alexander Vainshtein ; 
draft-ietf-bess-evpn-lsp-p...@ietf.org
Cc: bess@ietf.org; Alexander Ferdman ; Dmitry 
Valdman ; Ron Sdayoor ; Nitsan 
Dolev 
Subject: [EXTERNAL] Re: A question pertaining to validation of LSP Ping Echo 
requests in draft-ietf-bess-evpn-lsp-ping-08

Hi Sasha,

Thanks for your comments. Please refer to my responses below marked with “AS>”

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, November 14, 2022 at 1:36 AM
To: 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>
 
mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Alexander Ferdman 
mailto:alexander.ferd...@rbbn.com>>, Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>, Ron Sdayoor 
mailto:ron.sday...@rbbn.com>>, Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>
Subject: [bess] A question pertaining to validation of LSP Ping Echo requests 
in draft-ietf-bess-evpn-lsp-ping-08
Hi all,
My colleagues and I have a question about the validation rules for LSP Ping 
Echo Requests associated with EVPN Type 2 routes in 
draft-ietf-bess-evpn-lsp-ping-08<https://clicktime.symantec.com/15sLvRYetCY2KC1bwWUPA?h=-ckPg5zPj9JW8ZeCWk4IAlaBiELRKcWTwix5bTPwY0s==https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-08>.

The problematic text in Section 4.1 of the draft says:

   The LSP Echo Request is sent using the EVPN MPLS label(s) associated
   with the MAC/IP Advertisement route announced by a remote PE and the
   MPLS transport label(s) to reach the remote PE.  When remote PE
   processes the received LSP Echo Request packet, the remote PE
   validates the MAC state if the MAC/IP Sub-TLV contains only MAC
   address.  If the MAC/IP Sub-TLV contains both MAC and IP address, the
   PE validates the ARP/ND state.

AS>  The 2nd part of the above paragraph (2nd sentence onward)  should be 
modified as follow:
“ In EVPN, MAC/IP Advertisement has multiple personality and it is used for the 
following cases:

1)  This route with only MAC address and MPLS Label1 is used for populating 
MAC-VRF and performing MAC forwarding.

2)  This route with MAC and IP addresses and only MPLS Label1 is used for 
populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for 
performing MAC forwarding

3)  This route with MAC and IP addresses and both MPLS Label1 and Label2 is 
used for populating MAC-VRF and IP-VRF tables as well as for both MAC 
forwarding, and IP forwarding in case of symmetric IRB
When the remote PE receives MAC/IP Sub-TLV containing only MAC address, then 
the remote PE validates the

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Ali Sajassi (sajassi)]

Hi Sasha,

Thanks for your comments. Please refer to my replies marked with “AS>>”

From: Alexander Vainshtein 
Date: Wednesday, November 23, 2022 at 11:54 PM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , Alexander Ferdman 
, Dmitry Valdman , Ron 
Sdayoor , Nitsan Dolev , 
draft-ietf-bess-evpn-lsp-p...@ietf.org 
Subject: RE: A question pertaining to validation of LSP Ping Echo requests in 
draft-ietf-bess-evpn-lsp-ping-08
Hi Ali,
Lots of thanks for a prompt and very detailed response, and my sincere 
apologies for a delayed response.
Please see a short comment to your response marked [[Sasha]] inline below.


Please note also that I have recently added yet another question to my list, I 
am copying here it for your convenience:

RFC 8214<https://tools.ietf.org/html/rfc8214> defines usage of per EVI EVPN A-D 
(Type 1) routes in EVPN-VPWS in addition to their usage for aliasing/backup 
path defined in RFC 7432.  Suppose that the operator tries to perform a 
connectivity check to the aliasing function of some EVI but the PE that 
receives an LSP Ping Echo request with the EVPN Ethernet AD sub-TLV in the 
target label stack and label has advertised this FEC and label for a specific 
Attachment Circuit of an EVPN-VPWS instance. Is there any way it can indicate 
in the Echo Reply message that the label matches the target FEC but this FEC 
and label are used for EVPN-VPWS and not for aliasing?

AS>> EVIs are distinct and thus EVI for EVPN-VPWS is different from EVPN EVI. 
So, the receiving PE when it receives an Echo request, it knows whether this 
message is for EVPN-VPWS or EVPN based on EVI (represented by RD).

I see that the current version of the draft does not even mention RFC 8214.

AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a 
separate draft. I will talk to Parag about a write-up of a short draft about 
EVPN-VPWS and put a clarification statement that this draft is limited to EVPN 
and EVPN-IRB.

AS>> more comments below …

Regards, and lots of thanks in advance,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Tuesday, November 22, 2022 2:15 AM
To: Alexander Vainshtein ; 
draft-ietf-bess-evpn-lsp-p...@ietf.org
Cc: bess@ietf.org; Alexander Ferdman ; Dmitry 
Valdman ; Ron Sdayoor ; Nitsan 
Dolev 
Subject: [EXTERNAL] Re: A question pertaining to validation of LSP Ping Echo 
requests in draft-ietf-bess-evpn-lsp-ping-08

Hi Sasha,

Thanks for your comments. Please refer to my responses below marked with “AS>”

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, November 14, 2022 at 1:36 AM
To: 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>
 
mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Alexander Ferdman 
mailto:alexander.ferd...@rbbn.com>>, Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>, Ron Sdayoor 
mailto:ron.sday...@rbbn.com>>, Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>
Subject: [bess] A question pertaining to validation of LSP Ping Echo requests 
in draft-ietf-bess-evpn-lsp-ping-08
Hi all,
My colleagues and I have a question about the validation rules for LSP Ping 
Echo Requests associated with EVPN Type 2 routes in 
draft-ietf-bess-evpn-lsp-ping-08<https://clicktime.symantec.com/15sLvRYetCY2KC1bwWUPA?h=-ckPg5zPj9JW8ZeCWk4IAlaBiELRKcWTwix5bTPwY0s==https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-08>.

The problematic text in Section 4.1 of the draft says:

   The LSP Echo Request is sent using the EVPN MPLS label(s) associated
   with the MAC/IP Advertisement route announced by a remote PE and the
   MPLS transport label(s) to reach the remote PE.  When remote PE
   processes the received LSP Echo Request packet, the remote PE
   validates the MAC state if the MAC/IP Sub-TLV contains only MAC
   address.  If the MAC/IP Sub-TLV contains both MAC and IP address, the
   PE validates the ARP/ND state.

AS>  The 2nd part of the above paragraph (2nd sentence onward)  should be 
modified as follow:
“ In EVPN, MAC/IP Advertisement has multiple personality and it is used for the 
following cases:

1)  This route with only MAC address and MPLS Label1 is used for populating 
MAC-VRF and performing MAC forwarding.

2)  This route with MAC and IP addresses and only MPLS Label1 is used for 
populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for 
performing MAC forwarding

3)  This route with MAC and IP addresses and both MPLS Label1 and Label2 is 
used for populating MAC-VRF and IP-VRF tables as well as for both MAC 
forwarding, and IP forwarding in case of symmetric IRB
When the remote PE receives MAC/IP Sub-TLV containing only MAC address, then 
the remote PE validates the MAC state and forwarding.  When the remote PE 
receives MAC/IP Sub-TLV cont

Re: [bess] A doubt about draft-sajassi-bess-evpn-ip-aliasing-05

[Ali Sajassi (sajassi)]

Hi Jorge, Sasha:

Agreed that we just need to add a sentence or two (in Introduction and maybe 
Abstract as well) to make it clear that this draft’s applicability is limited 
to EVPN All-Active and Single-Active multi-homing ONLY!

Cheers,
Ali

From: Alexander Vainshtein 
Date: Thursday, November 24, 2022 at 5:38 AM
To: Jorge Rabadan (Nokia) , Ali Sajassi (sajassi) 

Cc: Luc André Burdet , bess@ietf.org , 
Nitsan Dolev , Alexander Ferdman 
, Ron Sdayoor , Dmitry 
Valdman , draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: Re: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05
Hi Jorge,
Any text that makes non-applicability of IP Aliasing to Single Flow-Active MH 
mode woild be OK with me.

My 2c,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>


From: Jorge Rabadan (Nokia) 
Sent: Thursday, November 24, 2022, 14:08
To: Alexander Vainshtein ; Ali Sajassi (sajassi) 

Cc: Luc André Burdet ; bess@ietf.org ; 
Nitsan Dolev ; Alexander Ferdman 
; Ron Sdayoor ; Dmitry 
Valdman ; draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: [EXTERNAL] Re: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05

Hi Sasha,

The document explicitly mentions single-active and all-active. Maybe we can add 
a sentence saying that those are the two multi-homing modes addressed by the 
spec. I don’t think we should mention anything else?

Thanks.
Jorge

From: Alexander Vainshtein 
Date: Wednesday, November 23, 2022 at 11:36 PM
To: Ali Sajassi (sajassi) 
Cc: Luc André Burdet , bess@ietf.org , 
Nitsan Dolev , Alexander Ferdman 
, Ron Sdayoor , Dmitry 
Valdman , draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: RE: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05
Hi Ali,
Lots of thanks for a prompt response and my sincere apologies for a 
much-delayed response.
Your response matches my understanding.

May I suggest that, since 
draft-sajassi-bess-evpn-ip-aliasing-05<https://clicktime.symantec.com/15siKyXAKWkixmcG2nv1Y?h=ewnEsUd2iE4xin3_mbyooIY1ENSU7btYKRsi0Xr6wM8==https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-05>
 is not intended for use with single flow-active multi-homing, this would be 
explicitly stated in the next revision of the draft?

Regards, and lots of thanks in advance,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Thursday, November 17, 2022 5:49 PM
To: Alexander Vainshtein ; 
draft-sajassi-bess-evpn-ip-alias...@ietf.org
Cc: Luc André Burdet ; bess@ietf.org; Nitsan Dolev 
; Alexander Ferdman ; Ron 
Sdayoor ; Dmitry Valdman 
Subject: [EXTERNAL] Re: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05

Hi Sasha,

EVPN based RFCs (7432 and 8365) define two types of multi-homing: All-Active 
and Single-Active. Both of these multi-homing mechanism relies on multi-homing 
PEs to control loop detection and prevention using DF election and 
split-horizon filtering.  
draft-ietf-bess-evpn-l2gw-proto-02<https://clicktime.symantec.com/15siF9Ksru58YpnLVEWrv?h=gJyaiM0MQ9etseWoNrSRgEXyb9bM6DrwLUAnALqYv_g==https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-02>
 introduces a 3rd multi-homing mechanism called Single-Flow-Active for 
scenarios where loop detection and prevention are performed by CE devices 
(running L2GW protocols) and not PEs.

draft-sajassi-bess-evpn-ip-aliasing-05<https://clicktime.symantec.com/15siKyXAKWkixmcG2nv1Y?h=ewnEsUd2iE4xin3_mbyooIY1ENSU7btYKRsi0Xr6wM8==https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-05>
 basically extends the baseline multi-homing mechanism of All-Active to L3 use 
cases mentioned in the draft (e.g., symmetric IRB). This draft is NOT intended 
for Single-Flow-Active multi-homing use case.  If single-flow-active 
multi-homing need to get extended to L3 use cases, then it can be covered in a 
follow-up single-flow-active draft.

Cheers,
Ali

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, November 17, 2022 at 2:25 AM
To: 
draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>>
Cc: Luc André Burdet mailto:laburdet.i...@gmail.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>, Alexander 
Ferdman mailto:alexander.ferd...@rbbn.com>>, Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>, Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>
Subject: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05
Hi,
I have doubts regarding applicability of the solution for L3 fast convergence 
defined in 
draft-sajassi-bess-evpn-ip-aliasing-05<https://clicktime.symantec.com/15siKyXAKWkixmcG2nv1Y?h=ewnEsUd2iE4xin3_mbyooIY1ENSU7btYKRsi0Xr6wM8==https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-05>
 for the scenarios in which the MH ES in question operates in Single 
Flow-Active load-balanci

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Ali Sajassi (sajassi)]

Hi Sasha,

Thanks for your comments. Please refer to my responses below marked with “AS>”

From: BESS  on behalf of Alexander Vainshtein 

Date: Monday, November 14, 2022 at 1:36 AM
To: draft-ietf-bess-evpn-lsp-p...@ietf.org 

Cc: bess@ietf.org , Alexander Ferdman 
, Dmitry Valdman , Ron 
Sdayoor , Nitsan Dolev 
Subject: [bess] A question pertaining to validation of LSP Ping Echo requests 
in draft-ietf-bess-evpn-lsp-ping-08
Hi all,
My colleagues and I have a question about the validation rules for LSP Ping 
Echo Requests associated with EVPN Type 2 routes in 
draft-ietf-bess-evpn-lsp-ping-08.

The problematic text in Section 4.1 of the draft says:

   The LSP Echo Request is sent using the EVPN MPLS label(s) associated
   with the MAC/IP Advertisement route announced by a remote PE and the
   MPLS transport label(s) to reach the remote PE.  When remote PE
   processes the received LSP Echo Request packet, the remote PE
   validates the MAC state if the MAC/IP Sub-TLV contains only MAC
   address.  If the MAC/IP Sub-TLV contains both MAC and IP address, the
   PE validates the ARP/ND state.

AS>  The 2nd part of the above paragraph (2nd sentence onward)  should be 
modified as follow:
“ In EVPN, MAC/IP Advertisement has multiple personality and it is used for the 
following cases:

  1.  This route with only MAC address and MPLS Label1 is used for populating 
MAC-VRF and performing MAC forwarding.
  2.  This route with MAC and IP addresses and only MPLS Label1 is used for 
populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for 
performing MAC forwarding
  3.  This route with MAC and IP addresses and both MPLS Label1 and Label2 is 
used for populating MAC-VRF and IP-VRF tables as well as for both MAC 
forwarding, and IP forwarding in case of symmetric IRB
When the remote PE receives MAC/IP Sub-TLV containing only MAC address, then 
the remote PE validates the MAC state and forwarding.  When the remote PE 
receives MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN 
label points to a MAC-VRF, then it validates the MAC state and forwarding. If 
the remote PE is not configured in symmetric IRB mode, then it validates ARP/ND 
state as well. However, if the EVPN label points to an IP-VRF, then it 
validates IP state and forwarding. Any other combinations, such as remote PE 
receiving MAC/IP Sub-TLV containing only MAC address but with EVPN label 
pointing to an IP-VRF, should be considered invalid and LSP Echo response 
should be sent with the appropriate return code.


Here are our questions:

  1.  Suppose that some MAC address:
 *   Has been learned by the intended egress PE from the Data Plane from an 
All-Active MH ES and advertised in a MAC-only route EVPN Type 2 route
 *   An EVPN Type 2 route for some IP→MAC pair with the same MAC address 
has been advertised by another PE attached to the same All-Active MH ES
 *   An LSP Ping Echo request with the IP→MAC pair in question and the 
label that has been advertised by the intended egress PE in the Label1 field of 
an EVPN Type 2 route for the MAC address in question is received
What is the expected result of the validation taking into account that the 
egress PE has not ever advertised an EVPN Type 2 route for the IP→MAC pair in 
question?
AS> Baseline EVPN (RFC 7432) describes how a MAC address or  pair is 
synched up among multi-homing PEs. So, if PE1 (but not PE2) advertises M1 or 
, PE2 will synch up with PE1 and programs M1 or (M1,IP1> in its tables 
as if it has received M1 or  via its local ESI. So, in your example, 
when PE3 send lsp ping request to PE2 (either for M1 for ), then PE2 
can validate it even though PE2 never advertised M1 or .  Of course, 
this assumes aliasing is enabled. If aliasing is not enabled, then PE3 doesn’t 
have the right MPLS label to send the LSP Ping request.


  1.  Suppose that:
 *   Some MAC address as been learned by the egress PE only via the control 
plane (ARP/ND) and advertised In an EVPN Type 2 route for an IP→MAC pair
 *   A MAC-only LSP Ping request for the MAC address in question with the 
label advertised in the Label1 field of the EVPN Type 2 route for an IP→MAC 
pair in question has been received
What is the expected result of the validation taking into account that the 
egress PE has not advertised any MAC-only routes for the MAC address in 
question?

AS> I believe the updated text should take care of this scenario.


  1.  Suppose that:
 *   We are dealing with a BD that is used by a Symmetric EVPN IRB
 *   Some MAC address as been learned by the egress PE only via the control 
plane (ARP/ND)  and has been advertised In an EVPN Type 2 route for an IP→MAC 
pair with Label2 field present
 *   A MAC-only LSP Ping request for the MAC address in question with the 
label advertised in the Label2field of the EVPN Type 2 route for an IP→MAC pair 
in question has been 

Re: [bess] A doubt about draft-sajassi-bess-evpn-ip-aliasing-05

[Ali Sajassi (sajassi)]

Hi Sasha,

EVPN based RFCs (7432 and 8365) define two types of multi-homing: All-Active 
and Single-Active. Both of these multi-homing mechanism relies on multi-homing 
PEs to control loop detection and prevention using DF election and 
split-horizon filtering.  
draft-ietf-bess-evpn-l2gw-proto-02
 introduces a 3rd multi-homing mechanism called Single-Flow-Active for 
scenarios where loop detection and prevention are performed by CE devices 
(running L2GW protocols) and not PEs.

draft-sajassi-bess-evpn-ip-aliasing-05
 basically extends the baseline multi-homing mechanism of All-Active to L3 use 
cases mentioned in the draft (e.g., symmetric IRB). This draft is NOT intended 
for Single-Flow-Active multi-homing use case.  If single-flow-active 
multi-homing need to get extended to L3 use cases, then it can be covered in a 
follow-up single-flow-active draft.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Thursday, November 17, 2022 at 2:25 AM
To: draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Cc: Luc André Burdet , bess@ietf.org , 
Nitsan Dolev , Alexander Ferdman 
, Ron Sdayoor , Dmitry 
Valdman 
Subject: A doubt about draft-sajassi-bess-evpn-ip-aliasing-05
Hi,
I have doubts regarding applicability of the solution for L3 fast convergence 
defined in 
draft-sajassi-bess-evpn-ip-aliasing-05
 for the scenarios in which the MH ES in question operates in Single 
Flow-Active load-balancing mode as described in 
draft-ietf-bess-evpn-l2gw-proto-02.

These doubts are based on the fact that, in Single Flow-Active load-balancing 
mode, the Primary PE is defined by the Layer 2 Control Protocol (or its 
equivalent) for each specific host, while the EVPN IP Aliasing draft advertises 
Primary/Backup paths via P/B bits in the EVPN Layer 2 Extended Community 
attached to the IP A-D EVPN routes.

What, if anything, did I miss?

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-ac-aware-bundling

[Ali Sajassi (sajassi)]

As a co-author, I support adoption of it and not aware of any undisclosed IPR.

Cheers,
Ali

From: BESS  on behalf of Stephane Litkowski (slitkows) 

Date: Monday, October 10, 2022 at 1:40 AM
To: bess-cha...@ietf.org , bess@ietf.org 
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-ac-aware-bundling
Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-ac-aware-bundling-06 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on October 24th 2022.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

[Ali Sajassi (sajassi)]

As a co-author, support publication of it and am not aware of any undisclosed 
IPR.

Regards,
Ali

From: BESS  on behalf of Bocci, Matthew (Nokia - GB) 

Date: Monday, September 26, 2022 at 4:06 AM
To: bess@ietf.org 
Subject: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05
This email starts a two-week working group last call for 
draft-ietf-bess-bgp-sdwan-usage-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as an Informational RFC.

This poll runs until the 10th October 2022

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors and contributors.
There are currently two IPR disclosures.


Thank you,
Matthew & Stephane


[1]  
draft-ietf-bess-bgp-sdwan-usage-05



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[Ali Sajassi (sajassi)]

I support publication of this draft and I am not aware of any undisclosed IPR.
Regards,
Ali

From: slitkows.i...@gmail.com 
Date: Wednesday, January 26, 2022 at 1:50 AM
To: bess@ietf.org , 
draft-ietf-bess-evpn-mh-split-hori...@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-mh-split-horizon

Hello Working Group,



This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-mh-split-horizon [1].



This poll runs until *the 9th of Feb*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



There is no IPR currently disclosed.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Ali Sajassi (sajassi)]

I support publication of this document and I am not aware of any IPR that 
hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Ali Sajassi (sajassi)]

I support the publication of this draft and I am not aware of any undisclosed 
IPR.

Cheers,
Ali

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Monday, September 27, 2021 at 11:03 PM
To: 'BESS' 
Cc: bess-cha...@ietf.org 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as an author or a contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors and contributors.

There are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Implementation poll for draft-ietf-bess-evpn-lsp-ping-05

[Ali Sajassi (sajassi)]

Hi Matthew,

Some of the co-authors are on PTO and I couldn’t reach them (typical of the 
month of August). So, I’d like to get a bit more extension.

Regarding the two questions below:

  1.  My company hasn’t implemented it.
  2.  I do think that we should process with the publication as it describes 
how LSP ping can be used to detect data-plane failures for various EVPN 
functionality including aliasing, split-horizon filtering using ESI label, 
multicast, l2-unicast, l3-unicast, IRB, etc. For MPLS transport tunnel, I am 
not aware of any other tool/draft that allows us to do data-plane failure 
detection. Thus, I think it is important to proceed with its publications.

Still I’d like to hear from other co-authors and other people in this community.

Regards,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, August 9, 2021 at 6:25 AM
To: bess@ietf.org , draft-ietf-bess-evpn-lsp-p...@ietf.org 

Subject: Implementation poll for draft-ietf-bess-evpn-lsp-ping-05
WG and Authors

Unfortunately I have not seen any responses indicating that there are any known 
implementations of this draft. I also did not see any responses to Stephane's 
question if we should proceed regardless.

As per the BESS WG implementation policy 
(https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw/), 
please can you respond to this email indicating either:

- That you are aware of any implementations (ideally providing some details)
- If you are not aware of any, if you think the WG should proceed with the 
draft's publication and why.

I will close this poll on 25th August 2021.

Regards

Matthew


On 14/06/2021, 17:38, "BESS on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : LSP-Ping Mechanisms for EVPN and PBB-EVPN
Authors : Parag Jain
  Samer Salam
  Ali Sajassi
  Sami Boutros
  Greg Mirsky
 Filename: draft-ietf-bess-evpn-lsp-ping-05.txt
 Pages   : 15
 Date: 2021-06-14

Abstract:
   LSP-Ping is a widely deployed Operation, Administration, and
   Maintenance (OAM) mechanism in MPLS networks.  This document
   describes mechanisms for detecting data-plane failures using LSP Ping
   in MPLS based EVPN and PBB-EVPN networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-lsp-ping-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09

[Ali Sajassi (sajassi)]

Hi Ben,

I just published rev-14 of the draft with the updates to the IANA section.

Cheers,
Ali

From: John E Drake 
Date: Wednesday, June 9, 2021 at 11:47 AM
To: Benjamin Kaduk 
Cc: Ali Sajassi (sajassi) , The IESG , 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org 
Subject: RE: Benjamin Kaduk's DISCUSS ballot comment on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09
Ben,

Thanks for your help.  I think Ali will add the text from Amanda in the next 
published version of the draft.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Wednesday, June 9, 2021 1:28 PM
> To: John E Drake 
> Cc: Ali Sajassi (sajassi) ; The IESG ; 
> draft-
> ietf-bess-evpn-inter-subnet-forward...@ietf.org; bess-cha...@ietf.org;
> bess@ietf.org
> Subject: Re: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-
> inter-subnet-forwarding-09
>
> [External Email. Be cautious of content]
>
>
> Hi John,
>
> As I wrote to Ali just now, my apologies for taking almost a month to reply.
>
> Adding a note to the registry entry for the MAC/IP Advertisement route would
> be a great path forward, and would be enough for me to clear my discuss.  
> (Just
> to confirm: I don't think this is in the published I-D yet,
> right?)
>
> Thanks again,
>
> Ben
>
> On Tue, May 11, 2021 at 09:26:08PM +, John E Drake wrote:
> > Hi,
> >
> > I corresponded with Amanda Baber and she says we can add a note to the
> IANA Considerations section of the IRB draft stating that "This document has
> been listed as an additional reference for the MAC/IP Advertisement route in 
> the
> EVPN Route Type registry".
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Benjamin Kaduk 
> > > Sent: Saturday, February 27, 2021 6:57 PM
> > > To: Ali Sajassi (sajassi) 
> > > Cc: The IESG ; draft-ietf-bess-evpn-inter-subnet-
> > > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org
> > > Subject: Re: Benjamin Kaduk's DISCUSS ballot comment on
> > > draft-ietf-bess-evpn-
> > > inter-subnet-forwarding-09
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > Hi Ali,
> > >
> > > Sorry for the slow response -- the IESG was working hard the past
> > > two weeks based on the page-count on the telechat.
> > >
> > > On Wed, Feb 10, 2021 at 11:29:04PM +, Ali Sajassi (sajassi) wrote:
> > > >
> > > > Hi Ben,
> > > >
> > > > I responded to your comments in the current thread but let me
> > > > respond to
> > > your comments in the draft’s ballot page more specifically here so
> > > that you don’t have to go through that email. Please let me know if
> > > you have any further comments.
> > >
> > > Thanks for pulling out the latest datatracker comments, as those are
> > > the most important ones.  (I think there are a couple things in the
> > > other thread I will also reply to for completeness.)
> > >
> > > >
> > > > 1)  I think draft-ietf-bess-evpn-irb-extended mobility needs to be
> > > > a normative reference, since "the procedures in [it] must be exercised"
> > > > incorporates its procedures by reference.
> > > >
> > > > AS>  The draft-ietf-bess-evpn-irb-extended-mobility describes the
> > > > AS> mobility
> > > procedures when a host has several IP addresses and a single MAC
> > > address (or vise versa); whereas, this draft describes the mobility
> > > procedures when the host has a single IP address and a single MAC
> > > address.  As such the extended-mobility draft does not need to be a
> > > normative reference. There was some confusion about IPv6 Link Local
> > > address & host mobility and I provided further clarification in the
> > > corresponding paragraph which is cut & pasted below for your convenience.
> > > >
> > > >
> > > >   “Depending on the expexted TS's behavior, an NVE needs to handle
> > > > at
> > > >
> > > >least the first bullet and should be able to handle the 2nd and
> > > > the
> > > >
> > > >3rd bullet.  The following subsections describe the procedures
> > > > for
> > > >
> > > >each of them where it is assumed that the MAC and IP add

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Thank you Ben for your meticulous review and valuable comments that you have 
provided during the course of this document review.

Cheers,
Ali

From: Benjamin Kaduk 
Date: Wednesday, June 9, 2021 at 10:26 AM
To: Ali Sajassi (sajassi) 
Cc: The IESG , 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Zhaohui Zhang 

Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Hi Ali,

My apologies once more for taking so long to get back to you -- I should
not make a habit of taking a month to reply.

I will top-post since the color is not retained in this text/plain message,
but in short, I think we can consider these topics resolved.
Thanks for confirming that the procedure and sequencing of steps in the
document (withdraw, then probe, then psosible re-advertise) is as-intended
to cover the common case.  This matches up with John's sentiment, and it
sounds like leaving the text in the document as-is is the right thing to
do.  I also appreciate the additional perspective about how the security
considerations for the layer-3 part of this IRB solution relate to the
considerations described in RFC 4365.

Thanks again,

Ben

On Tue, May 11, 2021 at 10:31:03PM +, Ali Sajassi (sajassi) wrote:
> Hi Ben,
>
> Sorry for the delayed response. I think we can address your last two comments 
> rather easily and hopefully close this review. Please refer to my replies 
> marked in red.
>
>
> From: Benjamin Kaduk 
> Date: Saturday, February 27, 2021 at 4:06 PM
> To: Ali Sajassi (sajassi) 
> Cc: The IESG , 
> draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org 
> , bess-cha...@ietf.org 
> , bess@ietf.org , Zhaohui Zhang 
> 
> Subject: Re: Benjamin Kaduk's Discuss on 
> draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
> Hi Ali (again),
>
> As promised in the other thread I wanted to say a couple more things here.
> I'll trim the stuff that's being covered elsewhere or is already
> resolved...
>
> On Fri, Feb 05, 2021 at 07:53:44AM +, Ali Sajassi (sajassi) wrote:
> > Hi Ben,
> >
> > Please see my replies marked with AS>>
> >
> > On 10/29/20, 5:26 PM, "Benjamin Kaduk"  wrote:
> >
> > On Thu, Sep 03, 2020 at 06:17:01AM +, Ali Sajassi (sajassi) wrote:
> > > Hi Ben,
> > >
> > > Thanks very much for your review and comments. Please refer to my 
> > replies inline marked with [AS].
> > >
> > > On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker" 
> >  wrote:
> > > Section 7
> > >
> > > The concrete advice we give in Section
> > > 7.1 to send a local ARP probe is good, but how rigid does the 
> > sequencing
> > > need to be amongst (receive EVPN MAC/IP Advertisement, send local 
> > ARP
> > > probe/wait for response, and withdraw EVPN Mac/IP Advertisement)? 
> >  If
> > > there was a way to avoid the need to withdraw+readvertise step, 
> > it seems
> > > like that might be preferable.
> > >
> > > [AS] If the reply to the local ARP probe is positive, then the source 
> > PE doesn't withdraw the MAC/IP but rather it readvertised it with a higher 
> > sequence number and performs MAC duplication detection.
> >
> > The current text does not give me that impression.  I would prefer if we
> > could reword it somehow to clarify, perhaps "It then sends an ARP probe
> > locally to ensure that the MAC is gone, and withdraws the EVP MAC/IP
> > Advertisement route upon confirmation that the MAC is gone".
> >
> > AS>>  The sentence above it says the source NVE withdraws the MAC/IP route. 
> > Here it is:
> > "It then withdraws its EVPN MAC/IP Advertisement route.
> >Furthermore, it sends an ARP probe locally to ensure that the MAC is
> >gone.  If an ARP response is received, the source NVE updates its ARP
> >entry for that (IP, MAC) and re-advertises an EVPN MAC/IP
> >Advertisement route for that (IP, MAC) along with MAC Mobility
> >Extended Community with the sequence number incremented by one."
>
> I think I'm still confused.  The sequencing in this paragraph, just taking
> the steps in order, is "first, withdraw the route.  Second, send a local ARP
> probe.  Third, if the ARP probe gets a response, re-advertise [a new] route
> for the MAC/IP with higher sequence number".  But earlier in the quoted
> text you said that "the source PE doesn't withdraw the MAC/IP but rather it
> readvertised it".  I stil

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Ben,

Sorry for the delayed response. I think we can address your last two comments 
rather easily and hopefully close this review. Please refer to my replies 
marked in red.


From: Benjamin Kaduk 
Date: Saturday, February 27, 2021 at 4:06 PM
To: Ali Sajassi (sajassi) 
Cc: The IESG , 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Zhaohui Zhang 

Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Hi Ali (again),

As promised in the other thread I wanted to say a couple more things here.
I'll trim the stuff that's being covered elsewhere or is already
resolved...

On Fri, Feb 05, 2021 at 07:53:44AM +, Ali Sajassi (sajassi) wrote:
> Hi Ben,
>
> Please see my replies marked with AS>>
>
> On 10/29/20, 5:26 PM, "Benjamin Kaduk"  wrote:
>
> On Thu, Sep 03, 2020 at 06:17:01AM +, Ali Sajassi (sajassi) wrote:
> > Hi Ben,
> >
> > Thanks very much for your review and comments. Please refer to my 
> replies inline marked with [AS].
> >
> > On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker" 
>  wrote:
> > Section 7
> >
> > The concrete advice we give in Section
> > 7.1 to send a local ARP probe is good, but how rigid does the 
> sequencing
> > need to be amongst (receive EVPN MAC/IP Advertisement, send local 
> ARP
> > probe/wait for response, and withdraw EVPN Mac/IP Advertisement)?  
> If
> > there was a way to avoid the need to withdraw+readvertise step, it 
> seems
> > like that might be preferable.
> >
> > [AS] If the reply to the local ARP probe is positive, then the source 
> PE doesn't withdraw the MAC/IP but rather it readvertised it with a higher 
> sequence number and performs MAC duplication detection.
>
> The current text does not give me that impression.  I would prefer if we
> could reword it somehow to clarify, perhaps "It then sends an ARP probe
> locally to ensure that the MAC is gone, and withdraws the EVP MAC/IP
> Advertisement route upon confirmation that the MAC is gone".
>
> AS>>  The sentence above it says the source NVE withdraws the MAC/IP route. 
> Here it is:
> "It then withdraws its EVPN MAC/IP Advertisement route.
>Furthermore, it sends an ARP probe locally to ensure that the MAC is
>gone.  If an ARP response is received, the source NVE updates its ARP
>entry for that (IP, MAC) and re-advertises an EVPN MAC/IP
>Advertisement route for that (IP, MAC) along with MAC Mobility
>Extended Community with the sequence number incremented by one."

I think I'm still confused.  The sequencing in this paragraph, just taking
the steps in order, is "first, withdraw the route.  Second, send a local ARP
probe.  Third, if the ARP probe gets a response, re-advertise [a new] route
for the MAC/IP with higher sequence number".  But earlier in the quoted
text you said that "the source PE doesn't withdraw the MAC/IP but rather it
readvertised it".  I still see the first "withdraw" step in the procedure,
so I'm not sure whether we expect there to be a "withdraw then readvertise
with higher sequence number" or just "readvertise with higher sequence
number" (no withdraw at all).

In terms of sequencing, both the current paragraph in section 7.1 and your 
understanding of it are correct (first, withdraw the route.  Second, send a 
local ARP probe.  Third, if the ARP probe gets a response, re-advertise [a new] 
route for the MAC/IP with higher sequence number). Sorry for confusing you with 
my earlier response by saying that "the source PE doesn't withdraw the MAC/IP 
but rather it
readvertised it". We always withdraw the route first and then send a local ARP 
probe.

(I don't really know how disruptive the withdraw is and thus I don't know
to what lengths we should go to avoid it.  But if the document is saying
something that is different than the expected behavior we should change the
document.)

Vast majority of the cases there is a valid workload/TS move which means the TS 
is moved from source to the target NVE. Therefore, the procedure in this 
section is based on that – i.e, to optimize for vast majority of the cases 
which need route withdrawal.

> > Section 11
> >
> >Furthermore, the security consideration for layer-3 routing is 
> this
> >document follows that of [RFC4365] with the exception for 
> application
> >
> > The Security Considerations of RFC 4365 notes that RFC 4111 
> provides a
> > template "that may be used to evaluate and summarize how a

Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop

[Ali Sajassi (sajassi)]

Support as a co-author. We requested our legal department in Nov/2020 to 
disclose an IPR related to this draft to IETF. We will follow it up to see why 
it hasn’t been disclosed yet.

Cheers,
Ali

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, April 19, 2021 at 11:07 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG and IPR poll adoption poll for 
draft-krattiger-evpn-modes-interop

Hello,

This email begins a two-weeks WG adoption poll for 
draft-krattiger-evpn-modes-interop-03 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 4th May 2021.

Regards,
Matthew and Stephane


[1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-brissette-bess-evpn-l2gw-proto

[Ali Sajassi (sajassi)]

Support as a co-author. There is an IPR which is being disclosed.

Cheers,
Ali

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, March 29, 2021 at 12:13 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-brissette-bess-evpn-l2gw-proto

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-l2gw-proto [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on April 12th 2021.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-l2gw-proto/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Ali Sajassi (sajassi)]

Support as a co-author. Not aware of any undisclosed IPR.

-Ali

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, December 9, 2020 at 1:23 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , , Cisco 
Employee , 
Resent-Date: Wednesday, December 9, 2020 at 1:22 AM

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 23rd December 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09

[Ali Sajassi (sajassi)]

Hi Ben,

I responded to your comments in the current thread but let me respond to your 
comments in the draft’s ballot page more specifically here so that you don’t 
have to go through that email. Please let me know if you have any further 
comments.


1)  I think draft-ietf-bess-evpn-irb-extended mobility needs to be a
normative reference, since "the procedures in [it] must be exercised"
incorporates its procedures by reference.

AS>  The draft-ietf-bess-evpn-irb-extended-mobility describes the mobility 
procedures when a host has several IP addresses and a single MAC address (or 
vise versa); whereas, this draft describes the mobility procedures when the 
host has a single IP address and a single MAC address.  As such the 
extended-mobility draft does not need to be a normative reference. There was 
some confusion about IPv6 Link Local address & host mobility and I provided 
further clarification in the corresponding paragraph which is cut & pasted 
below for your convenience.


  “Depending on the expexted TS's behavior, an NVE needs to handle at

   least the first bullet and should be able to handle the 2nd and the

   3rd bullet.  The following subsections describe the procedures for

   each of them where it is assumed that the MAC and IP addresses of a

   TS have one-to-one relationship (i.e., there is one IP address per

   MAC address and vice versa).  The procedures for host mobility

   detection in the presence of many-to-one relationship is outside the

   scope of this document and it is covered in

   [I-D.ietf-bess-evpn-irb-extended-mobility].  The many-to-one

   relationship means many host IP addresses corresponding to a single

   host MAC address or many host MAC addresses corresponding to a single

   IP address.  It should be noted that in case of IPv6, a link-local IP

   address does not count in many-to-one relationship because that

   address is confined to single Ethernet Segment and it is not used for

   host moblity (i.e., by definition host mobility is between two

   different Ethernet Segments).  Therefore, when an IPv6 host is

   configured with both a Global Unicast address (or a Unique Local

   address) and a Link Local address, for the purpose of host mobility,

   it is considered with a single IP address.”


2)  Similarly,
draft-ietf-idr-tunnel-encaps seems like a normative reference since we
require the RT-2 route used by this document to be advertised along with
the EC that indicates the tunnel type.

AS>  Yes, this draft needs to be normative and the correction has been made.


3)  I still think we need to discuss whether this document Updates: 7432.
RFC 7432 specifies the layout and interpretation of the RT-2 (MAC-IP
Advertisement Route) EVPN NRLI, but we extend it in several ways (e.g.,
the Label1 and Label2 (which we spell "Label-1" and "Label-2",
unfortunately) are only MPLS labels in 7432, but we expand that to also
allow VNI values in those fields; likewise, 7432 gives no semantics at
all for Label2, but we define some).  I understand that 7432 only covers
the L2 case but this document adds mixed L2/L3 (IRB), and furthermore
that the IRB case can be inferred based on the contets of the fields in
the advertisement, *if you know how to look for them*.  But I still
can't shake the feeling that this document should either be added as an
additional reference for EVPN Route Type 2, or listed as Updating 7432,
in order to indicate that we provide more details for the
interpretation and contents of the RT-2 NLRI.

AS> This document doesn’t introduce any new EVPN routes and it doesn’t expand 
the definition of existing routes. With regard to allowing Label1 and Label2 
being use as either MPLS labels or VxLAN VNIs, this document uses the 
precedence set in RFC8365. This document builds on top of RFC 7432 and RFC8365. 
RFC 8365 describes the use of Label1 field in RT-2 as VNI because of VxLAN 
encapsulation. Furthermore, the Lable2 field is not used at all in either RFC 
7432 or RFC 8365 because its only application is for IRB use cases and both 
7432 and 8365 are for pure layer-2 only.

Regards,
Ali

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Ben,

Please see my replies marked with AS>>

On 10/29/20, 5:26 PM, "Benjamin Kaduk"  wrote:

Hi Ali,

Sorry for the delayed response.  Comments inline.

On Thu, Sep 03, 2020 at 06:17:01AM +0000, Ali Sajassi (sajassi) wrote:
> Hi Ben,
> 
> Thanks very much for your review and comments. Please refer to my replies 
inline marked with [AS].
> 
> On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker"  
wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut 
this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> (1) Possibly a "discuss discuss", but ...
> if I'm understanding correctly, the symmetric IRB case over an 
Ethernet
> NVO tunnel (not MPLS or IP NVO) described in this document is
> introducing a new scenario where traffic using router (PE) MAC 
addresses
> as source and destination is comingled on the same tunnel with traffic
> using tenant system MAC addresses as source and destination.  This
> places an obligation on the tunnel endpoints to properly isolate and
> process such "internal" tunnel traffic without hampering the ability 
of
> tenans systems to communicate.  In a world where tenant systems can
> appear at any time, using previously unknown MAC addresses, this
> represents a rather challenging problem: how will the PEs be able to
> pick (and avertise) MAC addresses that they know will not conflict 
with
> any present or future customer systems?  (A similar dilemma led to 
quite
> a delay in the processing of draft-ietf-bfd-vxlan, which in that case
> was resolved by limiting the BFD operation to just the "management 
VNI"
> which is not subject to MAC address conflict with customer systems.)  
In
> this docuement's case, we seem to be using a "well-known"/reserved MAC
> address range from RFC 5798; in principle, this should be enough to
> avoid conflicts, if customer systems are known to not squat on this
> reserved range.  However, this document has some text in Section 4.1
> that indicates that there must be external knowledge that auto-derived
> MAC addresses in the RFC 5798 ranges "[do] not collide with any 
customer
> MAC address".  So I'm left uncertain whether or not this potential
> problem is addressed or not.  (Also, I don't know if the limit on 255
> distinct such MAC addresses presents a scaling issue.)
> 
> [AS] Because the MAC addresses based on RFC 5798 is from a reserved 
range, there should be no conflict with customer MAC addresses that typically 
use their corresponding vendor OUI. If there was a conflict, then we would have 
the same issue with VRRP. However, this document doesn't want to give a blank 
check for auto-derivation of MAC addresses and that's why the statement about 
"... auto- derived MAC does not collide with any customer MAC address".

Okay, thanks for the extra explanation.

AS>> You're welcome!

> Also, is there any risk that the EVPN IRB setup might also want to use
> VRRPv3, and thus collide on the MAC addresses in a different manner?
> 
> [AS] No, because redundancy procedure in EVPN replaces VRRP protocol. 

Should we say something like that in the document ("because EVPN provides a
superset of VRRP functionality, VRRP MUST NOT be used when EVPN is used")?

AS>>  I am afraid that may be confusing to some people because EVPN main mode 
of multi-homing is All-Active which has no relevance in VRRP.

> (1.1) I'm less sure whether there's a similar collision risk for IP
> addresses -- we assign IP addresses to NVEs (e.g., for use as BGP Next
> Hop addresses) and these are used as VTEP addresses when encapsulating
> packets that are going inter-subnet. 

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Erik,

Please see my reply marked w/ AS>>

On 12/9/20, 7:50 PM, "Erik Kline"  wrote:

Ali,

Thanks for your replies.

On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi)  
wrote:
>
> Hi Erik,
>
> Thanks for your comments and sorry to missed them in first place, please 
see my replies in line marked w/ [AS]:
>
> On 7/14/20, 11:22 PM, "Erik Kline via Datatracker"  
wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss
>
>
> --
> DISCUSS:
> --
>
> [ general ]
>
> * Can you give an example of what happens to non-IPv4/IPv6 Ethernet 
packets
>   received at the NVE/PE?  Do they get bridged, and if so how far?  
What
>   happens if a host in BT1 ARPs for IPv4 address associated with a TS 
in
>   a different BT?
>
> [AS] L2 packet (non-ARP/ND packet) gets bridged; however, ARP/ND packets 
from the host for its IP default GW gets terminated at the PE and process by 
it. Section 4.1 describes this in details and it provides an example of it at 
the bottom of the section. Since the PE acts as the IP default GW for the host, 
all packets to other TSes in other subnets gets forwarded to the PE (to its IP 
default GW).
>
> * Where there are multiple prefixes in an IP-VRF, is there a 
constraint that
>   any other IP-VRF that contains one of the prefixes must contain all 
of them?
>   Perhaps that's in 7432...?
>
> [AS] IP and MAC addresses for a given host is advertised with its 
corresponding Route Targets as described at the bottom of section 3, and in 
sections 5.2, 6.2 9.1.1, and 9.2.1. Any PE that has an IP-VRF for that 
tenant/host, imports the IP route into its VRF upon receiving it.
>
> [ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]
>
> * Please document what happens to IPv4 TTL/IPv6 Hop Limit values as 
they
>   cross various NVEs/PEs.
>
> [AS] Added the following to section 4:
> "It should be noted that whenever a PE performs a host IP lookup for a 
packet,
>IPv4 TTL or IPv6 hop limit for that packet is decremented by one and 
if it
>reaches zero, the packet is discarded. In case of symmetric IRB, the 
TTL/hop
>limit is decremented by both ingress and egress PEs (once by each); 
whereas,
>in case of asymmetric IRB, the TTL/hop limit is decremented only once 
by the
>ingress PE."

I don't quite understand what this text should be telling me.  IPv6
Neighbor Solicitations must be sent with a Hop Limit of 255 (4861
S4.3) and "HL==255" is a validation check performed on receipt (4861
S7.1.1).  The same goes for the Neighbor Advertisement replies.

I think your answers above clarifying the mixed routing and bridging
situation (depending on configuration) probably address my original
concern (that NS/NA HLs would not get decremented since they're
bridged; when they're routed they obviously can't be forwarded).  If
that's true, it might be better to undo this particular paragraph
addition, and I apologize for my confusion.

AS>> I modified the 1st sentence to say "... whenever a PE performs a host IP 
lookup for a packet that is routed, ". This way we clarify that the TTL/HL 
decrement is for routed packets and NOT for bridged packets that are forwarded 
w/ TTL/HL intact or NS/NA that get terminated.  


> [AS] I also added similar sentences to sections 5.4, 5.5, 6.3, and 9.1.2, 
and 9.2.2. This addition is not applicable to section 6.4.
>
> [ section 7 ]
>
> * The two statements:
>
>   (1) "Although the language used in this section is for IPv4 ARP,
>   it equally applies to IPv6 ND."
>
>   (2) "If there is [a] many-to-one relationship such that there are 
many host
>   IP addresses correspond[ing] to a single host MAC address ..., 
then to
>   detect host mobility, the procedures in [IRB-EXT-MOBILITY] must 
be
>   exercised..."
>
>   are in direct conflict.  All IPv6 hosts having at least one 
non-link-local
>   unicast address will have more than one IP address per MAC and this 
section,
>   or even this document, would not apply?
>
> [AS] I modified the paragraph to call out non-link-local address for IPv6 
explicitly:
>
> “If there is many-to-one relationship such that there are many hos

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Alvaro,

On 11/9/20, 12:33 PM, "Alvaro Retana"  wrote:

On October 13, 2020 at 2:55:07 AM, Ali Sajassi wrote:

Ali:

Hi!

> Thanks very much for your comments and sorry for the delay, please refer 
to
> my replies marked with [AS].

I looked at the replies and I'm clearing my DISCUSS.

There is one outstanding issue that I trust you to complete before
Martin approves:  The reference to draft-ietf-idr-tunnel-encaps needs
to be Normative.  Ben has this same point listed in his current
DISCUSS [1].

OK, changed it to be Normative.

Thank you for also addressing the questions from John Scudder about
multiple MAC ECs.

You're most welcome!
Cheers,
Ali

Alvaro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Ali Sajassi (sajassi)]

I looked into the IPR, and it has been disclosed and it shows up for the 
individual version of the draft but for some reason not for the WG version of 
it!

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Tuesday, February 2, 2021 at 9:39 AM
To: "slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01

Support the WGLC. I think there is an IPR associated with this draft. I will 
look into and if it is the case, will disclose it ASAP.

Cheers,
Ali

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 18, 2021 at 12:58 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


This email starts a two-week working group last call for 
draft-ietf-bess-evpn-irb-extended-mobility-01 [1]







Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.







This poll runs until February 1st.







We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.


In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].





Thank you,



Matthew & Stephane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!NEt6yMaO-gk!X5h4y9zD3js4IFT_XC9-diCFCY2KETdVMSaYYY3ihMfJkJT9ibnhUx4IgRXhv_vc$>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-ietf-bess-evpn-ipvpn-interworking chair review

[Ali Sajassi (sajassi)]

Hi Stephane,

Jorge, John, DJ, and I met several times over the course of last two weeks to 
address DJ and some of the other outstanding comments and in doing so covering 
the following three cases as well:

  1.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/o a domain-path Attribute
  2.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/ a domain-path Attribute that contains a new SAFI and 
new a domain-id
  3.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/ a domain-path Attribute that contains a new SAFI and 
one of the existing domain-id

Jorge is working hard to incorporate the new changes and by end of the week he 
should have a new rev that address all the comments including yours below.

Cheers,
Ali

From: "Stephane Litkowski (slitkows)" 
Date: Friday, December 11, 2020 at 7:37 AM
To: "draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org" 

Cc: "bess@ietf.org" , "bess-cha...@ietf.org" 

Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: 
Resent-To: , Cisco Employee , 
, , , 
, 
Resent-Date: Friday, December 11, 2020 at 7:35 AM

Hi Authors,


Please find below my chair review related to 
draft-ietf-bess-evpn-ipvpn-interworking.

BTW, you need to refresh the draft now, it has expired.

Section 3:

  *   Nit:
s/uniqueness of the DOMAIN- ID/uniqueness of the DOMAIN-ID/


  *   a) I agree with DJ’s comment on: “This attribute list may contain zero, 
one or more segments". It is actually one or more.
  *   The section 3 contains both normative and non-normative language. If 
section 3 is intended to detail the normative behavior of adding/modifying 
D-PATH, it must use normative for any of the normative procedure. For instance 
b) may require normative language. While it is very good to have an example in 
b), one or more clear normative rules are required before talking about the 
example.
  *   b) talks about domain-ids attached to IP-VRF, this is fine. However, the 
text should provide a wider view so people don’t think that this is the only 
option. Domain-Ids may be assigned at VRF level, but also at more a higher 
level (BGP peer), or even lower level (bgp community…). We should not limit 
implementations here in the granularity domain-ids are defined.
  *   c) I don’t see why “MUST NOT”, it does not hurt to have a DOMAIN-ID 
associated with non ISF world (routes learned from IGP, static)… there could be 
design where people do BGP one leg and non-BGP on the other leg. We should 
probably relax that.

Would you mind adding a beautiful ASCII-ART for the attribute format ? It’s 
usually good to have when reading to see the attribute format rather than 
having to read the text.


You need to define the error handling procedures for D-PATH as per RFC7606 (you 
should have it as normative ref too).


Section 3.1
This sentence is misleading and does not match with the normative behavior of 
Section 3) d)

“In general, any interworking PE that imports an ISF route MUST flag

   the route as "looped" if its D-PATH contains a  
segment, where DOMAIN-ID matches a local DOMAIN-ID

   in the tenant IP-VRF.”

I don’t see the value of this section beyond providing an example. The 
normative behavior is already given in Section 3) d). Can’t the example be 
packed under d).

Also the pointed sentence still refers to a DOMAIN-ID per VRF, which is not 
good for a generic statement. My domain ID info could from the BGP peer config. 
Again, this option of per VRF is fine, but this is not the only one that can be 
implemented.


Section 4.1:
I don’t see why “no-propagation-mode” is the default mode. This is breaking 
existing propagation of attributes from SAFI 1 to SAFI 128. When we have a CE 
running BGP with a PE, the PE propagates the attributes (CTs, ASPATH, MED…) 
coming from the CE.
This section creates some ambiguity about the D-PATH attribute. Based on 
Section 3, D-PATH will be necessarily sent but received D-PATH may be dropped 
and new one created but the text of section 4.1 makes me think that it’s not 
the case in no-propagation mode.
I think setting D-PATH is orthogonal to the attribute propagation.
As section 4.1 tells, people may still want to rely on existing SoO for 
instance in some case in this case D-PATH may not be added.
I think section 3 and 4.1 have to be more clear on the normative procedures 
about D-PATH addition/modification.

Section 4.2:
Isn’t it dangerous to try to define which attributes needs to be propagated, 
and which one should not be ? We are always creating new attributes, should 
people update this doc each time a new attribute comes ? I don’t really see how 
this could be managed.

Isn’t there an indentation issue starting “When propagating an ISD route to a 
different ISF SAFI…” ?

The considerations about ASPATH look really implementation details to me (at 
least the way it is written). Basically the ASPATH propagation 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ali Sajassi (sajassi)]

Support publication of this draft. I am not aware of any undisclosed IPR.

-Ali


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, November 30, 2020 at 12:15
To: "draft-ietf-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] Re: comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Please see my comments marked w/ [AS] below:


Just so that everyone is aware of the history, I introduced the control plane 
signaling concept for L2VPN,
as well as PW status signaling, capability exchange and PW QoS signaling for 
throttling the traffic.

EVPN utilized that idea and applied in EVPN signaling to offer related benefits.

https://tools.ietf.org/html/draft-shah-pwe3-control-protocol-extension-00


[AS] Himanshu, please do not make such unfounded claims as it may undermine 
your credibility. Making such claims is like saying EVPN is based on VPLS (RFC 
4762) because in that RFC, MAC list TLV is defined and can be signaled in 
control plane for a PW ☺
EVPN was designed to address a specific set of requirements listed in RFC 7209 
and you may want to enlighten people in this list on how your above draft 
addresses any of the requirements specified in that RFC (and please elaborate 
for everyone’s sake :-)
Since this is not a technical discussion anymore and Sami wants to address my 
concerns in the next rev of the draft, it is not productive to engage in any 
more discussions and I will wait till the next rev. is published to see how my 
raised issues with the so called “simple solution” are addressed.

-Ali


Control plane learning was used in arp-mediation (RFC 6575) and IPLS (RFC 7436).

(Just a note on the history).

Thanks,
Himanshu

From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Friday, November 20, 2020 at 2:15 AM
To: "Jeffrey (Zhaohui) Zhang" , "Sami com>" 

Cc: "bess@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] comments on 
draft-boutros-bess-elan-services-over-sr

Hi Sami and Jeffrey,

Please see some comments/replies in-line.

Thank you!
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, November 19, 2020 at 7:20 PM
To: Sami Boutros , Rabadan, Jorge (Nokia - US/Mountain 
View) 
Cc: bess@ietf.org 
Subject: RE: [bess] comments on draft-boutros-bess-elan-services-over-sr
To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.



Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,






On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.






@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


1.   While I see the anycast-SID as an interesting point, I disagree with 
the document’s motivation that EVPN needed to introduce control-plane learning 
due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?
[jorge] No, I didn’t make myself clear enough – control plane is needed with 
MP2P tunnels, yes, but what I meant is that in your motivation it *sounds* like 
control-plane learning was a necessary evil due to the need for MP2P tunnels to 
fix the scale issue. I see control-plane learning as an additional 
improvement/feature, as Jeffrey was saying.






1.   Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.







2.   Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.








3.   The document seems to claim fast mac move. How can that be guaranteed 
if the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.
[jorge] you are assuming that when that MAC moves to another port, it sends BUM 
traffic that is flooded and all the nodes can 

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,

Yes, EVPN has evolved over many years and that’s why it has such a big traction 
in industry (thanks to your contributions and many others) and we have always 
been open to improvements (mostly driven by our customers) and evaluated them 
objectively. So, if there is any suggestion wrt to Anycast ID, we can 
definitely evaluate it based on what use cases it covers, All-active mode (both 
equal and unequal LB), failure scenarios, convergence, impact to underlay and 
overlay protocols, as well as applicability to different encapsulations to name 
a few.

Cheers,
Ali

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee , "Jeffrey (Zhaohui) Zhang" 
, Sami Boutros 
Cc: "bess@ietf.org" 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

Hi Ali,

Yes, I understand it has pros and cons. What I meant is that, if using anycast 
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a 
completely new technology that needs to reinvent how to do all services (elan, 
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can 
apply anycast SIDs to existing EVPN.

Thanks.
Jorge

From: Ali Sajassi (sajassi) 
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
Jeffrey (Zhaohui) Zhang , Sami Boutros 

Cc: bess@ietf.org 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [**EXTERNAL**] Re: Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Sami,

If you want to respond, please elaborate so anyone who is following this thread 
can benefit from the exchange; otherwise, it won’t be productive. Please see my 
responses marked w/ [AS].

From: "Boutros, Sami" 
Date: Friday, November 20, 2020 at 10:51 AM
To: Cisco Employee , Sami Boutros , 
"Ali Sajassi (sajassi)" 
Cc: "bess@ietf.org" 
Subject: Re: [**EXTERNAL**] Re: [bess] Issues w/ 
draft-boutros-bess-elan-services-over-sr

Hi Ali,

Please see inline.


Sighhh! The first section of your draft (section 1) and the first two 
paragraphs of that section talks about (1) and (2) that I mentioned in my 
email. Basically, Introduction section states these two reasons as the 
underlying reasons for your draft.

[Sami] In fact, it is not, this is simply an opening statement explaining the 
control plane complexity that we are trying to simplify and is by no mean 
objectives to either reduce # of PWs and # of MAC entries, our proposal is a 
control plane simplification that eliminates need for PWs or EVPN control plane 
distribute any # of mac entries. You know there is a difference between 
reducing control plane overhead and eliminating it!

[AS] This draft is a technical draft and not a marketing white paper, so when 
you talk about a 20 year-old VPLS technology and give example wrt its scale 
issue, then I’d like to know why you are not mentioning PBB-VPLS which 
eliminate the PW scale issue of VPLS. And if you think doing control-plane 
signaling in LDP or BGP for PBB-VPLS is complex, then why not mention you can 
use static PW setup (via a controller). Why these existing solutions are not 
enough to address your concern if you want to use the old-method of data-plane 
learning.

With respect to EVPN, every routes in EVPN has a purpose but if you want to use 
a subset of features and use data-plane learning, then EVPN allows for that. As 
you may know PBB-EVPN uses only a subset of EVPN routes & functions while doing 
data-plane learning. So, if you think EVPN control-plane is complex and do 
data-plane learning, then why not use PBB-EVPN? Can you detail for me what 
aspects of PBB-EVPN is too complex for you?

As I explained in details in my response, we have been there and done that long 
time ago; however, I don’t see any mention of the previous work and RFCs in 
your draft, so maybe you don’t know about them (History is the best teacher one 
can have).

[Sami] I love history and have a library of history books at home! Please list 
drafts and other previous work that talked about eliminating PW signaling and 
we will be more than happy to reference it!

[AS] I mentioned all those RFCs in my first email. And wrt VxLAN RFC, it is 
7348.

Also, you didn’t address any of them issues that I raise and instead. I will 
list them again here and please respond  clearly to each of them:


  1.  If you want to do data-plane learning over SR, why not use PBB-EVPN over 
SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with 
SR, MPLS, TE, etc.
[Sami] Our proposal is not about using complex control plane to setup PWs  or 
EVPN to start with, so why should we use it?

[AS] Again,  if you want to have technical discussions, please elaborate on 
exactly what aspects of PBB-EVPN  control plane is complex given PBB-EVPN uses 
ONLY a subset of EVPN routes and procedures/functions.

  1.  How does your solution take care of VxLAN encoding which is prevalent in 
DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 
10 years ago) is not applicable? Needless to say that both data-plane and 
control-plane solutions for VxLAN was introduced at the same time about 10 
years ago and industry decided in favor of control-plane!!
[Sami] We are not saying by any mean don’t use EVPN. And we do respect the 
industry and service providers choice, so can we leave it to service providers 
and industry to decide their choice of technology or control plane!

[AS] But that wasn’t my question. What I am saying is we have seen this play 
ten years ago and how is your proposal handle VxLAN encap and how it is 
different from RFC7348.

  1.  How do you want to address IRB in your proposal? Will IRB be never be 
used in your proposal?
[Sami] We will address IRB in the next rev of the draft, as we see our proposal 
will provide great benefits to Data Center customers specially when using SRv6.

[AS] Nice marketing ☺ but can you give us a technical explanation now in one 
paragraph?

  1.  How do you want to address unequal LB for All-Active MH?
[Sami] In fact, how to achieve unequal LB with our solution was clearly 
explained on the slides I presented

[AS] Sami, referring me to a slide-page that doesn’t explain it and saying “it 
was clearly explained” is not productive. The one to last slide only says:
“Packets destined to the MH CE connected to node 5 and node 6 can be 
load-balanced (ECMP/UCMP) across the core given that the MAC addressed were 
lea

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Sami,

Sighhh! The first section of your draft (section 1) and the first two 
paragraphs of that section talks about (1) and (2) that I mentioned in my 
email. Basically, Introduction section states these two reasons as the 
underlying reasons for your draft. As I explained in details in my response, we 
have been there and done that long time ago; however, I don’t see any mention 
of the previous work and RFCs in your draft, so maybe you don’t know about them 
(History is the best teacher one can have).

Also, you didn’t address any of them issues that I raise and instead. I will 
list them again here and please respond  clearly to each of them:


  1.  If you want to do data-plane learning over SR, why not use PBB-EVPN over 
SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with 
SR, MPLS, TE, etc.
  2.  How does your solution take care of VxLAN encoding which is prevalent in 
DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 
10 years ago) is not applicable? Needless to say that both data-plane and 
control-plane solutions for VxLAN was introduced at the same time about 10 
years ago and industry decided in favor of control-plane!!
  3.  How do you want to address IRB in your proposal? Will IRB be never be 
used in your proposal?
  4.  How do you want to address unequal LB for All-Active MH?
  5.  How do you want to address host mobility where a MAC is associated with 
multiple IP address?

Now, with respect to your two claims:

  1.  Simplification: A solution can be simplified if it doesn’t need to 
address much of anything ☺ I.e., if it doesn’t need to address IRB, to address 
unequal LB, to address multiple IP address for a MAC, to address optimum mcast 
for L2 simultaneously (IRB), etc.
  2.  Anycast SID: the notion of anycast SID and anycast IP address for 
All-Active multi-homing is not new and again has been done for ages. Cisco 
proprietary solution for All-Active multi-homing (called VPC) before EVPN was 
based on anycast IP address. However, there are drawback for it – one of which 
is underlay topology decides LB instead of the actual link BW of MCLAG!!
Cheers,
Ali

From: Sami Boutros 
Date: Thursday, November 19, 2020 at 6:32 PM
To: "Ali Sajassi (sajassi)" 
Cc: "bess@ietf.org" , Cisco Employee , Sami 
Boutros 
Subject: Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

Hi Ali,

The draft doesn’t state neither 1 or 2 below. I’m not sure if we are looking at 
the same draft.

Here is the text in the draft introduction


   The goal of the proposed approach is to greatly simplify control

   plane functions and minimize the amount of control plane messages PE

   nodes have to process.  In this version of the document, we assume

   Segment Routing (SR) underlay network.  A future version of this

   document will generalize the underlay network to both classical MPLS

   and SR technologies.



   The proposed approach does not require PW, and hence the control

   plane complexity and message overhead associated with signaling and

   maintaining PWs are eliminated.

Our goal is to simplify:

1- The control plane by signaling very few messages possibly 1 message per node 
to signal all ELAN services configured on that node, presenting each ELAN 
service as 1 bit in the control plane message.

2- The data plane by setting up much less control plane elements like PWs, 
tunnels etc., and more importantly leveraging SR redundancy mechanisms of any 
cast SID to remove the need of any overlay convergence or redundancy mechanisms.

Not sure if any the stuff u listed below can address any of the above!

Thanks,

Sami


On Nov 19, 2020, at 12:21 PM, Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>> 
wrote:

Sami,

Since we didn’t have time to discuss the issues during the BESS meeting, let me 
explain and elaborate them here:

The draft states the following two main objectives for its purpose but both 
have been addressed already !!


  1.  Reducing # of PWs in VPLS:

 *   VPLS (both BGP and LDP) is a 20-year old technology which is getting 
deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, 
a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 
and 7080) to address the PW scale issues along with few other things.

  1.  Reducing # of EVPN MAC route advertisements:

 *   This may have been an issue 10 years ago and that’s why we introduced 
simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses 
data-plane learning and it uses concepts of service-id, source B-MAC (for MAC 
learning) and destination B-MAC (for BUM ID), and same concepts are used in 
your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as 
Single-Active with all the improvements that came later including per-ISID 
c-mac flushing that Jorge presented during the call. Needless to say that 
PBB-EVPN is transport agn

[bess] Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Sami,

Since we didn’t have time to discuss the issues during the BESS meeting, let me 
explain and elaborate them here:

The draft states the following two main objectives for its purpose but both 
have been addressed already !!


  1.  Reducing # of PWs in VPLS:
 *   VPLS (both BGP and LDP) is a 20-year old technology which is getting 
deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, 
a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 
and 7080) to address the PW scale issues along with few other things.
  2.  Reducing # of EVPN MAC route advertisements:
 *   This may have been an issue 10 years ago and that’s why we introduced 
simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses 
data-plane learning and it uses concepts of service-id, source B-MAC (for MAC 
learning) and destination B-MAC (for BUM ID), and same concepts are used in 
your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as 
Single-Active with all the improvements that came later including per-ISID 
c-mac flushing that Jorge presented during the call. Needless to say that 
PBB-EVPN is transport agnostic and can work with SR, MPLS, TE, etc.

So,  my question is that: what is the point of this draft? Are you trying to 
have a bit more compressed header over what we currently have in PBB-EVPN 
because in terms of functionality, I don’t see much difference. However, I see 
even more issues than PBB-EVPN such as IRB handling  and Unequal load-balancing 
 for an ES.

The idea of breaking a PW in to three components of service-id, source-id, and 
dest-id has been around for almost twenty years. I introduced mvpls draft in 
2002, followed by PBB-VPLS. VxLAN RFC (which also talks about data-plane 
learning) is along the same idea introduced in 2010. And finally PBB-EVPN in 
2012. So, why do we need to re-invent the wheel again?

-Ali
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Roman,

Thanks for your comments. Please see my replies inline marked with [AS]:

On 7/15/20, 6:45 PM, "BESS on behalf of Roman Danyliw via Datatracker" 
 wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

I support the DISCUSS ballot position of Erik Kline

I support the DISCUSS ballot position of Alvaro Retana

I support the DISCUSS ballot position of Ben Kaduk

Not much to add to the feedback of my peer ADs.

** Please respond to the SECDIR feedback (and thank you Chris Lonvick for 
doing
it!)

** Section 11.  As there is nothing documented to prevent this approach from
being used across administrative domains with different policies (i.e., 
there
is no applicability statement or normative language providing caution from
being used outside of the commonly reference data center use case) or any
security assumptions made about the elements involved, please reiterate that
there are no inherent security services being provided to protect the 
traffic. 
If this is desired it should provide through other means.

[AS] I added a paragraph to section 11 per another feedback to address this. It 
is reflected in rev10. 

Cheers,
Ali

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Alvaro,

Thanks very much for your comments and sorry for the delay, please refer to my 
replies marked with [AS].

On 7/14/20, 10:51 AM, "Alvaro Retana via Datatracker"  wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
DISCUSS:
--

I'm balloting DISCUSS because the specification in §9.1.1 is not clear, and 
it
is not in sync with draft-ietf-idr-tunnel-encaps.  [Some of the points below
are not DISCUSS-worthy, but I'm including them here because they are 
related to
the larger point.]

§9.1.1 talks about using the Encapsulation Extended Community *and* the
Router's MAC Extended Community.  However, the requirement for these
communities to appear together is not explicit anywhere.  What are the
implications for only one of them being present?

[AS] These two ECs are intended for two different purposes - one is to indicate 
tunnel type and the other to indicate PE's MAC address when doing Ethernet NVO 
tunnel. These two ECs don't need to appear together all the time - only for a 
specific use case which is described in section 9.1.1.

The Router's MAC Extended Community "is only required when Ethernet NVO 
tunnel
type is used".  It seems to me that normatively requiring the extended
community is important in this case.

[AS] Changed the sentence to "The Router's MAC Extended 
   community MUST be added when Ethernet NVO tunnel is used."

What exactly is the "Ethernet NVO tunnel type"?  §1 (Terminology) says that
"Examples of this type of tunnels are VXLAN or GENEVE."  A standards track
document should be specific about when something is required.  For example, 
I
assume that it would also be required when using NVGRE.  The tunnel types 
are a
finite number, so please be specific.

[AS] I changed it as follow:
"Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels
   with Ethernet payload as specified for VxLAN in 
   and for NVGRE in .


Where is the GENEVE tunnel type (to be used in the Encapsulation Extended
Community) defined?  BTW, the [GENEVE] reference is also missing.

[AS] I removed GENEVE since it was just an example and I am not aware of any 
implementation that uses GENEVE tunnel type since it is not defined. 

§4 has this text: "the tunnel connecting these IP-VRFs can be either IP-only
tunnel (in case of MPLS or GENEVE encapsulation) or Ethernet NVO tunnel (in
case of VxLAN encapsulation)."  It confuses me because of the apparent
contradiction between GENEVE being an example of an Ethernet NVO tunnel 
type,
but also (?) an IP-only tunnel in this case.

[AS] Yes, GENEVE can do both tunnel types; whereas, VxLAN can only do Ethernet 
NVO. GPE which is evolution of VxLAN, can also do both. I changed the example 
from GENEVE to GPE because GPE tunnel type is defined but not GENEVE: 
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types.


§4.2/draft-ietf-idr-tunnel-encaps mentions possible conflicts created by the
Router's MAC Extended Community and how it may be ignored, but this document
doesn't mention using the Encapsulation Sub-TLVs (also from
draft-ietf-idr-tunnel-encaps) for the same function.  Can the same function 
be
achieved with the Encapsulation Sub-TLVs?

[AS] All the info that is needed is already in the EVPN route itself and that 
is why there is no need to use Encapsulation Sub-TLVs. The tunnel-encap draft 
does a good job to explain when the tunnel-type EC is sufficient and when not 
to send the attribute itself. We coordinated that with Eric Rosen and it looked 
good the last time I checked. 

"section 4.5 of [TUNNEL-ENCAP]" is mentioned a couple of times, but there 
is no
§4.5 in draft-ietf-idr-tunnel-encaps, and there's no reference either.  
Please
remove the specific section number (to avoid becoming out of sync), and 
instead
mention the Encapsulation Extended Community by name.  Add a Normative
reference to draft-ietf-idr-tunnel-encaps.

[AS] Sounds good. I took care of it. BTW, there is already an informative 
reference.


--
COMMENT:

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Erik,

Thanks for your comments and sorry to missed them in first place, please see my 
replies in line marked w/ [AS]:

On 7/14/20, 11:22 PM, "Erik Kline via Datatracker"  wrote:

Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss


--
DISCUSS:
--

[ general ]

* Can you give an example of what happens to non-IPv4/IPv6 Ethernet packets
  received at the NVE/PE?  Do they get bridged, and if so how far?  What
  happens if a host in BT1 ARPs for IPv4 address associated with a TS in
  a different BT?

[AS] L2 packet (non-ARP/ND packet) gets bridged; however, ARP/ND packets from 
the host for its IP default GW gets terminated at the PE and process by it. 
Section 4.1 describes this in details and it provides an example of it at the 
bottom of the section. Since the PE acts as the IP default GW for the host, all 
packets to other TSes in other subnets gets forwarded to the PE (to its IP 
default GW).

* Where there are multiple prefixes in an IP-VRF, is there a constraint that
  any other IP-VRF that contains one of the prefixes must contain all of 
them?
  Perhaps that's in 7432...?

[AS] IP and MAC addresses for a given host is advertised with its corresponding 
Route Targets as described at the bottom of section 3, and in sections 5.2, 6.2 
9.1.1, and 9.2.1. Any PE that has an IP-VRF for that tenant/host, imports the 
IP route into its VRF upon receiving it.  

[ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]

* Please document what happens to IPv4 TTL/IPv6 Hop Limit values as they
  cross various NVEs/PEs.

[AS] Added the following to section 4:
"It should be noted that whenever a PE performs a host IP lookup for a packet,  
   IPv4 TTL or IPv6 hop limit for that packet is decremented by one and if it 
   reaches zero, the packet is discarded. In case of symmetric IRB, the TTL/hop
   limit is decremented by both ingress and egress PEs (once by each); whereas,
   in case of asymmetric IRB, the TTL/hop limit is decremented only once by the
   ingress PE."

[AS] I also added similar sentences to sections 5.4, 5.5, 6.3, and 9.1.2, and 
9.2.2. This addition is not applicable to section 6.4.

[ section 7 ]

* Is there a reference for IRB-EXT-MOBILITY?

[AS] Yes, there were couple of other comments on this and I have fixed that 
already. 

* The two statements:

  (1) "Although the language used in this section is for IPv4 ARP,
  it equally applies to IPv6 ND."

  (2) "If there is [a] many-to-one relationship such that there are many 
host
  IP addresses correspond[ing] to a single host MAC address ..., then to
  detect host mobility, the procedures in [IRB-EXT-MOBILITY] must be
  exercised..."

  are in direct conflict.  All IPv6 hosts having at least one non-link-local
  unicast address will have more than one IP address per MAC and this 
section,
  or even this document, would not apply?

[AS] I modified the paragraph to call out non-link-local address for IPv6 
explicitly: 

“If there is many-to-one relationship such that there are many host IP 
   addresses (non-link-local unicast addresses for IPv6)
   corresponding to a single host MAC address or there are many host MAC 
addresses 
   corresponding to a single IP address (non-link-local unicast address for 
IPv6), 
   then to detect host mobility, the procedures in
   
   must be exercised followed by the procedures described below.”


--
COMMENT:
--

[ general ]

* I believe this is true, but can you just state here (not in the doc) that
  there are no multi-link subnets that can be created with this model as
  defined in RFC 4903? It seems like everything is as it should be, but just
  to double-check.

[AS] I don’t see an multi-link subnet issue here. 

[ section 1 ]

* IP-VRF definition: s/VPN Routing.../Virtual Routing/?

[AS] Done.

[ section 3 ]

* 2nd to last paragraph: Is any of this still true for a setup that
  involves multiple IPv6 prefixes per BD, maybe I misunderstood
  (or maybe this assumed single prefix per broadcast domain w/ IPv4-only?).

  Perhaps avoid suggesting there's a 1:1 relationship and use phrases
  likes "at least as many X as there are Y" or something?

[AS] The paragraph says "typically", so it doesn't mandate 1:1 relationship.  

[ section 4 ]

* ARP table: a less IPv4-specific name, even though it's define to hold both
  IPv4 and IPv6 associations, would be "neighbor table".  That might be
  overloaded in routing contexts so no need to change it.

[AS] There was another comments 

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Ali Sajassi (sajassi)]

Hi John,

Thanks for your feedback. I was also thinking along the line of (2). I’ll take 
care of it in the next rev. soon.

Cheers,
Ali


From: John Scudder 
Date: Thursday, October 8, 2020 at 11:57 AM
To: Cisco Employee 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:57 AM

Thanks, Ali.

Yes, I think this should be explicit in the spec. I’d also suggest being 
explicit about what “ignore the rest” means. It could mean one of two things —

1. Don’t pay attention to the extra ones for purposes of computing the local 
forwarding table, but store them and propagate them.
2. Also don’t store or propagate them.

I’m guessing option 2 is better in this case. The problem with propagating them 
is sometimes implementations reorder things, so you could end up with 
inconsistency in the network.

—John


On Oct 8, 2020, at 2:42 PM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:



Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, October 8, 2020 at 11:12 AM
To: 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:stho...@cisco.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John



Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC Extended Communities (with different 
values) anyway, for example due to a bug or configuration error? This is a very 
real possibility since many BGP implementations allow policy to produce 
arbitrary communities.

Thanks,

—John

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Ali Sajassi (sajassi)]

Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder 
Date: Thursday, October 8, 2020 at 11:12 AM
To: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 

Cc: BESS 
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John


Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC Extended Communities (with different 
values) anyway, for example due to a bug or configuration error? This is a very 
real possibility since many BGP implementations allow policy to produce 
arbitrary communities.

Thanks,

—John

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-nr-bess-evpn-mh-split-horizon-03

[Ali Sajassi (sajassi)]

As a co-author, I support WG adoption of this draft and I am not aware of any 
relevant IPR.

Regards,
Ali

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, September 9, 2020 at 3:43 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-nr-bess-evpn-mh-split-horizon-03

Hello,

This email begins a two-weeks WG adoption poll for 
draft-nr-bess-evpn-mh-split-horizon-03 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 23rd September 2020.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-nr-bess-evpn-mh-split-horizon/



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Eric,

I add the following sentences in section 2 to provide further clarification to 
your point:
" It should be
   noted that if an IP-VRF in a NVE is configured for IPv6 and that NVE
   receives IPv4 traffic on the corresponding VLAN, then the IPv4
   traffic is treated as L2 traffic and it is bridged.  Also vise versa,
   if an IP-VRF in a NVE is configured for IPv4 and that NVE receives
   IPv6 traffic on the corresponding VLAN, then the IPv6 traffic is
   treated as L2 traffic and it is bridged." 

Cheers,
Ali

On 9/1/20, 1:46 AM, "Eric Vyncke (evyncke)"  wrote:

Thank you Ali for your reply.

My comments are non-blocking anyway but I am still not too happy with your 
reply to
- section 2, I still find the text not really clear
- unsure whether I understand the reasoning on section 4.1

Else, happy with all your changes => they will improve the document

Regards

-éric

-Original Message-
    From: "Ali Sajassi (sajassi)" 
Date: Tuesday, 1 September 2020 at 00:25
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Zhaohui Zhang 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

Hi Eric,

Thanks for your review and your comments, please refer to my replies 
inline marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  
wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to 
all
email addresses included in the To and CC lines. (Feel free to cut 
this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/




--
COMMENT:

--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would 
appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many 
acronyms even for
short words (e.g., "SN" instead of "Subnet"). There are also very 
long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route 
inter-subnet IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, 
then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be 
clear enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the 
one used in
the initial ARP reply or ND Neighbor Advertisement (NA) for that 
TS." by "then
the IRB interface MAC address MUST be the one used in the initial 
ARP reply or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for 
that TS"
because routers MAC addresses are also advertised by Router 
Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP 
reply can be used 
In RA because it is a multicast packet - i.e., the MAC address of old 
IRB interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the 
first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds 
this TS's MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the 
Length field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is 
carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please 

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

[Ali Sajassi (sajassi)]

Hi Ben,

Thanks very much for your review and comments. Please refer to my replies 
inline marked with [AS].

On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
DISCUSS:
--

(1) Possibly a "discuss discuss", but ...
if I'm understanding correctly, the symmetric IRB case over an Ethernet
NVO tunnel (not MPLS or IP NVO) described in this document is
introducing a new scenario where traffic using router (PE) MAC addresses
as source and destination is comingled on the same tunnel with traffic
using tenant system MAC addresses as source and destination.  This
places an obligation on the tunnel endpoints to properly isolate and
process such "internal" tunnel traffic without hampering the ability of
tenans systems to communicate.  In a world where tenant systems can
appear at any time, using previously unknown MAC addresses, this
represents a rather challenging problem: how will the PEs be able to
pick (and avertise) MAC addresses that they know will not conflict with
any present or future customer systems?  (A similar dilemma led to quite
a delay in the processing of draft-ietf-bfd-vxlan, which in that case
was resolved by limiting the BFD operation to just the "management VNI"
which is not subject to MAC address conflict with customer systems.)  In
this docuement's case, we seem to be using a "well-known"/reserved MAC
address range from RFC 5798; in principle, this should be enough to
avoid conflicts, if customer systems are known to not squat on this
reserved range.  However, this document has some text in Section 4.1
that indicates that there must be external knowledge that auto-derived
MAC addresses in the RFC 5798 ranges "[do] not collide with any customer
MAC address".  So I'm left uncertain whether or not this potential
problem is addressed or not.  (Also, I don't know if the limit on 255
distinct such MAC addresses presents a scaling issue.)

[AS] Because the MAC addresses based on RFC 5798 is from a reserved range, 
there should be no conflict with customer MAC addresses that typically use 
their corresponding vendor OUI. If there was a conflict, then we would have the 
same issue with VRRP. However, this document doesn't want to give a blank check 
for auto-derivation of MAC addresses and that's why the statement about "... 
auto- derived MAC does not collide with any customer MAC address".

Also, is there any risk that the EVPN IRB setup might also want to use
VRRPv3, and thus collide on the MAC addresses in a different manner?

[AS] No, because redundancy procedure in EVPN replaces VRRP protocol. 

(1.1) I'm less sure whether there's a similar collision risk for IP
addresses -- we assign IP addresses to NVEs (e.g., for use as BGP Next
Hop addresses) and these are used as VTEP addresses when encapsulating
packets that are going inter-subnet.  I think that at this point in the
packet processing we may already know that we're in the the "IRB tunnel"
scope and that may be enough to de-conflict any potential IP address
collision between NVE and customer addresses.

[AS] customer IP addresses are from overlay-space; whereas, NVE addresses are 
from underlay space. Each customer has its own overlay address space that can 
overlap with other customers or underlay space but that doesn't cause an issue 
because they are kept in their own set of VRFs (its own set of routing tables). 
 

(2) Section 7 appears to reference (in a normative fashion)
[IRB-EXT-MOBILITY] but there is no such reference.

[AS] It is fixed now.

Similarly (as Murray notes), there are a couple apparent references to
[TUNNEL-ENCAP] that are also arguably normative, but the target of the
reference is not forthcoming (and the IANA registry does not show a "BGP
Encapsulation Extended Community" that is supposedly defined by
[TUNNEL-ENCAP]).

[AS]. "Encapsulation Extended Community" is in IANA registry: 
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml.
 


There is also not a listed reference for [EVPN-PREFIX], though one could
perhaps surmise that it is 

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Eric,

Thanks for your review and your comments, please refer to my replies inline 
marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would appreciate 
a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many acronyms even 
for
short words (e.g., "SN" instead of "Subnet"). There are also very long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route inter-subnet 
IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be clear 
enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the one used 
in
the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by 
"then
the IRB interface MAC address MUST be the one used in the initial ARP reply 
or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS"
because routers MAC addresses are also advertised by Router Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP reply can 
be used 
In RA because it is a multicast packet - i.e., the MAC address of old IRB 
interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's 
MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the Length 
field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please add IPv6 NDP cache.

[AS] Done.

-- Section 6.1 --
Same comments as for section 5.1

AS] Done.

-- Section 6.2 --
Same comments as for section 5.2

[AS] Done.

-- Section 7 --
Good to state "Although the language used in this section is for IPv4 ARP, 
it
equally applies to IPv6 ND."; even if I would have preferred to use by 
default
IPv6 ND ;-)

[AS] yes, the quoted sentence already exist. 

Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC
(one link-local fe80::... and one global); so, "In the following 
subsections,
it is assumed that the MAC and IP addresses of a TS have one-to-one
relationship (i.e., there is one IP address per MAC address and vice 
versa). "
is obviously never the case for IPv6. I understand that the rest of the
paragraph explains how to handle the case but it could be easier to treat 
IPv6
in a separate sentence.

-- Section 7.1 --
While about mobility, this section appears to be also applicable to 
Duplicate
Address Detection but is unclear on what to do when the same IP but 
different
MAC (i.e., an actual IP address collision). Or is it covered in other 
documents?

[AS] duplicate MACs are covered in RFC 7432.

== NITS ==

-- Section 1 --
"BD and subnet are equivalent terms" while in the rest of the document "IP
subnet" is often used. If "subnet IP" and "subnet" are synonyms, then I 
suggest
to keep using one for consistency or at least mention that "IP subnet" and
"subnet" are the same concept (or explain the difference if they are not
identical).

[AS] Added clarification that "subnet" means "IP subnet".




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

[Ali Sajassi (sajassi)]

Sue,

I am afraid if we don’t clean up the draft, it can cause confusion as it has 
already and result in immediate errata filing for it after publication. A 
sub-bullet got added to the latest rev (rev17) that is not correct. It says 
that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However, 
EVPN never uses this sub-tlv as its routes has all the needed info. 
Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation 
Extended Community (per section 4.1). As I said, I am not aware of any of the 
vendors using these sub-TVLs and it is easy to have a quick poll.

Regarding the paragraph that got omitted, it is making it much more ambiguous 
than it used to. I would opt for clarifying the paragraph rather than removing 
it. If needed I can provide an updated paragraph. Section 9 of RFC 8365 
specifies how a VPN multicast route can be advertised with PMSI tunnel 
attribute and Encapsulation extended community and has been implemented by many 
vendors.

Cheers,
Ali


From: Susan Hares 
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee , "bess@ietf.org" , 
"i...@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali:

It is wise to start with the RFC6514 and the 
draft-ietf-idr-tunnel-encapsulation draft.

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC – so it is 
inappropriate to call for the request to remove these sections.  The WG LC that 
is currently running is whether to remove the “AS” field from the tunnel 
endpoint field, and replace it with a reserved field.

The implementation page is on:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations

If you wish to provide information on the cisco implementation, you are welcome 
to add information on the page.
I can call for an update to the page from vendors.

[WG chair hat off[
[Document shepherd hat on]

The issue is during the edits the text from RFC6514 from Eric Rosen was 
unclear.  The text was:



   It has been suggested that it may sometimes be useful to attach a
   Tunnel Encapsulation attribute to a BGP UPDATE message that is also
   carrying a PMSI (Provider Multicast Service Interface) Tunnel
   attribute [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>].  If the 
PMSI Tunnel attribute specifies an IP
   tunnel, the Tunnel Encapsulation attribute could be used to provide
   additional information about the IP tunnel.  The usage of the Tunnel
   Encapsulation attribute in combination with the PMSI Tunnel attribute
   is outside the scope of this document.

Since the text itself was unclear what additional information could be 
provided, the authors removed it from the draft.

As we had not received any feedback about active RFC6514 interactions on the 
list.

[document shepherd off]

If you have an implementation of the interaction between the RF6514 and tunnel 
encapsulation, it would be valuable to provide:

a)  either a draft specifying the interaction you wish to IDR WG, or
b)  comments that could replace the original the original text.

Since the IDR draft has gone through multiple WG LC and a very complete review 
from Alvaro – so a quick response would be appreciated.   IMHO a draft on the 
interaction between RFC6514 and the tunnel-encapsulation draft – would be the 
best thing at this point.  Let me know if you are interested in working on such 
a draft.

Sue


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Friday, July 31, 2020 1:54 AM
To: Susan Hares; bess@ietf.org; i...@ietf.org
Cc: 'Hu, Jun (Nokia - US/Mountain View)'
Subject: Re: IPSec Tunnels and draft-sajassi-bess-secure-evpn



Sue,

Before getting to the discussions of the three IPsec proposals, there are some 
elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have 
caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in 
sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has 
implemented these sub-tlvs because the info in these sub-tlv already exist in 
EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have 
implemented it. Therefore, all the vendors that I am aware of use Extended 
Community  defined in section 4.1  along with EVPN routes to signal VxLAN and 
GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! 
So, as the first step, we should remove these three sections from the draft if 
there is no objection.

Cheers,
Ali

From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee , "bess@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact 
draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been 
discu

[bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

[Ali Sajassi (sajassi)]

John, Jeff:

During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS WG 
meeting, you had a question/concern regarding why we are defining a new EC if 
we are doing conditional transitive. First, I’d like to make a correction to 
the preso by saying that the transitivity is not conditional and we will 
correct this in the next rev of the draft. So, the EC is simply transitive at 
all time. Given the EC defined in draft-ietf-idr-link-bandwidth-07.txt is 
non-transitive, we cannot use this EC for our application. That’s why we are 
defining a new one.

Cheers,
Ali

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

[Ali Sajassi (sajassi)]

Sue,

Before getting to the discussions of the three IPsec proposals, there are some 
elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have 
caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in 
sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has 
implemented these sub-tlvs because the info in these sub-tlv already exist in 
EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have 
implemented it. Therefore, all the vendors that I am aware of use Extended 
Community  defined in section 4.1  along with EVPN routes to signal VxLAN and 
GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! 
So, as the first step, we should remove these three sections from the draft if 
there is no objection.

Cheers,
Ali

From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee , "bess@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact 
draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been 
discussing these three drafts (Ali and two other authors sets) to try to find 
out if we can have one general solutions.

The discussion has been very fruitful to point up BGP issues of 
interoperability, security, privacy, manageability, and scaling.  For example, 
there is a lack of a clear specification between RFC6514 (PMSI tunnel 
attribute) and the tunnel-encaps draft that specifies how these drafts 
interoperate.  I suspect the bess and idr chairs will need to discuss if 
tunnel-encaps has to address this point.

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the authors 
could tell me what I misunderstood.   You’ll find this draft stops half way.  I 
have the rest of the draft written, but I wanted feedback from all the author 
teams before sending it out.

After hearing some of the details from the authors, I would like to sponsor an 
IDR interim so we could discuss these issues at length.   If you think this is 
a good idea, please let me know.

One other thing… unfortunately, I scheduled a set of meetings for EDT time 
after IETF meetings this week.   Your next response will occur from 11-16 UTC 
on Wednesday.

Cheerily, Sue


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

[Ali Sajassi (sajassi)]

Sue,


From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:11 AM
To: Cisco Employee , "bess@ietf.org" 
Subject: RE: [bess] Why are you specifying two new tunnel types for 
encapsulation for EVPN?

Ali:

Three major high points from the discussion:

1) tunnel-encap and RFC6512 lack a clearly defined interoperability statement
If you are using RFC6512 PMSI tunnel attribute and Tunnel-encap attribute, 
this issue needs to be sorted out.

AS>  Secure-evpn draft doesn’t use RFC6512 PMSI tunnel attribute. It only uses 
Tunnel-encap. I was just providing an example wrt underlay tunnel type vs. 
overlay encap.


2)  If your draft depends on draft-carrell-ipsecme-controller-ike-00.txt,
 then the review at IETF 105 by security experts had concerns which have 
not been resolved.
(Also draft-carrell-ipsecme-controller-ike-01.txt has expired and there is not 
a replacement.)

AS> Secure-evpn relies on rekeying from 
draft-carrell-ipsecme-controller-ike-00.txt. If there is a better proposal for 
rekeying, then I am all ears. We’ll take care of the expired status of that 
draft shortly.

If your draft depends on general features of rekeying, nonces, security 
association databases, and security policy data bases, then I suggest revising 
the draft to point to existing features.

AS> secure-evpn draft does reference to carrell controller-ike draft regarding 
those features (e.g., section 4.4 for rekeying, section, 4.5 for ipsec 
databases).

3) [IDR-Shepherd-hat on]  A general solution for IPsec security association 
passing is wise

AS> That’s what is described here – i.e., a general solution that applies to 
EVPN and other type of VPNs because it uses an attribute that can be passed 
with any NLRI.

All of this points toward the creation of a general IPSEC functionality in BGP 
rather than EVPN specific work.If it is true, then we ought to create one 
solution in IDR for the 3 scenarios.

AS> As I said before, the solution applies to EVPN as well as other VPN types. 
That’s why I have a section that explain how other VPN solution can be 
beneficiary of the same solution. BTW, because we are talking about signaling 
for BGP Enable Services, this draft and any other related drafts in this area 
belong to BESS. Of course, IDR will be involved as always.

Cheers,
Ali

See my comments as Sue2>.  I use the following abbreviations


tunnel-encaps -  draft-ietf-idr-tunnel-encaps-17.txt
sajassi-s-evpn – draft-sajasssi-bess-secure-evpn-03.txt
RFC6514 – PMSI Tunnel Attribute (PMSI)

Cheerily, Sue

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Tuesday, July 28, 2020 9:45 AM
To: Susan Hares; bess@ietf.org
Subject: Re: [bess] Why are you specifying two new tunnel types for 
encapsulation for EVPN?

Sue,

Please see my responses below marked with AS>

From: BESS  on behalf of Susan Hares 
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "bess@ietf.org" 
Subject: [bess] Why are you specifying two new tunnel types for encapsulation 
for EVPN?

Ali:
From draft-sajassi-bess-secure-evpn:
6<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-6> BGP 
Encoding

This document defines two new Tunnel Types along with its associated

   sub-TLVs for The Tunnel Encapsulation Attribute 
[TUNNEL-ENCAP<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP>].
 These

   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as

   described in section 
4<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-4>. The 
following sub-TLVs apply to both tunnel

   types unless stated otherwise.


1.  Why are you specifying 2 new tunnel types?  What makes these special?

What in the use of the tunnel encapsulation draft does not support for the 
inner and outer tunnel requires you to specify a ESP-Transport and  
ESP-in-UDP-Transport?

AS> We need to differentiate between underlay tunnel and overlay encap. For 
example, in PMSI tunnel attribute, tunnel type can be PIM-SM or PIM-SSM; 
whereas, overlay encap can be VxLAN, NVGRE, GENVE, etc. So, similarly here, the 
underlay tunnel can be ESP-Transport or ESP-in-UDP-Transport and the overlay 
can be any of the overlay encap. If you think the existing tunnel-encap can 
address both underlay and overlay, please indicate how.

Sue2> One of my main concerns is the interoperability between tunnel-encaps and 
extensions to RFC6514.

AS>> No interop is needed as explained above.

tunnel-encaps  provides both outer encapsulation [see section 3.3] and inner 
encapsulation [see section 3.2].  The only overlay thing in sajassi-s-evpn 
which tunnel-encaps  which cannot be supported is GENVE.

Reviewers of tunnel-encaps have requested why GENVE was not included.  IDR 
requires 2 implementation of the code.  If sajassi-s-evpn has an implementation 
with GENVE, then tunnel-encaps should include it in the base tunnel-encaps 
draft.

I do not see a PIM-SM o

Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

[Ali Sajassi (sajassi)]

Sue,

Please see my responses below marked with AS>

From: BESS  on behalf of Susan Hares 
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "bess@ietf.org" 
Subject: [bess] Why are you specifying two new tunnel types for encapsulation 
for EVPN?

Ali:
From draft-sajassi-bess-secure-evpn:
6 BGP 
Encoding

This document defines two new Tunnel Types along with its associated

   sub-TLVs for The Tunnel Encapsulation Attribute 
[TUNNEL-ENCAP].
 These

   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as

   described in section 
4. The 
following sub-TLVs apply to both tunnel

   types unless stated otherwise.


1.  Why are you specifying 2 new tunnel types?  What makes these special?

What in the use of the tunnel encapsulation draft
does not support for the inner and outer tunnel requires
you to specify a ESP-Transport and  ESP-in-UDP-Transport?

AS> We need to differentiate between underlay tunnel and overlay encap. For 
example, in PMSI tunnel attribute, tunnel type can be PIM-SM or PIM-SSM; 
whereas, overlay encap can be VxLAN, NVGRE, GENVE, etc. So, similarly here, the 
underlay tunnel can be ESP-Transport or ESP-in-UDP-Transport and the overlay 
can be any of the overlay encap. If you think the existing tunnel-encap can 
address both underlay and overlay, please indicate how.

[see section 5.1 of your draft]

2.  What IPSEC security information is unique to the EVPN solution that is not 
general?

AS> They are general and not specific to EVPN.

Section 4 of  draft-sajassi-bess-secure-evpn-03.txt
describes the IPSEC DIM and security policies on in the following case:

a) you need to send IPSEC information – via RR mesh
b) you have policies that you want to use  the 
[draft-carrell-ipsecme-controller-ike-00.txt]
c) you want on demand re-keying
d) “policy” – undefined
on #a) there are multiple BGP IPsec proposal using the RR mesh

AS> What is the question wrt this draft?

on #b) can you tell me what is unique about 
[draft-carrell-ipsecme-controller-ike-00.txt]

AS> Again what is the specific question wrt this draft? What section/line of 
this draft is not clear?

on #c) isn’t on-demand re-keying a desire to prevent DDOS that is a good 
feature for all IPsec?

AS> Yes, re-keying is a requirement.

On #d) policy is normal for all IPsec

AS> You can have min. set with no SA policy, you can have a single SA policy, 
or you can have a SA policy list.

Cheers,
Ali

Thank you, Sue
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Questions about the ESP-Transport and ESP-in-UDP transport in SECURE-EVPN

[Ali Sajassi (sajassi)]

Linda,

Please see my responses inline marked with AS> …

From: Linda Dunbar 
Date: Tuesday, July 28, 2020 at 5:49 AM
To: Cisco Employee , "bess@ietf.org" 
Subject: Questions about the ESP-Transport and ESP-in-UDP transport in 
SECURE-EVPN

Ali,

Just follow up with my question in the BESS WG session.
Your draft introduced two Tunnel Types in 5.1: ESP-Transport and ESP-in-UDP 
Transport as below.


When standard IP Encapsulating Security Payload (ESP) is used
(without outer UDP header) for encryption of NVO packets, it is used
in transport mode as depicted below. When such encapsulation is used,
for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set
to ESP-Transport and the Tunnel Type of Encapsulation Extended
Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,
etc.). This implies that the customer packets are first encapsulated
using NVO encapsulation type and then it is further encapsulated &
encrypted using ESP-Transport mode.

Question 1:  Are you assuming that  using IPsec Transport mode? Instead of 
IPsec Tunnel mode?


AS> Not assuming but stating ☺ 1st line of section 5.1 says:

 “ … it is used in transport mode as depicted below”

Question 2: Your Figure 3 has two encodings, which one is “ESP-Transport”, 
which one is “ESP-in-UDP”?

AS> Figure 3 is for ESP-transport and Figure 4 is for ESP-in-UDP. Furthermore, 
section 5.1 is for ESP-transport and section 5.2 is for ESP-in-UDP.

Question 3: The NVO encapsulation (VxLAN, GENEVE, GRE) can also be inside the 
IPsec ESP tunnel. In that case, which type is used?

AS> The tunnel type of the attribute indicates what kind of underlay tunnel is 
used and the tunnel type of the extended community indicates what kind of 
overlay encap is used. Section 5.1 says:


   “the Tunnel Type of Tunnel Encapsulation TLV is set

   to ESP-Transport and the Tunnel Type of Encapsulation Extended

   Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,

   etc.).”

And section 5.2 says:

   “the Tunnel Type

   of Tunnel Encapsulation TLV is set to ESP-in-UDP-Transport and the

   Tunnel Type of Encapsulation Extended Community is set to NVO

   encapsulation type (e.g., VxLAN, GENEVE, GPE, etc.). “

Cheers,
Ali

Thanks, Linda

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Murray,

Thanks for your review and comments. Please see my responses inline marked with 
"AS>".

Cheers,
Ali

On 7/13/20, 10:50 PM, "Murray Kucherawy via Datatracker"  
wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

Bigger stuff:

I'll see Benjamin's DISCUSS (meaning I support it) and raise him the two
seemingly normative references to [TUNNEL-ENCAP], which is also undefined.

AS> Added the reference to tunnel-encap.

As someone not from the Routing Area, I found this a little hard to read
because it becomes quite dense with acronyms in some places.

Is Section 13 intended to remain in the final published version?  Is it 
needed?

AS> removed this one-line section since other RFCs don't have such an explicit 
IPR section.

In the Abstract, please expand all acronyms on first use in the abstract, 
per
the I-D Guidelines.

AS> Done.

Lesser stuff:

Thanks for the glossary in Section 1.  I note that, although defined in the
glossary here, the terms "DGW", "Ethernet A-D route", "GRE", "GW IP", "IPL",
"ML", and "VXLAN" are not used anywhere else in this document.

AS> removed the unused terms.

There are lots of places where a single hyphen is used to break up a 
sentence,
such as to introduce an example.  These should be em dashes, or commas, or
maybe semicolons, but not simply hyphens.

AS> done.

A few nits:

Section 2:

* "... all the inter-subnet forwarding are performed ..." -- s/are/is/

AS> done.

* "... connected to the same PE, wanted to communicate ..." -- remove the 
comma

AS> done.

Section 3:

* "A MAC-VRF can consists of one ..." -- either drop "can", or use "consist"

AS> done.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Rob,

Thanks for your review and comments. Please see my reply inline marked with 
"AS>". 

On 7/16/20, 6:38 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

I agree with the other ADs that this document seemed terse in places and 
won't
repeat those same comments here.

One question I have is whether it is possible to have a deployment where 
some
devices support synchronous mode and others support asynchronous mode.  Am I
right in presuming that this is not supported and if so is this capability
signaled in any way? Or is the expectation that this would be controlled via
deployment choice of network device, or though configuration management?

AS> The current deployments AFAIK are either symmetric or asymmetric. However, 
this  doesn't mean that we won't run into interop between symmetric and 
asymmetric IRB in the future. That's why we put out a draft to describe the 
interop between symmetric and asymmetric IRB modes about a year ago - 
https://tools.ietf.org/html/draft-krattiger-evpn-modes-interop-01.

Cheers,
Ali

Regards,
Rob




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess