[bess] draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Hi all,
I have a few questions about the last para of Section 15 of the 7432bis 
draft
 which it says (same as in the original RFC 7432):

If two (or more) PEs advertise the same MAC address with the same sequence 
number but different Ethernet segment identifiers, a PE that receives these 
routes selects the route advertised by the PE with the lowest IP address as the 
best route. If the PE is the originator of the MAC route and it receives the 
same MAC address with the same sequence number that it generated, it will 
compare its own IP address with the IP address of the remote PE and will select 
the lowest IP. If its own route is not the best one, it will withdraw the route.

Now my questions:

  1.  It seems that the situation in which two (or more) PEs advertise the same 
MAC address with the same sequence number but different Ethernet segment 
identifiers  can only occur as the result of a race condition between the data 
plane that locally learns the MAC address in question and the control plane 
that receives advertisement for this MAC address form other PEs. Is this 
correct?
  2.  Assuming affirmative answer for the previous question: I can easily see 
how such race condition can occur in the case of the MAC address in question 
being locally learned by different PEs at 3 (three) different Ethernet 
Segments. Do you think it may occur in scenarios with just two different 
Ethernet Segments?
  3.  It seems that the tie-preaking procedure defined in the quoted text does 
may result in inconsistency between the data plane and EVPN control plane and 
consequent traffic loss (because the best route selected in accordance with the 
tie-breaking procedure does not have to match actual latest location of the MAC 
address in question).  Is this correct? If yes, did you consider a 
recommendation to notify the operator in this case?

Your timely feedback will be, as always, highly appreciated.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07

[Alexander Vainshtein]

Hi Donald,
My apologies for a much-delayed response to your email.
I am now reading the -08 version of the draft, and I will send a detailed 
response based on this document.

At the same time, I would like to bring to your attention my detailed comments 
on the -07 version of the 
draft<https://mailarchive.ietf.org/arch/msg/bess/lXi2BB6Fn95UW3bbJc0tL1mgiKQ/> 
which I have asked to consider as any other LC comments on the draft.

I cannot yet say whether the -08 version addresses these comments or not.

Regards,
Sasha

From: Donald Eastlake 
Sent: Monday, September 30, 2024 6:54 PM
To: Alexander Vainshtein 
Cc: Mohamed Boucadair ; bess@ietf.org; 
draft-ietf-bess-evpn-bfd@ietf.org; rtg-...@ietf.org
Subject: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of 
draft-ietf-bess-evpn-bfd-07

Hi Sasha,

On Tue, Sep 17, 2024 at 8:27 AM Alexander Vainshtein
mailto:Alexander.Vainshtein=40rbbn@dmarc.ietf.org>>
 wrote:
>
> Mohammed,
>
> Lots of thanks for the review.
>
> I have posted my concerns about the draft in question some time ago, and they 
> are mainly orthogonal to the issues you raise.
>
> However, there is one important point that you are raising and that overlaps, 
> to some extent, with some of my comments.
>
> You have written that you have failed finding “EVPN network layer” in 7432 or 
> 7432bis, and your guess is that the authors may refer to the definition in 
> Section 2.1 of RFC 9062.

Yes, the draft does intend to refer to the network layer specified in
Section 2.1 of RFC 9062 and hopefully that is clearer in the latest
revision of the draft.

> But I think that the real question here should be whether EVPN network layer 
> exists at all, and, if yes, whether it could be monitored using BFD.

Well, it seems to me that PEs exist and the paths between PEs that are
used by EVPN exist and it can be useful to monitor those paths. It is
convenient to have some name to use for the set of such paths. Is
there some name you would prefer to "network layer"? It also seems to
me that it can be monitored with BFD but it could be monitored in
other ways.

> Quoting from Section 9.2.1 of RFC 7432 (the relevant text is highlighted):
>
>
> A PE may advertise the same single EVPN label for all MAC addresses
> in a given MAC-VRF. This label assignment is referred to as a per
> MAC-VRF label assignment. Alternatively, a PE may advertise a unique
> EVPN label per  combination. This label
> assignment is referred to as a per  label
> assignment. As a third option, a PE may advertise a unique EVPN
> label per  combination. This label assignment is
> referred to as a per  label assignment. As a
> fourth option, a PE may advertise a unique EVPN label per MAC
> address. This label assignment is referred to as a per MAC label
> assignment. All of these label assignment methods have their
> trade-offs. The choice of a particular label assignment methodology
> is purely local to the PE that originates the route.
>
>
> This is definition is re-phrased (without any change in the semantics) in 
> Section 9.2.1 of 7432bis as following:
>
>
> The choice of a particular label assignment methodology is purely local to 
> the PE that originates the route :¶
> · A PE may advertise the same single EVPN label for all MAC addresses in a 
> given MAC-VRF. This label assignment is referred to as a per MAC-VRF label 
> assignment.
> · Alternatively, a PE may advertise a unique EVPN label per  Ethernet tag> combination. This label assignment is referred to as a per 
>  label assignment.
> · As a third option, a PE may advertise a unique EVPN label per  Ethernet tag> combination. This label assignment is referred to as a per 
>  label assignment.
> · As a fourth option, a PE may advertise a unique EVPN label per MAC address. 
> This label assignment is referred to as a per MAC label assignment.
> All of these label assignment methods have their trade‑offs. An assignment 
> per MAC-VRF label requires the least number of EVPN labels but requires a MAC 
> lookup in addition to an MPLS lookup on an egress PE for forwarding. On the 
> other hand, a unique label per  or a unique label per MAC 
> allows an egress PE to forward a packet that it receives from another PE to 
> the connected CE, after looking up only the MPLS labels without having to 
> perform a MAC lookup. This includes the capability to perform appropriate 
> VLAN ID translation on egress to the CE.
>
>
> In both cases 4 (four) different options for allocating labels carried in the 
> Label1 field of the NLRI of EVPN Type 2 routes are listed, and 7432bis 
> explains that each of these options has its own trade-offs.
>
>
> At the same time, Section 2.3 EVPN Network Layer OAM” of RFC 9062 says:
>
> EVPN Network OAM is visible to the PE nodes only. This

[bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07

[Alexander Vainshtein]

Mohammed,
Lots of thanks for an extra-prompt response!

One of my main concerns about this this draft is lack of any BFD-based 
monitoring of the “network layer” of BGP/MPLS IP-VPNs.

What do you think?

Regards,
Sasha

From: mohamed.boucad...@orange.com 
Sent: Tuesday, September 17, 2024 3:47 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-ietf-bess-evpn-bfd@ietf.org; rtg-...@ietf.org
Subject: RE: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of 
draft-ietf-bess-evpn-bfd-07

Hi Sasha,

Thanks for zooming into this. I trust the authors will follow up and DISCUSS.

The point you raised about scalability is a point I do share as well. I 
actually found the current scalability discussion in the draft too brief (with 
mention of +/- timer).

Cheers,
Med

De : Alexander Vainshtein 
mailto:Alexander.Vainshtein=40rbbn@dmarc.ietf.org>>
Envoyé : mardi 17 septembre 2024 14:27
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-bfd@ietf.org<mailto:draft-ietf-bess-evpn-bfd@ietf.org>;
 rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Objet : [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of 
draft-ietf-bess-evpn-bfd-07

Mohammed,
Lots of thanks for the review.

I have posted my concerns about the draft in 
question<https://mailarchive.ietf.org/arch/msg/bess/lXi2BB6Fn95UW3bbJc0tL1mgiKQ>
 some time ago, and they are mainly orthogonal to the issues you raise.

However, there is one important point that you are raising and that overlaps, 
to some extent, with some of my comments.

You have written that you have failed finding “EVPN network layer” in 7432 or 
7432bis, and your guess is that the authors may refer to the definition in 
Section 2.1 of RFC 9062.

But I think that the real question here should be whether EVPN network layer 
exists at all, and, if yes, whether it could be monitored using BFD.

Quoting from Section 9.2.1 of RFC 7432 (the relevant text is highlighted):

   A PE may advertise the same single EVPN label for all MAC addresses
   in a given MAC-VRF.  This label assignment is referred to as a per
   MAC-VRF label assignment.  Alternatively, a PE may advertise a unique
   EVPN label per  combination.  This label
   assignment is referred to as a per  label
   assignment.  As a third option, a PE may advertise a unique EVPN
   label per  combination.  This label assignment is
   referred to as a per  label assignment.  As a
   fourth option, a PE may advertise a unique EVPN label per MAC
   address.  This label assignment is referred to as a per MAC label
   assignment.  All of these label assignment methods have their
   trade-offs.  The choice of a particular label assignment methodology
   is purely local to the PE that originates the route.

This is definition is re-phrased (without any change in the semantics)  in 
Section 9.2.1 of 
7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-10#section-9.2.1>
 as following:

The choice of a particular label assignment methodology is purely local to the 
PE that originates the route 
:¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-10#section-9.2.1-8>
·   A PE may advertise the same single EVPN label for all MAC addresses in 
a given MAC-VRF. This label assignment is referred to as a per MAC-VRF label 
assignment.
·   Alternatively, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per 
 label assignment.
·   As a third option, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per  label assignment.
·   As a fourth option, a PE may advertise a unique EVPN label per MAC 
address. This label assignment is referred to as a per MAC label assignment.
All of these label assignment methods have their trade‑offs. An assignment per 
MAC-VRF label requires the least number of EVPN labels but requires a MAC 
lookup in addition to an MPLS lookup on an egress PE for forwarding. On the 
other hand, a unique label per  or a unique label per MAC 
allows an egress PE to forward a packet that it receives from another PE to the 
connected CE, after looking up only the MPLS labels without having to perform a 
MAC lookup. This includes the capability to perform appropriate VLAN ID 
translation on egress to the CE.

In both cases 4 (four) different options for allocating labels carried in the 
Label1 field of the NLRI of EVPN Type 2 routes are listed, and 7432bis explains 
that each of these options has its own trade-offs.

At the same time, Section 2.3 EVPN Network Layer OAM” of RFC 9062 says:
EVPN Network OAM is visible to the PE nodes only. This OAM layer is analogous 
to Virtual Circuit Connectivity Verification (VCCV) 
[RFC5085<https://datatracker.ietf.org/doc/html/rfc5085>] in the case of 
VPLS/VPWS. It provides mechanisms to check the correct operation of the data 
plane as we

[bess] Yet another minor inconsistency in draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Hi,
I would like to present what looks to me as yet another minor inconsistency in 
the rfc7432bis 
draft.

Section 9.2.1 lists four possible methods for allocating the label that is 
carried in the Label1 field of the NLRI of MAC/IP Advertisement (EVPN Type 2) 
routes as shown below:


  *   A PE may advertise the same single EVPN label for all MAC addresses in a 
given MAC-VRF. This label assignment is referred to as a per MAC-VRF label 
assignment.¶
  *   Alternatively, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per 
 label 
assignment.¶
  *   As a third option, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per  label 
assignment.¶
  *   As a fourth option, a PE may advertise a unique EVPN label per MAC 
address. This label assignment is referred to as a per MAC label 
assignment.¶

However, an EVI that implements VLAN-aware bundle service interface as defined 
in Section 6.3 of the draft, the same MAC address may be locally learned in 
different BDs (identified by their Ethernet Tag IDs) in the same MAC-VRF.
To me this suggests that there is (at least in theory) there is the fifth 
option, in which a unique EVPN label would be allocated per  combination.

Hopefully this note will be useful.





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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-bfd-07

[Alexander Vainshtein]

Mohammed,
Lots of thanks for the review.

I have posted my concerns about the draft in 
question
 some time ago, and they are mainly orthogonal to the issues you raise.

However, there is one important point that you are raising and that overlaps, 
to some extent, with some of my comments.

You have written that you have failed finding “EVPN network layer” in 7432 or 
7432bis, and your guess is that the authors may refer to the definition in 
Section 2.1 of RFC 9062.

But I think that the real question here should be whether EVPN network layer 
exists at all, and, if yes, whether it could be monitored using BFD.

Quoting from Section 9.2.1 of RFC 7432 (the relevant text is highlighted):

   A PE may advertise the same single EVPN label for all MAC addresses
   in a given MAC-VRF.  This label assignment is referred to as a per
   MAC-VRF label assignment.  Alternatively, a PE may advertise a unique
   EVPN label per  combination.  This label
   assignment is referred to as a per  label
   assignment.  As a third option, a PE may advertise a unique EVPN
   label per  combination.  This label assignment is
   referred to as a per  label assignment.  As a
   fourth option, a PE may advertise a unique EVPN label per MAC
   address.  This label assignment is referred to as a per MAC label
   assignment.  All of these label assignment methods have their
   trade-offs.  The choice of a particular label assignment methodology
   is purely local to the PE that originates the route.

This is definition is re-phrased (without any change in the semantics)  in 
Section 9.2.1 of 
7432bis
 as following:

The choice of a particular label assignment methodology is purely local to the 
PE that originates the route 
:¶
·   A PE may advertise the same single EVPN label for all MAC addresses in 
a given MAC-VRF. This label assignment is referred to as a per MAC-VRF label 
assignment.
·   Alternatively, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per 
 label assignment.
·   As a third option, a PE may advertise a unique EVPN label per  combination. This label assignment is referred to as a per  label assignment.
·   As a fourth option, a PE may advertise a unique EVPN label per MAC 
address. This label assignment is referred to as a per MAC label assignment.
All of these label assignment methods have their trade‑offs. An assignment per 
MAC-VRF label requires the least number of EVPN labels but requires a MAC 
lookup in addition to an MPLS lookup on an egress PE for forwarding. On the 
other hand, a unique label per  or a unique label per MAC 
allows an egress PE to forward a packet that it receives from another PE to the 
connected CE, after looking up only the MPLS labels without having to perform a 
MAC lookup. This includes the capability to perform appropriate VLAN ID 
translation on egress to the CE.

In both cases 4 (four) different options for allocating labels carried in the 
Label1 field of the NLRI of EVPN Type 2 routes are listed, and 7432bis explains 
that each of these options has its own trade-offs.

At the same time, Section 2.3 EVPN Network Layer OAM” of RFC 9062 says:
EVPN Network OAM is visible to the PE nodes only. This OAM layer is analogous 
to Virtual Circuit Connectivity Verification (VCCV) 
[RFC5085] in the case of 
VPLS/VPWS. It provides mechanisms to check the correct operation of the data 
plane as well as a mechanism to verify the data plane against the control 
plane. This includes the ability to perform fault detection and diagnostics 
on:¶
·   the MP2P tunnels used for the transport of unicast traffic between PEs. 
EVPN allows for three different models of unicast label assignment: label per 
EVI, label per , and label per MAC address. In all three 
models, the label is bound to an EVPN Unicast Forwarding Equivalence Class 
(FEC). EVPN Network OAM MUST provide mechanisms to check the operation of the 
data plane and verify that operation against the control plane view.

This text is slightly inconsistent with the text in 7432/7432bis (one of the 
four options of the latter is missing in the former). But in any case, the 
“EVPN network layer” in the specific PE may be associated not just with a 
specific MAC-VRF (or with a specific BD within a MAC-VRF) but with a specific 
NAC-VRF, locally attached Ethernet Segment} pair or even with a specific 
 pair.

And this raises a question about the number of EVPN BFD sessions that could be 
required to monitor such EVPN Network layer.

Hope these notes will be useful.

Regards,
Sasha

From: Mohamed Boucadair via Datatracker 
Sent: Monday, Se

[bess] A question about Section 3.1 of RFC 8317

[Alexander Vainshtein]

Hi all,
I have a question about Section 3.1 "Scenario 1: Leaf or Root Site(s) per PE" 
of RFC 8317.

This section proposes using dedicated Root and Leaf Route Targets (RT) for the 
service instance in such a way that:

  *   The MAC-VRFs in Root PEs add just the Root RT to all EVPN routes it 
advertises and imports EVPN routes with both Root and Leaf RT
  *   The MAC-VRFs in Leaf PEs add just the Leaf RT to all EVPN routes it 
advertises and imports EVPN routes with just the Root RT.

It is my understanding is that, if this scheme is followed, a MAC-VRF in a Leaf 
PE, upon receiving a customer Ethernet frame with the Destination MAC address 
that has been locally learned by another Leaf PE shall flood this frame to 
MAC-VRFs in all Root PEs which, in their turn, shall send it to the attached 
customer sites.

Is this correct? If not, what have I missed?

If yes, is this the acceptable behavior?   Or should I file an Erratum?

Please note the solution described in Section 3.2 of the same RFC does not have 
this problem.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] My concerns regarding draft-ietf-bess-evpn-bfd

[Alexander Vainshtein]

Hi all ,
I would like to share with you my serious concerns regarding the EVPN Network 
Layer Fault 
Management 
draft.

These concerns are closely related to the email exchange with the authors of 
the draft that can be found 
here.
I have decided to present them now because the WG Chairs have said yesterday 
that the draft is going to the WG LS.


  1.  Section 3 of the draft says that "In addition to detecting link failures 
in the EVPN network, BFD sessions at the network layer can be used to monitor 
the successful setup, such as label programming, of MP2P and P2MP EVPN tunnels 
transporting Unicast and BUM traffic. The scope of reachability detection 
covers the ingress and the egress EVPN PE (Provider Edge) nodes and the network 
connecting them". IMHO and FWIW this statement actually contradicts the OAM 
layering scheme:
 *   The underlay failures such as link failures, P and PE node failures 
etc.) should be monitored by their own monitoring mechanisms and should be 
quite aggressive for fast detection of failure and activation of the relevant 
protection mechanisms
 *   The OAM mechanisms used for the EVPN network layer should be separated 
from the mechanisms used in the underlay and should not be over-aggressive in 
order to avoid multiple instances of false detection of failures at the network 
layer. E.g., failure of the link in the undelay network that is detected by 
fast single-op IP BD (TFV 5880) and triggers appropriate local protection 
action (e.g., SR TI-LFA)  should not be reported by the EVPN Network layer OAM 
mechanisms.
 *   The above means that the EVPN Network Layer OAM should be limited to 
detecting failures in programming the labels/VNI advertised in various  EVPN 
routes.  Such failures can occur, but hardly require fast monitoring mechanisms:

  i.  EVPN LSP 
Ping (RFC 9489) already provides an on-demand OAM mechanism for detecting such 
failures

 ii.  It is 
worth noting that BFD has never been proposed as the Network Layer OAM 
mechanism for BGP/MPLS IP/VPN (RFC 4364) in the 20+ years period in which both 
mechanisms have been available and widely deployed.

  1.  IMHO and FWIW:
 *   BFD sessions should be set up in accordance with the procedures 
defined in RFC 5882:

  i.  Set up by 
some "client entity" thar listens to the session state transitions

 ii.  Each BFD 
flavor defines the session uniqueness rules, and multiple client entities can 
listen to the same existing session if a new session cannot b set up without 
violating these rules

   iii.  When the 
session exits its UP state (e.g.,  fails) , listening clients take appropriate 
actions

 *   When a new BFD "flavor" is defined,  explicit definition of potential 
client entities and actions they take upon failure of the session in question 
is highly- RFC 7130 provides a good example. However, such definitions are 
missing in the draft in question. In particular:

  i.  It is not 
clear when a specific BFD session is set up, and at what granularity (per MAC 
address? Per EVI? Per EVI Ethernet Tag> for EVI that implements VLAN-aware 
Bundle service interface ?)

 ii.  Should 
BFD sessions be activated for EVI/BD that are not attached to any MH ES? In 
this case EVI/BD would not advertise any per EVI Ethernet A-D routes, and only 
MAC/IP Advertisement routes carry the information MAC addresses and the labels 
associated with them,

   iii.  What, if 
anything, should be done if a specific "EVPN BFD" BFD session fails? In 
particular, how should the customer traffic presumably affected by the failed 
session should be restored?

  1.  Encapsulation of the BFD packets defined in Sections 6.1.1 and 6.2.1 
include a  VAN ID field, but the draft does not specify how the value of this 
VLAN ID is defined.

 Please consider these notes as my WG LC comments if/when this LC is announced.


Regards,
Sasha
Closely

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 attac

[bess] Re: My concerns regarding draft-ietf-bess-evpn-bfd

[Alexander Vainshtein]

Re-sending...

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


From: Alexander Vainshtein 
Sent: Thursday, July 25, 2024 1:13:00 PM
To: draft-ietf-bess-evpn-...@ietf.org 
Cc: bess@ietf.org ; BFD WG 
Subject: My concerns regarding draft-ietf-bess-evpn-bfd

Hi all ,
I would like to share with you my serious concerns regarding the EVPN Network 
Layer Fault 
Management<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-07> 
draft.

These concerns are closely related to the email exchange with the authors of 
the draft that can be found 
here<https://mailarchive.ietf.org/arch/msg/bess/VfGN6fLORF9dylzoFjCmKLINjDM/>.
I have decided to present them now because the WG Chairs have said yesterday 
that the draft is going to the WG LS.


  1.  Section 3 of the draft says that “In addition to detecting link failures 
in the EVPN network, BFD sessions at the network layer can be used to monitor 
the successful setup, such as label programming, of MP2P and P2MP EVPN tunnels 
transporting Unicast and BUM traffic. The scope of reachability detection 
covers the ingress and the egress EVPN PE (Provider Edge) nodes and the network 
connecting them”. IMHO and FWIW this statement actually contradicts the OAM 
layering scheme:
 *   The underlay failures such as link failures, P and PE node failures 
etc.) should be monitored by their own monitoring mechanisms and should be 
quite aggressive for fast detection of failure and activation of the relevant 
protection mechanisms
 *   The OAM mechanisms used for the EVPN network layer should be separated 
from the mechanisms used in the underlay and should not be over-aggressive in 
order to avoid multiple instances of false detection of failures at the network 
layer. E.g., failure of the link in the undelay network that is detected by 
fast single-op IP BD (TFV 5880) and triggers appropriate local protection 
action (e.g., SR TI-LFA)  should not be reported by the EVPN Network layer OAM 
mechanisms.
 *   The above means that the EVPN Network Layer OAM should be limited to 
detecting failures in programming the labels/VNI advertised in various  EVPN 
routes.  Such failures can occur, but hardly require fast monitoring mechanisms:

  i.  EVPN LSP 
Ping (RFC 9489) already provides an on-demand OAM mechanism for detecting such 
failures

 ii.  It is 
worth noting that BFD has never been proposed as the Network Layer OAM 
mechanism for BGP/MPLS IP/VPN (RFC 4364) in the 20+ years period in which both 
mechanisms have been available and widely deployed.

  1.  IMHO and FWIW:
 *   BFD sessions should be set up in accordance with the procedures 
defined in RFC 5882:

  i.  Set up by 
some “client entity” thar listens to the session state transitions

 ii.  Each BFD 
flavor defines the session uniqueness rules, and multiple client entities can 
listen to the same existing session if a new session cannot b set up without 
violating these rules

   iii.  When the 
session exits its UP state (e.g.,  fails) , listening clients take appropriate 
actions

 *   When a new BFD “flavor” is defined,  explicit definition of potential 
client entities and actions they take upon failure of the session in question 
is highly– RFC 7130 provides a good example. However, such definitions are 
missing in the draft in question. In particular:

  i.  It is not 
clear when a specific BFD session is set up, and at what granularity (per MAC 
address? Per EVI? Per EVI Ethernet Tag> for EVI that implements VLAN-aware 
Bundle service interface ?)

 ii.  Should 
BFD sessions be activated for EVI/BD that are not attached to any MH ES? In 
this case EVI/BD would not advertise any per EVI Ethernet A-D routes, and only 
MAC/IP Advertisement routes carry the information MAC addresses and the labels 
associated with them,

   iii.  What, if 
anything, should be done if a specific “EVPN BFD” BFD session fails? In 
particular, how should the customer traffic presumably affected by the failed 
session should be restored?

  1.  Encapsulation of the BFD packets defined in Sections 6.1.1 and 6.2.1 
include a  VAN ID field, but the draft does not specify how the value of this 
VLAN ID is defined.

 Please consider these notes as my WG LC comments if/when this LC is announced.


Regards,
Sasha
Closely

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential an

[bess] Adoption of the EVPN Fast Reroute draft

[Alexander Vainshtein]

Hi all,
The EVPN Fast reroute 
draft
 has been mentioned as being in the middle of the queue for the BESS WG 
adoption call at the BESS WG session today.

IMHO and FWIW this draft is:

  *   Short, well-written and easy to understand
  *   Addresses a real problem - prevention of transient forwarding loops while 
handing failure of one of the PE-CE links in a MH ES
  *   Quite stable (the latest change was about SRv6 support).

Therefore, I would like to suggest expediting the WG adoption call for this 
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
To unsubscribe send an email to bess-le...@ietf.org

[bess] My comments regarding the EVPN Underlay Network Migration From IPv4 to IPv6 draft presentation

[Alexander Vainshtein]

Ali and all,
My comment at the BESS WG session during the presentation of the EVPN Underlay 
Network Migration From IPv4 to 
IPv6
 was about usage of Assisted Ingress 
Replication
 for BW-effective delivery of BUM traffic in EVPN.

It is my understanding that:

  *   Assisted Ingress Replication can be used with EVPN-VxLAN and relies on 
Source IP addresses in the VxLAN-encapsulated packets for loop prevention
  *   In the case of Underlay migration from IPv4 to IPv6 the ARREPLICATOR (and 
possibly, A-LRAF?) routes must also undergo migration
  *   The draft in its current form does not define any migration procedures 
for these nodes.
As mentioned during the discussion at the mike, the draft currently is limited 
to Ingress Replication.
Neither Assisted Ingress Replication nor use of of P2MP tunnels (if used for 
delivery of BUM traffic) are addressed..

IMHO and FWIW both issues should be covered in the next versions of the draft.


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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: A controversy in draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Ali,
Lots of thanks for a prompt response.
Will be waiting for th -10 revision of the draft.

Regards,
Sasha

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


From: Ali Sajassi (sajassi) 
Sent: Thursday, July 11, 2024 8:04:10 PM
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org 
Subject: [EXTERNAL] Re: A controversy in draft-ietf-bess-rfc7432bis

Hi Sasha,

Thanks for bringing this to our attention. RFC7432bis already talks about 
two-bit field for redundancy mode and defines two values for it (All-Active and 
Single-Active). So, we will ensure that the term redundancy mode is used 
consistently throughout the document with values of All-Active or Single-Active 
Redundancy Mode.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Wednesday, July 10, 2024 at 5:41 AM
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org 
Subject: A controversy in draft-ietf-bess-rfc7432bis
Hi,
I think that I have found a controversy in the latest version of the 
7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09> 
draft.

Section 5 of the draft contains the following text:

If a bridged network does not connect to the PEs using a LAG, then only one of 
the links between the bridged network and the PEs must be the active link for a 
given . In this case, the set of Ethernet A-D per ES routes advertised 
by each PE MUST have the "Single-Active" bit in the flags of the ESI Label 
extended community set to 1.


Section 8.2.1 of the draft conatis the following text:
The ESI Label extended community MUST be included in the route. If All-Active 
redundancy mode is desired, then the "Single-Active" bit in the flags of the 
ESI Label extended community MUST be set to 0 and the MPLS label in that 
Extended Community MUST be set to a valid MPLS label value.
…
If Single-Active redundancy mode is desired, then the "Single-Active" bit in 
the flags of the ESI Label extended community MUST be set to 1 and the ESI 
label SHOULD be set to a valid MPLS label value.

Section 8.4 of the draft mentions “the "Single-Active" bit in the flags of the 
ESI Label extended community”.


Section 14.1.1 of the draft contains the following text (copied verbatim from 
the namesake section of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432>):

For a given ES, if a remote PE has imported the set of Ethernet A‑D per ES 
routes from at least one PE, where the "Single-Active" flag in the ESI Label 
extended community is set, then that remote PE MUST deduce that the ES is 
operating in Single-Active redundancy mode.

Similarly, Section 14.1.2 of the draft contains the following text:

For a given ES, if the remote PE has imported the set of Ethernet A-D per ES 
routes from one or more PEs and none of them have the "Single‑Active" flag in 
the ESI Label extended community set, then the remote PE MUST deduce that the 
ES is operating in All-Active redundancy mode.



The problem with all these (and, possibly, some other) fragments is that the 
“Single-Active bit” (or flag) in the Flags field of the ESI Label extended 
community that has been defined in RFC 7432 does not exist in the 7432bis 
draft. Instead, Section 7.5 of the dratf defines a two-bit RED subfield in the 
Flags field of the ESI Label Extended Community, and defines two (out of 4) 
possible values for this field. (Yet another value is defined in the Layer 2 
EVPM Multi-Homing Mechanism for Layer 2 Protocol Gateways 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-04>.)

Hopefully, these notes will be helpful.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] A controversy in draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Hi,
I think that I have found a controversy in the latest version of the 
7432bis 
draft.

Section 5 of the draft contains the following text:

If a bridged network does not connect to the PEs using a LAG, then only one of 
the links between the bridged network and the PEs must be the active link for a 
given . In this case, the set of Ethernet A-D per ES routes advertised 
by each PE MUST have the "Single-Active" bit in the flags of the ESI Label 
extended community set to 1.


Section 8.2.1 of the draft conatis the following text:
The ESI Label extended community MUST be included in the route. If All-Active 
redundancy mode is desired, then the "Single-Active" bit in the flags of the 
ESI Label extended community MUST be set to 0 and the MPLS label in that 
Extended Community MUST be set to a valid MPLS label value.
…
If Single-Active redundancy mode is desired, then the "Single-Active" bit in 
the flags of the ESI Label extended community MUST be set to 1 and the ESI 
label SHOULD be set to a valid MPLS label value.

Section 8.4 of the draft mentions “the "Single-Active" bit in the flags of the 
ESI Label extended community”.


Section 14.1.1 of the draft contains the following text (copied verbatim from 
the namesake section of RFC 
7432):

For a given ES, if a remote PE has imported the set of Ethernet A‑D per ES 
routes from at least one PE, where the "Single-Active" flag in the ESI Label 
extended community is set, then that remote PE MUST deduce that the ES is 
operating in Single-Active redundancy mode.

Similarly, Section 14.1.2 of the draft contains the following text:

For a given ES, if the remote PE has imported the set of Ethernet A-D per ES 
routes from one or more PEs and none of them have the "Single‑Active" flag in 
the ESI Label extended community set, then the remote PE MUST deduce that the 
ES is operating in All-Active redundancy mode.



The problem with all these (and, possibly, some other) fragments is that the 
“Single-Active bit” (or flag) in the Flags field of the ESI Label extended 
community that has been defined in RFC 7432 does not exist in the 7432bis 
draft. Instead, Section 7.5 of the dratf defines a two-bit RED subfield in the 
Flags field of the ESI Label Extended Community, and defines two (out of 4) 
possible values for this field. (Yet another value is defined in the Layer 2 
EVPM Multi-Homing Mechanism for Layer 2 Protocol Gateways 
draft.)

Hopefully, these notes will be helpful.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Comments about Section 7.11 of 7432bis

[Alexander Vainshtein]

Hi,
I have a couple of comments about the first two sentences in Section 7.11 of 
7432bis
 "EVPN Layer 2 Attributes Extended Community":


[RFC8214] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled.

Usage and applicability of this Extended community to Bridging is clarified 
here.

My first comment is about interpretation of RFC 8214 as defining and requiring 
usage of L2-Attr Extended Community with per-EVI Ethernet A-D routes advertised 
for "bridging" EVI.  Please note that:

  *   Construction of per-EVI Ethernet A-D routes is defined in Section 8.4.1 
of RFC 7432 , and 
this definition does not mention attachment of L2-Attr Extended Community to 
these routes
  *   RFC 8214 is not marked as updating RFC 7432.

My second comment is about inclusion of L2-Attr Extended community with per-EVI 
Ethernet A-D routes when multi-homing is enabled. Actually, RFC 8214 requires, 
in the case of EVPN-VPLS instances, advertisement of per-EVI Ethernet A-D 
routes regardless of multihoming, and L2-Attr Extended Community may be 
attached to these routes. E.g., in order to enable L2-MTU check for the 
corresponding service instance.

May I suggest the following replacement for the quoted sentences (removed text 
is marked with red strikethrough font while  added text is marked with bold 
green italics):

[RFC8214] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled advertised by EVPN-based VPWS instances.

Usage and applicability of this Extended community to Bridging EVPN instances 
is clarified defined here.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: A question about the role of per-ES Ethernet A-D routes in DF election in EVPN.

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

I do not say that AC-DF capability should be included in 7432bis as mandatory – 
exactly because there are so many 7432 implementations around.

But I think that a  short of issues may be encountered in the case of the 
discrepancy between the set of received RT-4 and the set of received per-ES 
RT-1 reminder (with a reference to Section 4 of RFC 
8584<https://datatracker.ietf.org/doc/html/rfc8584#section-4>)  would be useful.

RFC 8584 is already listed as a Normative reference in 7432bis, so this would 
not cause any delays.


My 2c,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Thursday, July 4, 2024 1:23 AM
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432...@ietf.org; satya...@cisco.com; 
enthil.sathap...@nokia.com; Kiran Nagaraj (Nokia) 
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: A question about the role of per-ES Ethernet A-D routes 
in DF election in EVPN.

Hi Sasha,

I agree the AC-DF capability is important, and that’s one of the reasons for 
RFC8584, but I am missing your point.
Are you saying the AC-DF capability must be included in 7432bis as mandatory?

I don’t think we should, given all the 7432 implementations out there.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Wednesday, July 3, 2024 at 6:21 AM
To: 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>,
 satya...@cisco.com<mailto:satya...@cisco.com> 
mailto:satya...@cisco.com>>, 
enthil.sathap...@nokia.com<mailto:enthil.sathap...@nokia.com> 
mailto:enthil.sathap...@nokia.com>>, Kiran Nagaraj 
(Nokia) mailto:kiran.naga...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: A question about the role of per-ES Ethernet A-D routes in DF election 
in EVPN.

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 all,
I have a question about the role of per-ES Ethernet A-D routes in DF Election 
in EVPN.

1.  Both Section 8.5 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-8.5> and Section 8.5 
of 
7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#section-8.5>
 say that the DF of a MH ES is elected based solely on information that is 
advertised in received Ethernet Segment (EVPN RT-4) routes

2.  Section 4 of RFC 
8584<https://datatracker.ietf.org/doc/html/rfc8584#section-4> says that, in the 
case of AC-influenced DF election, the PEs from which per-ES Ethernet A-D (RVPN 
RT-1) routes have not been received  for the MH ES in question must be excluded 
from the list of candidate PEs for DF election.

I wonder whether this rule should not be extended to all kinds of DF Election 
procedures. The rationale for such behavior is the need to prevent various 
certain corner cases, e.g.:

1.  A MH ES that is attached to PE-1 and PE-2 operates in Single-Active 
redundancy mode.

2.  A certain EVI is attached to this MH ES in PE-1 but not in PE-2 (due to 
misconfiguration)

3.  Constrained route distribution (RFC 
4684<https://datatracker.ietf.org/doc/html/rfc4684> is enabled in all the BGP 
speakers in the network in question. As a consequence, per-ES RT-1 for the MH 
ES in question that has bene advertised by PE-2 shall not be received by PE-1

4.  PE-2 has been elected as the DF for the MH ES and EVI in question in 
accordance with the DF Election procedures of RFC 7432. Therefore, PE-1 shall 
shut down its AC on the MH ES. So that customer site attached to the EVPN 
domain via the MH ES in question shall not be able to send or receive any 
traffic.

Another potential corner case is misconfiguration of redundancy mode in 
different PEs attached to the same MH ES. This mode is carried only in the ESI 
Extended Community that is attached to the per-ES RT-1.

Recently we have observed a commercially available EVPN implementation that 
advertises the per-ES Ethernet A-D route for a recovering member of an MH ES a 
few seconds later than the Ethernet Segment route for the same MH ES, so that 
my question is neither purely theoretical nor limited to just misconfiguration 
corner cases.

Your timely feedback would be highly appreciated.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] A question about the role of per-ES Ethernet A-D routes in DF election in EVPN.

[Alexander Vainshtein]

Hi all,
I have a question about the role of per-ES Ethernet A-D routes in DF Election 
in EVPN.

  1.  Both Section 8.5 of RFC 
7432 and Section 8.5 
of 
7432bis
 say that the DF of a MH ES is elected based solely on information that is 
advertised in received Ethernet Segment (EVPN RT-4) routes
  2.  Section 4 of RFC 
8584 says that, in the 
case of AC-influenced DF election, the PEs from which per-ES Ethernet A-D (RVPN 
RT-1) routes have not been received  for the MH ES in question must be excluded 
from the list of candidate PEs for DF election.

I wonder whether this rule should not be extended to all kinds of DF Election 
procedures. The rationale for such behavior is the need to prevent various 
certain corner cases, e.g.:

  1.  A MH ES that is attached to PE-1 and PE-2 operates in Single-Active 
redundancy mode.
  2.  A certain EVI is attached to this MH ES in PE-1 but not in PE-2 (due to 
misconfiguration)
  3.  Constrained route distribution (RFC 
4684 is enabled in all the BGP 
speakers in the network in question. As a consequence, per-ES RT-1 for the MH 
ES in question that has bene advertised by PE-2 shall not be received by PE-1
  4.  PE-2 has been elected as the DF for the MH ES and EVI in question in 
accordance with the DF Election procedures of RFC 7432. Therefore, PE-1 shall 
shut down its AC on the MH ES. So that customer site attached to the EVPN 
domain via the MH ES in question shall not be able to send or receive any 
traffic.

Another potential corner case is misconfiguration of redundancy mode in 
different PEs attached to the same MH ES. This mode is carried only in the ESI 
Extended Community that is attached to the per-ES RT-1.

Recently we have observed a commercially available EVPN implementation that 
advertises the per-ES Ethernet A-D route for a recovering member of an MH ES a 
few seconds later than the Ethernet Segment route for the same MH ES, so that 
my question is neither purely theoretical nor limited to just misconfiguration 
corner cases.

Your timely feedback would be highly appreciated.

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
To unsubscribe send an email to bess-le...@ietf.org

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

[Alexander Vainshtein]

Ali,
Lots of thanks again for a prompt and very encouraging response.

I defer to you and the rest of the authors of 7432bis whether Informative 
reference to MEF documents describing processing of L2 Control Protocols should 
be added. (IMHO it could be useful while not causing any procedural issues).

I wonder if your use case (b) should be covered under vlan-bundle (including 
port-based as a special case) service interface.
IMHO the relevant deployment use case for the port-based service interface is 
the scenario in which the customer does not want to negotiate the list of VIDs 
it uses for traffic with the EVPN service provider.
If you agree, maybe some text clarifying this point could be added to Section 
6.1.2 of the draft?


Regards,
Sasha

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

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:

a)  Access ports where the data traffic over such ports are untagged

b)  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 
mailto:alexander.vainsht...@rbbn.com>>
Date: Wednesday, June 19, 2024 at 12:09 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto: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) 
mailto:jorge.raba...@nokia.com>>
Sent: Wednesday, June 19, 2024 12:00 AM
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,

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> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://aka.ms/AAb9ysg>

____
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> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailt

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

[Alexander Vainshtein]

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> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://aka.ms/AAb9ysg>


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> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailto: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> 
mailto:draft-ietf-bess-rfc7432...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#section-6.2.1>.

This section defines Port-based Service Interface in EVPN as “a special case of 
the VLAN bundle service interface, where all of the VLANs on the port are part 
of the same service and map to the same bundle” . It further states that “The 
procedures are identical to those described in Section 6.2” which, in its turn, 
says that “no VID translation is allowed for this (VLAN bundle - Sasha) service 
interface type”.

My question is: what happens with untagged traffic received from an Ethernet 
port to which an EVI (or EVPN-VPWS) implementing port-based service interface 
is attached?
It seems that mapping untagged traffic to tagged using port-based VLAN ID at 
ingress and stripping this VLAN tag at egress is not complia

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

[Alexander Vainshtein]

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<https://aka.ms/AAb9ysg>


From: Jorge Rabadan (Nokia) 
Sent: Tuesday, June 18, 2024 7:36:22 PM
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,

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 
Date: Tuesday, June 18, 2024 at 5:54 AM
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: 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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#section-6.2.1>.

This section defines Port-based Service Interface in EVPN as “a special case of 
the VLAN bundle service interface, where all of the VLANs on the port are part 
of the same service and map to the same bundle” . It further states that “The 
procedures are identical to those described in Section 6.2” which, in its turn, 
says that “no VID translation is allowed for this (VLAN bundle - Sasha) service 
interface type”.

My question is: what happens with untagged traffic received from an Ethernet 
port to which an EVI (or EVPN-VPWS) implementing port-based service interface 
is attached?
It seems that mapping untagged traffic to tagged using port-based VLAN ID at 
ingress and stripping this VLAN tag at egress is not compliant with the 
definitions above.

An interesting special case could be the case of an All-Active MH ES that runs 
LACP on its constituent links vs. the attached CE.

Your feedback would be highly appreciated.

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
To unsubscribe send an email to bess-le...@ietf.org

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

[Alexander Vainshtein]

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 interface, where all of the VLANs on the port are part 
of the same service and map to the same bundle" . It further states that "The 
procedures are identical to those described in Section 6.2" which, in its turn, 
says that "no VID translation is allowed for this (VLAN bundle - Sasha) service 
interface type".

My question is: what happens with untagged traffic received from an Ethernet 
port to which an EVI (or EVPN-VPWS) implementing port-based service interface 
is attached?
It seems that mapping untagged traffic to tagged using port-based VLAN ID at 
ingress and stripping this VLAN tag at egress is not compliant with the 
definitions above.

An interesting special case could be the case of an All-Active MH ES that runs 
LACP on its constituent links vs. the attached CE.

Your feedback would be highly appreciated.

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
To unsubscribe send an email to bess-le...@ietf.org

[bess] Questions about draft-ietf-bess-evpn-bfd

[Alexander Vainshtein]

Hi,
I am reading the latest available version of the 
draft,  and 
I have several questions to the authors.


  1.  RFC 5882 suggest that BFD sessions in general are coupled with their 
clients which:
 *   Initiate establishment of these sessions
 *   React to state transitions of these sessions in some way
The well-known clients can be routing protocols, redundancy mechanisms etc.
Can the authors please clarify which entities are expected to act as the 
clients of the EVPN BFD sessions, and which actions can these clients take 
upon, say, exist of an established session from its UP state?

  1.  Section 4 "Fault Detection for Unicast Traffic" suggests advertisement of 
"My" discriminator values in the BGP Discriminator attribute in MAC/IP 
Advertisement (EVPN Type 2, a.k.a. RT-2) routes.
 *   Can the authors please clarify whether a different My discriminator 
value is expected to be assigned for each MAC address that have been locally 
learned by the given PE?
 *   Suppose that:

  i.  PE-1 and 
PE-2 participate in the same EVI and the same BD in this EVI

 ii.  PE-1 has 
locally learned MAC-1, assigned My Discriminaror D1 to it and advertised D1 in 
the corresponding RT-2

   iii.  PE-2 has 
locally learned MAC-2, assigned My Discriminaror D2 to it and advertised D2 in 
the corresponding RT-2
Does the draft imply that a BFD session between PE-1 and PE-2 using D1 and D2 
as the cross-matching pairs of ___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] rfc9251

[Alexander Vainshtein]

Hi all,
Yet another question related to RFC 9251.

Section 4.2 of RFC 
9251<https://datatracker.ietf.org/doc/html/rfc9251#section-4.2> says:


As mentioned in the previous sections, each PE MUST have proxy querier 
functionality for the following reasons:

  1.  to enable the collection of EVPN PEs providing Layer 2 Virtual Private 
Network (L2VPN) service to act as a distributed multicast router with an 
anycast IP address for all attached hosts in that subnet
  2.  to enable suppression of IGMP Membership Reports and Membership Queries 
over MPLS/IP core

I wonder whether Source IP address of the queries mentioned above is presumed 
to be an IP address of an anycast EVPN IRB as defined in RFC 9135,  and, if 
yes, is this EVPN IRB assumed to be Symmetric or Asymmetric.

Regards, and lots of thanks in advance,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:06 PM
To: Ali Sajassi (sajassi) ; Samir Thoria (sthoria) 
; John E Drake ; 
'manka...@cisco.com' ; w...@juniper.net
Cc: 'bess@ietf.org' 
Subject: RE: rfc9251

Hi all,
Re-sending to the authors since the address : 
rfc9...@ietf.org<mailto:rfc9...@ietf.org> is invalid.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:01 PM
To: rfc9...@ietf.org<mailto:rfc9...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: rfc9251

Hi all,
I have a question regarding expected DP behavior in conjunction with RFC 9521: 
Are the PEs that support this RFC expected to decrement TTL in IP headers of 
multicast IP packets they forward?

This question is equally applicable to the "last mile" PEs that have received 
IGMP/MLD Joins and advertised them as SMET routes, and to the "first mile" PEs 
that receive and install these SMET routes.

The context for this question is my understanding that multicast IP traffic 
that is forwarded based on IMET route (e.g., to the PEs that have not 
advertised ability to advertise SMET routes)   does not undergo TTL decrement.

I have failed to find an answer to my question in the text of RFC 9251.

Your timely feedback would be highly appreciated.

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] rfc9251

[Alexander Vainshtein]

Hi all,
Re-sending to the authors since the address : 
rfc9...@ietf.org<mailto:rfc9...@ietf.org> is invalid.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:01 PM
To: rfc9...@ietf.org
Cc: bess@ietf.org
Subject: rfc9251

Hi all,
I have a question regarding expected DP behavior in conjunction with RFC 9521: 
Are the PEs that support this RFC expected to decrement TTL in IP headers of 
multicast IP packets they forward?

This question is equally applicable to the "last mile" PEs that have received 
IGMP/MLD Joins and advertised them as SMET routes, and to the "first mile" PEs 
that receive and install these SMET routes.

The context for this question is my understanding that multicast IP traffic 
that is forwarded based on IMET route (e.g., to the PEs that have not 
advertised ability to advertise SMET routes)   does not undergo TTL decrement.

I have failed to find an answer to my question in the text of RFC 9251.

Your timely feedback would be highly appreciated.

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

[bess] rfc9251

[Alexander Vainshtein]

Hi all,
I have a question regarding expected DP behavior in conjunction with RFC 9521: 
Are the PEs that support this RFC expected to decrement TTL in IP headers of 
multicast IP packets they forward?

This question is equally applicable to the "last mile" PEs that have received 
IGMP/MLD Joins and advertised them as SMET routes, and to the "first mile" PEs 
that receive and install these SMET routes.

The context for this question is my understanding that multicast IP traffic 
that is forwarded based on IMET route (e.g., to the PEs that have not 
advertised ability to advertise SMET routes)   does not undergo TTL decrement.

I have failed to find an answer to my question in the text of RFC 9251.

Your timely feedback would be highly appreciated.

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] [Technical Errata Reported] RFC8214 (7837)

[Alexander Vainshtein]

John,
Lots of thanks for the clarification. HFDU seems good enough.

Regards,
Sasha

From: John Scudder 
Sent: Tuesday, March 5, 2024 3:44 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: [Technical Errata Reported] RFC8214 (7837)

Indeed, opinions may vary as to the adjective to apply to “clear” (“crystal” 
vs. “insufficiently” for instance) but the underlying point remains that the 
proposed erratum is an improvement, not a correction of an error, and so isn’t 
a candidate for verification other than as HFDU, per 
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/<https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507>

As a practical matter, HFDU errata show up when errata are viewed on the RFC 
editor website, so it still gets the job done almost as well as a verified 
technical erratum.

—John


On Mar 5, 2024, at 8:34 AM, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:

John,
Speaking just for myself, I can say that the intent was not crystal clear for 
me – may be my personal problem, of course.

I have looked up the latest version of the 7432bis draft, and I see that the 
authors have added the highlighted text in Section 7.11:

[RFC8214<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8214__;!!NEt6yMaO-gk!ECGwEs5ZsZ6uWKijnemlIXH6DEAmp36EwrLJ1NqN1iGDimkHPIeakyGXhiKZ9xzzGHlXATgu569a5VCZNE_0mtmq$>]
 defines and requires this extended community ("L2-Attr"), to be included with 
per-EVI Ethernet A-D routes when multihoming is enabled.
To me this suggests that that the intention probably was not so clear for other 
people as well😊

My 2c,
Sasha

From: John Scudder mailto:j...@juniper.net>>
Sent: Tuesday, March 5, 2024 3:17 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] Re: [Technical Errata Reported] RFC8214 (7837)

This looks like a candidate “hold for document update”. The original document 
doesn’t seem to be in error, the erratum is just suggesting some editorial 
improvements/clarifications. Note that RFC 2119 keywords are not mandatory [*] 
in IETF specifications, what’s important is that the intent is clear, and I 
think the intent is crystal clear with the lowercase “mandatory“.

Unless there’s disagreement, I’ll verify this as HFDU later this week.

—John

[*] see what I did there?

> On Mar 5, 2024, at 5:50 AM, RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>> wrote:
>
>
>
> The following errata report has been submitted for RFC8214,
> "Virtual Private Wire Service Support in Ethernet VPN".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7837__;!!NEt6yMaO-gk!ECfJun-NPxU03B9Sfleq6xIj3IAePWsksETEL7ltxPlKDab3vqjlsXLZwlk3CGcfbqzdDpIW8cKMZwUTyuXDWw$<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7837__;!!NEt6yMaO-gk!ECfJun-NPxU03B9Sfleq6xIj3IAePWsksETEL7ltxPlKDab3vqjlsXLZwlk3CGcfbqzdDpIW8cKMZwUTyuXDWw$>
>
> --
> Type: Technical
> Reported by: Alexander ("Sasha") Vainshtein 
> mailto:alexander.vainsht...@rbbn.com>>
>
> Section: 3.1
>
> Original Text
> -
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes. This attribute is mandatory if multihoming is 
> enabled.
>
> Corrected Text
> --
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes.
>
> If multihoming is enabled, this attribute is MANDATORY regardless of whether 
> the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a 
> "bridging" EVPN instance.
>
>
>
> Notes
> -
> The lower-case "mandatory" used in the original text does not represent any 
> form of requirement in IETF documents, therefore replacing with upper-case 
> "MANDATORY" is needed.
>
> The reference to per-EVI Ethernet A-D routes advertised by both "bridging" 
> EVPN and EVPN-VPWS is needed to remove possible doubts about the scope of 
> this requirement since the standard is about EVPN-VPWS.
>
> 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.
>
> --
> RFC8214 (draft-ietf-bess-evpn-vpws-14)
> --
&g

Re: [bess] [Technical Errata Reported] RFC8214 (7837)

[Alexander Vainshtein]

John,
Speaking just for myself, I can say that the intent was not crystal clear for 
me – may be my personal problem, of course.

I have looked up the latest version of the 7432bis draft, and I see that the 
authors have added the highlighted text in Section 7.11:

[RFC8214] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled.
To me this suggests that that the intention probably was not so clear for other 
people as well😊

My 2c,
Sasha

From: John Scudder 
Sent: Tuesday, March 5, 2024 3:17 PM
To: bess@ietf.org
Subject: [EXTERNAL] Re: [Technical Errata Reported] RFC8214 (7837)

This looks like a candidate “hold for document update”. The original document 
doesn’t seem to be in error, the erratum is just suggesting some editorial 
improvements/clarifications. Note that RFC 2119 keywords are not mandatory [*] 
in IETF specifications, what’s important is that the intent is clear, and I 
think the intent is crystal clear with the lowercase “mandatory“.

Unless there’s disagreement, I’ll verify this as HFDU later this week.

—John

[*] see what I did there?

> On Mar 5, 2024, at 5:50 AM, RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>> wrote:
>
>
>
> The following errata report has been submitted for RFC8214,
> "Virtual Private Wire Service Support in Ethernet VPN".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7837__;!!NEt6yMaO-gk!ECfJun-NPxU03B9Sfleq6xIj3IAePWsksETEL7ltxPlKDab3vqjlsXLZwlk3CGcfbqzdDpIW8cKMZwUTyuXDWw$
>
> --
> Type: Technical
> Reported by: Alexander ("Sasha") Vainshtein 
> mailto:alexander.vainsht...@rbbn.com>>
>
> Section: 3.1
>
> Original Text
> -
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes. This attribute is mandatory if multihoming is 
> enabled.
>
> Corrected Text
> --
> This document defines a new extended community [RFC4360], to be included with 
> per-EVI Ethernet A-D routes.
>
> If multihoming is enabled, this attribute is MANDATORY regardless of whether 
> the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a 
> "bridging" EVPN instance.
>
>
>
> Notes
> -
> The lower-case "mandatory" used in the original text does not represent any 
> form of requirement in IETF documents, therefore replacing with upper-case 
> "MANDATORY" is needed.
>
> The reference to per-EVI Ethernet A-D routes advertised by both "bridging" 
> EVPN and EVPN-VPWS is needed to remove possible doubts about the scope of 
> this requirement since the standard is about EVPN-VPWS.
>
> 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.
>
> --
> RFC8214 (draft-ietf-bess-evpn-vpws-14)
> --
> Title : Virtual Private Wire Service Support in Ethernet VPN
> Publication Date : August 2017
> Author(s) : S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan
> Category : PROPOSED STANDARD
> Source : BGP Enabled ServiceS
> Area : Routing
> Stream : IETF
> Verifying Party : IESG

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] A couple of question about draft-ietf-bess-evpn-ac-aware-bundling

[Alexander Vainshtein]

Hi,
Regarding my Q2:

I have encountered deployments in which an EVPN IRB is configured with multiple 
IP subnets while the single attachment circuit of the broadcast domain it uses 
is delimited by a single VLAN.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Tuesday, February 6, 2024 3:51 PM
To: draft-ietf-bess-evpn-ac-aware-bundl...@ietf.org
Cc: bess@ietf.org
Subject: A couple of question about draft-ietf-bess-evpn-ac-aware-bundling
Importance: High

Hi,
I have a couple of question about the AC-aware bundling 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ac-aware-bundling-04>
 .
The background for these questions is given below.


1.   Section 6.2 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-6.2> that defines 
VLAN Bundle Service Interface says that "MAC addresses MUST be unique across 
all VLANs for that EVI in order for this service to work" .

a.   This requirement is not limited to multihomed PEs

b.   No mechanisms for enforcement of this requirement (e.g., by detecting 
and handling of possible violations) are defined

c.   Any manipulation of VLAN tags is strictly prohibited with this service 
interface

2.   The draft in question defines a similar requirement and effectively 
provides a way to enforce it. However:

a.   Detection of misconfiguration is explicitly limited to just multihomed 
PEs (as can be seen from the title of Section 5)

b.   The draft does not impose any limitations on VLAN manipulation (this 
is expected in the case of inter-subnet traffic (with each subnet 
differentiated by a VLAN) within a single broadcast domain)

c.   The draft seems to deal just with the situation in which multiple 
subnets in the same broadcast domain are differentiated by VLANs.

And now my questions:

Q1: What is the rationale for restricting detection and handling of violation 
of the above-mentioned rule to just multi-homed PEs?
Q2: Does the draft support the situations in which multiple IP subnets in the 
same broadcast domain are NOT differentiated by different VLANs?
Q3: Is VLAN translation with AC-aware bundling service interface allowed for 
intra-subnet traffic that undergoes "pure Layer 2 switching" in the single 
broadcast domain?

Your feedback would be highly appreciated.

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

[bess] A couple of question about draft-ietf-bess-evpn-ac-aware-bundling

[Alexander Vainshtein]

Hi,
I have a couple of question about the AC-aware bundling 
draft
 .
The background for these questions is given below.


  1.  Section 6.2 of RFC 
7432 that defines 
VLAN Bundle Service Interface says that "MAC addresses MUST be unique across 
all VLANs for that EVI in order for this service to work" .
 *   This requirement is not limited to multihomed PEs
 *   No mechanisms for enforcement of this requirement (e.g., by detecting 
and handling of possible violations) are defined
 *   Any manipulation of VLAN tags is strictly prohibited with this service 
interface
  2.  The draft in question defines a similar requirement and effectively 
provides a way to enforce it. However:
 *   Detection of misconfiguration is explicitly limited to just multihomed 
PEs (as can be seen from the title of Section 5)
 *   The draft does not impose any limitations on VLAN manipulation (this 
is expected in the case of inter-subnet traffic (with each subnet 
differentiated by a VLAN) within a single broadcast domain)
 *   The draft seems to deal just with the situation in which multiple 
subnets in the same broadcast domain are differentiated by VLANs.
And now my questions:

Q1: What is the rationale for restricting detection and handling of violation 
of the above-mentioned rule to just multi-homed PEs?
Q2: Does the draft support the situations in which multiple IP subnets in the 
same broadcast domain are NOT differentiated by different VLANs?
Q3: Is VLAN translation with AC-aware bundling service interface allowed for 
intra-subnet traffic that undergoes "pure Layer 2 switching" in the single 
broadcast domain?

Your feedback would be highly appreciated.

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] [Pals] [EXTERNAL] [Technical Errata Reported] RFC7432 (7758)

[Alexander Vainshtein]

Andy,
Lots of thanks for a prompt response.
There seems to be a consensus about the disposition of this Erratum, so I do 
not expect any problems.

Regards,
Sasha

From: Andrew G. Malis 
Sent: Thursday, January 11, 2024 3:04 PM
To: Alexander Vainshtein 
Cc: Pavel Mykhailyk ; RFC Errata System 
; rtg-...@ietf.org; bess@ietf.org; p...@ietf.org
Subject: Re: [Pals] [EXTERNAL] [Technical Errata Reported] RFC7432 (7758)

Sasha,

Andrew will take care of it.

Cheers,
Andy


On Thu, Jan 11, 2024 at 5:37 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Pavel,
Lots of thanks for your email.
Looks as we are aligned😊. I am not sure if the reporter of an Erratum can 
revoke it (never tried this).


Regards,
Sasha

From: Pavel Mykhailyk 
mailto:pavel.mykhai...@gmail.com>>
Sent: Thursday, January 11, 2024 12:33 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; 
p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

Hi
Sorry, looks like i just misunderstood some terms, so ES route means EVPN Type 
4 (not 1) -  you are absolutely right, it is used for DF and limited to PEs 
that are connected to MH Po.

Thanks for clarification
With Regards

чт, 11 янв. 2024 г. в 11:56, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>:
Hi all,

IMHO and FWIW the corrected text proposed in this Erratum is technically 
incorrect, and. Therefore, the Erratum must be rejected.

Ethernet Segment (EVPN Type 4) routes are used solely for discovery of all PEs 
that participate in the process of election of the Designated Forwarder (DF)for 
the specific MH ES, and their parameters that affect the election process 
(e.g., DF Election algorithm and its parameters).  This includes all the PEs 
that are attached to the MH ES in question, and none other.

The PEs that are not attached to the MH ES in question do not participate in 
the DF election and, by design, are not aware of the DF election results.
In the case of All-Active multi-homing, there is no need for such PEs to be 
aware of these results.
The case of Single-Active multi-homing is addressed by the following statement 
from Section 8.4 of RFC 7432 (the relevant text is highlighted):

   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the advertised MAC address to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.

AFAIK, EVPN implementation that follow the design defined in 7432 have been 
widely deployed for years.

My 2c,
Sasha

From: Pals mailto:pals-boun...@ietf.org>> On Behalf Of 
RFC Errata System
Sent: Thursday, January 11, 2024 10:03 AM
To: saja...@cisco.com<mailto:saja...@cisco.com>; 
raggarw...@yahoo.com<mailto:raggarw...@yahoo.com>; 
nabil.n.bi...@verizon.com<mailto:nabil.n.bi...@verizon.com>; 
aisaa...@bloomberg.net<mailto:aisaa...@bloomberg.net>; 
utt...@att.com<mailto:utt...@att.com>; 
jdr...@juniper.net<mailto:jdr...@juniper.net>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
j...@juniper.net<mailto:j...@juniper.net>; 
andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>; 
gihe...@cisco.com<mailto:gihe...@cisco.com>; 
nabil.n.bi...@verizon.com<mailto:nabil.n.bi...@verizon.com>
Cc: pavel.mykhai...@gmail.com<mailto:pavel.mykhai...@gmail.com>; 
p...@ietf.org<mailto:p...@ietf.org>; 
rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>
Subject: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

The following errata report has been submitted for RFC7432,
"BGP MPLS-Based Ethernet VPN".

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

--
Type: Technical
Reported by: Pavel Mykhailyk 
mailto:pavel.mykhai...@gmail.com>>

Section: 8.1.1

Original Text
-
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
multihomed to the same Ethernet segment

Corrected Text
--
The Ethernet Segment rout

Re: [bess] [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

[Alexander Vainshtein]

Pavel,
Lots of thanks for your email.
Looks as we are aligned😊. I am not sure if the reporter of an Erratum can 
revoke it (never tried this).


Regards,
Sasha

From: Pavel Mykhailyk 
Sent: Thursday, January 11, 2024 12:33 PM
To: Alexander Vainshtein 
Cc: RFC Errata System ; rtg-...@ietf.org; 
bess@ietf.org; p...@ietf.org
Subject: Re: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

Hi
Sorry, looks like i just misunderstood some terms, so ES route means EVPN Type 
4 (not 1) -  you are absolutely right, it is used for DF and limited to PEs 
that are connected to MH Po.

Thanks for clarification
With Regards

чт, 11 янв. 2024 г. в 11:56, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>:
Hi all,

IMHO and FWIW the corrected text proposed in this Erratum is technically 
incorrect, and. Therefore, the Erratum must be rejected.

Ethernet Segment (EVPN Type 4) routes are used solely for discovery of all PEs 
that participate in the process of election of the Designated Forwarder (DF)for 
the specific MH ES, and their parameters that affect the election process 
(e.g., DF Election algorithm and its parameters).  This includes all the PEs 
that are attached to the MH ES in question, and none other.

The PEs that are not attached to the MH ES in question do not participate in 
the DF election and, by design, are not aware of the DF election results.
In the case of All-Active multi-homing, there is no need for such PEs to be 
aware of these results.
The case of Single-Active multi-homing is addressed by the following statement 
from Section 8.4 of RFC 7432 (the relevant text is highlighted):

   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the advertised MAC address to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.

AFAIK, EVPN implementation that follow the design defined in 7432 have been 
widely deployed for years.

My 2c,
Sasha

From: Pals mailto:pals-boun...@ietf.org>> On Behalf Of 
RFC Errata System
Sent: Thursday, January 11, 2024 10:03 AM
To: saja...@cisco.com<mailto:saja...@cisco.com>; 
raggarw...@yahoo.com<mailto:raggarw...@yahoo.com>; 
nabil.n.bi...@verizon.com<mailto:nabil.n.bi...@verizon.com>; 
aisaa...@bloomberg.net<mailto:aisaa...@bloomberg.net>; 
utt...@att.com<mailto:utt...@att.com>; 
jdr...@juniper.net<mailto:jdr...@juniper.net>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
j...@juniper.net<mailto:j...@juniper.net>; 
andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>; 
gihe...@cisco.com<mailto:gihe...@cisco.com>; 
nabil.n.bi...@verizon.com<mailto:nabil.n.bi...@verizon.com>
Cc: pavel.mykhai...@gmail.com<mailto:pavel.mykhai...@gmail.com>; 
p...@ietf.org<mailto:p...@ietf.org>; 
rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>
Subject: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

The following errata report has been submitted for RFC7432,
"BGP MPLS-Based Ethernet VPN".

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

--
Type: Technical
Reported by: Pavel Mykhailyk 
mailto:pavel.mykhai...@gmail.com>>

Section: 8.1.1

Original Text
-
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
multihomed to the same Ethernet segment

Corrected Text
--
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
connected to same EVI

Notes
-
In all text in context of evpn-multihoming term ES used for logical set of 
links - distributed PortChannel when CE use several links to different PEs as 
single aggregate link. But in section 8.1.1 term ES can't be used in same way, 
becouse ES routes must be distributed for all PE that hold same VLAN. For 
example PE1 and PE2 connected to CE1 with EVPN-MH PortChannel (ESI-1) and use 
VLAN 10, CE2 connected to PE3 and use VLAN 10 but not use any aggregation - not 
included to any ES. PE3 build mac table for CE1 mac and must use ESI-1 as 
next-hop, so it must apply ES route and not filter it, regardles of local 
connection to ES in terms of EVP

Re: [bess] [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

[Alexander Vainshtein]

Hi all,

IMHO and FWIW the corrected text proposed in this Erratum is technically 
incorrect, and. Therefore, the Erratum must be rejected.

Ethernet Segment (EVPN Type 4) routes are used solely for discovery of all PEs 
that participate in the process of election of the Designated Forwarder (DF)for 
the specific MH ES, and their parameters that affect the election process 
(e.g., DF Election algorithm and its parameters).  This includes all the PEs 
that are attached to the MH ES in question, and none other.

The PEs that are not attached to the MH ES in question do not participate in 
the DF election and, by design, are not aware of the DF election results.
In the case of All-Active multi-homing, there is no need for such PEs to be 
aware of these results.
The case of Single-Active multi-homing is addressed by the following statement 
from Section 8.4 of RFC 7432 (the relevant text is highlighted):

   The backup path is a closely related function, but it is used in
   Single-Active redundancy mode.  In this case, a PE also advertises
   that it has reachability to a given EVI/ES using the same combination
   of Ethernet A-D per EVI route and Ethernet A-D per ES route as
   discussed above, but with the "Single-Active" bit in the flags of the
   ESI Label extended community set to 1.  A remote PE that receives a
   MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
   the advertised MAC address to be reachable via any PE that has
   advertised this combination of Ethernet A-D routes, and it SHOULD
   install a backup path for that MAC address.

AFAIK, EVPN implementation that follow the design defined in 7432 have been 
widely deployed for years.

My 2c,
Sasha

From: Pals  On Behalf Of RFC Errata System
Sent: Thursday, January 11, 2024 10:03 AM
To: saja...@cisco.com; raggarw...@yahoo.com; nabil.n.bi...@verizon.com; 
aisaa...@bloomberg.net; utt...@att.com; jdr...@juniper.net; 
wim.henderi...@alcatel-lucent.com; aretana.i...@gmail.com; j...@juniper.net; 
andrew-i...@liquid.tech; gihe...@cisco.com; nabil.n.bi...@verizon.com
Cc: pavel.mykhai...@gmail.com; p...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758)

The following errata report has been submitted for RFC7432,
"BGP MPLS-Based Ethernet VPN".

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

--
Type: Technical
Reported by: Pavel Mykhailyk 
mailto:pavel.mykhai...@gmail.com>>

Section: 8.1.1

Original Text
-
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
multihomed to the same Ethernet segment

Corrected Text
--
The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are
connected to same EVI

Notes
-
In all text in context of evpn-multihoming term ES used for logical set of 
links - distributed PortChannel when CE use several links to different PEs as 
single aggregate link. But in section 8.1.1 term ES can't be used in same way, 
becouse ES routes must be distributed for all PE that hold same VLAN. For 
example PE1 and PE2 connected to CE1 with EVPN-MH PortChannel (ESI-1) and use 
VLAN 10, CE2 connected to PE3 and use VLAN 10 but not use any aggregation - not 
included to any ES. PE3 build mac table for CE1 mac and must use ESI-1 as 
next-hop, so it must apply ES route and not filter it, regardles of local 
connection to ES in terms of EVPN-MH PortChannel. So each PE connected to EVI 
import this route

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.

--
RFC7432 (draft-ietf-l2vpn-evpn-11)
--
Title : BGP MPLS-Based Ethernet VPN
Publication Date : February 2015
Author(s) : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. 
Drake, W. Henderickx
Category : PROPOSED STANDARD
Source : Layer 2 Virtual Private Networks
Area : Routing
Stream : IETF
Verifying Party : IESG

___
Pals mailing list
p...@ietf.org
https://www.ietf.org/mailman/listinfo/pals

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

[bess] draft-ietf-bess-evpn-modes-interop

[Alexander Vainshtein]

Hi all,
I have a few questions regarding the expired EVPN Interoperability 
Modes
 draft.


  1.  Do the authors plan to refresh the expired WG draft? Please note that:
 *   It has been expired for ~4 months already
 *   It does not appear as a goal in the list of WG goals?
  2.  Assuming that the draft is not abandoned, what is its intended status? I 
am asking that because:
 *   The draft itself states that its intended status is Informational
 *   At the same time, the draft clearly defines some changes in the 
standard-defined procedures, e.g.:

   i.  Section 
3.1.1 states that an EVI that implements VLAN-aware VLAN bundles service 
interface and contains a single BD must "allow to send and receive zero 
EtherTag". This contradicts the definitions in Section 6.3 of RFC 
7432

 ii.  Section 
3.2 states that an EVI that implements VLAN-based service interface "MUST allow 
receiving of non-zero EtherTag". This contradicts the definitions in Section 
6.1 of RFC 7432.

I also have to admit that I do not understand why an EVI with a single BD 
should ever be considered as implementing VLAN-aware Bundle Service Interface.

Your feedback will be highly appreciated.

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

[bess] A question about draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Hi all,
I would appreciate an answer to my question about a certain aspect of Section 
8.2.1 of the 7432-bis 
draft
 that discusses construction of the per-ES Ethernet A-D (EVPN Type 1) route.

  1.  This section says that "The ESI Label extended community MUST be included 
in the route".
  2.  It also says (in Section 8.2.1.1) that "The set of Ethernet A-D routes 
per ES MUST carry the entire set of RTs for all the EVPN instances to which the 
Ethernet segment belongs".  (The need to advertise a set of per-ES Ethernet A-D 
(EVPN Type 1) routes for a given MH ES (rather than a single such route pe ES) 
presumably arises when the number of Route Targets to be advertised for this MH 
ES exceeds the common limit on the size of the BGP UPDATE message or an 
implementation-specific on the number of Extended Communities that can be 
carried in a single UPDATE message).

I would like to understand, whether, in the case when multiple per-ES Ethernet 
A-D routes are advertised for the same MH ES, the ECI Label Extended Community 
MUST be attached to each of these routes.  IMHO and FWIW #1 above suggest that, 
but an explicit statement would be most helpful.

I also assume that, if the ECI Label Extended Community is attached to all the 
per-ES Ethernet A-D routes in the set, it MUST carry the same flags and the 
same Label value - is this correct? If yes, could this be explicitly specified 
in the draft?

Your feedback would be highly appreciated.

Regards, lots of thanks in advance, and best New Year wishes,
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] A question about Section 4.4.1 of RFC 9136

[Alexander Vainshtein]

Jorge,
Again, lots of thanks for your email!

It really helps to resolve some serious concerns!

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Friday, December 22, 2023 9:19 PM
To: Alexander Vainshtein ; Wim Henderickx 
(Nokia) ; w...@juniper.net; John E Drake 
; Ali Sajassi (sajassi) 

Cc: bess@ietf.org
Subject: [EXTERNAL] Re: A question about Section 4.4.1 of RFC 9136

Hi Sasha,

About your questions:


1.  Yes, DGW1/DGW2 could use the RD of the IP-VRF if they advertise a prefix 
for H1. Note that the DGW could also genera a default route, etc.

2.  DGW1 and DGW2 decide if they advertise host routes for those hosts in IP 
Prefix routes, or local subnets, etc. Same as you would do with the VPN-IP 
families in an IP-VRF.. not sure why you would do anything different

My two cents.

Thanks.
Jorge


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, December 11, 2023 at 4:43 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Wim Henderickx 
(Nokia) mailto:wim.henderi...@nokia.com>>, 
w...@juniper.net<mailto:w...@juniper.net> 
mailto:w...@juniper.net>>, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>,
 Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: A question about Section 4.4.1 of RFC 9136

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 all,
I have a couple of questions about usage of EVPN Type 5 routes (a.k.a. RT-5) in 
the Interface-less IP-VRF-to-IP-VRF model described in Section 4.4.1 of RFC 
9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.1>.

I am copying the diagram shown in Figure 8 in this section for convenience.

   NVE1(M1)
  ++
  IP1+|  (BD-1)|DGW1(M3)
  |  \ |+-+ ++
  |(IP-VRF)|| |-|(IP-VRF)|+
  |  / || | ++|
  +---|  (BD-2)|| |  _+_
  |   ++| | (   )
   SN1| |  VXLAN/ |( WAN )--H1
  |NVE2(M2) |  GENEVE/| (___)
  |   ++|  MPLS   |   +
  +---|  (BD-2)|| | DGW2(M4)  |
  |   \|| | ++|
  |(IP-VRF)|| |-|(IP-VRF)|+
  |   /|+-+ ++
  SN2+|  (BD-3)|
  ++



As you can see, this model does not show any Broadcast Domains (BD) or IRB 
interfaces in IP-VRFs residing in DGW1/DGW2.
The text that follows the diagram explains how prefixes representing SN1 and 
SN2 are advertised by NVE1 and NVE2 as RT-5 and accepted by IP-VRFs in DGW1 and 
DGW2.
Therefore, traffic generated by H1 can reach the destinations in subnets SN1 
and SN2.


1.   Do I understand correctly that IP-VRFs in DGW1/DGW2 advertise RT-5 to 
some destination that cover H1? If yes are the RDs in the NLRI of these routes 
are the RDs of the advertising IP-VRFs?

2.   Suppose that some hosts (say, H11 and H22) are locally connected to 
the IP-VRF in DGW1 and DGW2 respectively - without any BDs and IRB interfaces 
in these devices as shown below. Will DGW1 and DGW2 advertise RT-5 that cover 
these destinations?


  H11
   NVE1(M1)+
  ++   |
  IP1+|  (BD-1)|   DGW1(M3)|
  |  \ |+-+ ++
  |(IP-VRF)|| |-|(IP-VRF)|+
  |  / || | ++|
  +---|  (BD-2)|| |  _+_
  |   ++| | (   )
   SN1| |  VXLAN/ |( WAN )--H1
  |NVE2(M2) |  GENEVE/| (___)
  |   ++|  MPLS   |   +
  +---|  (BD-2)|| | DGW2(M4)  |
  |   \|| | ++|
  |(IP-VRF)|| |-|(IP-VRF)|+
  |   /|+-+ ++
  SN2+|  (BD-3)||
  ++|
   +
   H22




Your timely feedback will be highly appreciated.

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 wi

Re: [bess] A minor contradiction between RFC 9135 and RFC 9136?

[Alexander Vainshtein]

Jorge,
Lots of thanks for your email. It really helps.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Friday, December 22, 2023 9:19 PM
To: Alexander Vainshtein ; Wim Henderickx 
(Nokia) ; Ali Sajassi (sajassi) 
; John E Drake 
; w...@juniper.net; ssa...@cisco.com; 
stho...@cisco.com
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: A minor contradiction between RFC 9135 and RFC 9136?

Hi Sasha,

In your case, the route type 5 would use the RD of the IP-VRF. I don't think 
any implementation would do anything different.

RFC9136 says the RD has to be used in the same way it is defined in RFC7432, 
but the text refers to the recommendation of using a type 1 RD and its 
uniqueness, in fact the spec says that you take the RD from a mac-vrf or an 
ip-vrf. This could have been explicitly written, but I don't think it creates 
any interop issue at all. We've been testing this across vendors for quite some 
time now, and I don't see issues.

RFC9136 allows using the RD of a mac-vrf in a few cases where the there is no 
ip-vrf and a route type 5 is generated, but in the ip-vrf-to-ip-vrf cases you 
would use the RD of the IP-VRF.

My 2 cents.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, December 10, 2023 at 2:39 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Wim Henderickx 
(Nokia) mailto:wim.henderi...@nokia.com>>, Ali 
Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>,
 John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>,
 w...@juniper.net<mailto:w...@juniper.net> 
mailto:w...@juniper.net>>, 
ssa...@cisco.com<mailto:ssa...@cisco.com> 
mailto:ssa...@cisco.com>>, 
stho...@cisco.com<mailto:stho...@cisco.com> 
mailto:stho...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: A minor contradiction between RFC 9135 and RFC 9136?

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 all,
A gentle reminder...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:22 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>; Ali Sajassi 
(sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>;
 John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>;
 w...@juniper.net<mailto:w...@juniper.net>; 
ssa...@cisco.com<mailto:ssa...@cisco.com>; 
stho...@cisco.com<mailto:stho...@cisco.com>
Subject: FW: A minor contradiction between RFC 9135 and RFC 9136?

Hi all,
The email expansions for the authors of RFC 9135 and RFC 9136 do not work 
anymore.
Therefore, I forward my email to you individually.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:08 PM
To: 
draft-ietf-bess-evpn-prefix-advertisem...@ietf.org<mailto:draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>;
 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: A minor contradiction between RFC 9135 and RFC 9136?
Importance: High

Hi all,
I see what looks to me as a contradiction between Section 9.1.1 of RFC 
9315<https://datatracker.ietf.org/doc/html/rfc9135#section-9.1.1> and Section 
4.4.1 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.1>:


The former:

Defines a Symmetric IRB as an interface connecting an IP-VRF to an EVPN 
Broadcast Domain (a MAC-VRF or a specific BBD within a MAC-VRF that implements 
VLAN-Aware service interface)

Describes an IP Prefix (EVPN Type 5, a.k.a. RT-5) route advertised for the 
subnet of a Symmetric EVPN IRB and states that RD in the NLRI of this route is 
the RD of IP-VRF that contains that the IRB in question

The latter describes the Interface-less IP-VRF to IP-VRF model:

To the best of my understanding, this model deals with just Symmetric IRBs

The RFC states that the NVE/DGW will, for each of its prefixes, advertise an 
RT-5 with RD in its NLRI as defined in RFC 
7432<https://www.rfc-editor.org/rfc/rfc7432.html>. Since RFC 7432 does not 
refer to IP-VRFs at all, this strongly suggests to me that it means RD of a 
MAC-VRF .

The following diagram shows why this difference may be meaningful:

[cid:image001.png@01DA3651.693E1C60]
In this diagram PE-1, PE-2 and PE-3 can only exchange L2VPN/EVPN routes but not 
VPN-IP routes.
Suppose that IP-VRF in PE-1 and PE-2 are configured with a static route to SN-. 
In this case:

PE-1 and PE-2 can advertise RT-5 for SN-1 using either RDs of IP-VRFs or RDs of 
MAC-VRF

If RT-5 uses RDs of containing IP-VRF, bi-directional connectivity between 
devices in SN-1 and SN-2 can be established

If RT-5 uses RDs of MAC-VRF in its NLRI, PE-

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

[Alexander Vainshtein]

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

[bess] A question about Section 4.4.1 of RFC 9136

[Alexander Vainshtein]

Hi all,
I have a couple of questions about usage of EVPN Type 5 routes (a.k.a. RT-5) in 
the Interface-less IP-VRF-to-IP-VRF model described in Section 4.4.1 of RFC 
9136.

I am copying the diagram shown in Figure 8 in this section for convenience.

   NVE1(M1)
  ++
  IP1+|  (BD-1)|DGW1(M3)
  |  \ |+-+ ++
  |(IP-VRF)|| |-|(IP-VRF)|+
  |  / || | ++|
  +---|  (BD-2)|| |  _+_
  |   ++| | (   )
   SN1| |  VXLAN/ |( WAN )--H1
  |NVE2(M2) |  GENEVE/| (___)
  |   ++|  MPLS   |   +
  +---|  (BD-2)|| | DGW2(M4)  |
  |   \|| | ++|
  |(IP-VRF)|| |-|(IP-VRF)|+
  |   /|+-+ ++
  SN2+|  (BD-3)|
  ++



As you can see, this model does not show any Broadcast Domains (BD) or IRB 
interfaces in IP-VRFs residing in DGW1/DGW2.
The text that follows the diagram explains how prefixes representing SN1 and 
SN2 are advertised by NVE1 and NVE2 as RT-5 and accepted by IP-VRFs in DGW1 and 
DGW2.
Therefore, traffic generated by H1 can reach the destinations in subnets SN1 
and SN2.


  1.  Do I understand correctly that IP-VRFs in DGW1/DGW2 advertise RT-5 to 
some destination that cover H1? If yes are the RDs in the NLRI of these routes 
are the RDs of the advertising IP-VRFs?
  2.  Suppose that some hosts (say, H11 and H22) are locally connected to the 
IP-VRF in DGW1 and DGW2 respectively - without any BDs and IRB interfaces in 
these devices as shown below. Will DGW1 and DGW2 advertise RT-5 that cover 
these destinations?


  H11
   NVE1(M1)+
  ++   |
  IP1+|  (BD-1)|   DGW1(M3)|
  |  \ |+-+ ++
  |(IP-VRF)|| |-|(IP-VRF)|+
  |  / || | ++|
  +---|  (BD-2)|| |  _+_
  |   ++| | (   )
   SN1| |  VXLAN/ |( WAN )--H1
  |NVE2(M2) |  GENEVE/| (___)
  |   ++|  MPLS   |   +
  +---|  (BD-2)|| | DGW2(M4)  |
  |   \|| | ++|
  |(IP-VRF)|| |-|(IP-VRF)|+
  |   /|+-+ ++
  SN2+|  (BD-3)||
  ++|
   +
   H22




Your timely feedback will be highly appreciated.

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] A minor contradiction between RFC 9135 and RFC 9136?

[Alexander Vainshtein]

Hi all,
A gentle reminder...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:22 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) ; 
wim.henderi...@nokia.com; Ali Sajassi (sajassi) 
; John E Drake 
; w...@juniper.net; ssa...@cisco.com; 
stho...@cisco.com
Subject: FW: A minor contradiction between RFC 9135 and RFC 9136?

Hi all,
The email expansions for the authors of RFC 9135 and RFC 9136 do not work 
anymore.
Therefore, I forward my email to you individually.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:08 PM
To: 
draft-ietf-bess-evpn-prefix-advertisem...@ietf.org<mailto:draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>;
 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: A minor contradiction between RFC 9135 and RFC 9136?
Importance: High

Hi all,
I see what looks to me as a contradiction between Section 9.1.1 of RFC 
9315<https://datatracker.ietf.org/doc/html/rfc9135#section-9.1.1> and Section 
4.4.1 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.1>:


1.   The former:

a.   Defines a Symmetric IRB as an interface connecting an IP-VRF to an 
EVPN Broadcast Domain (a MAC-VRF or a specific BBD within a MAC-VRF that 
implements VLAN-Aware service interface)

b.   Describes an IP Prefix (EVPN Type 5, a.k.a. RT-5) route advertised for 
the subnet of a Symmetric EVPN IRB and states that RD in the NLRI of this route 
is the RD of IP-VRF that contains that the IRB in question

2.   The latter describes the Interface-less IP-VRF to IP-VRF model:

a.   To the best of my understanding, this model deals with just Symmetric 
IRBs

b.   The RFC states that the NVE/DGW will, for each of its prefixes, 
advertise an RT-5 with RD in its NLRI as defined in RFC 
7432<https://www.rfc-editor.org/rfc/rfc7432.html>. Since RFC 7432 does not 
refer to IP-VRFs at all, this strongly suggests to me that it means RD of a 
MAC-VRF .

The following diagram shows why this difference may be meaningful:

[cid:image001.png@01DA2B65.E342FB80]
In this diagram PE-1, PE-2 and PE-3 can only exchange L2VPN/EVPN routes but not 
VPN-IP routes.
Suppose that IP-VRF in PE-1 and PE-2 are configured with a static route to SN-. 
In this case:

-  PE-1 and PE-2 can advertise RT-5 for SN-1 using either RDs of 
IP-VRFs or RDs of MAC-VRF

-  If RT-5 uses RDs of containing IP-VRF, bi-directional connectivity 
between devices in SN-1 and SN-2 can be established

-  If RT-5 uses RDs of MAC-VRF in its NLRI, PE-3 cannot advertise RT-5 
for SN-2 because there is no MAC-VRF in this PE.


What, if anything,  do I miss?

Your timely feedback would be highly appreciated.

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] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Alexander Vainshtein]

Jeffrey and all,
I support adoption of this draft.

I am neither an author nor a contributor. 

Regards,
Sasha

-Original Message-
From: Jeffrey (Zhaohui) Zhang  
Sent: Monday, November 13, 2023 1:51 PM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' ; 
draft-sajassi-bess-evpn-ip-alias...@ietf.org
Subject: [bess] 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

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] The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft

[Alexander Vainshtein]

Luc,
Lots of thanks for a prompt response. It seems that we are actually in sync 
regarding the traffic that would use ERL.

IMHO and FWIW an explicit statement that "BUM is not in-scope of the draft, it 
is not redirected" would help the readers. It would also help to clarify that 
bypassing DF Election behavior is not relevant for All-Active and Single 
Flow-Active redundancy modes.

Regarding Port-Active redundancy mode:

  1.  Section 3.2 of Port-Active Multi-Homing  
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-09#section-3.2>
 states that "Non-DF routers SHOULD implement a bidirectional blocking scheme 
for all traffic".  To me bidirectional blocking means that traffic is neither 
received nor transmitted via the non-DF link - can you please clarify how 
bypassing DF Election procedures can help with his?
  2.  Section 5.1 of the EVPN FRR draft says that "to support EVPN Fast 
Reroute, the CE must be able to receive traffic from an OOS LAG link ".
 *   This is a requirement for the CE which is not aware of EVPN r 
multi-homing
 *   Can you please clarify if this is aligned with IEEE 802.1AX-2014?

Regards,
Sasha




Regards,
Sasha

From: Luc Andre Burdet (lburdet) 
Sent: Thursday, November 9, 2023 6:00 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: The significance of bypassing DF Election Behavior in 
the EVPN Fast Reroute draft

Hi Sasha,

BUM is not in-scope of the draft, it is not redirected;

The Fast-Reroute draft describes 2 behaviours, terminal disposition and 
NDF-bypass. The mechanism is agnostic to the load-balancing mode: one, the 
other, or both behaviours may be applicable. You are right, in A/A the 
"NDF-bypass" is not applicable for ERL

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com<mailto:lbur...@cisco.com>  |  Tel: +1 
613 254 4814


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, November 9, 2023 at 10:41
To: Luc Andre Burdet (lburdet) mailto:lbur...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: The significance of bypassing DF Election Behavior in the EVPN Fast 
Reroute draft
Luc and 
all,https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1<https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1>
I have a question regarding significance of bypassing DF Election behavior in 
Section 5.1 of the EVPN Fast Reroute draft, at least in the case of All-Active 
multi-homing and EVPN-MPLS.

To the best of my understanding, in this case DF Election based filtering is 
applied only to BUM traffic. Per Section 11.2 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-11.2> this traffic 
is carried using the label advertised in the PMSI attribute in the EVPN IMET 
route so that DF Election-based filtering can be applied only to the traffic 
received with this label:

·   In the case of ingress replication, this label is down-stream allocated 
by the egress PE and therefore would be different from the ERL label

·   In the case of P-multicast trees, this label would be 
upstream-allocated by the ingress PE and, in the case of non-aggregated 
tunnels, preceded by the label that identifies the P-multicast tree. (I am 
leaving aside the case of aggregated P-multicast trees).
I.e., in both cases, the egress PE can identify the received BUM traffic based 
on the label stack in its EVPN encapsulation and apply DF-Election-based 
filtering just to this traffic - but not to traffic received with the ESL or 
ERL labels.

What, if anything, do 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] [EXTERNAL] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

[Alexander Vainshtein]

Christian and all,
++ Adrian.
Please note that Path Trace ID mismatch in SONET/SDH and OTN is a data plane 
feature:

  *   The configured Tx Trace Identifier string is carried in the corresponding 
overhead
  *   The SONET/SDH/OTN framers are configured with both the Expected Rx Trace 
Identifier and a flag enabling its check.

Endpoint-ID in the draft is a pure control plane feature so that, in any case, 
it would not be able to detect inconsistencies between control plane and data 
plane (a.k.a. misconnection).
This can be done using, say, LSP Ping for the appropriate FEC (FEC-128 or 
FEC-129) as defined in RFC 8029<https://datatracker.ietf.org/doc/html/rfc8029>.

Please also note that in GMPLS-controlled OTN networks Path Trace Identifier is 
used for auto-detection of data plane connectivity between the GMPLS actors. In 
this case the Path Trace ID check is disabled – Adrian, can you please comment?

Regards,
Sasha

From: Christian Schmutzer (cschmutz) 
Sent: Thursday, November 9, 2023 6:23 PM
To: Alexander Vainshtein 
Cc: Christian Schmutzer (cschmutz) ; Andrew G. Malis 
; p...@ietf.org; bess@ietf.org; Stewart Bryant 

Subject: Re: [EXTERNAL] Endpoint-ID in draft 
https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Hi Alexander and Andy,

Yes, very useful comments indeed !

Totally agree  in case a “misconnection” is detected a downstream fault 
indication signal such as AIS or LF must be inserted, I meant to cover that but 
it somehow slipped through the cracks so far. Btw I would further propose to 
follow SDH/OTN where this is conditional on local configuration. SDH calls this 
TIMAISdis and OTN calls it TIMActDis.

I will think about proper text to be inserted in 
https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2>
 as well as draft-schmutzer-pals-ple-signaling and 
draft-schmutzer-bess-bitstream-vpws-signalling in furture revisions.

On the topic of FEC-129 vs Endpoint-ID, I need some time to refresh my memory 
on FEC-129 and think about how all of this would tie back to meeting the user 
expectations … I will come back to this thread in the future

Cheers
Christian

On 09.11.2023, at 15:59, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:

Andrew hi!
Very glad to hear from you!

I have looked up Section 7 of RFC 
4842<https://datatracker.ietf.org/doc/html/rfc4842#section-7>, and I fully 
agree that the draft should define equivalent behavior (where applicable) for 
both Private Line to PSN and PSN to Private Line directions.

These actions are probably specific to each PLE type.

In any case, the draft does not define any action on Endpoint-ID mismatch. My 
guess is that PW setup should fail in this case – Christian, can you please 
comment? (This would happen automatically if FEC-129 were used and mismatch 
between SAII and TAII occurs).

If my guess is correct then Section 7.2.2 of the PLE 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2>
 requires that “the CE-bound NSP function MUST inject the appropriate native 
downstream fault indication signal”  because failure to set up the PW means 
that  the PW is not operationally UP.

Regards,
Sasha

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Thursday, November 9, 2023 4:35 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>>; 
p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; 
Stewart Bryant mailto:stewart.bry...@gmail.com>>
Subject: [EXTERNAL] Re: Endpoint-ID in draft 
https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00<https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00>

Christian and Sasha,

Section 7 of RFC 4842 discusses the actions taken when you have trace mismatch 
conditions as well as other SONET/SDH-layer failures. Perhaps this text should 
be adapted to draft-ietf-pals-ple as well.

Cheers,
Andy


On Thu, Nov 9, 2023 at 8:34 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Christian and all,
Repeating the gist of my comments on the PLE Signaling 
draft<https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00>
 at the MPLS WG session in Prague today.

I think that Endpoint-ID defined in Section 5.5. of this draft is not needed.

If you want the endpoints of a PLE to be aware of the remote AC, you can use 
the generalized PWId 
FEC<https://datatracker.ietf.org/doc/html/rfc8077#section-6.2> a.k.a. FEC-129) 
for this purpose.

I also think that your reference to Path Trace Identifier in OTN is not really 
accurate:

1.   This construct has been already defined for SONET and SDH

2.   Mismatch of Path Trace Identifier, if enabled, results in killing he 
traffic (generat

Re: [bess] [EXTERNAL] Re: Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

[Alexander Vainshtein]

Andrew hi!
Very glad to hear from you!

I have looked up Section 7 of RFC 
4842<https://datatracker.ietf.org/doc/html/rfc4842#section-7>, and I fully 
agree that the draft should define equivalent behavior (where applicable) for 
both Private Line to PSN and PSN to Private Line directions.

These actions are probably specific to each PLE type.

In any case, the draft does not define any action on Endpoint-ID mismatch. My 
guess is that PW setup should fail in this case – Christian, can you please 
comment? (This would happen automatically if FEC-129 were used and mismatch 
between SAII and TAII occurs).

If my guess is correct then Section 7.2.2 of the PLE 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-01#section-7.2.2>
 requires that “the CE-bound NSP function MUST inject the appropriate native 
downstream fault indication signal”  because failure to set up the PW means 
that  the PW is not operationally UP.

Regards,
Sasha

From: Andrew G. Malis 
Sent: Thursday, November 9, 2023 4:35 PM
To: Alexander Vainshtein 
Cc: Christian Schmutzer (cschmutz) ; p...@ietf.org; 
bess@ietf.org; Stewart Bryant 
Subject: [EXTERNAL] Re: Endpoint-ID in draft 
https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Christian and Sasha,

Section 7 of RFC 4842 discusses the actions taken when you have trace mismatch 
conditions as well as other SONET/SDH-layer failures. Perhaps this text should 
be adapted to draft-ietf-pals-ple as well.

Cheers,
Andy


On Thu, Nov 9, 2023 at 8:34 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Christian and all,
Repeating the gist of my comments on the PLE Signaling 
draft<https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00>
 at the MPLS WG session in Prague today.

I think that Endpoint-ID defined in Section 5.5. of this draft is not needed.

If you want the endpoints of a PLE to be aware of the remote AC, you can use 
the generalized PWId 
FEC<https://datatracker.ietf.org/doc/html/rfc8077#section-6.2> a.k.a. FEC-129) 
for this purpose.

I also think that your reference to Path Trace Identifier in OTN is not really 
accurate:

1.   This construct has been already defined for SONET and SDH

2.   Mismatch of Path Trace Identifier, if enabled, results in killing he 
traffic (generation of downstream AIS) in both SONET/SDH and OTN.

a.   I have not found any action on mismatch of Endpoint-IDs in the draft

b.   Mismatch of AII in FEC-129 would result in failure to establish a PW.

Hopefully these notes will be useful.


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

[bess] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

[Alexander Vainshtein]

Christian and all,
Repeating the gist of my comments on the PLE Signaling 
draft
 at the MPLS WG session in Prague today.

I think that Endpoint-ID defined in Section 5.5. of this draft is not needed.

If you want the endpoints of a PLE to be aware of the remote AC, you can use 
the generalized PWId 
FEC a.k.a. FEC-129) 
for this purpose.

I also think that your reference to Path Trace Identifier in OTN is not really 
accurate:

  1.  This construct has been already defined for SONET and SDH
  2.  Mismatch of Path Trace Identifier, if enabled, results in killing he 
traffic (generation of downstream AIS) in both SONET/SDH and OTN.
 *   I have not found any action on mismatch of Endpoint-IDs in the draft
 *   Mismatch of AII in FEC-129 would result in failure to establish a PW.

Hopefully these notes will be useful.


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

[bess] The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft

[Alexander Vainshtein]

Luc and 
all,https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1
I have a question regarding significance of bypassing DF Election behavior in 
Section 5.1 of the EVPN Fast Reroute draft, at least in the case of All-Active 
multi-homing and EVPN-MPLS.

To the best of my understanding, in this case DF Election based filtering is 
applied only to BUM traffic. Per Section 11.2 of RFC 
7432 this traffic 
is carried using the label advertised in the PMSI attribute in the EVPN IMET 
route so that DF Election-based filtering can be applied only to the traffic 
received with this label:

  *   In the case of ingress replication, this label is down-stream allocated 
by the egress PE and therefore would be different from the ERL label
  *   In the case of P-multicast trees, this label would be upstream-allocated 
by the ingress PE and, in the case of non-aggregated tunnels, preceded by the 
label that identifies the P-multicast tree. (I am leaving aside the case of 
aggregated P-multicast trees).
I.e., in both cases, the egress PE can identify the received BUM traffic based 
on the label stack in its EVPN encapsulation and apply DF-Election-based 
filtering just to this traffic - but not to traffic received with the ESL or 
ERL labels.

What, if anything, do 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] A question about draft-sajassi-bess-evpn-l3-optimized-irb

[Alexander Vainshtein]

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
  2.  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
  3.  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,
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,

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

[Alexander Vainshtein]

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] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge and all,
Lots of thanks for a prompt and very encouraging response!

I have looked up the -09 revision, and the new text looks OK.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, October 23, 2023 4:03 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Thanks once more for reviewing. Since the WG adoption call will start soon, we 
published version 9 to address your comments.

For points 1..3, we modified the text to make as per your comments.
For point 4, we clarified that the two bullets are both true for the primary PE.

Thanks,
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, October 22, 2023 at 8:44 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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 the update.

A few comments on the new text of Section 3.1:


1.   “The Ethernet Tag should be set to 0” - IMHO this is MUST or, at least 
SHOULD. The IP-VRF that installs this route cannot interpret a non-zero value 
of the Ethernet Tag in any way.

2.   “The route MUST carry the Route Target of the corresponding IP-VRF” - 
IMHO it should be “all Export Route Targets of the corresponding IP VRF” (there 
may be more than one Export Route Target in an IP-VRF, and an IP-VRF may use a 
different set of Import Route Targets.

3.   “For backup path, the Primary PE will advertise P=1 and the Backup PE 
will advertise P=0, B=1”:

a.   This seems to apply to Single-Active multi-homing only, because the 
previous sentence covers All-Active multi-homing

b.   Should be “the Primary PE will advertise P=1 and B=0”

4.   “The Primary PE SHOULD be a PE with a routing adjacency to the 
attached CE” and “The Primary PE MAY be … elected by a DF Election” - IMHO and 
FWIW with Single-Active multi-homing (which is the context for discussing 
Primary/Backup roles) these two statements always elect the same PE, i.e., one 
of these statements can be removed.
Hopefully, these notes will be useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Friday, October 20, 2023 9:57 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

We just published version 08.
We made some changes in section 3.1 based on your comments.

Note that the draft does not really create a new situation for the AD per EVI 
route in which it could be imported in different VRF types. Prior to this 
document the A-D per EVI route could also be imported in a MAC-VRF or a VPWS 
type of service.

Thanks!
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, July 13, 2023 at 2:25 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

1.   My reading of Section 5.3.1 of RFC 
8365<https://www.rfc-editor.org/rfc/rfc8365.html#section-5.1.3>, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation

2.   Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”

3.   Last but not least, Encapsulation Extended community is not mentioned 
at all in Section 3.1 of the 
draft<https://datatracker.ietf.org/d

Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge,
Lots of thanks for the update.

A few comments on the new text of Section 3.1:


  1.  “The Ethernet Tag should be set to 0” - IMHO this is MUST or, at least 
SHOULD. The IP-VRF that installs this route cannot interpret a non-zero value 
of the Ethernet Tag in any way.
  2.  “The route MUST carry the Route Target of the corresponding IP-VRF” - 
IMHO it should be “all Export Route Targets of the corresponding IP VRF” (there 
may be more than one Export Route Target in an IP-VRF, and an IP-VRF may use a 
different set of Import Route Targets.
  3.  “For backup path, the Primary PE will advertise P=1 and the Backup PE 
will advertise P=0, B=1”:
 *   This seems to apply to Single-Active multi-homing only, because the 
previous sentence covers All-Active multi-homing
 *   Should be “the Primary PE will advertise P=1 and B=0”
  4.  “The Primary PE SHOULD be a PE with a routing adjacency to the attached 
CE” and “The Primary PE MAY be … elected by a DF Election” - IMHO and FWIW with 
Single-Active multi-homing (which is the context for discussing Primary/Backup 
roles) these two statements always elect the same PE, i.e., one of these 
statements can be removed.
Hopefully, these notes will be useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Friday, October 20, 2023 9:57 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

We just published version 08.
We made some changes in section 3.1 based on your comments.

Note that the draft does not really create a new situation for the AD per EVI 
route in which it could be imported in different VRF types. Prior to this 
document the A-D per EVI route could also be imported in a MAC-VRF or a VPWS 
type of service.

Thanks!
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, July 13, 2023 at 2:25 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

1.   My reading of Section 5.3.1 of RFC 
8365<https://www.rfc-editor.org/rfc/rfc8365.html#section-5.1.3>, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation

2.   Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”

3.   Last but not least, Encapsulation Extended community is not mentioned 
at all in Section 3.1 of the 
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-07#section-3.1>
 that defines construction of IP per-EVI  A-D routes.
With regard to your statement “we never specified how to import routes with a 
single label if they come with multiple route targets and they match different 
MAC-VRFs and IP-VRFs” : I agree that this has never been specified, but, IMHO, 
this was not really needed, because, until now, the standards defining these 
routes have never allowed any alternatives. From my POV the draft creates a new 
situation, where, locking just at the NLRI of the EVPN Type 1 route, it is 
impossible to decide whether it will be installed in the FDB of a MAC-VRF/BD, 
or in the RIB (and FIB) of an IP-VRF.
So I think some text in the draft clarifying this would be most useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, July 11, 2023 9:06 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

In-line too.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, July 11, 2023 at 9:27 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org&

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Alexander Vainshtein]

Matthew, and all,
I feel pretty sure that this draft, if approved, should be considered as 
updating RFC 8584.

I also thing that there is no backward compatibility issues.

My 2c,
Sasha

From: rtg-dir  On Behalf Of Matthew Bocci (Nokia)
Sent: Friday, October 13, 2023 7:49 PM
To: Luc Andre Burdet (lburdet) ; Adrian Farrel 
; rtg-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-fast-df-recovery@ietf.org
Subject: [EXTERNAL] Re: [RTG-DIR] Rtgdir early review of 
draft-ietf-bess-evpn-fast-df-recovery-07

Authors, Working Group,

I would like to gauge the consensus of the group on the question below about 
the draft updating 8584. The meaning of "updates" is perhaps a little 
ambiguous, and the interpretation I had used when suggesting that we should 
mark the draft as updating 8584 was that it makes some changes to the 
procedures in 8584. Specifically, these changes are described in the 
introduction section of the draft, as follows:

"This document updates the state machine described in Section 2.1 of
   [RFC8584], by optionally introducing delays between some events, as
   further detailed in Section 2.2.  The solution is based on a simple
   one-way signaling mechanism."


Are there any concerns about interoperability between a 8584-only compliant 
implementation, and one that also implements 
draft-ietf-bess-evpn-fast-df-recovery?

Thanks

Matthew



From: Luc Andre Burdet (lburdet) mailto:lbur...@cisco.com>>
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel mailto:adr...@olddog.co.uk>>, 
rtg-...@ietf.org 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org
 
mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org>>
Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

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 Adrian,

Thank you for your valuable comments, and apologies for the late reply/update. 
I have incorporated all changes into -v08 which I hope address your feedback: 
some comments are replied to below:


I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

[LAB] It is worth noting that the delay introduced (change to 8584) is by 
default 0 i.e. no change to RFC8584 when the extcomm is not present.
An implementation which does not support this adding a delay of 0 and one 
supporting it but with a delay of 0 would display similar behaviours ?  I can 
defer to Matthew and the WG on this.


Why bit 3? I know the answer is "because that's the bit our
implementation uses" and I'm fine with that and I'm not asking for any
change, but it makes me suspicious about what happened to bits 0 and 2.
Why aren't they used? Is someone squatting on them?

[LAB] yes bits 0 and 2 are in-use already for Preference-Based DF indication;  
Bit 2 is iirc from an old version of this document which was also requesting a 
H=handshake bit, no longer is.  We felt it best to just leave this one at 3 
instead of shifting down. (Bit 5 is also in-use for Port-Mode in another 
document)



I see some challenges here.
The first is when a PE joins the segment while DF election is ongoing
among the other PEs.
The second is what happens if the SCT BGP extended community is present
when the T-bit is not set.
The third is what happens if the T-bit is set but no SCT BGP extended
community is provided.
All of these are easy to describe.

Does the backwards compatibility not describe these already i.e. "SHALL revert 
back to 7432" ?

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Adrian Farrel via Datatracker mailto:nore...@ietf.org>>
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org
 
mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org>>
Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Reviewer: Adrian Farrel
Review result: Has Issues

Hello

I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery.
 I
reviewed revision -07.

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

[Alexander Vainshtein]

Ali,
Lots of thanks for a very encouraging response.

I will be waiting for the -08 version of the draft.

Regards,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Tuesday, October 3, 2023 9:57 PM
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432bis.auth...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: A question regarding sections 15.2 and 15.3 of 
draft-ietf-bess-rfc7432bis

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 mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, September 26, 2023 at 2:56 AM
To: 
draft-ietf-bess-rfc7432bis.auth...@ietf.org<mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>
 
mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto: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.<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07>

Section 15.2 (which is copied from the parallel section of RFC 
7432<https://www.rfc-editor.org/rfc/rfc7432.html#section-15.2>) 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<https://datatracker.ietf.org/doc/html/rfc9135#section-4.1>, 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.


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

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

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

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

[Alexander Vainshtein]

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.

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.

I would highly appreciate your answers to the following questions:

  1.  Should anycast MAC addresses configured on EVPN IRB be treated as 
"sticky"?
  2.  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
 *   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?

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

[Alexander Vainshtein]

Ali,
Lots of thanks for a prompt response.

I have probably been not clear enough in my sequence of messages in this thread.

To clarify my position:

  1.  I do not have any issues with the latest (-14) version of the Virtual 
Ethernet Segment draft.
  2.  I fully agree that "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 ESI. I also think that, in the 
case of "bridging" EVPN,  the scope of MTU a specific Broadcast Domain and not 
any individual Ethernet Segment (physical or virtual) to which this Broadcast 
Domain is attached.
  3.  I see that L2-Attributes Extended Community is not mentioned in the -014 
version of the draft in any way. Therefore, there is no need to add a reference 
to the 7432bis draft that extends its usage to "bridging" EVPN.

I apologize for possible churn my previous emails have introduced.

Regards,
Sasha

From: BESS  On Behalf Of Ali Sajassi (sajassi)
Sent: Sunday, September 24, 2023 8:26 PM
To: Alexander Vainshtein ; 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: [EXTERNAL] Re: [bess] Intdir telechat review of 
draft-ietf-bess-evpn-virtual-eth-segment-13

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 mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, September 24, 2023 at 2:05 AM
To: Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>,
 Brian Haberman mailto:br...@innovationslab.net>>, 
int-...@ietf.org<mailto:int-...@ietf.org> 
mailto:int-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segment@ietf.org>
 
mailto:draft-ietf-bess-evpn-virtual-eth-segment@ietf.org>>,
 last-c...@ietf.org<mailto:last-c...@ietf.org> 
mailto: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 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Sunday, September 24, 2023 11:33:17 AM
To: Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>;
 Brian Haberman mailto:br...@innovationslab.net>>; 
int-...@ietf.org<mailto:int-...@ietf.org> 
mailto:int-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segment@ietf.org>
 
mailto:draft-ietf-bess-evpn-virtual-eth-segment@ietf.org>>;
 last-c...@ietf.org<mailto:last-c...@ietf.org> 
mailto: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 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Sunday, September 24, 2023 9:05:18 AM
To: Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>>;
 Brian Haberman mailto:br...@innovationslab.net>>; 
int-...@ietf.org<mailto:int-...@ietf.org> 
mailto:int-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segment@ietf.org>
 
mailto:draft-ietf-bess-evpn-virtual-eth

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

[Alexander Vainshtein]

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/<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 
o

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

[Alexander Vainshtein]

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

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

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

[Alexander Vainshtein]

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


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

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

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

[Alexander Vainshtein]

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] Errata 7180 on RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)

[Alexander Vainshtein]

Eric and all,
I do not think that this Erratum reflects any real issue. Technical or 
editorial, with RFC 4364..

The original text in the RFC, IMHO and FWIW, simply means that the VPN 
architecture does not require a dedicated SAFI for routes with the NLRI 
comprised by an 8-octet RD followed by an IP prefix but not containing any 
labels.

At the same time Section 10 discussed both advertisement of unlabeled IP routes 
(in what is known as Inter-AS Option A) and labeled IP routes (in what is known 
as Inter-AS Option C).

RFC 4264 (and its predecessor RFC 2547) have been implemented for many years 
and widely deployed. There are multiple deployments in the fields where 
implementations by different equipment vendors successfully interoperate. AFAIK 
during all these years the text in question has never been misinterpreted 
causing interoperability issues.

I  suggest rejecting the Erratum.

Regards,
Sasha

-Original Message-
From: BESS  On Behalf Of Eric Vyncke (evyncke)
Sent: Thursday, August 3, 2023 3:57 PM
To: bess@ietf.org
Subject: [EXTERNAL] [bess] Errata 7180 on RFC 4364 BGP/MPLS IP Virtual Private 
Networks (VPNs)

As the L3VPN activities have been transferred to the BESS WG, I would 
appreciate feedback from the BESS WG on this errata.
https://clicktime.symantec.com/15siKzyo3CizY1LdsHeqv?h=osVKgJrEFlcW2bC1ypy5YVa-gwTFAL57vb6sQp0DhDE=&u=https://clicktime.symantec.com/15sM1HB9ZpAML5YT8bq46?h=HWRSOoaNbU7qgBs842MyqB5JpChoAwWy9kXqPFoTOO8=&u=https://www.rfc-editor.org/errata_search.php?eid%253D7180

The section 4.3.4 text
"   Note that this VPN architecture does not require the capability to
   distribute unlabeled VPN-IPv4 addresses."

Is suggested to be replaced by
"  Note that this VPN architecture does not require the capability to
   distribute unlabeled IPv4 addresses.

With the errata reporter note: From my understanding, VPN-IPv4 addresses are 
necessarily labeled, but IPv4 adresses are not indeed. Section 10 seems to 
confirm the error by using the correct term: "distribute unlabeled IPv4 
addresses to each other."

Thanks in advance for your review,

-éric


___
BESS mailing list
BESS@ietf.org
https://clicktime.symantec.com/15siFAnWab3Q84WiKjFhJ?h=53eKMniWfdoGr2W_7YyC6ocyKCO4MPcOP-V1oSAeyjQ=&u=https://clicktime.symantec.com/15sLvSys7CUkv8iXb3RuU?h=suzmpcLHxwQqYp9qsTJ_9tNLlvAqgDDz89Th_sNvugw=&u=https://www.ietf.org/mailman/listinfo/bess

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] Comments on the VPN Inter-AS Option BC draft

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

I tend to agree with your position.
Let's wait for a more detailed version of the draft.

Regards,
Sasha

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


From: Jorge Rabadan (Nokia) 
Sent: Wednesday, August 2, 2023 3:02:28 AM
To: Alexander Vainshtein 
Cc: bess@ietf.org ; Nitsan Dolev ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Sasha,

Jeffrey would want to reply to those questions, the draft would need to be 
specific about the TEA use. Personally I don’t see any issues in using the TEA 
if properly specified in this draft.

Thx
Jorge

From: Alexander Vainshtein 
Date: Tuesday, August 1, 2023 at 8:42 AM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , Nitsan Dolev , 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: RE: Comments on the VPN Inter-AS Option BC draft

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,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012<https://clicktime.symantec.com/15siFAn1RKeQBV28niQrX?h=Q05YbxJ5VmnNz13pCxBX5bAAu9TXh6SCpDGkNh0sS74=&u=https://www.rfc-editor.org/rfc/rfc9012.html%23section-4.1>
 says that the semantics of this extended community are the same as could be 
encoded in the “barebones Tunnel TLV”.

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha’s points.
For completeness I’d like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

-EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org<mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

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,
A few comments on the VPN Inter-AS Option BC 
draft<https://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k=&u=https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00>
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that “Option BC” combines the 
advantages and mitigates the disadvantages of both classic “Option B” and 
“classic” Option C.
I also think that “Option BC” provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes<https://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8=&u=https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12>
 and BGP Color-Aware 
Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE=&u=https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),
  because it is possible to set up intent=aware inter-AS/inter-domain tunnels 
for “colored” services based on the color of the original service routes.

At the same time, I think that:

1.   As mentioned during the session, Inter-AS Option B for EVPN has its 
own issues (documented in the EVPN Inter-Domain Option B 
draft<https://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 and these

Re: [bess] Comments on the VPN Inter-AS Option BC draft

[Alexander Vainshtein]

Jorge,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012<https://www.rfc-editor.org/rfc/rfc9012.html#section-4.1> says that the 
semantics of this extended community are the same as could be encoded in the 
"barebones Tunnel TLV".

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha's points.
For completeness I'd like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-   RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

-   EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org<mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

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,
A few comments on the VPN Inter-AS Option BC 
draft<https://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k=&u=https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00>
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that "Option BC" combines the 
advantages and mitigates the disadvantages of both classic "Option B" and 
"classic" Option C.
I also think that "Option BC" provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes<https://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8=&u=https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12>
 and BGP Color-Aware 
Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE=&u=https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),
  because it is possible to set up intent=aware inter-AS/inter-domain tunnels 
for "colored" services based on the color of the original service routes.

At the same time, I think that:

1.   As mentioned during the session, Inter-AS Option B for EVPN has its 
own issues (documented in the EVPN Inter-Domain Option B 
draft<https://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 and these issues fully apply to "Option BC"

2.   The draft defines two possible solutions, one based on the Tunnel 
Encapsulation Attribute (TEA, RFC 
9012<https://clicktime.symantec.com/15t5z3YdWSSWCUF9bxWYU?h=Eo8x2bOQorNn4An26KlhQGMaow4EDWU6fwDgx-LKhZg=&u=https://datatracker.ietf.org/doc/html/rfc9012>)
 and the other based on ability to carry multiple labels in the NLRI of 
"labeled" routes as defined in RFC 
8277<https://clicktime.symantec.com/15t5uDMM3pkunXRE4Q7Pr?h=X5O-7WPStfY9Ws3f_gOPo314zCnRjXQrJAId3fyJJSc=&u=https://datatracker.ietf.org/doc/html/rfc8277>:

a.   My guess (FWIW) is that these solutions are not interoperable and, 
therefore, ability to support each of these options should be advertised using 
appropriate Capability Codes

b.   In the TEA-based solution the draft mentions "Composite Tunnel", but 
there is no mention of composite tunnels in RFC 9012.  From my POV:


   i.  Specific tunnel type (one of the types 
defined in the IANA Tunnel Types 
regi

[bess] Comments on the VPN Inter-AS Option BC draft

[Alexander Vainshtein]

Hi,
A few comments on the VPN Inter-AS Option BC 
draft 
that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that "Option BC" combines the 
advantages and mitigates the disadvantages of both classic "Option B" and 
"classic" Option C.
I also think that "Option BC" provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes and BGP 
Color-Aware 
Routing),  
because it is possible to set up intent=aware inter-AS/inter-domain tunnels for 
"colored" services based on the color of the original service routes.

At the same time, I think that:

  1.  As mentioned during the session, Inter-AS Option B for EVPN has its own 
issues (documented in the EVPN Inter-Domain Option B 
draft),
 and these issues fully apply to "Option BC"
  2.  The draft defines two possible solutions, one based on the Tunnel 
Encapsulation Attribute (TEA, RFC 
9012) and the other based on 
ability to carry multiple labels in the NLRI of "labeled" routes as defined in 
RFC 8277:
 *   My guess (FWIW) is that these solutions are not interoperable and, 
therefore, ability to support each of these options should be advertised using 
appropriate Capability Codes
 *   In the TEA-based solution the draft mentions "Composite Tunnel", but 
there is no mention of composite tunnels in RFC 9012.  From my POV:

   i.  Specific 
tunnel type (one of the types defined in the IANA Tunnel Types 
registry)
 should be specified, or a request for allocating a new tunnel type should be 
added to the next revision of the document

 ii.  I wonder 
if MPLS Encapsulation Tunnel type and the Label Stack Sub-TLV can be used in 
the TEA-based solution. My guess is that this would require an update to RFC 
8365

Hopefully these issues will be addressed in the next revision of the draft.

My 2c,
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] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

  1.  My reading of Section 5.3.1 of RFC 
8365<https://www.rfc-editor.org/rfc/rfc8365.html#section-5.1.3>, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation
  2.  Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”
  3.  Last but not least, Encapsulation Extended community is not mentioned at 
all in Section 3.1 of the 
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-07#section-3.1>
 that defines construction of IP per-EVI  A-D routes.
With regard to your statement “we never specified how to import routes with a 
single label if they come with multiple route targets and they match different 
MAC-VRFs and IP-VRFs” : I agree that this has never been specified, but, IMHO, 
this was not really needed, because, until now, the standards defining these 
routes have never allowed any alternatives. From my POV the draft creates a new 
situation, where, locking just at the NLRI of the EVPN Type 1 route, it is 
impossible to decide whether it will be installed in the FDB of a MAC-VRF/BD, 
or in the RIB (and FIB) of an IP-VRF.
So I think some text in the draft clarifying this would be most useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Tuesday, July 11, 2023 9:06 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

In-line too.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, July 11, 2023 at 9:27 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

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 your response.

Please see more comments inline below.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, July 11, 2023 6:35 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Let me try to reply to your questions:

How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI 
Ethernet A-D route or a per-EVI IP A-D route?
[jorge] The IP A-D per EVI route carries a route target of an IP-VRF.
[[Sasha]] Yes, I have assumed the same. But what is supposed to happen if an 
A-D per-EVI route carries RTs that match both some IP-=VRF and some MAC-VRF in 
the receiving PE? Should such a route be simply treated as an error (and, if 
yes, what would be the action on it), or should one of the two possibilities 
given priority? Such a route clearly could not be installed in both places.
[jorge] I don’t think we need to specify that in the draft, in the same way we 
never specified how to import routes with a single label if they come with 
multiple route targets and they match different MAC-VRFs and IP-VRFs. Clearly 
if the advertising PE does as specified, it will send different routes for ESIs 
in MAC-VRFs or in IP-VRFs. So what you are describing is a non-expected 
scenario. Even so, the receiving PE could potentially import it in two places 
(I don’t see why not), but the route would be of no use in one of the VRFs 
unless you received also the proper MAC/IP routes and IP Prefix routes with the 
same ESI.

2.   “The draft defines, without going into details,  quite a different 
procedure for recursive resolution of such routes that uses per EVI IP A-D 
routes introduced in the draft. This procedure inherently assumes that 
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., 
without inner L2 encapsulation).
My question is: How can the PE that receives an EVPN IP Prefix routes with a 
non-reserved ESI value decide which of these two procedures it should apply to 
each specific route?”


[jorge] As discussed, for IP Prefix routes, the draft

Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge,
Lots of thanks for your response.

Please see more comments inline below.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Tuesday, July 11, 2023 6:35 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Let me try to reply to your questions:

How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI 
Ethernet A-D route or a per-EVI IP A-D route?
[jorge] The IP A-D per EVI route carries a route target of an IP-VRF.
[[Sasha]] Yes, I have assumed the same. But what is supposed to happen if an 
A-D per-EVI route carries RTs that match both some IP-=VRF and some MAC-VRF in 
the receiving PE? Should such a route be simply treated as an error (and, if 
yes, what would be the action on it), or should one of the two possibilities 
given priority? Such a route clearly could not be installed in both places.

2.  “The draft defines, without going into details,  quite a different 
procedure for recursive resolution of such routes that uses per EVI IP A-D 
routes introduced in the draft. This procedure inherently assumes that 
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., 
without inner L2 encapsulation).
My question is: How can the PE that receives an EVPN IP Prefix routes with a 
non-reserved ESI value decide which of these two procedures it should apply to 
each specific route?”


[jorge] As discussed, for IP Prefix routes, the draft extends RFC9136 section 
4.4.1 (we added some text about it) to support the resolution of IP Prefix 
routes to IP A-D routes.

-   RFC9136 section 4.4.1 supports both Ethernet NVO tunnels and IP NVO tunnels 
(see the terminology section in RFC9136). That is, both inner L2 or L3 
encapsulation.

-   If an implementation receives an IP Prefix route with a non-reserved ESI 
value that is imported in an IP-VRF, the procedures in the draft are followed, 
irrespective of whether the PEs use Ethernet NVO or IP NVO tunnels. The route 
resolution is described in 5.3.1.

-   By the way, the recursive resolution is compatible with RFC9136. See table 
1, first two top rows:
 +==+==+==++===+
  | ESI  | GW IP| MAC* | Label  | Overlay Index |
  +==+==+==++===+
  | Non-Zero | Zero | Zero | Don't Care | ESI   |
  +--+--+--++---+
  | Non-Zero | Zero | Non-Zero | Don't Care | ESI   |
  +--+--+--++---+

[[Sasha]] Unfortunately, it doesn’t, it seems that my original question has 
been presented clearly enough.
My scope of interest is EVPN over an IP/MPLS core, i.e., I am only discussing 
only MPLS tunnels.
My understanding of the interface-less IP-VRF-to-IP-VRF model as described in 
9136 is that it does not imply recursive resolution and inter-subnet traffic 
crosses the core as pure IP over MPLS (i.e., the customer IP header immediately 
follows the bottom of the label stack). This is fully aligned with the 
mechanism used with Symmetric IRB as defined in Section 5.4 of RFC 9135 that 
says: “If the tunnel type is that of an MPLS or IP-only NVO tunnel, then the 
TS's IP packet is sent over the tunnel without any Ethernet header.” I assume 
that your modified model does not change the way customer inter-subnet traffic 
is carried across the IP/NMPLS core (you’ve mentioned that the modified model 
still does not use SBD).


At the same time, all the scenarios in RFC 9136 that use recursive resolution 
imply insertion of an “inner Ethernet header” between the bottom of the label 
stack and the customer IP header, and the difference between these methods is 
about the way Destination MAC address of this inner Ethernet header is obtained 
(from the suitable RT-2, from the Router MAC Extended Community or by a local 
policy). This matches my understanding of Asymmetric IRB as defined in Section 
6.3 of RFC 9135: “The ingress PE gets the destination TS's MAC address for that 
TS's IP address from its ARP table or NDP cache. It encapsulates the packet 
with that destination MAC address and a source MAC address corresponding to 
that IRB interface and sends the packet to its destination subnet MAC-VRF/BT. 
The destination MAC address lookup in the MAC-VRF/BT results in a BGP next-hop 
address of the egress PE along with label1 (L2 VPN MPLS label or VNI).”

With RFC 9136, the PE that receives an IP Prefix Route can decide whether its 
handling by the data plane does or does not involve inclusion of the “inner L2 
header: recursive resolution always implies inner L2 header, if it is not used, 
no inner L2 header is needed.

Your modification breaks this simple rule: data plane handling of a received 
and installed an RT-5 with a non-reser

Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge and all,
More of the same:

How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI 
Ethernet A-D route or a per-EVI IP A-D route?

My 2c,
Sasha

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


From: Alexander Vainshtein 
Sent: Sunday, July 9, 2023 12:57:00 PM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org ; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org 

Subject: RE: Question and comments on the EVPN IP Aliasing draft

Jorge,
Lots of thanks for the new revision, it addresses the majority of my comments.

I still have some doubts about co-existence of the “old” (as in RFC 9136 
Section 4.4.1) and “new” interface-less IP-VRF-to-IP-VRF models.
Specifically:

  1.  Section 4.3 of RFC 9136 provides a detailed procedure for recursive 
resolution of received EVPN IP Prefix routes with a non-reserved ESI value in 
their NLRI.  To the best of my understanding, this procedure inherently assumes 
that inter-subnet traffic is carried between the PEs as EVPN traffic (i.e., 
with inner L2 encapsulation). This procedure uses the Router MAC Extended 
Community, or, in the case of its absence, a local policy for determination of 
the Destination MAC address in the inner L2 encapsulation/
  2.  The draft defines, without going into details,  quite a different 
procedure for recursive resolution of such routes that uses per EVI IP A-D 
routes introduced in the draft. This procedure inherently assumes that 
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., 
without inner L2 encapsulation).

My question is: How can the PE that receives an EVPN IP Prefix routes with a 
non-reserved ESI value decide which of these two procedures it should apply to 
each specific route?


I think that the draft should provide an unambiguous answer to this question.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Thursday, July 6, 2023 9:23 PM
To: Alexander Vainshtein ; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft

Sasha,

We just published version 07 of the EVPN IP Aliasing draft, and tried to 
address your comments in this thread. Let us know if you have further comments.
Thank you!
Jorge

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Date: Tuesday, April 4, 2023 at 5:09 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: Re: Question and comments on the EVPN IP Aliasing draft
Hi Sasha,

I can work on some clarifications in the text based on your feedback.

About whether the draft updates RFC9136, I’m hesitant to add it to the header, 
since this spec is obviously optional.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, April 3, 2023 at 5:51 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Question and comments on the EVPN IP Aliasing draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See 
https://clicktime.symantec.com/15siFAdRxjC6ZR12VsdcD?h=9dKjeFiIGxpBYd94GifyAUHFA2O22JVj1NliypFJLQk=&u=http://nok.it/ext
 for additional information.


Hi Jorge,
Lots of thanks for a prompt response.

I have explained my position with regard to IP Aliasing for RT-5 in 
Interface-less IP-VRF-to-IP-VRF model in my previous email.
I only can add that the neither the metadata of the IP Aliasing draft nor its 
text specify an update to RFC 9136.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, April 3, 2023 4:17 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>; Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>; Michael Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>; Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>; Egon Haparnass 
mailto:ehaparn...@rbbn.com>>; Shell Nakash 
mailto:shell.nak...@rbbn.com>>; Marina Fizgeer 
mailto:marina.fizg...@rbbn.com>>; Orly Kariv 
mailto:orly.ka...@rbbn.com>>; Moti Morgenstern 
mailto:moti.morgenst...@rbbn.com>>; Rotem Cohen 
mailto:rotem.co...@rbbn.com>>
Subje

Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Jorge,
Lots of thanks for the new revision, it addresses the majority of my comments.

I still have some doubts about co-existence of the “old” (as in RFC 9136 
Section 4.4.1) and “new” interface-less IP-VRF-to-IP-VRF models.
Specifically:

  1.  Section 4.3 of RFC 9136 provides a detailed procedure for recursive 
resolution of received EVPN IP Prefix routes with a non-reserved ESI value in 
their NLRI.  To the best of my understanding, this procedure inherently assumes 
that inter-subnet traffic is carried between the PEs as EVPN traffic (i.e., 
with inner L2 encapsulation). This procedure uses the Router MAC Extended 
Community, or, in the case of its absence, a local policy for determination of 
the Destination MAC address in the inner L2 encapsulation/
  2.  The draft defines, without going into details,  quite a different 
procedure for recursive resolution of such routes that uses per EVI IP A-D 
routes introduced in the draft. This procedure inherently assumes that 
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e., 
without inner L2 encapsulation).

My question is: How can the PE that receives an EVPN IP Prefix routes with a 
non-reserved ESI value decide which of these two procedures it should apply to 
each specific route?


I think that the draft should provide an unambiguous answer to this question.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Thursday, July 6, 2023 9:23 PM
To: Alexander Vainshtein ; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft

Sasha,

We just published version 07 of the EVPN IP Aliasing draft, and tried to 
address your comments in this thread. Let us know if you have further comments.
Thank you!
Jorge

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Date: Tuesday, April 4, 2023 at 5:09 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: Re: Question and comments on the EVPN IP Aliasing draft
Hi Sasha,

I can work on some clarifications in the text based on your feedback.

About whether the draft updates RFC9136, I’m hesitant to add it to the header, 
since this spec is obviously optional.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, April 3, 2023 at 5:51 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Question and comments on the EVPN IP Aliasing draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See 
https://clicktime.symantec.com/15siFAdRxjC6ZR12VsdcD?h=9dKjeFiIGxpBYd94GifyAUHFA2O22JVj1NliypFJLQk=&u=http://nok.it/ext
 for additional information.


Hi Jorge,
Lots of thanks for a prompt response.

I have explained my position with regard to IP Aliasing for RT-5 in 
Interface-less IP-VRF-to-IP-VRF model in my previous email.
I only can add that the neither the metadata of the IP Aliasing draft nor its 
text specify an update to RFC 9136.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, April 3, 2023 4:17 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>; Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>; Michael Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>; Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>; Egon Haparnass 
mailto:ehaparn...@rbbn.com>>; Shell Nakash 
mailto:shell.nak...@rbbn.com>>; Marina Fizgeer 
mailto:marina.fizg...@rbbn.com>>; Orly Kariv 
mailto:orly.ka...@rbbn.com>>; Moti Morgenstern 
mailto:moti.morgenst...@rbbn.com>>; Rotem Cohen 
mailto:rotem.co...@rbbn.com>>
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Please see in-line with [jorge].

Thanks for the good questions/points.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, March 26, 2023 at 11:16 PM
To: 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto

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

[Alexander Vainshtein]

Matthew, Stephane and all,

  1.  I support advancing draft-ietf-bess-evpn-l2gw-proto.
  2.  I am neither an author nor a contributor, but, in any case, I am not 
aware of any undisclosed IPR.
  3.  Ribbon(c) has developed a partially 
compliant implementation of this draft which is part of a production SW release 
in one of its product lines.

Regards,
Sasha

From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Wednesday, June 14, 2023 11:13 AM
To: bess@ietf.org
Subject: [EXTERNAL] [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

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] Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 14.1.1

[Alexander Vainshtein]

Menachem,
More inline below.

Regards,
Sasha

From: Menachem Dodge 
Sent: Thursday, June 15, 2023 11:56 AM
To: Alexander Vainshtein 
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 
14.1.1

Hello Sasha,

Thank you kindly for your email.

Based on what you have written the PE that is attached to this MH ES will send 
the RED=00 in the Type 1 Ethernet A-D ESI route and will send the L2-ATTR with 
the ‘P’ bit raised.
[[Sasha]] There are two flavors of Ethernet A-D (EVPN Type 1) routes: per-ES 
(with all zeroes in the Label field and MAX-ET in the Ethernet Tag ID field) 
and per EVI (with the valid Ethernet Tag ID value identifying the BD for which 
it has been advertised, and with the valid “aliasing” label for this BD).
In the case of an All-Active MH ES:

  *   RED in the ESI Label Extended Community attached to (potentially, 
multiple copies of) the per-ES Ethernet A-D route (with different 
auto-generated RD in the NLRI of these copies) MUST be set to ‘00’
  *   P bit in the Layer 2 Attributes Extended Community attached to the 
per-EVI Ethernet A-D route SHOULD be set to ‘1’.

If for whatever reason (example misconfiguration) another PE attached to the 
same MH ES sends RED=01 what should be the behavior of the first PE when it 
receives this information?
[[Sasha]] I think that the only thing you can do is  to report a 
misconfiguration problem.

Thank you kindly.

Best Regards,
Menachem

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, 15 June 2023 at 10:01
To: Menachem Dodge mailto:mdo...@drivenets.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 14.1.1
Menachem,
Please see some tentative answers to your questions inline below.

Hopefully this helps.

Regards,
Sasha

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Menachem Dodge
Sent: Wednesday, June 14, 2023 11:29 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] Re: [bess] Draft draft-ietf-bess-7432bis-07 Section 7.5, 
7.11 and 14.1.1

Hello All,

Please could someone kindly respond to my questions below.

Thank you kindly.

Best Regards,
Menachem Dodge

From: Menachem Dodge mailto:mdo...@drivenets.com>>
Date: Sunday, 11 June 2023 at 16:17
To: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 14.1.1
Hello All,

I have a query regarding the behavior of a PE that is a member of an ES and has 
been configured to be in All-Active mode.

According to section 7.5 the multihomed site redundancy mode is set to RED = 
00: A value of 00 means that the multihomed site is operating in All-Active 
redundancy mode.

What defines “operating”?  Is this according to local configuration only?
[[Sasha]] Please note that the highlighted text in the draft refers to 
operation of the customer site to which multiple EVPN PEs are attached via 
PE-CE links forming an All-Active MH ES. I.e., this site:

·   MUST be ready to receive and deliver to its proper destination an 
Ethernet frame received from any of these links

·   Expects that traffic it sends to remote sites via any of these links to 
be delivered to its proper destination.
One example of such behavior is a site with a single CE that terminates all 
PE-CE links comprising the MH ES in question and locally treating them as a  
single Link Aggregation Group with all members being in the “Collecting and 
Distributing” state.

In section 7.11 the ‘P’ bit of the L2-ATTR Extended Community MUST be set to 1 
for multihoming All-Active scenarios by all active PE(s).
What is an “active PE”? Is this according to local configuration only?
[[Sasha]] From my POV an active PE in this context is a PE that can send and 
receive traffic via the PE-CE link that locally (in this PE) represents the 
All-Active MH ES in question.


In section 14.1.1 it states that:


For a given ES, if a remote PE has imported the set of Ethernet A-D
   per ES routes from at least one PE, where the "Single-Active" flag in
   the ESI Label extended community is set, then that remote PE MUST
   deduce that the ES is operating in Single-Active redundancy mode.


My understanding is that the meaning of “remote PE” is a PE that is not a 
member of the ES. This statement indicates that the “remote PE” deduces that 
the ES is operating in Single-Active redundancy mode from the set of Ethernet 
A-D per ES routes it has received.

What should be the behavior of the “local PE” that is a member of the ES ? I 
could not find this defined in the document.

Does the “local PE” assume that the configuration of all attached PEs to the ES 
is consistent and therefore it sends RED = 00 and sets the ‘P’ bit in the 
L2-ATTR ? Or does the “local PE” change what it advertises according to what it 
receives from the other “local PEs” att

Re: [bess] Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 14.1.1

[Alexander Vainshtein]

Menachem,
Please see some tentative answers to your questions inline below.

Hopefully this helps.

Regards,
Sasha

From: BESS  On Behalf Of Menachem Dodge
Sent: Wednesday, June 14, 2023 11:29 AM
To: bess@ietf.org
Subject: [EXTERNAL] Re: [bess] Draft draft-ietf-bess-7432bis-07 Section 7.5, 
7.11 and 14.1.1

Hello All,

Please could someone kindly respond to my questions below.

Thank you kindly.

Best Regards,
Menachem Dodge

From: Menachem Dodge mailto:mdo...@drivenets.com>>
Date: Sunday, 11 June 2023 at 16:17
To: bess@ietf.org mailto:bess@ietf.org>>
Subject: Draft draft-ietf-bess-7432bis-07 Section 7.5, 7.11 and 14.1.1
Hello All,

I have a query regarding the behavior of a PE that is a member of an ES and has 
been configured to be in All-Active mode.

According to section 7.5 the multihomed site redundancy mode is set to RED = 
00: A value of 00 means that the multihomed site is operating in All-Active 
redundancy mode.

What defines “operating”?  Is this according to local configuration only?
[[Sasha]] Please note that the highlighted text in the draft refers to 
operation of the customer site to which multiple EVPN PEs are attached via 
PE-CE links forming an All-Active MH ES. I.e., this site:

  *   MUST be ready to receive and deliver to its proper destination an 
Ethernet frame received from any of these links
  *   Expects that traffic it sends to remote sites via any of these links to 
be delivered to its proper destination.
One example of such behavior is a site with a single CE that terminates all 
PE-CE links comprising the MH ES in question and locally treating them as a  
single Link Aggregation Group with all members being in the “Collecting and 
Distributing” state.

In section 7.11 the ‘P’ bit of the L2-ATTR Extended Community MUST be set to 1 
for multihoming All-Active scenarios by all active PE(s).
What is an “active PE”? Is this according to local configuration only?
[[Sasha]] From my POV an active PE in this context is a PE that can send and 
receive traffic via the PE-CE link that locally (in this PE) represents the 
All-Active MH ES in question.


In section 14.1.1 it states that:


For a given ES, if a remote PE has imported the set of Ethernet A-D
   per ES routes from at least one PE, where the "Single-Active" flag in
   the ESI Label extended community is set, then that remote PE MUST
   deduce that the ES is operating in Single-Active redundancy mode.


My understanding is that the meaning of “remote PE” is a PE that is not a 
member of the ES. This statement indicates that the “remote PE” deduces that 
the ES is operating in Single-Active redundancy mode from the set of Ethernet 
A-D per ES routes it has received.

What should be the behavior of the “local PE” that is a member of the ES ? I 
could not find this defined in the document.

Does the “local PE” assume that the configuration of all attached PEs to the ES 
is consistent and therefore it sends RED = 00 and sets the ‘P’ bit in the 
L2-ATTR ? Or does the “local PE” change what it advertises according to what it 
receives from the other “local PEs” attached to the same ES?

For example: If a PE is configured as all-active shall this PE Send RED=00 and 
set the ‘P’ bit in the L2-ATTR, even when it receives from another PE on the 
same Ethernet-Segment RED=01 ?

Thank you kindly.

Best Regards,

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

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bes

Re: [bess] [EXTERNAL] MAC Mobility Section 9.1 and 15 - Draft draft-ietf-bess-7432bis-07

[Alexander Vainshtein]

Menachem,
You are welcome.

As for the text in Sections 9.1 and 15 – personally I do not see the need for 
updated wording.

Regards,
Sasha

From: Menachem Dodge 
Sent: Monday, June 12, 2023 4:04 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org
Subject: Re: [EXTERNAL] [bess] MAC Mobility Section 9.1 and 15 - Draft 
draft-ietf-bess-7432bis-07

Hello Sasha,

Thanks very much for your response.

Should the wording in section 9.1 and section 15 be modified to indicate this 
more clearly?

Best Regards,
Menachem

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, 12 June 2023 at 15:21
To: Menachem Dodge mailto:mdo...@drivenets.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: [EXTERNAL] [bess] MAC Mobility Section 9.1 and 15 - Draft 
draft-ietf-bess-7432bis-07
Menachem and all,
Inline below.
Hope this helps.
Regards,
Sasha

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Menachem Dodge
Sent: Monday, June 12, 2023 2:46 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] [bess] MAC Mobility Section 9.1 and 15 - Draft 
draft-ietf-bess-7432bis-07

Hello All,

In Section 9.1 of it states:

There are applications where a MAC address that is reachable via a
   given PE on a locally attached segment (e.g., with ESI X) may move,
   such that it becomes reachable via another PE on another segment
   (e.g., with ESI Y).  This is referred to as "MAC Mobility".
   Procedures to support this are described in Section 15 ("MAC
   Mobility").



1.   Must ESI X be on a different PE than ESI Y ?  [[Sasha]] No.

2.   What should be the procedure if both ESI X and ESI Y are on the same 
PE ? [[Sasha]] If X and Y are two single-homed ES attached to the same PE, the 
PEs that are not attached to X  and Y do not have to be aware of the move. If X 
or Y are multi-homed, the common procedures apply.

3.   If a MAC address which is reachable via a given PE on a locally 
attached segment which is single-homed and ESI X = 0, moves to another locally 
attached segment which is also single homed such that ESI Y = 0 as well, on the 
same PE, what should be the procedure in this case? [[Sasha]]Please see above.

Thank you kindly.

Best Regards,

Menachem Dodge
System Architect
[signature_1593666450]
+972-526175734
mdo...@drivenets.com<mailto:mdo...@drivenets.com>
follow us on 
Linkedin<https://clicktime.symantec.com/15t5jYgj5jYNmRvaBXjUw?h=oyx4Y3cPSvvEJbdB8AIEkfHuaGvqnSnJaDNP1z3eQfY=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttps-3A__clicktime.symantec.com_15t5jYgi49achdXWxbT1v-3Fh-3DPwtR8u5uJIArW94Vnq2TGFzFxN9RZZhiLs52gMGepRY-3D-26u-3Dhttps-3A__www.linkedin.com_company_drivenets%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DLQNEkrIwr2YJl4lKkHvl0mzdfboi0UGdw-trFQDTOsY%26s%3DOs-VC8Ux0rb6Y78pxySg4fskOmYfZmS-sBLMP0adMKc%26e%3D>
www.drivenets.com<https://clicktime.symantec.com/15t5ZtJAAWBBwYGj6QwBh?h=6gTgaGTZah_ppfLLmekumlHlzdxk80fSI3piOYjKkgw=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttp-3A__www.drivenets.com%26d%3DDwQGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DLQNEkrIwr2YJl4lKkHvl0mzdfboi0UGdw-trFQDTOsY%26s%3DYVKB4Ar-BgesCjVWTwfEhmugzhEGazhjXOoYfavJ6A0%26e%3D>
[DriveNets Network 
Cloud]<https://clicktime.symantec.com/15t5eiVSd7rnMV6edyLLK?h=-A6E4ggUsMv4lGfJ_kcd9fug7bUP71OzBNC4GC8sEWY=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttps-3A__clicktime.symantec.com_15t5eiVRbXu2HghbR33sJ-3Fh-3DOtkEoO074pTmYQ87p0VSbfi8LPjwJl4R2fr8cOizTSg-3D-26u-3Dhttps-3A__drivenets.com_products_%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DLQNEkrIwr2YJl4lKkHvl0mzdfboi0UGdw-trFQDTOsY%26s%3DZH1xwXlNGCqebuLIIMPSeOBBVydgLCXcHCThTWw2tTQ%26e%3D>



Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for 

Re: [bess] [EXTERNAL] MAC Mobility Section 9.1 and 15 - Draft draft-ietf-bess-7432bis-07

[Alexander Vainshtein]

Menachem and all,
Inline below.
Hope this helps.
Regards,
Sasha

From: BESS  On Behalf Of Menachem Dodge
Sent: Monday, June 12, 2023 2:46 PM
To: bess@ietf.org
Subject: [EXTERNAL] [bess] MAC Mobility Section 9.1 and 15 - Draft 
draft-ietf-bess-7432bis-07

Hello All,

In Section 9.1 of it states:

There are applications where a MAC address that is reachable via a
   given PE on a locally attached segment (e.g., with ESI X) may move,
   such that it becomes reachable via another PE on another segment
   (e.g., with ESI Y).  This is referred to as "MAC Mobility".
   Procedures to support this are described in Section 15 ("MAC
   Mobility").



1.   Must ESI X be on a different PE than ESI Y ?  [[Sasha]] No.

2.   What should be the procedure if both ESI X and ESI Y are on the same 
PE ? [[Sasha]] If X and Y are two single-homed ES attached to the same PE, the 
PEs that are not attached to X  and Y do not have to be aware of the move. If X 
or Y are multi-homed, the common procedures apply.

3.   If a MAC address which is reachable via a given PE on a locally 
attached segment which is single-homed and ESI X = 0, moves to another locally 
attached segment which is also single homed such that ESI Y = 0 as well, on the 
same PE, what should be the procedure in this case? [[Sasha]]Please see above.

Thank you kindly.

Best Regards,

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

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Jorge,
Lots of thanks for an encouraging response.

I can imagine an implementation which would derive Type 1 RDs of all per-ES 
Ethernet A-D routes from one loopback address and all the rest of Type 1 RDs – 
from another loopback address.
Explicitly recommending to derive all Type 1 RDs of all EVPN routes from the 
same (loopback) address would at least discourage such implementations.
So if you can add such a sentence, please do that!


Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Tuesday, May 30, 2023 4:23 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; 
rfc7432...@ietf.org; wang.yub...@zte.com.cn
Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha,

About your suggestion on 7432bis, it’s kind of implicit, but I see no harm in 
adding a sentence.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, May 28, 2023 at 1:26 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>
 
mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>>,
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org> 
mailto:rfc7432...@ietf.org>>, 
wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn> 
mailto:wang.yub...@zte.com.cn>>
Subject: RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

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 your response.

Please see inline below.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, May 16, 2023 11:42 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>;
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org>
Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha,


However,  neither 7432bis nor any other RFC or standard I am aware of says that 
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as 
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs 
assigned to MAC-VRFs.  And this is obviously a precondition for using the 
solution suggested in Section 3.1.2.
[jorge] the example in section 3.1.2 should be enough to clarify that the 
administrator part of the RD is the same. Let us know if that is not the case 
please.
[[Sasha]] This was a comment about 7432bis. IMHO and FWIW it makes sense to 
clarify in this document that the Administrator part of Type 1 RDs used in all 
the EVPN routes advertised by a specific PE SHOULD be the same. What do you 
think?

I also have some doubts regarding solution that is documented in Section 3.1.3 
of the EVPN Inter-Domain Option B draft because:

·   Only implementations that do not use OPTIONAL per EVI EVPN A-D routes 
can benefit from this solution. In all other cases the per EVI Mass Withdrawal 
solution (documented in Section 3.1 of the draft)  would work exactly as well

·   Such implementations could not benefit from aliasing and/or backup path 
EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus 
severely compromising any benefits of the Mass Withdrawal mechanisms.
[jorge] as discussed earlier, this is documenting viable existing solutions 
with their trade-offs, not mandating any particular one. Both things you point 
out are described in 3.1.3 section. If you don’t think so, please let us know.
[[Sasha]] I have misspoken – my apologies. I should say that I have some doubts 
regarding the practical value of the solution documented in Section 3.1.3 of 
the EVPN Option-B draft. The solution itself is quite clear.

Thanks!
Jorge



From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, May 14, 2023 at 10:31 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn> 
mailto:wang.yub...@zte.com.cn>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>
 
mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>>,
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org> 
mailto:rfc7432...@ietf.org>>
Subject: RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-raba

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

[Alexander Vainshtein]

Ali, Sami and all,
A short comment inline below.

Regards,
Sasha

From: BESS  On Behalf Of Ali Sajassi (sajassi)
Sent: Wednesday, May 24, 2023 10:14 PM
To: Boutros, Sami ; BESS 
Subject: [EXTERNAL] Re: [bess] Question on symmetric EVPN IRB RFC 9135

Hi Sami,

Please refer to my response inline in red ...

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Boutros, Sami 
mailto:sboutros=40ciena@dmarc.ietf.org>>
Date: Tuesday, May 23, 2023 at 2:31 PM
To: BESS mailto:bess@ietf.org>>
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).
[[Sasha]] Please consider the case when the route in question is received by a 
BGP Route Reflector.  In this case obviously there would be no need in any 
error messages.
And in any case IMHO this case is not different from the case in which a PE 
receives a VPN-IP route with attached RTs that do not match one of Import RTs 
of any of its IP-VRFs. AFAIK, most implementations simply silently ignore such 
routes.


-  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

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] [EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Jorge,
Lots of thanks for your response.

Please see inline below.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Tuesday, May 16, 2023 11:42 PM
To: Alexander Vainshtein ; wang.yub...@zte.com.cn
Cc: bess@ietf.org; draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; 
rfc7432...@ietf.org
Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha,


However,  neither 7432bis nor any other RFC or standard I am aware of says that 
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as 
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs 
assigned to MAC-VRFs.  And this is obviously a precondition for using the 
solution suggested in Section 3.1.2.
[jorge] the example in section 3.1.2 should be enough to clarify that the 
administrator part of the RD is the same. Let us know if that is not the case 
please.
[[Sasha]] This was a comment about 7432bis. IMHO and FWIW it makes sense to 
clarify in this document that the Administrator part of Type 1 RDs used in all 
the EVPN routes advertised by a specific PE SHOULD be the same. What do you 
think?

I also have some doubts regarding solution that is documented in Section 3.1.3 
of the EVPN Inter-Domain Option B draft because:

·   Only implementations that do not use OPTIONAL per EVI EVPN A-D routes 
can benefit from this solution. In all other cases the per EVI Mass Withdrawal 
solution (documented in Section 3.1 of the draft)  would work exactly as well

·   Such implementations could not benefit from aliasing and/or backup path 
EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus 
severely compromising any benefits of the Mass Withdrawal mechanisms.
[jorge] as discussed earlier, this is documenting viable existing solutions 
with their trade-offs, not mandating any particular one. Both things you point 
out are described in 3.1.3 section. If you don’t think so, please let us know.
[[Sasha]] I have misspoken – my apologies. I should say that I have some doubts 
regarding the practical value of the solution documented in Section 3.1.3 of 
the EVPN Option-B draft. The solution itself is quite clear.

Thanks!
Jorge



From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, May 14, 2023 at 10:31 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn> 
mailto:wang.yub...@zte.com.cn>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>
 
mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>>,
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org> 
mailto:rfc7432...@ietf.org>>
Subject: RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

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, Yubao and all,
A couple of comments.

The current version of 
7432bis<https://clicktime.symantec.com/15t5Zt9SEXGagfrZxwR9z?h=gGcib8S3C26TGyskaohEYo1_njxaFnOgTQKSs6yx1Ww=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07>
  says that:

·   Per-ES EVPN A-D routes MUST use Type 1 RDs with the Administrator field 
comprising “an IP address of the PE (typically, the loopback address)”

·   Per-EVI EVPN A-D routes and EVPN MAC/IP Advertisement routes advertised 
by an EVPN Instance locally represented by a MAC-VRF use the RD that is 
assigned to this MAC-VRF, and usage of   Type 1 RD with the Administrator field 
comprising “an IP address of the PE (typically, the loopback address)” is 
RECOMMENDED.

RFC 2119 says that “the adjective "RECOMMENDED", mean that there may exist 
valid reasons in particular circumstances to ignore a particular item, but the 
full implications must be understood and carefully weighed before choosing a 
different course”. Therefore, I concur with Jorge that people who decide not to 
assign Type 1 RDs to  MAC-VRFs should bear the consequences in mind, including 
non-applicability of the solution suggested in Section 3.1.2 of the EVPN 
Inter-Domain Option B 
draft<https://clicktime.symantec.com/15t5eiLih8xB6cgVWVpJc?h=op8TeX0Vsru5FkDFaRdxWuqgdODq44ba2I1LrFCkDsg=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>.

However,  neither 7432bis nor any other RFC or standard I am aware of says that 
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as 
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs 
assigned to MAC-VRFs.  And this is obviously a precondition for using the 
solution suggested in Section 3.1.2.

IMHO and FWIW adding a corresponding 

Re: [bess] [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Yubao hi!

Let us to differentiate between RDs that are used in per ES Ethernet A-D routes 
and RDs that are assigned to MAC-VRFs.

  *   The latter may be auto-derived or manually configured – this is the 
operator’s choice in most cases
  *   The former cannot be manually assigned because, as the number of EVI 
attached to a given MH ES grows, the PE would have to generate additional 
per-ES Ethernet A-D routes for the same ES, and these routes MUST have 
different RDs. (This will happen for any implementation once the number of EVI 
attached to the MH ES in question exceeds 512 – simply because BGP Update 
messages are limited to 4K, and each RT is 8 octets long).
  *   If you use Type 0/Type 2 RD in accordance with the rules defined in RFC 
4364 (i.e., use the AS Number of the device as the Administrator subfield of 
these RDs), there is no way to guarantee that that RDs of these routes that are 
auto-generated by different PEs would not be the same.
The bottom line:

  1.  I do not see how you could safely use Type 0/Type 2 RDs in the per-ES 
Ethernet A-D routes, therefore I do not think this restriction can be relaxed
  2.  The user may manually assign Type 0/Type 2 RDs to MAC-VRFs, if h/she 
fully understands all the implications.
  3.  I have not found any requirement for RR to drop EVPN routes if the RD in 
their NLRI is Type 0/Type 2. IMHO and FWIW  if this happens, this is the side 
effect of the BGP selection process.
Regards,
Sasha

From: wang.yub...@zte.com.cn 
Sent: Tuesday, May 16, 2023 3:28 PM
To: Alexander Vainshtein 
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; bess@ietf.org; 
jorge.raba...@nokia.com; draft-ietf-bess-rfc7432...@ietf.org
Subject: [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: [bess] 
Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Sasha,



I agree with you on the following:

1) in the case of EVPN, it is really important to guarantee that MAC-VRFs that 
locally represent the same EVI in different PEs are assigned with different RDs.

2) Type 1 RD is easier to achieve above goal, especially when the RD is 
auto-generated.



But type 0/2 RD can also achieve above goal, and as far as I know, RFC4364 had 
not forbidden this way of using type 0/2 RD. Thus type 0/2 RD don't always 
means the same RD on different PE.

Many existing deployments are using type 0/2 RD. I think it will be enough to 
point out that  "it is important to guarantee that MAC-VRFs that locally 
represent the same EVI in different PEs are assigned with different RDs", but 
don't have to limit it to using type 1 RD. At least a RR is not necessary to 
drop an A-D per ES route with a type 0/2 RD.



Thanks,

Yubao




原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com;draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com;draft-ietf-bess-rfc7432...@ietf.org>;
日 期 ：2023年05月16日 14:38
主 题 ：RE: [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on 
rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,
The scenario in which MAC-VRFs  that locally represent the same EVI in 
different nodes may have severe implications on the EVPN operation.
E.g., consider the scenario in which:

1.   An EVI that implements LAN-based service interface:

a.   Is instantiated in 3 nodes – PE-1, PE-2 and PE-3,

b.   Is attached to single-homed Ethernet Segments in PE-1 and PE2

c.   MAC-VRFs that locally represent this EVI in PE-1 and PE-2 use the same 
RD.

2.   Initially, MAC-VRF in PE-1 locally learns reachability to a certain 
MAC address M from the single-homed Ethernet Segment to which it is attached 
and advertises reachability of this MAC address in an EVPN MAC/IP Advertisement 
(Type 2) route. Both the ESI and Ethernet Tag ID field in the NLRI of this 
route would be set to all zeroes

3.   Both PE-2 and PE-3 receive and install this route in the FDB of their 
MAC-VRFs

4.   At some stage, MAC address M moves to a different customer site and is 
locally learned by the MAC-VRF in PE-2 from the single-homed Ethernet Segment 
to which it is attached. As the result

a.   PE-2 advertises reachability of M advertises reachability of this MAC 
address in an EVPN MAC/IP Advertisement (Type 2) route and attaches a MAC 
Mobility Extended Community with increased sequence number to this route.

b.   MP-BGP PE-3 receives this route, and notes that the comparable fields 
of its NLRI (RD, ES, Ethernet Tag ID, MAC address and IP address (if present)  
match these fields of a route that it has received from PE-1 because MAC-VRFs 
in PE-1 and PE2 have been assigned with the same RD. In this case BGP performs 
the path selection 
process<https://clicktime.symantec.com/15siFALgFKas5JtDZqXdd?h=-T2xqjUfkPMbEt_Cp2ext_w2CFe6Iq8wYb89TuKRhWU=&a

Re: [bess] [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

th such usage.
  2.  Therefore:
 *   I think that both the restriction to just Type 1 RDs in EVPN per ES 
Ethernet A-D routes and recommendation to assign Type 1 RDs for MAC-VRFs should 
be retained in 7432bis
 *   I also suggest adding a recommendation in 7432bis to use the same IP 
address in the Administartor subfield of Type 1 RDs of all EVPN routes 
advertised by a specific PE.

Regards,
Sasha

From: wang.yub...@zte.com.cn 
Sent: Tuesday, May 16, 2023 7:07 AM
To: Alexander Vainshtein 
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org; 
bess@ietf.org; jorge.raba...@nokia.com
Subject: [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on 
rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Sasha,



When a MAC-VRF use a type 1 RD,  is it expected that the RD of the EVPN 
Instance has differnet RD on different PE? When a MAC-VRF use a type 2 RD,  is 
it expected that the RD of the EVPN Instance has the same RD on different PE?

In many deployment, whether the RD of the EVPN Instance has different RD-value 
on different PE is independent of the RD-type.

The RD of A-D per ES route is limited to type 1 RD just because orther RD-types 
are assumed that they will have the same value for a specified EVI on different 
PEs.

Is my understanding correct?



Another way is constructing each A-D per ES route separately by using the RD of 
corresponding MAC-VRF, as described in 
draft-rabadan-bess-evpn-inter-domain-opt-b.



Thanks,

Yubao




原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com>;
日 期 ：2023年05月15日 21:24
主 题 ：RE: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,
Can you please clarify what you mean by “another way to construct A-D per ES 
route has been in sight”?

From my POV using Type 1 RDs in all types of EVPN routes has multiple 
advantages – starting from the fact that it prevents RRs suppressing routes 
advertised by different PEs as part of the BGP path selection process. (The 
same actually applies for VPN-IP routes as well). IMHO and FWIW the operators 
should be discouraged from using other RD types even when it is not already 
prohibited.
The bottom line: For the record I strongly oppose the proposal to relax the 
limitation on RDs in EVPN per ES Ethernet A- (Type 1) routes that exists from 
the -00 revision of the EVPN 
draft<https://clicktime.symantec.com/15sLvSXvBP3UBnNF1aJvo?h=BDT5-g37Z7iFFy2u11jpjIstNkzW3RH-WmA8ATBcgNM=&u=https://datatracker.ietf.org/doc/html/draft-ietf-l2vpn-evpn-00%23section-10.1.2>.

Regards,
Sasha

From: wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn> 
mailto:wang.yub...@zte.com.cn>>
Sent: Monday, May 15, 2023 3:56 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>;
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>; 
jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>
Subject: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Sasha,



Thanks for your helpful notes.

There is only one method to determine the RD of A-D per ES routes in the 
original years of RFC7432, but now there are at least two methods to determine 
the RD of A-D per ES routes.

If it is the only reason why RFC7432 restrict the RD of A-D per ES route to 
type 1 RD, maybe it is a good chance for the restriction to be relaxed, because 
another way to construct A-D per ES route has been in sight.

The original way can still be “RECOMMENDED”while other ways don't have to be 
forbidden. Maybe we can say that it is out of the scope of rfc7432bis (but not 
forbidden).



If RFC7432 is not revised, people who decide not to assign Type 1 RDs to  
MAC-VRFs should bear the consequences in mind, including non-applicability of 
the solution suggested in Section 3.1.2 of the EVPN Inter-Domain Option B 
draft<https://clicktime.symantec.com/15siFALMfJ21KxF7rKwJX?h=a68vMaID3OjatSV90lFuCgmEvl0FrxLZtiXQdb2gyNY=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>,
 as you point out in another mail. But when RFC7432 is revised and rfc7432bis 
is still a draft, I think it will be better to take new scenarios into account.



Especially on a RR node,  according to RFC7432 or current rfc7432bis, a RR has 
to discard the A-D per ES routes which don't have a type 1 RD, but a RR is not 
responsible for selecting different RD for different set of route-targets at 
all. A RR has no difficulty to permit a A-D per ES route

Re: [bess] [EXTERNAL] Re:[EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Hi Yubao,
Can you please clarify what you mean by “another way to construct A-D per ES 
route has been in sight”?

From my POV using Type 1 RDs in all types of EVPN routes has multiple 
advantages – starting from the fact that it prevents RRs suppressing routes 
advertised by different PEs as part of the BGP path selection process. (The 
same actually applies for VPN-IP routes as well). IMHO and FWIW the operators 
should be discouraged from using other RD types even when it is not already 
prohibited.
The bottom line: For the record I strongly oppose the proposal to relax the 
limitation on RDs in EVPN per ES Ethernet A- (Type 1) routes that exists from 
the -00 revision of the EVPN 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-l2vpn-evpn-00#section-10.1.2>.

Regards,
Sasha

From: wang.yub...@zte.com.cn 
Sent: Monday, May 15, 2023 3:56 PM
To: Alexander Vainshtein 
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org; 
bess@ietf.org; jorge.raba...@nokia.com
Subject: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Sasha,



Thanks for your helpful notes.

There is only one method to determine the RD of A-D per ES routes in the 
original years of RFC7432, but now there are at least two methods to determine 
the RD of A-D per ES routes.

If it is the only reason why RFC7432 restrict the RD of A-D per ES route to 
type 1 RD, maybe it is a good chance for the restriction to be relaxed, because 
another way to construct A-D per ES route has been in sight.

The original way can still be “RECOMMENDED”while other ways don't have to be 
forbidden. Maybe we can say that it is out of the scope of rfc7432bis (but not 
forbidden).



If RFC7432 is not revised, people who decide not to assign Type 1 RDs to  
MAC-VRFs should bear the consequences in mind, including non-applicability of 
the solution suggested in Section 3.1.2 of the EVPN Inter-Domain Option B 
draft<https://clicktime.symantec.com/15siFALMfJ21KxF7rKwJX?h=a68vMaID3OjatSV90lFuCgmEvl0FrxLZtiXQdb2gyNY=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>,
 as you point out in another mail. But when RFC7432 is revised and rfc7432bis 
is still a draft, I think it will be better to take new scenarios into account.



Especially on a RR node,  according to RFC7432 or current rfc7432bis, a RR has 
to discard the A-D per ES routes which don't have a type 1 RD, but a RR is not 
responsible for selecting different RD for different set of route-targets at 
all. A RR has no difficulty to permit a A-D per ES route with other RD-type to 
pass through, while it has to discard it according to current rfc7432bis.



Thanks,

Yubao




原始邮件
发件人：AlexanderVainshtein
收件人：王玉保10045807;
抄送人：draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;bess@ietf.org;jorge.raba...@nokia.com>;
日 期 ：2023年05月15日 16:09
主 题 ：RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b
Yubao,
Please note that an EVPN PE that s attached to a MH ES, generally speaking, has 
to generate multiple per-ES A-D routes with the ESI of this MH ES in their NLRI.
This happens because:

·   The set of these routes, in its entirety, must carry the Route Targets 
of all the EVI that are local attached to this MH ES

·   The number of Route Targets that can be caried in a single BGP Update 
message is limited.

For BGP path selection process not to suppress some of these routes, these 
routes in this set must include different RDs in their NLRI.
Since the set of these routes changes dynamically as new EVIs are attached 
to/detached from the MS EH in question, these RDs have to be auto-generated by 
the PE itself.
This, in its turn requires usage of Type 1 RDs because these can be 
auto-generated by the PEs while remaining globally unique.

The bottom line: Restriction of RDs used in the NLRI of per-ES Ethernet A-D 
routes cannot be relaxed.

Hope this helps.

Regards,
Sasha

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
wang.yub...@zte.com.cn<mailto:wang.yub...@zte.com.cn>
Sent: Monday, May 15, 2023 10:40 AM
To: jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>
Cc: 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org<mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>;
 rfc7432...@ietf.org<mailto:rfc7432...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Jorge,



I think the description in draft-rabadan-bess-evpn-inter-domain-opt-b is OK. 
But I don't know why the RD of AD per ES route is limited to type 1 RD. That's 
why I talk about this together with rfc7432bis.

If the s

Re: [bess] [EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Yubao,
Please note that an EVPN PE that s attached to a MH ES, generally speaking, has 
to generate multiple per-ES A-D routes with the ESI of this MH ES in their NLRI.
This happens because:

  *   The set of these routes, in its entirety, must carry the Route Targets of 
all the EVI that are local attached to this MH ES
  *   The number of Route Targets that can be caried in a single BGP Update 
message is limited.

For BGP path selection process not to suppress some of these routes, these 
routes in this set must include different RDs in their NLRI.
Since the set of these routes changes dynamically as new EVIs are attached 
to/detached from the MS EH in question, these RDs have to be auto-generated by 
the PE itself.
This, in its turn requires usage of Type 1 RDs because these can be 
auto-generated by the PEs while remaining globally unique.

The bottom line: Restriction of RDs used in the NLRI of per-ES Ethernet A-D 
routes cannot be relaxed.

Hope this helps.

Regards,
Sasha

From: BESS  On Behalf Of wang.yub...@zte.com.cn
Sent: Monday, May 15, 2023 10:40 AM
To: jorge.raba...@nokia.com
Cc: draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org; 
bess@ietf.org
Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b




Hi Jorge,



I think the description in draft-rabadan-bess-evpn-inter-domain-opt-b is OK. 
But I don't know why the RD of AD per ES route is limited to type 1 RD. That's 
why I talk about this together with rfc7432bis.

If the scenario from draft-rabadan-bess-evpn-inter-domain-opt-b has shown out 
that it will be useful for the RD-type of AD per ES route being consistence 
with MAC-VRF RD, I think maybe it is not necessary for rfc7432bis to keep these 
restraints unchanged. I notice that you are also a co-author of rfc7432bis, how 
do you think from the viewpoint of rfc7432bis?



Thanks,

Yubao




原始邮件
发件人：JorgeRabadan(Nokia)
收件人：王玉保10045807;draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;rfc7432...@ietf.org;
抄送人：bess@ietf.org;
日 期 ：2023年05月13日 00:23
主 题 ：Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b
Hi Yubao,

Thanks for reviewing the document.
I don’t see any conflicting information:


·   On one hand the use of type 1 RD for MAC-VRF is RECOMMENDED in 
rfc7432bis, which means that normally people will have a type 1 RD in MAC-VRFs. 
If you don’t follow that strong recommendation for the MAC-VRF RD, you can’t 
use the documented solutions in 3.1.2 or 3.1.3

·   On the other hand draft-rabadan-bess-evpn-inter-domain-opt-b is 
documenting some existing solutions, but not specifying or imposing any in 
particular.

So I don’t think there is conflicting information. But if you still think we 
should clarify that in draft-rabadan-bess-evpn-inter-domain-opt-b we’ll be 
happy to do it.

Thanks.
Jorge

From: wang.yub...@zte.com.cn 
mailto:wang.yub...@zte.com.cn>>
Date: Friday, May 12, 2023 at 4:54 AM
To: 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org
 
mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>>,
 Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
rfc7432...@ietf.org 
mailto:rfc7432...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

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 Authors,



It seems that draft-rabadan-bess-evpn-inter-domain-opt-b has conflicting 
discription with rfc7432 about the RD-type of AD per ES routes:



Section 3.1.3 of draft-rabadan-bess-evpn-inter-domain-opt-b-00:   "If that is 
the case, now the A-D per ES routes can use the route distinguisher assigned to 
the EVPN Instance (or VRF), which is the same one used by the routes type 2 or 
5 for the EVI."

Section 8.2.1 of rfc7432bis: "The Route Distinguisher MUST be a Type 1 RD 
[RFC4364].  The value field comprises an IP address of the PE (typically, the 
loopback address) followed by a number unique to the PE."



The RD of EVI is not always a Type 1 RD but rfc7432 says that the RD of AD per 
ES route MUST be a Type1 RD. If it is not necessary to prevent other RD-types 
from being used in AD per ES routes, is it better for rfc7432bis to change the 
"MUST" to "MAY" ?  I think such change is also compatible.



Thanks,

Yubao



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 imm

Re: [bess] [EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

[Alexander Vainshtein]

Jorge, Yubao and all,
A couple of comments.

The current version of 
7432bis  
says that:

  *   Per-ES EVPN A-D routes MUST use Type 1 RDs with the Administrator field 
comprising “an IP address of the PE (typically, the loopback address)”
  *   Per-EVI EVPN A-D routes and EVPN MAC/IP Advertisement routes advertised 
by an EVPN Instance locally represented by a MAC-VRF use the RD that is 
assigned to this MAC-VRF, and usage of   Type 1 RD with the Administrator field 
comprising “an IP address of the PE (typically, the loopback address)” is 
RECOMMENDED.

RFC 2119 says that “the adjective "RECOMMENDED", mean that there may exist 
valid reasons in particular circumstances to ignore a particular item, but the 
full implications must be understood and carefully weighed before choosing a 
different course”. Therefore, I concur with Jorge that people who decide not to 
assign Type 1 RDs to  MAC-VRFs should bear the consequences in mind, including 
non-applicability of the solution suggested in Section 3.1.2 of the EVPN 
Inter-Domain Option B 
draft.

However,  neither 7432bis nor any other RFC or standard I am aware of says that 
the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as 
the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs 
assigned to MAC-VRFs.  And this is obviously a precondition for using the 
solution suggested in Section 3.1.2.

IMHO and FWIW adding a corresponding RECOMMENDATION to the 7432bis draft would 
be very much in place.

I also have some doubts regarding solution that is documented in Section 3.1.3 
of the EVPN Inter-Domain Option B draft because:

  *   Only implementations that do not use OPTIONAL per EVI EVPN A-D routes can 
benefit from this solution. In all other cases the per EVI Mass Withdrawal 
solution (documented in Section 3.1 of the draft)  would work exactly as well
  *   Such implementations could not benefit from aliasing and/or backup path 
EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus 
severely compromising any benefits of the Mass Withdrawal mechanisms.

Hopefully these notes will be useful.

Regards,
Sasha




Regards,
Sasha

From: BESS  On Behalf Of Jorge Rabadan (Nokia)
Sent: Friday, May 12, 2023 7:23 PM
To: wang.yub...@zte.com.cn; 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org; rfc7432...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and 
draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Yubao,

Thanks for reviewing the document.
I don’t see any conflicting information:


-   On one hand the use of type 1 RD for MAC-VRF is RECOMMENDED in rfc7432bis, 
which means that normally people will have a type 1 RD in MAC-VRFs. If you 
don’t follow that strong recommendation for the MAC-VRF RD, you can’t use the 
documented solutions in 3.1.2 or 3.1.3

-   On the other hand draft-rabadan-bess-evpn-inter-domain-opt-b is documenting 
some existing solutions, but not specifying or imposing any in particular..

So I don’t think there is conflicting information. But if you still think we 
should clarify that in draft-rabadan-bess-evpn-inter-domain-opt-b we’ll be 
happy to do it.

Thanks.
Jorge

From: wang.yub...@zte.com.cn 
mailto:wang.yub...@zte.com.cn>>
Date: Friday, May 12, 2023 at 4:54 AM
To: 
draft-rabadan-bess-evpn-inter-domain-op...@ietf.org
 
mailto:draft-rabadan-bess-evpn-inter-domain-op...@ietf.org>>,
 Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, 
rfc7432...@ietf.org 
mailto:rfc7432...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

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 Authors,



It seems that draft-rabadan-bess-evpn-inter-domain-opt-b has conflicting 
discription with rfc7432 about the RD-type of AD per ES routes:



Section 3.1.3 of draft-rabadan-bess-evpn-inter-domain-opt-b-00:   "If that is 
the case, now the A-D per ES routes can use the route distinguisher assigned to 
the EVPN Instance (or VRF), which is the same one used by the routes type 2 or 
5 for the EVI."

Section 8.2.1 of rfc7432bis: "The Route Distinguisher MUST be a Type 1 RD 
[RFC4364].  The value field comprises an IP address of the PE (typically, the 
loopback address) followed by a number unique to the PE."



The RD of EVI is not always a Type 1 RD but rfc7432 says that the RD of AD per 
ES route MUST be a Type1 RD. If it is not necessary to prevent other RD-types 
from being used in AD per ES routes, is it better for rfc7432bis to change the 
"MUST" to "MAY" ?

Re: [bess] Questions about Section 4.4.3 of RFC 9136

[Alexander Vainshtein]

Jorge,
Again lots of thanks for a prompt and very useful response.

With regard to mapping routes that are installed in the VRF RIB following 
recursive resolution of EVPN Type-5 routes:

I consider bringing this issue to the attention of the RTGWG and the authors of 
the RIB Extension YANG Data Model 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-rib-extend-18>.

What do you think?

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, May 8, 2023 3:48 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; Wim Henderickx (Nokia) ; 'John E 
Drake' ; Wen Lin ; Ali Sajassi (sajassi) 

Subject: [EXTERNAL] Re: Questions about Section 4.4.3 of RFC 9136

Hi Sasha,

Please see in-line.
Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, May 7, 2023 at 9:00 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Wim Henderickx (Nokia) 
mailto:wim.henderi...@nokia.com>>, 'John E Drake' 
mailto:jdr...@juniper.net>>, Wen Lin 
mailto:w...@juniper.net>>, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Subject: RE: Questions about Section 4.4.3 of RFC 9136

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 your response.
Please see some comments to your responses inline below.



Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, May 4, 2023 3:39 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Wim 
Henderickx (Nokia) mailto:wim.henderi...@nokia.com>>; 
'John E Drake' mailto:jdr...@juniper.net>>; Wen Lin 
mailto:w...@juniper.net>>; Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] Re: Questions about Section 4.4.3 of RFC 9136

Hi Sasha,

I'm doing my best to answer your questions in-line below. Some others may want 
to chime in too.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, April 30, 2023 at 4:04 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Wim Henderickx 
(Nokia) mailto:wim.henderi...@nokia.com>>, 'John E 
Drake' mailto:jdr...@juniper.net>>, Wen Lin 
mailto:w...@juniper.net>>, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Questions about Section 4.4.3 of RFC 9136

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 all,
Adding one more item in Q2 of the original email...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, April 30, 2023 10:52 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>; 'John E Drake' 
mailto:jdr...@juniper.net>>; Wen Lin 
mailto:w...@juniper.net>>; Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Questions about Section 4.4.3 of RFC 9136
Importance: High

Hi all,
I have a couple of question about Section 4.4.3 of RFC 
9136<https://clicktime.symantec.com/15siFAGbNprHbhZ3At8JV?h=h9FlN1MttgnCaUgbweyTGHngXB9zrsasMRBQlsGAesY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23section-4.4.3>.
This section discusses usage of EVPN IP Prefix (Type 5 routes) in the 
Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB scenario.

Q1:  Is this scenario relevant for IP-VRFs that carry IPv6 customer traffic? To 
the best of my understanding:

1.   In this case the IRB that connects IP-VRFs in different NVEs/DGEs to 
the SBD are IPv6-capable interfaces

2.   As per Section 2.1 of RFC 
4291<https://clicktime.symantec.com/15siKzTsqSXt1eNxiSXT7?h=vMYxCTxue7GkBRb8ICviR24o4qBo7bl2OZ-omBypsew=&u=https://www.rfc-editor.org/rfc/rfc4291.html%23section-2.1>
 "All interfaces are required to have at least one Link-Local unicast address". 
Specifically, each IRB MUST possess at  least a unicast link-local IPv6 address

3.   Link-local IPv6 addresses of the IRBs that connect IP-VRFs in 
different NVEs and DGEs SHOULD be different, otherwise the IPv6 Duplicated 
Address Detection check (see Section 5.4 of RFC 4862) would fail. If this 
condition is met, the scenario defined in section 4.4.2 of RFC 9136 becomes 
applicable.


[jorge] yes, the scenario is applicable too. You're right that IPv6-capable 
IRBs have at least an LLA, but you may still use the model in 4.4.3 if you want 
to use a MAC as an overlay index. Otherwise using the LLA as GW-IP overlay 

Re: [bess] Questions about Section 4.4.3 of RFC 9136

[Alexander Vainshtein]

Jorge,
Lots of thanks for your response.
Please see some comments to your responses inline below.



Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Thursday, May 4, 2023 3:39 AM
To: Alexander Vainshtein ; Wim Henderickx 
(Nokia) ; 'John E Drake' ; Wen 
Lin ; Ali Sajassi (sajassi) 
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Questions about Section 4.4.3 of RFC 9136

Hi Sasha,

I'm doing my best to answer your questions in-line below. Some others may want 
to chime in too.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, April 30, 2023 at 4:04 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Wim Henderickx 
(Nokia) mailto:wim.henderi...@nokia.com>>, 'John E 
Drake' mailto:jdr...@juniper.net>>, Wen Lin 
mailto:w...@juniper.net>>, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Questions about Section 4.4.3 of RFC 9136

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 all,
Adding one more item in Q2 of the original email...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, April 30, 2023 10:52 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>; 'John E Drake' 
mailto:jdr...@juniper.net>>; Wen Lin 
mailto:w...@juniper.net>>; Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Questions about Section 4.4.3 of RFC 9136
Importance: High

Hi all,
I have a couple of question about Section 4.4.3 of RFC 
9136<https://clicktime.symantec.com/15siFAGbNprHbhZ3At8JV?h=h9FlN1MttgnCaUgbweyTGHngXB9zrsasMRBQlsGAesY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23section-4.4.3>.
This section discusses usage of EVPN IP Prefix (Type 5 routes) in the 
Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB scenario.

Q1:  Is this scenario relevant for IP-VRFs that carry IPv6 customer traffic? To 
the best of my understanding:

1.   In this case the IRB that connects IP-VRFs in different NVEs/DGEs to 
the SBD are IPv6-capable interfaces

2.   As per Section 2.1 of RFC 
4291<https://clicktime.symantec.com/15siKzTsqSXt1eNxiSXT7?h=vMYxCTxue7GkBRb8ICviR24o4qBo7bl2OZ-omBypsew=&u=https://www.rfc-editor.org/rfc/rfc4291.html%23section-2.1>
 "All interfaces are required to have at least one Link-Local unicast address". 
Specifically, each IRB MUST possess at  least a unicast link-local IPv6 address

3.   Link-local IPv6 addresses of the IRBs that connect IP-VRFs in 
different NVEs and DGEs SHOULD be different, otherwise the IPv6 Duplicated 
Address Detection check (see Section 5.4 of RFC 4862) would fail. If this 
condition is met, the scenario defined in section 4.4.2 of RFC 9136 becomes 
applicable.


[jorge] yes, the scenario is applicable too. You're right that IPv6-capable 
IRBs have at least an LLA, but you may still use the model in 4.4.3 if you want 
to use a MAC as an overlay index. Otherwise using the LLA as GW-IP overlay 
index would be the model in 4.4.2.
[[Sasha]] Got, it, lots of thanks! At the same time, I wonder if there could be 
any specific reason for the operator to prefer using MAC addresses as overlay 
indices when link-local addresses of IPv6-capable IRBs addresses are in any 
case available and can be used as overlay indices?

Q2: Does this scenario implicitly introduce unnumbered LAN interfaces in IPv4?
[jorge] it introduces concepts specific to EVPN IP-VRF-to-IP-VRF models, one of 
them the SBD, which can have an unnumbered IRB.
[[Sasha]] IMHO and FWIW IRB as a LAN interface has been a well-understood 
concept long before emergence of EVPN. Do you imply that an unnumbered IRB is 
limited to EVPN IP-VRF-to-IP-VRF model with SBD?


1.   Unnumbered IPv4 interfaces are discussed in multiple IETF standards 
(RFC 1812, RFC 2328, RFC 5309 and more)

a.   AFAIK, in all these documents unnumbered IPv4 interfaces are 
restricted to be "point-to-point lines" (using the terminology of RFC 1812)

b.   The IRBs that connect IP-VRFs in different NVEs/DGEs to the SBD are 
unnumbered but obviously not point-to-point
[jorge] as per the above comment, RFC9136 is very specific to the use of EVPN 
in IP-VRFs, the concepts here do not apply generically, but only to EVPN IP 
Prefix routes.


2.   Consider the network depicted in Figure 10 in the section in question 
and suppose that the operator of this network wants to check IP connectivity 
between IP-VRF in DGW1 and host IP1.

a.   Can the operator ping IP1 from IP-VRF in DFW1?

b.   If yes, then which source IP address would be used in the ping packets?
[jorge] in figure 10, BD1 is conne

Re: [bess] Questions about Section 4.4.3 of RFC 9136

[Alexander Vainshtein]

Hi all,
Adding one more item in Q2 of the original email...

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, April 30, 2023 10:52 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) ; 
wim.henderi...@nokia.com; 'John E Drake' ; Wen Lin 
; Ali Sajassi (sajassi) 
Cc: bess@ietf.org
Subject: Questions about Section 4.4.3 of RFC 9136
Importance: High

Hi all,
I have a couple of question about Section 4.4.3 of RFC 
9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.3>.
This section discusses usage of EVPN IP Prefix (Type 5 routes) in the 
Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB scenario.

Q1:  Is this scenario relevant for IP-VRFs that carry IPv6 customer traffic? To 
the best of my understanding:

1.   In this case the IRB that connects IP-VRFs in different NVEs/DGEs to 
the SBD are IPv6-capable interfaces

2.   As per Section 2.1 of RFC 
4291<https://www.rfc-editor.org/rfc/rfc4291.html#section-2.1> "All interfaces 
are required to have at least one Link-Local unicast address". Specifically, 
each IRB MUST possess at  least a unicast link-local IPv6 address

3.   Link-local IPv6 addresses of the IRBs that connect IP-VRFs in 
different NVEs and DGEs SHOULD be different, otherwise the IPv6 Duplicated 
Address Detection check (see Section 5.4 of RFC 4862) would fail. If this 
condition is met, the scenario defined in section 4.4.2 of RFC 9136 becomes 
applicable.

Q2: Does this scenario implicitly introduce unnumbered LAN interfaces in IPv4?

  1.  Unnumbered IPv4 interfaces are discussed in multiple IETF standards (RFC 
1812, RFC 2328, RFC 5309 and more)
 *   AFAIK, in all these documents unnumbered IPv4 interfaces are 
restricted to be "point-to-point lines" (using the terminology of RFC 1812)
 *   The IRBs that connect IP-VRFs in different NVEs/DGEs to the SBD are 
unnumbered but obviously not point-to-point
  2.  Consider the network depicted in Figure 10 in the section in question and 
suppose that the operator of this network wants to check IP connectivity 
between IP-VRF in DGW1 and host IP1.
 *   Can the operator ping IP1 from IP-VRF in DFW1?
 *   If yes, then which source IP address would be used in the ping packets?
  3.  Consider the network depicted in Figure 10 in the section in question and 
suppose that a management system that uses the base RIB data model defined in 
RFC 8439<https://www.rfc-editor.org/rfc/rfc8349> retrieves the RIB of the 
IP-VRF in DGW1 after EVPN IP Prefix routes to host IP1 and to subnets SN1 and 
SN2 have been received and installed.
 *   What will the management receive as the next hops and egress 
interfaces of these routes?
 *   Will these routes be perceived as labeled routes, and if yes, how 
would the management system be able to differentiate between these routes and 
routes received as VPNv4/VPNv6 routes?







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

[bess] Questions about Section 4.4.3 of RFC 9136

[Alexander Vainshtein]

Hi all,
I have a couple of question about Section 4.4.3 of RFC 
9136.
This section discusses usage of EVPN IP Prefix (Type 5 routes) in the 
Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB scenario.

Q1:  Is this scenario relevant for IP-VRFs that carry IPv6 customer traffic? To 
the best of my understanding:

  1.  In this case the IRB that connects IP-VRFs in different NVEs/DGEs to the 
SBD are IPv6-capable interfaces
  2.  As per Section 2.1 of RFC 
4291 "All interfaces 
are required to have at least one Link-Local unicast address". Specifically, 
each IRB MUST possess at  least a unicast link-local IPv6 address
  3.  Link-local IPv6 addresses of the IRBs that connect IP-VRFs in different 
NVEs and DGEs SHOULD be different, otherwise the IPv6 Duplicated Address 
Detection check (see Section 5.4 of RFC 4862) would fail. If this condition is 
met, the scenario defined in section 4.4.2 of RFC 9136 becomes applicable.

Q2: Does this scenario implicitly introduce unnumbered LAN interfaces in IPv4?

  1.  Unnumbered IPv4 interfaces are discussed in multiple IETF standards (RFC 
1812, RFC 2328, RFC 5309 and more)
 *   AFAIK, in all these documents unnumbered IPv4 interfaces are 
restricted to be "point-to-point lines" (using the terminology of RFC 1812)
 *   The IRBs that connect IP-VRFs in different NVEs/DGEs to the SBD are 
unnumbered but obviously not point-to-point
  2.  Consider the network depicted in Figure 10 in the section in question and 
suppose that the operator of this network wants to check IP connectivity 
between IP-VRF in DGW1 and host IP1.
 *   Can the operator ping IP1 from IP-VRF in DFW1?
 *   If yes, then which source IP address would be used in the ping packets?

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] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard

[Alexander Vainshtein]

Jorge,
Lots of thanks for your response.

It seems we are mainly on the same page.

It would be nice if you could clarify the point about "a group of PW that share 
the same pair of unidirectional LSPs" and mention the need to identify the 
ingress LSP from which the PW packets have been received by the EVPN PE in the 
text of the draft.
Such a text would fully resolve my comment.

Regards,
Sasha



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


From: Jorge Rabadan (Nokia) 
Sent: Thursday, April 27, 2023, 20:18
To: Alexander Vainshtein 
Cc: bess@ietf.org ; last-c...@ietf.org ; 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org 

Subject: [EXTERNAL] Re: Last Call: 
 (EVPN Virtual Ethernet 
Segment) to Proposed Standard

Hi Sasha,

I think the misunderstanding could be solved if we worded the association to 
the virtual ES differently. The association is really to a group of PWs that 
share the same unidirectional LSP pair (rather than to the LSP, which I can see 
why is confusing). The multi-homing procedures are done on the PWs and not on 
the LSPs. In other words, in Figure 2, we could two vESes composed of PW3/PW5 
and PW4/PW6, or you could group them together and have only one vES, i.e. 
PW3+PW4/PW5+PW6. The latter is a way to reduce the amount of ethernet segments 
given that e.g., PW3 and PW4 share fate in case one of their transport LSPs 
fail.

About the additional questions:


1.   It is my understanding that in the case of LSP as a multi-homed 
virtual Ethernet Segment, the service carving algorithm would be applied to 
each individual PW aggregated in this LSP. E.g., in the example of Figure 2 in 
the draft, the situation in which PW3 is elected as the DF in the {PW3, PW5} 
pair while  PW6 is elected as the DF in the {PW4, PW6} pair may occur. Can you 
please confirm is this correct?

Yes. Note that we are using the definition of Ethernet Tag as in RFC8584, where 
the Ethernet Tag can be a configured ID or configured EVI value, or etc. as 
long as it represents the BD and it is consistently configured on all the PEs 
attached to the ES.


2.   If (1) above is correct, can you please clarify, which value should be 
used as the Ethernet Tag of the specific PW in this LSP, since the reverence to 
a VLAN ID in Section 3.5 of the draft looks problematic to me.
See above. In the implementations that I know of, an ID identifying the BD is 
configured consistently in the PEs attached to the ES. That can be a VLAN ID or 
an EVI or anything as per RFC8584. I don’t see a problem here.

Thanks.
Jorge


From: Alexander Vainshtein 
Date: Thursday, April 20, 2023 at 5:23 PM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , last-c...@ietf.org , 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org 

Subject: RE: Last Call:  (EVPN 
Virtual Ethernet Segment) to Proposed Standard

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

I will try to summarize our agreements and disagreements.
I also have an additional question regarding usage of LSPs as virtual Explicit 
Segments.

First, the summary:


1.   As I see, we agree that LSP as a virtual Ethernet Segment actually 
means  “a pair of unidirectional LSPs where the origination endpoint of one 
matches the termination endpoint of the other”, so that one direction of the 
aggregated PWs uses on of these LSPs and the other direction – the other one.  
(This presumably implies that the two LSPs also share the life span).

2.   We also seem agree that the (data plane of the) EVPN PE that acts as 
the tail-end of one of these LSPs MUST be able to identify the PW packets it 
receives as being delivered in this LSP.  This precludes using PHP towards EVPN 
PE

Neither of these points is explicitly mentioned in the current version of the 
draft (or at least I have not found any mention of them).

Our disagreement seems to be entirely about references to MPLS-TP:


1.   You object to restricting LSPs as virtual Ethernet Segment to MPLS-TP 
and static PWs.

2.   From my POV:

a.   A pair of unidirectional LSPs with a common life span and such that 
the head-end of one matches the tail-end of the other and vice versa is exactly 
what RFC 59060 calls an “associated bidirectional LSP” in MPLS-TP

b.   MPLS-TP also strongly discourages usage of PHP

c.These definitions do not say anything about the method by which such 
a pair of LSPs and the PWs that us it are set up:


   i.  RFC 
6373<https://clicktime.symantec.com/15siFAEXoqZFzL2ph9fzk?h=BRKc2hwfLrEKYungZ6EQviPdp8eBkvLX4NvHb9xOC9s=&u=https://datatracker.ietf.org/doc/html/rfc6373>
 defines a framework for dynamically signaling various types of MPLS-TP LSPs 
and states that the common PW con

Re: [bess] [EXTERNAL] Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Alexander Vainshtein]

Eric, 
Regarding 
Regarding your second DISCUSS point "I wonder how the length of the "IP Prefix" 
field can be known by the receiver ?"

This length can be unambiguously inferred from the length of the IP Prefix 
sub-TLV because in accordance with Section 3.1 of RFC 9136 the IP Prefix and 
the GW IP address in the NLRI of EVPN IP Prefix 9Type 5) routes MUST be from 
the same family (either both are IPv4 or both are IPv6).

At the same time I fully agree that this deserves explicit clarification by the 
authors.

Regards,
Sasha

-Original Message-
From: BESS  On Behalf Of ?ric Vyncke via Datatracker
Sent: Monday, April 24, 2023 1:02 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: [EXTERNAL] [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-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://clicktime.symantec.com/15sM1Gc6AY26NeWG4mtjV?h=fMSSL2DZa8PWDKeoV_WU98RtZ1-L1Go5M78gceLKtvE=&u=https://clicktime.symantec.com/15sM1Gc6AnEk2fPYRAnxP?h=rPr4T36xJXeX7CYjROGRv7E-Y3MeayQviNlHFtXZ8Tc=&u=https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://clicktime.symantec.com/15sLvSQohvLVxhgLXDVas?h=rFOi45hn5CAcc0c3p0NleETW_n-OSK0Pf0DNfFoo42E=&u=https://clicktime.symantec.com/15sLvSQoiAZ9ciZcscPom?h=Cr9Yso3cP5WwFFjth2L43SXrblZNgEgKKxzAH8vK6No=&u=https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
DISCUSS:
--

Thank you for the work put into this document, it can only help operations.

Please find below two blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education).

Special thanks to Matthew Bocci for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in 
https://clicktime.symantec.com/15sM66oNd9hgnbLBcLHt7?h=x8dkjmRZ81ni2AVC8joih18UQqV2oxAR7Em7a3BWl1A=&u=https://clicktime.symantec.com/15sM66oNdPvLScDTxjC71?h=5XSWHNDO-opR1Y6OamjkBG1vzlnpfQlQ2CL4mkzUFqo=&u=https://www.ietf.org/blog/handling-iesg-ballot-positions/,
 a
DISCUSS ballot is a request to have a discussion on the following topics:

## Missing normative references

Even experienced authors sometimes forget to add normative references to RFC
2119 and RFC 8174 ;-)

## Section 4.4

Probably due to my lack of knowledge about EVPN and RFC 9136 et al, but I
wonder how the length of the "IP Prefix" field can be known by the receiver ?
There is a "IP Prefix length" field but it seems to indicate the prefix length,
e.g., "IP Prefix Len" field could be 32 bit but the "IP Prefix" field itself
could be the 128-bit value of 2001:db8::

May I strongly suggest adding clarification text if my understanding is
incorrect ?


--
COMMENT:
--


# COMMENTS (non blocking)

## Typos

I had not the same patience as Jim Guichard for catching all typos... But, it
is surprising that there are so many left at this stage of the publication
process. Please run a proof reader.

## Section 1

Please expand "PBB" at first use.

## Section 4.1

Even if the old RFC 7432 (dated 8 years ago) only understands 48-bit MAC
addresses, there are MAC addresses with different length. Should this document
handle those MAC addresses ?

## Section 6.1

Is there a reason why the MAC addresses are not written in the IEEE standard
way ? I.e., "00aa.00bb.00cc" should be written as "00-AA-00-BB-00-CC".

In 2023, I would have preferred to have an IPv6 example rather than an IPv4 one.

## Section 7

Are there mitigation techniques ?



___
BESS mailing list
BESS@ietf.org
https://clicktime.symantec.com/15sMAvzf5mPHCYA79th2j?h=WI06Ako5IJmLuIla9F1zhaKaDEXnk883qS1Jz3RuUms=&u=https://clicktime.symantec.com/15sMAvzf61bvrZ3PWHbFd?h=RGO6_50UhoLvzyc-G-VPtVBF1vBVxf2NAxF_-ZzMmw4=&u=https://www.ietf.org/mailman/listinfo/bess

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 for

Re: [bess] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

I will try to summarize our agreements and disagreements.
I also have an additional question regarding usage of LSPs as virtual Explicit 
Segments.

First, the summary:


  1.  As I see, we agree that LSP as a virtual Ethernet Segment actually means  
“a pair of unidirectional LSPs where the origination endpoint of one matches 
the termination endpoint of the other”, so that one direction of the aggregated 
PWs uses on of these LSPs and the other direction – the other one.  (This 
presumably implies that the two LSPs also share the life span).
  2.  We also seem agree that the (data plane of the) EVPN PE that acts as the 
tail-end of one of these LSPs MUST be able to identify the PW packets it 
receives as being delivered in this LSP.  This precludes using PHP towards EVPN 
PE

Neither of these points is explicitly mentioned in the current version of the 
draft (or at least I have not found any mention of them).

Our disagreement seems to be entirely about references to MPLS-TP:


  1.  You object to restricting LSPs as virtual Ethernet Segment to MPLS-TP and 
static PWs.
  2.  From my POV:
 *   A pair of unidirectional LSPs with a common life span and such that 
the head-end of one matches the tail-end of the other and vice versa is exactly 
what RFC 59060 calls an “associated bidirectional LSP” in MPLS-TP
 *   MPLS-TP also strongly discourages usage of PHP
 *   These definitions do not say anything about the method by which such a 
pair of LSPs and the PWs that us it are set up:

   i.  RFC 
6373<https://datatracker.ietf.org/doc/html/rfc6373> defines a framework for 
dynamically signaling various types of MPLS-TP LSPs and states that the common 
PW control plane can be used for signaling PWs that use MPLS-TP LSPs

 ii.  AFAIK 
there are implementations of such a control plane.
From my POV, my comment would be resolved if you clarified the above-mentioned 
points of agreement even without mentioning MPLS-TP.

Now my additional question.

Sections 3.5 and  4.1 of the draft explain how the  default (“service carving”) 
DF Election algorithm as defined in RFC 7432  could be used with virtual 
Ethernet Segments.

  1.  It is my understanding that in the case of LSP as a multi-homed virtual 
Ethernet Segment, the service carving algorithm would be applied to each 
individual PW aggregated in this LSP. E.g., in the example of Figure 2 in the 
draft, the situation in which PW3 is elected as the DF in the {PW3, PW5} pair 
while  PW6 is elected as the DF in the {PW4, PW6} pair may occur. Can you 
please confirm is this correct?
  2.  If (1) above is correct, can you please clarify, which value should be 
used as the Ethernet Tag of the specific PW in this LSP, since the reverence to 
a VLAN ID in Section 3.5 of the draft looks problematic to me.

Regards, and lots opf thanks in advance
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Wednesday, April 19, 2023 9:50 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; last-c...@ietf.org; 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org
Subject: [EXTERNAL] Re: Last Call: 
 (EVPN Virtual Ethernet 
Segment) to Proposed Standard

Hi Sasha,

“To me this is equivalent to your definition.”

Sure, however, I was not excluding any LSP type, and I don’t think we need to, 
since the actions are really happening on the PWs riding on those LSPs.
So if your suggestion is that we should add text to restrict this to static PWs 
and MPLS-TP LSPs, I don’t agree. That does not reflect what implementations are 
doing.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Wednesday, April 19, 2023 at 7:47 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
last-c...@ietf.org<mailto:last-c...@ietf.org> 
mailto:last-c...@ietf.org>>, 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>
 
mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>>
Subject: Re: Last Call:  (EVPN 
Virtual Ethernet Segment) to Proposed Standard

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 your response.

This indeed may be a matter of terminology.
Section 3.1.3 of RFC 
5960<https://clicktime.symantec.com/15t5eiByNXDkfTWSFy5rH?h=PWpabQIfD818Y8rD_hEEip92W5R9D2ueQAbFw4T-z2Y=&u=https://datatracker.ietf.org/doc/html/rfc5960%23section-3.1.3>
 says:



   A point-to-point associated bidirectional LSP between LSRs A and B

   consists of two unidirectional point-to-point LSPs, one from A to B

   and the other from B to A, which are regarded as a pair providing a

   single logical

Re: [bess] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard

[Alexander Vainshtein]

Jorge,
Lots of thanks for your response.

This indeed may be a matter of terminology.
Section 3.1.3 of RFC 
5960 says:



   A point-to-point associated bidirectional LSP between LSRs A and B
   consists of two unidirectional point-to-point LSPs, one from A to B
   and the other from B to A, which are regarded as a pair providing a
   single logical bidirectional transport path.


To me this is equivalent to your definition.


Did I miss something substsntial?

Regards,
Sasha





Get Outlook for Android

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] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

AFAIK it is perfectly valid to advertise Implicit Null label for a FEC 
representing a local address in RSVP-TE.
And I am not sure what you mean by "single-hop LSPs in general".

>From my POV, LSP are, generally speaking, unidirectional while PWs and 
>Ethernet Segments are inherently bi-directional.
In the case of Ethernet Segments:

  *   Their egress direction affects the results of DF election
  *   Their ingress direction affects inclusion - or non-inclusion of ESI label 
in certain copies of flooded BUM traffic.
So I still think that if you want to treat an LSP as a virtual Ethernet 
Segment, you need a bi-directional LSP (Be it MPLS-TP or not).

The draft, in its current form, simply ignores these differences.
What, if anything, do I miss?

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, April 17, 2023 9:08 AM
To: Alexander Vainshtein ; last-ca...@ietf.org; 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Last Call: 
 (EVPN Virtual Ethernet 
Segment) to Proposed Standard

Hi Sasha,

There would be more cases where you can identify traffic coming from a given 
LSP.
For instance RSVP-TE, or single-hop LSPs in general, etc - there is no need for 
bidirectional MPLS-TP.

The text itself implicitly refers to the cases where PWs can be aggregated into 
a common LSP, so not sure if anything else is needed.

Thanks.
Jorge



From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, April 16, 2023 at 5:44 PM
To: last-ca...@ietf.org<mailto:last-ca...@ietf.org> 
mailto:last-ca...@ietf.org>>, 
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>
 
mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>>
Cc: GTD-SYS-Packet Solutions 
mailto:gtd-sys-packet-soluti...@rbbn.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: Re: Last Call:  (EVPN 
Virtual Ethernet Segment) to Proposed Standard

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 all,
I have doubts regarding the text in Section 1.2 of the draft that refers to 
LSPs (as opposed to PWs) as virtual Ethernet Segments.

The problematic (from my POV) text refers to Figure 2 and says (the problematic 
part is highlighted):


   In such scenarios, a virtual ES (vES) is defined as a set of
   individual PWs if they cannot be aggregated into a common LSP.  If
   the aggregation of PWs is possible, the vES can be associated to an
   LSP in a given PE.  In the example of Figure 2, EVC3 is connected to
   a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and
   PW5 respectively.  EVC4 is connected to a separate VPWS instance on
   AG2 that gets connected to an EVI on PE1 and PE2 via PW4 and PW6,
   respectively.  Since the PWs for the two VPWS instances can be
   aggregated into the same LSPs going to the MPLS network, a common
   virtual ES can be defined for LSP1 and LSP2.  This vES will be shared
   by two separate EVIs in the EVPN network.


The problem with the highlighted text is that PE1 and PE2 always can identify 
the PW from which they receive this or that packet, but, in most cases, cannot 
identify the LSP in which this PW has been running.
(The only exception of which I am aware, is the case of static PWEs in 
bi-directional MPLS-TP LSPs).
If LSP1 and LSP2 were components of a common virtual MH ES,  PE1, upon 
reception of a BUM packet from PW4, would not be able to identify this MH ES 
and to insert a suitable ESI label into the EVPN encapsulation of the copy it 
would be sending to PE2.

IMHO and FWIW some clarification (e.g., restricting ability to use LSPs as 
virtual Ethernet Segments to just bi-directional MPLS-TP LSPs?) would be very 
much in place.

Hopefully these notes will be useful.

Regards,
Sasha


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to 
consider the following document: - 'EVPN Virtual Ethernet Segment'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the 
last-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2023-04-27. 
Exceptionally, comments may be sent to i...@ietf.org<mailto:i...@ietf.org> 
instead. In either case, please retain the beginning of the Subject line to 
allow automated sorting.

Abstract


   EVPN and PBB-EVPN 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 for an Ethernet Segment (ES),
   itself defined as a set of physical links between the mul

Re: [bess] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard

[Alexander Vainshtein]

Hi all,
I have doubts regarding the text in Section 1.2 of the draft that refers to 
LSPs (as opposed to PWs) as virtual Ethernet Segments.

The problematic (from my POV) text refers to Figure 2 and says (the problematic 
part is highlighted):


   In such scenarios, a virtual ES (vES) is defined as a set of
   individual PWs if they cannot be aggregated into a common LSP.  If
   the aggregation of PWs is possible, the vES can be associated to an
   LSP in a given PE.  In the example of Figure 2, EVC3 is connected to
   a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and
   PW5 respectively.  EVC4 is connected to a separate VPWS instance on
   AG2 that gets connected to an EVI on PE1 and PE2 via PW4 and PW6,
   respectively.  Since the PWs for the two VPWS instances can be
   aggregated into the same LSPs going to the MPLS network, a common
   virtual ES can be defined for LSP1 and LSP2.  This vES will be shared
   by two separate EVIs in the EVPN network.


The problem with the highlighted text is that PE1 and PE2 always can identify 
the PW from which they receive this or that packet, but, in most cases, cannot 
identify the LSP in which this PW has been running.
(The only exception of which I am aware, is the case of static PWEs in 
bi-directional MPLS-TP LSPs).
If LSP1 and LSP2 were components of a common virtual MH ES,  PE1, upon 
reception of a BUM packet from PW4, would not be able to identify this MH ES 
and to insert a suitable ESI label into the EVPN encapsulation of the copy it 
would be sending to PE2.

IMHO and FWIW some clarification (e.g., restricting ability to use LSPs as 
virtual Ethernet Segments to just bi-directional MPLS-TP LSPs?) would be very 
much in place.

Hopefully these notes will be useful.

Regards,
Sasha


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to 
consider the following document: - 'EVPN Virtual Ethernet Segment'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the 
last-c...@ietf.org mailing lists by 2023-04-27. Exceptionally, comments may be 
sent to i...@ietf.org instead. In either case, please retain the beginning of 
the Subject line to allow automated sorting.

Abstract


   EVPN and PBB-EVPN 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 for an Ethernet Segment (ES),
   itself defined as a set of physical links between the multi-homed
   device/network and a set of PE devices that they are connected to.
   This document extends the Ethernet Segment concept so that an ES can
   be associated to a set of EVCs (e.g., VLANs) or other objects such as
   MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as
   Virtual Ethernet Segments (vES).  This draft describes the
   requirements and the extensions needed to support vES in EVPN and
   PBB-EVPN.





The file can be obtained via
https://clicktime.symantec.com/15sLvSMFe6yJaL7it9kEb?h=WX7sPrWtPYj6YArP1_IG-VUvi72ntJf3jPZD8aotZlk=&u=https://clicktime.symantec.com/15siFA9u7fT6Pcy1rRzYE?h=oH6e_3PB3X1eWGKah_83SV7rAO13MiTubvXyMPWLSs4=&u=https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/


The following IPR Declarations may be related to this I-D:

   
https://clicktime.symantec.com/15sM1GYY6ietzGweRi9PD?h=LatO2AZiVAH39lrwHIwya5amzj8HrV_kDAIVEAeg85M=&u=https://clicktime.symantec.com/15siKzMBaH8goZnwPzPgr?h=2sUb0zrdQ5wcPvhgS2fD7IYQBGY3koDFG7wzpwkjYlU=&u=https://datatracker.ietf.org/ipr/3169/
   
https://clicktime.symantec.com/15sMAvw71x25pAbVWpwgT?h=GdR-katv1Fmx1tCzKJUyhSBiuWnAI85UP95ltcuRR_U=&u=https://clicktime.symantec.com/15siVejkVWVsdTSnV7Bz6?h=sT7aE2ZEJl5mDkO4HW9iizdbIbzENVSMXvgn_zrG5lg=&u=https://datatracker.ietf.org/ipr/3354/
   
https://clicktime.symantec.com/15sM66jpZLLVQDmZyGYXq?h=Hr8E955Kl0orr2_O8JUL1JHDwJMJS1wH8Q2F_JhQIrM=&u=https://clicktime.symantec.com/15siQpYU2tpHDWcrwYnqU?h=vhhGcaEYULDbhQhTesln7lZn7Qj-ZfAKgO-VH6KAeCU=&u=https://datatracker.ietf.org/ipr/3353/





Regards,
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] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Hi Jorge,
Lots of thanks for a prompt response.

I have explained my position with regard to IP Aliasing for RT-5 in 
Interface-less IP-VRF-to-IP-VRF model in my previous email.
I only can add that the neither the metadata of the IP Aliasing draft nor its 
text specify an update to RFC 9136.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, April 3, 2023 4:17 AM
To: Alexander Vainshtein ; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Cc: bess@ietf.org; Dmitry Valdman ; Nitsan Dolev 
; Michael Gorokhovsky ; 
Ron Sdayoor ; Egon Haparnass ; Shell 
Nakash ; Marina Fizgeer ; Orly 
Kariv ; Moti Morgenstern ; 
Rotem Cohen 
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Please see in-line with [jorge].

Thanks for the good questions/points.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, March 26, 2023 at 11:16 PM
To: 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Dmitry Valdman mailto:dmitry.vald...@rbbn.com>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>, Michael 
Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>, Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>, Egon Haparnass 
mailto:ehaparn...@rbbn.com>>, Shell Nakash 
mailto:shell.nak...@rbbn.com>>, Marina Fizgeer 
mailto:marina.fizg...@rbbn.com>>, Orly Kariv 
mailto:orly.ka...@rbbn.com>>, Moti Morgenstern 
mailto:moti.morgenst...@rbbn.com>>, Rotem Cohen 
mailto:rotem.co...@rbbn.com>>
Subject: Question and comments on the EVPN IP Aliasing draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See 
https://clicktime.symantec.com/15t5Zsu7ZPvvXHNzW589B?h=3ceHKr8YVLM3UOko-NyIuMmvVO2HwRp1fi1RLBdLkNo=&u=http://nok.it/ext
 for additional information.


Hi all,
A few questions and comments on the EVPN IP Aliasing 
draft<https://clicktime.symantec.com/15t5ei6Q21cWwECv3dXHo?h=hLCOzcf5t8oR3LIGwDra1wBHCN4UcxyL3SN_N-D7vPY=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>:


1.   Section 3 of the draft states that a PE that is attached to a MH ES  
shall advertise a set of IP per ES A-D routes, and Section 4.1 says that these 
routes shall be tagged with Export RTs of all IP-VRFs attached to this MH ES. 
The following is not mentioned:

a.   Should the ESI Label Extended Community be attached to these routes? 
My guess (FWIW) is that this is necessary, since this is the only way to let 
the remote PEs to know the MH mode of the MH ES in question.
[jorge] correct

b.   Assuming an affirmative answer to the previous question, what should 
the ESI Label Extended Community attached to these routes carry in its Label 
field? My guess (FWIW)  is that his field is not relevant and should be set to 
all zeroes.
[jorge] yes. We can add a sentence to that respect. The label field SHOULD be 
set to 0 and MUST be ignored on reception.


2.   Section 3 of the draft says that “a remote PE that receives an EVPN 
MAC/IP Advertisement route or an IP Prefix route with a non-reserved ESI and 
the RT of a particular IP-VRF SHOULD consider it reachable by every PE that has 
advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF”:

a.   Is the statement above applicable in the case of a MH ES in 
Single-Active MH Mode? My guess is that it is only applicable to MH Es in 
All-Active MH mode
[jorge] same as in rfc7432bis, both modes


   i.  If the answer to the previous question 
is negative, should the PE that receives an EVPN Type 2 route for an IP→MAC 
pair treat the IP address in this pair reachable only via he PE that has 
advertised this route and treating other PEs as “backup PEs” (similar to what 
is defined in Section 14.1.1 of RFC 
7432<https://clicktime.symantec.com/15t5pNUxwEyhm7rm8kKb3?h=m9ESlNFEXlL5s4xyn-g6bmr0dWvx9li2FHAjKrC16c0=&u=https://www.rfc-editor.org/rfc/rfc7432.html%23section-14.1.1>)?
[jorge] yes, assuming that PE the has received the AD routes.


 ii.  The suggestion to attach the Layer 2 
Attributes Extended Community to the per EVI IP A-D route in Section 3.1 of the 
draft seems to support my guesses above


   iii.  I also think that if the MH ES in 
Single-Active mode is attached o more than 2 PEs, the Layer 2 Attributes 
Extended Community MUST be attached to EVPN per EVI IP A-D routes.
[jorge] at the moment the ad

Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Alexander Vainshtein]

Re-sending with a reduced list of addressees…

Regards,
Sasha

From: Alexander Vainshtein
Sent: Wednesday, March 29, 2023 11:30 AM
To: 'bess@ietf.org' 
Cc: Dmitry Valdman ; Nitsan Dolev 
; Michael Gorokhovsky ; 
Ron Sdayoor ; Egon Haparnass ; Shell 
Nakash ; Marina Fizgeer ; Orly 
Kariv ; Moti Morgenstern ; 
Rotem Cohen ; 
'draft-rabadan-bess-evpn-inter-domain-opt-b.auth...@ietf.org' 
; 
'draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org' 

Subject: RE: Question and comments on the EVPN IP Aliasing draft
Importance: High

Hi all,
#3 issue in my original email seems to equally affect mass withdrawal of IP 
Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario in general.
This scenario is mentioned in Section 3.1 of the EVPN Inter-Domain Option-B 
Solution 
draft<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-00#section-3.1>.

My guess (FWIW) is an update of RFC 9136 is needed to address this issue.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Monday, March 27, 2023 12:16 PM
To: 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Dmitry Valdman 
mailto:dmitry.vald...@rbbn.com>>; Nitsan Dolev 
mailto:nitsan.do...@rbbn.com>>; Michael Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>; Ron 
Sdayoor mailto:ron.sday...@rbbn.com>>; Egon Haparnass 
mailto:ehaparn...@rbbn.com>>; Shell Nakash 
mailto:shell.nak...@rbbn.com>>; Marina Fizgeer 
mailto:marina.fizg...@rbbn.com>>; Orly Kariv 
mailto:orly.ka...@rbbn.com>>; Moti Morgenstern 
mailto:moti.morgenst...@rbbn.com>>; Rotem Cohen 
mailto:rotem.co...@rbbn.com>>
Subject: Question and comments on the EVPN IP Aliasing draft

Hi all,
A few questions and comments on the EVPN IP Aliasing 
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>:


1.   Section 3 of the draft states that a PE that is attached to a MH ES  
shall advertise a set of IP per ES A-D routes, and Section 4.1 says that these 
routes shall be tagged with Export RTs of all IP-VRFs attached to this MH ES. 
The following is not mentioned:

a.   Should the ESI Label Extended Community be attached to these routes? 
My guess (FWIW) is that this is necessary, since this is the only way to let 
the remote PEs to know the MH mode of the MH ES in question.

b.   Assuming an affirmative answer to the previous question, what should 
the ESI Label Extended Community attached to these routes carry in its Label 
field? My guess (FWIW)  is that his field is not relevant and should be set to 
all zeroes.

2.   Section 3 of the draft says that “a remote PE that receives an EVPN 
MAC/IP Advertisement route or an IP Prefix route with a non-reserved ESI and 
the RT of a particular IP-VRF SHOULD consider it reachable by every PE that has 
advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF”:

a.   Is the statement above applicable in the case of a MH ES in 
Single-Active MH Mode? My guess is that it is only applicable to MH Es in 
All-Active MH mode


   i.  If the answer to the previous question 
is negative, should the PE that receives an EVPN Type 2 route for an IP→MAC 
pair treat the IP address in this pair reachable only via he PE that has 
advertised this route and treating other PEs as “backup PEs” (similar to what 
is defined in Section 14.1.1 of RFC 
7432<https://www.rfc-editor.org/rfc/rfc7432.html#section-14.1.1>)?


 ii.  The suggestion to attach the Layer 2 
Attributes Extended Community to the per EVI IP A-D route in Section 3.1 of the 
draft seems to support my guesses above


   iii.  I also think that if the MH ES in 
Single-Active mode is attached o more than 2 PEs, the Layer 2 Attributes 
Extended Community MUST be attached to EVPN per EVI IP A-D routes.

3.   I have to admit that I do not understand how IP Aliasing should work 
for EVPN IP Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario 
mentioned in Section 1.2 of he draft:

a.   Table 1 in RFC 
9136<https://datatracker.ietf.org/doc/html/rfc9136#fields_overlay_table> states 
that a non-zero ESI value in the NLRI of IP Prefix routes is used as an Overlay 
index for recursive resolution, while that the Label value in such a NLRI is 
“Don’t Care”.

b.   At the same time, section 4.1.1 of this RFC states that the ESI field 
of the NLRI f these routes is set to all zeroes in the Interface-less 
IP-VRF-to-IP-VRF scenario while the Label field in the NRLI of

Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

[Alexander Vainshtein]

Saumya,
More of the same - quoting from Section 2 of RFC 
4360<https://www.rfc-editor.org/rfc/rfc4360#section-2> (the relevant text is 
highlighted):



   The Extended Communities Attribute is a transitive optional BGP
   attribute, with the Type Code 16.  The attribute consists of a set of
   "extended communities".  All routes with the Extended Communities
   attribute belong to the communities listed in the attribute.

The term “set” in this context (as opposed to “list”) means that the order in 
which specific Extended Communities appear in this attribute is not relevant.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Monday, March 27, 2023 1:09 PM
To: Dikshit, Saumya 
Cc: bess@ietf.org; Jorge Rabadan (Nokia) 
Subject: RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
Lots of thanks for a prompt response.

I do not think that the order in which RTs appear in the list of extended 
communities has any significance in any application.
In particular, this order is not specified in RFC 9135, so that nothing 
prevents an otherwise interoperable implementation to add the IP-VRF Export RT 
first and the MAC-VRF RT second.

Regards,
Sasha

From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Sent: Monday, March 27, 2023 11:56 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Subject: [EXTERNAL] RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha,

I had picked up a very simple example, in context of Route-Type-1 handling as 
it’s ambiguous as compared to Route-Type-2 handling (2nd label and 2nd 
Route-Target can be associated with IP-VRF while processing). I am sure, there 
may be many-more combinations/deployments/configurations which can lead to 
issues, if it’s worth digging into them.
That’s even more a reason to call it out explicitly in this new draft and/or 
flag it off as IP-VRF and not leave it to the operator.

Coming to your below example:
>>> As a consequence, MAC-VRF in PE-3 will install this route, but it will not 
>>> install any routes to MAC addresses that have been learned by the MAC-VRF 
>>> in PE-1 from traffic.
[SD] PE-3 can still ignore absorbing anything against Route-Target-2 in MAC-VRF 
(from MAC/IP route), as it can take clue from the fact that Route-Target-2 
(corresponding to Label-2) is the 2nd route-target carried in the MAC/IP route, 
other than Route-Target-1 (corresponding to Label-1). But I agree that MAC-only 
routes will not be absorbed at all as it will carry only Route-Target-1.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com]
Sent: Sunday, March 26, 2023 6:25 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Subject: RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
My guess (FWIW) is that the operator should not “reuse” RTs used for L3 VPNs in 
EVPN - and vice versa.

If this rule of the thumb is violated, lots of unpleasant things can happen 
even without IP aliasing.

Egg,, consider the case in which:
*   PE1 contains a MAC-VRF with RT-1 and an IP-VRF with RT-2 that are 
connected by a Symmetric IRB
*   PE-2 contains an IP-VRF with RT-2
*   PE-3 contains a MAC-VRF with RT-2.
When MAC-VRF inPE-1 learns some IP→MAC pair {IP1, M1} from ARP/ND, it 
advertises an EVPN Type 2 route with RT-1 and Rt-2 attached. As a consequence, 
MAC-VRF in PE-3 will install this route, but it will not install any routes to 
MAC addresses that have been learned by the MAC-VRF in PE-1 from traffic.

My 2c,
Sasha

From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Sent: Sunday, March 26, 2023 3:52 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Jorge 
Rabadan (Nokia) mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha, Jorge and all

Consider the simplistic scenario of BGP-EVPN-Peers (and Vteps), PE1 and PE2 
(might be in different/same fabrics/sites/pods), wherein,

*   PE1 supports both IP A-D and MAC A-D whereas

*   PE2 supports legacy of MAC A-D.

PE1 publishes:

*   MAC A-D with Route-Target1 (for EVI-1/VNI-1/Bride-domain-1) and

*   IP A-D (for EVI-2/VNI-2/local-VRF-x) with Route-Target2
indicating MAC aliasing and IP aliasing respectively.

Whereas, PE2 is configured for

*(EVI-1/VNI-1/Bridge-domain-1) for importing with Route-Target1, and

*(EVI-2/VNI-2/Bridge-domain-2) for importing with Route-Target2

PE2 can surely mistake IP A-D published by PE1 for a MAC A-D and
establishes it’s next-hop database (ecmp or otherwize) accord

Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

[Alexander Vainshtein]

Saumya,
Lots of thanks for a prompt response.

I do not think that the order in which RTs appear in the list of extended 
communities has any significance in any application.
In particular, this order is not specified in RFC 9135, so that nothing 
prevents an otherwise interoperable implementation to add the IP-VRF Export RT 
first and the MAC-VRF RT second.

Regards,
Sasha

From: Dikshit, Saumya 
Sent: Monday, March 27, 2023 11:56 AM
To: Alexander Vainshtein 
Cc: bess@ietf.org; Jorge Rabadan (Nokia) 
Subject: [EXTERNAL] RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha,

I had picked up a very simple example, in context of Route-Type-1 handling as 
it’s ambiguous as compared to Route-Type-2 handling (2nd label and 2nd 
Route-Target can be associated with IP-VRF while processing). I am sure, there 
may be many-more combinations/deployments/configurations which can lead to 
issues, if it’s worth digging into them.
That’s even more a reason to call it out explicitly in this new draft and/or 
flag it off as IP-VRF and not leave it to the operator.

Coming to your below example:
>>> As a consequence, MAC-VRF in PE-3 will install this route, but it will not 
>>> install any routes to MAC addresses that have been learned by the MAC-VRF 
>>> in PE-1 from traffic.
[SD] PE-3 can still ignore absorbing anything against Route-Target-2 in MAC-VRF 
(from MAC/IP route), as it can take clue from the fact that Route-Target-2 
(corresponding to Label-2) is the 2nd route-target carried in the MAC/IP route, 
other than Route-Target-1 (corresponding to Label-1). But I agree that MAC-only 
routes will not be absorbed at all as it will carry only Route-Target-1.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com]
Sent: Sunday, March 26, 2023 6:25 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Subject: RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya,
My guess (FWIW) is that the operator should not “reuse” RTs used for L3 VPNs in 
EVPN - and vice versa.

If this rule of the thumb is violated, lots of unpleasant things can happen 
even without IP aliasing.

Egg,, consider the case in which:
*   PE1 contains a MAC-VRF with RT-1 and an IP-VRF with RT-2 that are 
connected by a Symmetric IRB
*   PE-2 contains an IP-VRF with RT-2
*   PE-3 contains a MAC-VRF with RT-2.
When MAC-VRF inPE-1 learns some IP→MAC pair {IP1, M1} from ARP/ND, it 
advertises an EVPN Type 2 route with RT-1 and Rt-2 attached. As a consequence, 
MAC-VRF in PE-3 will install this route, but it will not install any routes to 
MAC addresses that have been learned by the MAC-VRF in PE-1 from traffic.

My 2c,
Sasha

From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Sent: Sunday, March 26, 2023 3:52 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Jorge 
Rabadan (Nokia) mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha, Jorge and all

Consider the simplistic scenario of BGP-EVPN-Peers (and Vteps), PE1 and PE2 
(might be in different/same fabrics/sites/pods), wherein,

*   PE1 supports both IP A-D and MAC A-D whereas

*   PE2 supports legacy of MAC A-D.

PE1 publishes:

*   MAC A-D with Route-Target1 (for EVI-1/VNI-1/Bride-domain-1) and

*   IP A-D (for EVI-2/VNI-2/local-VRF-x) with Route-Target2
indicating MAC aliasing and IP aliasing respectively.

Whereas, PE2 is configured for

*(EVI-1/VNI-1/Bridge-domain-1) for importing with Route-Target1, and

*(EVI-2/VNI-2/Bridge-domain-2) for importing with Route-Target2

PE2 can surely mistake IP A-D published by PE1 for a MAC A-D and
establishes it’s next-hop database (ecmp or otherwize) accordingly against the 
Bridge-domain-2 instead of ignoring the IP A-D advertisement.

The difference between IP A-D/MAC A-D (Route type-1) and the Route Type-2 is 
that

*   in Route Type-2, the second label and the second route-target imply 
that its being carried for IP-VRF

*   whereas , in Route Type-1, it comes down to configuration and operators 
prerogative to take care of it.


https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2<https://clicktime.symantec.com/15sM1GSZo6UHTMFNWpX2g?h=G4kq24V2sHHnLgNQaaqdkxzq2a1liVTw7LqgPSNsECc=&u=https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2>
If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route 
Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but 
the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST 
ignore the MPLS Label2 field and install the MAC address in the corresponding 
MAC-VRF and (IP, MAC) association in the 

Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

[Alexander Vainshtein]

Saumya,
My guess (FWIW) is that the operator should not “reuse” RTs used for L3 VPNs in 
EVPN - and vice versa.

If this rule of the thumb is violated, lots of unpleasant things can happen 
even without IP aliasing.

Egg,, consider the case in which:

  *   PE1 contains a MAC-VRF with RT-1 and an IP-VRF with RT-2 that are 
connected by a Symmetric IRB
  *   PE-2 contains an IP-VRF with RT-2
  *   PE-3 contains a MAC-VRF with RT-2.
When MAC-VRF inPE-1 learns some IP→MAC pair {IP1, M1} from ARP/ND, it 
advertises an EVPN Type 2 route with RT-1 and Rt-2 attached. As a consequence, 
MAC-VRF in PE-3 will install this route, but it will not install any routes to 
MAC addresses that have been learned by the MAC-VRF in PE-1 from traffic.

My 2c,
Sasha

From: Dikshit, Saumya 
Sent: Sunday, March 26, 2023 3:52 PM
To: Alexander Vainshtein ; Jorge Rabadan (Nokia) 

Cc: bess@ietf.org
Subject: [EXTERNAL] RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Sasha, Jorge and all

Consider the simplistic scenario of BGP-EVPN-Peers (and Vteps), PE1 and PE2 
(might be in different/same fabrics/sites/pods), wherein,

*   PE1 supports both IP A-D and MAC A-D whereas

*   PE2 supports legacy of MAC A-D.

PE1 publishes:

*   MAC A-D with Route-Target1 (for EVI-1/VNI-1/Bride-domain-1) and

*   IP A-D (for EVI-2/VNI-2/local-VRF-x) with Route-Target2
indicating MAC aliasing and IP aliasing respectively.

Whereas, PE2 is configured for

*(EVI-1/VNI-1/Bridge-domain-1) for importing with Route-Target1, and

*(EVI-2/VNI-2/Bridge-domain-2) for importing with Route-Target2

PE2 can surely mistake IP A-D published by PE1 for a MAC A-D and
establishes it’s next-hop database (ecmp or otherwize) accordingly against the 
Bridge-domain-2 instead of ignoring the IP A-D advertisement.

The difference between IP A-D/MAC A-D (Route type-1) and the Route Type-2 is 
that

*   in Route Type-2, the second label and the second route-target imply 
that its being carried for IP-VRF

*   whereas , in Route Type-1, it comes down to configuration and operators 
prerogative to take care of it.


https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2<https://clicktime.symantec.com/15sM1GSZo6UHTMFNWpX2g?h=G4kq24V2sHHnLgNQaaqdkxzq2a1liVTw7LqgPSNsECc=&u=https://www.rfc-editor.org/rfc/rfc9135.html%23section-5.2>
If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route 
Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but 
the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST 
ignore the MPLS Label2 field and install the MAC address in the corresponding 
MAC-VRF and (IP, MAC) association in the ARP table for that tenant (identified 
by the corresponding IP-VRF Route Target).

For above reasons, we should have an explicit flagging off and/or atleast a 
dedicate section in the draft for calling-out this scenario,
as we don’t have an organic/implicit way of distinguishing between IP-VRF and 
MAC-VRF related attributes being carried in Route-Type-1, unlike a Route-Type-2.

Regards,
Saumya.

From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com]
Sent: Saturday, March 25, 2023 6:43 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>; Dikshit, Saumya 
mailto:saumya.diks...@hpe.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Saumya, Jorge and all,
FWIW I concur with Jorge.

The draft states than an IP per EVI EVPN A-D route:
1. Includes RD of IO-VEF in its NLRI
2. Carries RT of IP-VRF.
Assuming that Import RTs of MAC-VRFs and IP-VRFs in any given PE are different, 
I do not see any potential for wrong mapping.

My 2c,
Sasha

Get Outlook for 
Android<https://clicktime.symantec.com/15sLvSFHLUnh3QRSyG7t4?h=GyX9YOygLsY9e_Nf9hF6oQ03ZR4tPLXHzRlhgVl7z-A=&u=https://aka.ms/AAb9ysg>


From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Friday, March 24, 2023, 23:26
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: [EXTERNAL] Re: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Saumya,

I don’t think there is any need for especial flagging and the route-target will 
identify in which VRF the route needs to be imported.
We have other cases in which a route type can be imported into a MAC-VRF or 
IP-VRF (see RFC9135) and there is no especial ‘flag’ for it. This has not 
caused any issues so I don’t see why A-D routes would create issues either, to 
me it is the same thing.

Thanks.
Jorge


From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Date: Friday, March 24, 2023 at 6:50 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>

Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

[Alexander Vainshtein]

Saumya, Jorge and all,
FWIW I concur with Jorge.

The draft states than an IP per EVI EVPN A-D route:

  1.  Includes RD of IO-VEF in its NLRI
  2.  Carries RT of IP-VRF.

Assuming that Import RTs of MAC-VRFs and IP-VRFs in any given PE are different, 
I do not see any potential for wrong mapping.

My 2c,
Sasha

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


From: Jorge Rabadan (Nokia) 
Sent: Friday, March 24, 2023, 23:26
To: Dikshit, Saumya ; Alexander Vainshtein 

Cc: bess@ietf.org 
Subject: [EXTERNAL] Re: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Saumya,

I don’t think there is any need for especial flagging and the route-target will 
identify in which VRF the route needs to be imported.
We have other cases in which a route type can be imported into a MAC-VRF or 
IP-VRF (see RFC9135) and there is no especial ‘flag’ for it. This has not 
caused any issues so I don’t see why A-D routes would create issues either, to 
me it is the same thing.

Thanks.
Jorge


From: Dikshit, Saumya 
Date: Friday, March 24, 2023 at 6:50 AM
To: Jorge Rabadan (Nokia) , Alexander Vainshtein 

Cc: bess@ietf.org 
Subject: RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See 
https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext
 for additional information.


Thank You Jorge.

Since it’s already on the field, I have few follow up queries related to 
“Interworking with BGP-Peers capable of ONLY MAC-aliasing”:

As I understand that the draft does not proposes any new PDU constructs and 
leverages existing ones (as defined for MAC-aliasing in rfc7432) to publish IP 
A-D per ES and IP A-D per EVI (EVPN Route Type 1) for IP-aliasing and 
fast-convergence respectively.

1.  For interworking with “BGP-EVPN peers” that comply only to MAC-aliasing 
and not to IP-aliasing, are there any explicit procedures defined in the draft ?

2.  As it’s expected to be Route-Target based absorption/dropping of the IP 
A-D (per ES or EVI) NLRI,

a.   is the ONLY implicit way for receive-side BGP-EVPN-Peers (only 
expecting MAC-aliasing in network) to ignore the IP A-D routes.

b.  If “a” is true, then is there a possibility that EVI mappings (MPLS 
Labels, VNIs and corresponding Route-Targets) sent in IP A-D is being leveraged 
by MAC-Aliasing for an Layer-2 configuration (Bridge-domain and corresponding 
Route Targets) and can lead to error in processing.


3.  Instead, will it apt to call out the IP A-D from MAC A-D via an 
explicit flagging in the route itself. It will save the receive side BGP-EVPN 
peer (only doing MAC-aliasing) from processing the IP A-D with no avail. Thus 
saving some processing cycles which may lead to an error state.

It will be great to have a section for “backward compatibility with 
MAC-aliasing ONLY peers”.

Regards,
Saumya.


From: Jorge Rabadan (Nokia) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, March 23, 2023 3:58 PM
To: Dikshit, Saumya ; Alexander Vainshtein 

Cc: bess@ietf.org
Subject: Re: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

Hi Saumya,

Yes, there are implementations deployed in networks.
For the vendor I’m aware of, it includes pretty much all transport tunnels - 
vxlan, mpls, sr-mpls, SRv6…
The use cases in the draft are agnostic of the transport.
Thx
Jorge

From: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Sent: Thursday, March 23, 2023 09:51
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; Jorge 
Rabadan (Nokia) mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See 
http://nok.it/ext<https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext>
 for additional information.


Hello Authors of draft-sajassi-bess-evpn-ip-aliasing,

If there is an implementation reference from any Vendor for this draft 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/<https://clicktime.symantec.com/15siKzEg7Et2KtCx3oBPU?h=wNU3T3Cevp1QqxepBtv7LOJDxf-F4f7-WvODlSy5Hos=&u=https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/>.
It will be good to know if the reference fabric for the implementation. Does it 
includes Vxlan, if not others ?

Regards,
Saumya.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 10, 2023 9:14 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf

Re: [bess] A question about Duplicated MAC Issue in Single Flow-Active multi-homing

[Alexander Vainshtein]

Luc,
Lots of thanks for a prompt and very useful response.

An explicit mention of the possibility of false duplicated MAC detection and a 
recommendation for tuning the parameters of the duplicated MAC detection 
mechanism in accordance with the hold timers of the Layer 2 Control Protocol 
would be fine IMHO.

Regards,
Sasha

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


From: Luc André Burdet 
Sent: Thursday, February 9, 2023, 22:31
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org ; Nitsan Dolev ; 
Alexander Ferdman ; Yair Nissim 
; Evyatar Wiesel ; 
draft-ietf-bess-evpn-l2gw-pr...@ietf.org 

Subject: [EXTERNAL] Re: A question about Duplicated MAC Issue in Single 
Flow-Active multi-homing

Hi Sasha,

The Access Protocol should protect from frequent topology changes—most access 
protocols have dampening or hold-times incorporated.
We can add a note commenting on this possibility though... and a MAY or SHOULD 
increasing limits on mobility procedures for scenarios where unwanted behaviour 
occurs (in case access protocols hold-time is insufficient)

Regards,
Luc André

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


From: Alexander Vainshtein 
Date: Thursday, February 9, 2023 at 12:02
To: draft-ietf-bess-rfc7432...@ietf.org 
Cc: bess@ietf.org , Nitsan Dolev , 
Alexander Ferdman , Yair Nissim 
, Evyatar Wiesel , 
draft-ietf-bess-evpn-l2gw-pr...@ietf.org 

Subject: A question about Duplicated MAC Issue in Single Flow-Active 
multi-homing
Hi,
I have a questions about detection and handling of the duplicated MAC addresses 
(as described in Section 15.1 of the 7432bis 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-06#section-15.1<https://clicktime.symantec.com/15siKyzgnJGPGVhmKQ1jW?h=IS2FntitpqllknQYEDDxwFr8I_uYY3tkFoAz_JLE0_w=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-06%23section-15.1>>)
 in the case of Single Flow-active multihoming as described in the EVPN 
Multi-Homing Mechanism for Layer-2 Gateway 
Protocols<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-02<https://clicktime.symantec.com/15siF9oQKganrYsqmqcat?h=D-1-JOvi3DuqNIG9XB61Zujdb0s1S0QLscs5O9Or4aM=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-02>>
 draft. Section 5 of this draft states:

When a host moves to PE2 from the PE1 L2GW peer, the MAC mobility sequence 
number is incremented to signal to remote peers that a 'move' has occurred and 
the routing tables must be updated to PE2. This is required when an Access 
Protocol is running where the loop is broken between two CEs in the access and 
the L2GWs, and the host is no longer reachable from the PE1-side but now from 
the PE.

This means that frequent topology changes in the Layer 2 customer site  
attached to the EVPN domain via a MH ES in Single Flow-Active multi-homing mode 
could result in false detection of MAC duplidation.
This, in its turn, would result in the L2 GW PEs stopping "sending, updating or 
processing any BGP MAC/IP Advertisement routes" for the MAC addresses affected 
by these topology changes and this, in its turn, would result in (full or 
partial) blackholing of traffic to such MAC addresses.

It is not clear to me how this situation should be handled. One possibility 
that comes to my mind is disabling of the MAC duplication procedures for MAC 
addresses that arre learned fro m MH ES in Single Flow-Active MH mode


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

[bess] A question about Duplicated MAC Issue in Single Flow-Active multi-homing

[Alexander Vainshtein]

Hi,
I have a questions about detection and handling of the duplicated MAC addresses 
(as described in Section 15.1 of the 7432bis 
draft)
 in the case of Single Flow-active multihoming as described in the EVPN 
Multi-Homing Mechanism for Layer-2 Gateway 
Protocols
 draft. Section 5 of this draft states:

When a host moves to PE2 from the PE1 L2GW peer, the MAC mobility sequence 
number is incremented to signal to remote peers that a 'move' has occurred and 
the routing tables must be updated to PE2. This is required when an Access 
Protocol is running where the loop is broken between two CEs in the access and 
the L2GWs, and the host is no longer reachable from the PE1-side but now from 
the PE.

This means that frequent topology changes in the Layer 2 customer site  
attached to the EVPN domain via a MH ES in Single Flow-Active multi-homing mode 
could result in false detection of MAC duplidation.
This, in its turn, would result in the L2 GW PEs stopping "sending, updating or 
processing any BGP MAC/IP Advertisement routes" for the MAC addresses affected 
by these topology changes and this, in its turn, would result in (full or 
partial) blackholing of traffic to such MAC addresses.

It is not clear to me how this situation should be handled. One possibility 
that comes to my mind is disabling of the MAC duplication procedures for MAC 
addresses that arre learned fro m MH ES in Single Flow-Active MH mode.

Your feedback on this question 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] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

[Alexander Vainshtein]

Jorge and all,
I have read the latest revision of the draft and I agree that it is ready for 
the WG adoption call.
>From my POV it meets the two conditions that, IMHO, define WG adoption:

  *   It addresses a real problem
  *   It provides a reasonably good start for solution of this problem.

My 2c,
Sasha

From: BESS  On Behalf Of Jorge Rabadan (Nokia)
Sent: Tuesday, January 10, 2023 3:52 PM
To: bess@ietf.org
Subject: [EXTERNAL] [bess] FW: New Version Notification for 
draft-sajassi-bess-evpn-ip-aliasing-06.txt

FYI

We just updated this draft based on the comments made by Sasha on the list. We 
also fixed some nits and updated references.
We'd like to reiterate that document is ready for WG adoption call.

Thanks.
Jorge

From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Tuesday, January 10, 2023 at 2:40 PM
To: A. Sajassi mailto:saja...@cisco.com>>, G. Badoni 
mailto:gbad...@cisco.com>>, J. Drake 
mailto:jdr...@juniper.net>>, Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, L. Krattiger 
mailto:lkrat...@cisco.com>>, P. Warade 
mailto:pwar...@cisco.com>>, S. Pasupula 
mailto:surpa...@cisco.com>>, Ali Sajassi 
mailto:saja...@cisco.com>>, Gaurav Badoni 
mailto:gbad...@cisco.com>>, John Drake 
mailto:jdr...@juniper.net>>, Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>, Lukas Krattiger 
mailto:lkrat...@cisco.com>>, Priyanka Warade 
mailto:pwar...@cisco.com>>
Subject: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt

A new version of I-D, draft-sajassi-bess-evpn-ip-aliasing-06.txt
has been successfully submitted by J. Rabadan and posted to the
IETF repository.

Name:   draft-sajassi-bess-evpn-ip-aliasing
Revision:   06
Title:  EVPN Support for L3 Fast Convergence and Aliasing/Backup Path
Document date:  2023-01-10
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-sajassi-bess-evpn-ip-aliasing-06

Abstract:
   This document proposes an EVPN extension to allow several of its
   multihoming functions, fast convergence and aliasing/backup path, to
   be used in conjunction with inter-subnet forwarding.  The extension
   is limited to All-Active and Single-Active redundancy modes.




The IETF Secretariat

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] Question regarding section 17.3 draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Menachem,
Please note that the procedures defined in Section 17.3 of RFC 7432 (and of the 
7432bis draft) are not limited to failure of PE-CE links that belong to 
multi-homed Ethernet Segments (MH ES).

If the failed link belongs to a All-Active MH ES, retention of EVPN MAC/IP 
Advertisement routes advertised by the PE in question for MAC addresses locally 
learned by the PE in question:

  1.  Allows remote PEs to continue forwarding traffic with Destination MAC 
addresses in question to other PEs attached to the same MH ES as described in 
Section 8.2 of RFC 7432
  2.  Prevents these MAC addresses being from being stuck forever in the FDBs 
of remote PEs if they are not locally re-learned by one of the remaining PEs 
attached to the same MH ES.

Hope this helps.

Regards,
Sasha

From: Menachem Dodge 
Sent: Monday, January 9, 2023 2:37 PM
To: Alexander Vainshtein ; bess@ietf.org
Subject: [EXTERNAL] Re: Question regarding section 17.3 
draft-ietf-bess-rfc7432bis

Hello Sasha,

Thanks for your response.

If the only reason to keep the MAC addresses at the PE with the failed link is 
for implementing the EVPN Fast Reroute, then would it be possible to state this 
clearly in section 17.3; such that if the EVPN Fast Reroute is not supported or 
the EVPN Redirect Label was not received from the other PEs of that ESI, then 
BGP could send withdraw of MAC/IP Advertisement routes immediately.

Thank you kindly.

Best Regards,
Menachem


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, 9 January 2023 at 14:22
To: Menachem Dodge mailto:mdo...@drivenets.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: RE: Question regarding section 17.3 draft-ietf-bess-rfc7432bis
Menachem and all,
As I see it, Section 17.3 of 
7432bis<https://clicktime.symantec.com/15t5pN1f8G28GkmXKHYMT?h=SjpaaxCyxLAZzwwflrJej0b7trn9LrojCZMcgSkK2h8=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Drfc7432bis-2D06-23section-2D17.3%26d%3DDwMFAg%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DdfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0%26s%3DfHphfhvH0o5QSVnCcrA_dI1yivjVdxbrkq5Bn8ChUsk%26e%3D>
 does not differ from Section 17.3 in RFC 
7432<https://clicktime.symantec.com/15t5uCCwashighbSrqwW5?h=WHsjQh3h8Twd1jPlYfM9vpTX9F0ObZymPu7ZykHmVU0=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttps-3A__www.rfc-2Deditor.org_rfc_rfc7432-23section-2D17.3%26d%3DDwMFAg%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DdfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0%26s%3Dut1QXQIflQEqnm0ubOZ7I_JC1pBwc-Hxzf5QiHhDWX4%26e%3D>.
Both documents only define reaction of the EVPN Control Plane to failure of a 
PE-CE link, and these definitions guarantee that remote PEs would stop sending 
"known unicast" traffic for customer MAC addresses that have been learned from 
the failed link to the affected PE.

If the failed link belonged to a multi-homed Ethernet Segment, fast recovery of 
affected traffic can be provided using the method defined in the EVPN Fast 
Reroute<https://clicktime.symantec.com/15t5jXpNfeLXrowbmj9Cq?h=9bR1ndElY_ypBg4i3gF9fz4-imFmDppGk_XBQmU7nrc=&u=https://urldefense.proofpoint.com/v2/url?u%3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dburdet-2Dbess-2Devpn-2Dfast-2Dreroute-2D03%26d%3DDwMFAg%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DcezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E%26m%3DdfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0%26s%3DQnbRrmQWvX1osKypfiORzfk0pcI1btu8O0d5-A15t4g%26e%3D>
 draft.


Regards,
Sasha

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Menachem Dodge
Sent: Monday, January 9, 2023 10:22 AM
To: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] [bess] Question regarding section 17.3 
draft-ietf-bess-rfc7432bis

Hello All,


In section 17.3 of the draft-ietf-bess-rfc7432bis PE-to-CE Network Failures the 
first paragraph states that:

"If the connectivity between the multihomed CE and one of the PEs to which it 
is attached fails, the PE MUST withdraw the set of Ethernet A-D per ES routes 
that had been previously advertised for that ES."

...

"When the MAC entry on the PE ages out, the PE MUST withdraw the MAC address 
from BGP."

The last paragraph of that section 17.3 states that:

When a PE receives a withdrawal of a particular Ethernet A-D route from an 
advertising PE, it SHOULD consider all the MAC/IP Advertisement routes that are 
learned from the same ESI as in the Ethernet A-D route from the advertising PE 
as having been withdrawn. This optimizes the network convergence times in the 
event of PE-to-CE failures.

Clarification

Please could you explain why the PE that has detected the network failure to 
its CE is retaining the MAC addresses until age-out time, and only then 
withd

Re: [bess] Question regarding section 17.3 draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Menachem and all,
As I see it, Section 17.3 of 
7432bis
 does not differ from Section 17.3 in RFC 
7432.
Both documents only define reaction of the EVPN Control Plane to failure of a 
PE-CE link, and these definitions guarantee that remote PEs would stop sending 
"known unicast" traffic for customer MAC addresses that have been learned from 
the failed link to the affected PE.

If the failed link belonged to a multi-homed Ethernet Segment, fast recovery of 
affected traffic can be provided using the method defined in the EVPN Fast 
Reroute
 draft.


Regards,
Sasha

From: BESS  On Behalf Of Menachem Dodge
Sent: Monday, January 9, 2023 10:22 AM
To: bess@ietf.org
Subject: [EXTERNAL] [bess] Question regarding section 17.3 
draft-ietf-bess-rfc7432bis

Hello All,


In section 17.3 of the draft-ietf-bess-rfc7432bis PE-to-CE Network Failures the 
first paragraph states that:

"If the connectivity between the multihomed CE and one of the PEs to which it 
is attached fails, the PE MUST withdraw the set of Ethernet A-D per ES routes 
that had been previously advertised for that ES."

...

"When the MAC entry on the PE ages out, the PE MUST withdraw the MAC address 
from BGP."

The last paragraph of that section 17.3 states that:

When a PE receives a withdrawal of a particular Ethernet A-D route from an 
advertising PE, it SHOULD consider all the MAC/IP Advertisement routes that are 
learned from the same ESI as in the Ethernet A-D route from the advertising PE 
as having been withdrawn. This optimizes the network convergence times in the 
event of PE-to-CE failures.

Clarification

Please could you explain why the PE that has detected the network failure to 
its CE is retaining the MAC addresses until age-out time, and only then 
withdrawing the MAC/IP Advertisement routes; while all the remote PEs that 
receive the withdrawal of the Ethernet A-D route should be considering all the 
MAC/IP Advertisement routes received from that PE and learned from that ESI as 
having been withdrawn, without waiting for the withdrawal of the MAC/IP 
Advertisement routes. This seems to be inconsistent behavior.

Thank you kindly.

Best Regards,

Menachem Dodge
System Architect
[signature_227873180]
+972-52-617-5734
mdo...@drivenets.com
follow us on 
LinkedIn
www.drivenets.com





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] A doubt in the requirements pertaining to VLAN-aware service interface in draft-ietf-bess-rfc7432bis

[Alexander Vainshtein]

Ali and all,
I have read the new version of Section 6.3 of 7432-bis, and it addresses my 
concerns.

Regards, and lots of thanks for taking care of this issue.
Sasha

From: Ali Sajassi (sajassi) 
Sent: Friday, January 6, 2023 12:09 AM
To: Alexander Vainshtein ; 
draft-ietf-bess-rfc7432bis.auth...@ietf.org
Cc: bess@ietf.org; Ron Sdayoor ; Moti Morgenstern 
; Nitsan Dolev ; Michael 
Gorokhovsky 
Subject: [EXTERNAL] Re: A doubt in the requirements pertaining to VLAN-aware 
service interface in draft-ietf-bess-rfc7432bis

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

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

3)  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 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, November 29, 2022 at 2:18 AM
To: 
draft-ietf-bess-rfc7432bis.auth...@ietf.org<mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>
 
mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Ron Sdayoor mailto:ron.sday...@rbbn.com>>, Moti 
Morgenstern mailto:moti.morgenst...@rbbn.com>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>, Michael 
Gorokhovsky mailto:michael.gorokhov...@rbbn.com>>
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<https://clicktime.symantec.com/15siF9byzEiFPAhs8AxLb?h=vgZyn6M9g5pMAup4Gz6UGHO0ysNqEHAPmpqoYioaG4A=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-05%23section-6.3>
 (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 
VLA

[bess] MAC Move events in EVPN Single Flow-Active Multi-Homing mode

[Alexander Vainshtein]

Hi all,
I have a question about handling of MAC Move events in EVPN Single Flow-Active 
(SFA) multi-homing.

Section 15 of RFC 7432 
defines MAC Move events as following (the relevant text is highlighted):

   It is possible for a given host or end-station (as defined by its MAC
   address) to move from one Ethernet segment to another; this is
   referred to as 'MAC Mobility' or 'MAC move', and it is different from
   the multihoming situation in which a given MAC address is reachable
   via multiple PEs for the same Ethernet segment.


With SFA multi-homing, at any given moment each specific customer MAC address 
is reachable via just one of the multiple PEs for the same Ethernet segment.
And indeed,  Section 5 of the SFA 
draft
 states:


   When a host moves to PE2 from the PE1 L2GW peer, the MAC mobility

   sequence number is incremented to signal to remote peers that a

   'move' has occurred and the routing tables must be updated to PE2.

PE2 and PE1 in Figure 1 in the draft are attached to the same MH ES in SFA 
mode, therefore my reading of the quoted text above is that, with SFA 
multi-homing, MAC Move events are recognized and advertised as such even when a 
given host moves between two PEs attached to the same MH ES.

However, the quoted text appears in only in Section 5 "Inter-Subnet Forwarding" 
of the draft, and this section contains multiple references to RFC 9135.
Therefore, it is not clear to me whether the same rule is applicable to the 
scenarios in which SFA multi-homing should be applicable for intra-subnet 
forwarding scenarios.
My guess (FWIW) that it should be equally applicable, but an explicit 
clarification 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] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Alexander Vainshtein]

Ali,
Again lots of thanks and more comments inline below.

Regards,
Sasha

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

< 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 
mailto:alexander.vainsht...@rbbn.com>>
Date: Wednesday, November 23, 2022 at 11:54 PM
To: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>
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>>, 
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>>
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://clicktime.symantec.com/15sLvRarab44zTHqki3B5?h=-pQqvRTWyDgbZBFNWxJKt61Yx1qwxuredpm7yjxg84g=&u=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.
[[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>> more comments below …

Regards, and lots of thanks in advance,
Sasha

From: Ali Sajassi (sajassi) mailto:saja...@cisco.com>>
Sent: Tuesday, November 22, 2022 2:15 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
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>; 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: [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: [bes