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

[Ali Sajassi (sajassi)]

Hi John

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

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

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

Cheers,
Ali

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

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

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

You say:

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

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

Thanks,

—John

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

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

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

[Ali Sajassi (sajassi)]

Hi John,


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

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

Regards,
Ali

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

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

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

—John

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

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

[Ali Sajassi (sajassi)]

Hi John,

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


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

Cheers,
Ali

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

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

Thanks and happy Friday,

—John

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

--
Status: Verified
Type: Technical

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

Section: 4.2.

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

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

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

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

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

[Ali Sajassi (sajassi)]

Hi John,

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

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

Regards,
Ali


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

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

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

—John

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

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

[Ali Sajassi (sajassi)]

Hi Menachem,

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

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


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

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

Cheers,
Ali


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

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

Thank you kindly for your response.

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

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

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

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

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


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

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

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

Thank you kindly.

Best Regards,
Menachem


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

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

Hi Matthew, Menachem:

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

Cheers,
Ali

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

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

Thank you kindly.

Best Regards,
Menachem

From: BESS  on behalf of Matthew Bocci (Nokia) 

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

Hi Authors

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

Thanks in advance

Matthew

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

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

[Ali Sajassi (sajassi)]

Hi Matthew, Menachem:

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

Cheers,
Ali

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

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

Thank you kindly.

Best Regards,
Menachem

From: BESS  on behalf of Matthew Bocci (Nokia) 

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

Hi Authors

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

Thanks in advance

Matthew

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

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

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

Can we just remove the text in yellow?

Thanks

Matthew


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

   *  If a network uses deep packet inspection for its ECMP, then the
  the following rules for "Preferred PW MPLS Control Word" [RFC4385]
  apply:

  -  It MUST be used with the value 0 (e.g., a 4-octet field with a
 value of zero) when sending unicast EVPN-encapsulated packets
 over an MP2P LSP.

  -  It SHOULD NOT be used when sending EVPN-encapsulated packets
 over a P2MP or P2P RSVP-TE LSP.

  -  It SHOULD be used with the value 0 when sending EVPN-
 encapsulated packets over a mLDP P2MP LSP.  There can be
 scenarios where multiple links or tunnels can exist between two
 nodes and thus it is important to ensure that all packets for a
 given flows take the same link (or tunnel) between the two
 nodes.

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


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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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


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

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

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

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

Regards, and lots of thanks n advance,
Sasha



Disclaimer

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

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

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

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

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

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

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

Thanks.
Jeffrey

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

Cheers,
Ali

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

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

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

My reading of your responses looks as following:

  1.  An optimized IRB is a Symmetric EVPN IRB:

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

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

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

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

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

My 2c,
Sasha

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

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

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

Hi Neeraj,

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


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

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

Hi Ali, Sasha,

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

Thanks,
Neeraj

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

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

Cheers,
Ali

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

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

[Ali Sajassi (sajassi)]

Hi Neeraj,

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


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

Cheers,
Ali

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

Hi Ali, Sasha,

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

Thanks,
Neeraj

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

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

Cheers,
Ali

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

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

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

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha



Disclaimer

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

Cheers,
Ali

From: BESS  on behalf of Alexander Vainshtein 

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

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

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

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

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha



Disclaimer

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

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

[Ali Sajassi (sajassi)]

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


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

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

Cheers,
Ali

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

Friendly reminder, would appreciate your response.

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

Thanks,
Jeff

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

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

[Ali Sajassi (sajassi)]

Hi Folks,

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

Cheers,
Ali

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

Friendly reminder, would appreciate your response.

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

Thanks,
Jeff

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

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

[Ali Sajassi (sajassi)]

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

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

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

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

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

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

This poll will close on Thursday 12th October.

Regards

Matthew

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

From: BESS  on behalf of Alexander Vainshtein 

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

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

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

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

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

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

[AS] That is fair and it can happen.

I would highly appreciate your answers to the following questions:

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


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

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

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

Cheers,
Ali

Your timely feedback would be highly appreciated.

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

Regards, and lots of thanks in advance,
Sasha



Disclaimer

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

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

Cheers,
Ali

From: BESS  on behalf of Alexander Vainshtein 

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

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

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

My 2c,
Sasha

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


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

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

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

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


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

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

Ali and all,

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


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

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

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

My 2c,
Sasha



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

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

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

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

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

Hi Brian,

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

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

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

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

Major Issues:

Minor Issues:

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


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

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

[Ali Sajassi (sajassi)]

Hi Brian,

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

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

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

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

Major Issues:

Minor Issues:

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


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

Nits:

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


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


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



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

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

[Ali Sajassi (sajassi)]

I am not aware of any undisclosed IPRs.

Cheers,
Ali

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

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

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

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

This poll runs until Tuesday 3rd October.

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

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

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



Thank you,
Stephane, Matthew, Jeffrey

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

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

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

[Ali Sajassi (sajassi)]

Hi Matthew,

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

Regards,
Ali

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

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

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

Thanks

Matthew

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

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

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


Hi Folks,

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

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

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

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

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

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

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

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

This WG LC ends on Wednesday 16th August 2023.

Thanks

Matthew

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

Regards,
Ali

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

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

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

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

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

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

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

Regards, and lots of thanks in advance,
Sasha






Regards,
Sasha



Disclaimer

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

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

[Ali Sajassi (sajassi)]

Hi Folks,

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

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

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

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

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

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

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

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

This WG LC ends on Wednesday 16th August 2023.

Thanks

Matthew

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

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

[Ali Sajassi (sajassi)]

Hi Martin,

Elaborating a bit further to ensure there is no ambiguity …



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

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

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


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

 Done






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

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

[Ali Sajassi (sajassi)]

Hi Mankamana,

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

Cheers,
Ali

From: BESS  on behalf of Mankamana Mishra (mankamis) 

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

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

Hi WG,







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

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







This poll runs until 6/30.







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

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

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



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

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

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

all the Authors and Contributors.



There is currently one IPR disclosed.







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

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

conformance with IETF rules.







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

indicate if you are aware of any implementations.







Thank you,



Matthew & Stephane







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



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

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

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

[Ali Sajassi (sajassi)]

Hi Matthew,

Done and it is waiting for your check-in.

Cheers,
Ali

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

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

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

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

Regards

Matthew


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

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

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


Linda,

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

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

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

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


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

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

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

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


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

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

Cheers,
Ali

  *

Thank you very much

Linda


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

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

[Ali Sajassi (sajassi)]

Shunwan,

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

Cheers,
Ali

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

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

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

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

  Figure 6


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

Question: Which is the right format we want?

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

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

[Ali Sajassi (sajassi)]

Linda,

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

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

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

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


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

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

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

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


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

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

Cheers,
Ali

  *

Thank you very much

Linda


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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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


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

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

This poll for adoption closes on June 7th.

Regards,
Matthew and Stephane

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

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

[Ali Sajassi (sajassi)]

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

Regards,
Ali

From: BESS  on behalf of Matthew Bocci (Nokia) 

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

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

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

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

This poll for adoption closes on June 9th 2023

Regards,
Matthew and Stephane

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

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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



Hi All,



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

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

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

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

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



Thanks,

Yubao




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

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

[Ali Sajassi (sajassi)]

Hi Sami,

Please refer to my response inline in red …

From: BESS  on behalf of Boutros, Sami 

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

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


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

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


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

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

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

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

Cheers,
Ali

Thanks,

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

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

[Ali Sajassi (sajassi)]

Hi Nitsan,

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

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

Cheers,
Ali

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

Cc: Alexander Vainshtein , Ron Sdayoor 

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

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

Much oblige,
Nitsan

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

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

Hi Nitsan,

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

Cheers,
Ali

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

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

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

Nitsan Dolev
Ribbon Communications

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

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

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

[Ali Sajassi (sajassi)]

Hi Nitsan,

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

Cheers,
Ali

From: BESS  on behalf of Nitsan Dolev 

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

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

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

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

Nitsan Dolev
Ribbon Communications

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

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

[Ali Sajassi (sajassi)]

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

Thanks very much for your helpful response.

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

That’s correct.

Cheers,
Ali

Thank you kindly.

Best Regards,
Menachem

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

Please refer to my comments below in red …

From: BESS  on behalf of Menachem Dodge 

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

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





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


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


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


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

Cheers,
Ali






Thank you kindly.

Best Regards,

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

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

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

[Ali Sajassi (sajassi)]

Please refer to my comments below in red …

From: BESS  on behalf of Menachem Dodge 

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

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



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


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


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


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

Cheers,
Ali




Thank you kindly.

Best Regards,

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

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

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

[Ali Sajassi (sajassi)]

Hi Folks,

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

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

Cheers,
Ali

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

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

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

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

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

Note to Readers

   _RFC EDITOR: please remove this section before publication_

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



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

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

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


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


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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

Thanks for your insightful comments. A few comments:


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

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

Cheers,
Ali



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

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


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


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

   different CEs and thus VID translation is required, a normalized

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

   Furthermore, the advertising PE advertises the MPLS Label1 in the

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

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

   advertising PE can identify the corresponding bridge table from the

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

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

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

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

   in all EVPN routes MUST be set to the normal

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

My doubts are based on the following scenario:

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

Please refer to my comments below:



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

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


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

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

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

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

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

[Ali Sajassi (sajassi)]

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

Hi Sasha,

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

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


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

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

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

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

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

AS>> more comments below …

Regards, and lots of thanks in advance,
Sasha

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

Hi Sasha,

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

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

The problematic text in Section 4.1 of the draft says:

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

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

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

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

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

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


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

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

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

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

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

AS>> more comments below …

Regards, and lots of thanks in advance,
Sasha

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

Hi Sasha,

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

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

The problematic text in Section 4.1 of the draft says:

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

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

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

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

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

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

[Ali Sajassi (sajassi)]

Hi Jorge, Sasha:

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

Cheers,
Ali

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

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

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

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


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

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

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

Hi Sasha,

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

Thanks.
Jorge

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

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

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

Regards, and lots of thanks in advance,
Sasha

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

Hi Sasha,

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

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

Cheers,
Ali

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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

From: BESS  on behalf of Alexander Vainshtein 

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

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

The problematic text in Section 4.1 of the draft says:

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

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

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


Here are our questions:

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


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

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


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

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

[Ali Sajassi (sajassi)]

Hi Sasha,

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

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

Cheers,
Ali

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

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

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

What, if anything, did I miss?

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha


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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

From: BESS  on behalf of Stephane Litkowski (slitkows) 

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

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

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on October 24th 2022.

Regards,
Matthew and Stephane


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

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

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

[Ali Sajassi (sajassi)]

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

Regards,
Ali

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

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

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

This poll runs until the 10th October 2022

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

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


Thank you,
Matthew & Stephane


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



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

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

[Ali Sajassi (sajassi)]

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

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

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

Hello Working Group,



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



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



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

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



There is no IPR currently disclosed.



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



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



Thank you,

Stephane & Matthew


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

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

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

This poll runs until Monday 14th February 2022.

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

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

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

Thank you,
Matthew & Stephane

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


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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

Hi,



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



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



This poll runs until the 12th October 2021.



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



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

There are currently two IPR disclosures.



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



Thank you,

Matthew & Stephane





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

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

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

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

[Ali Sajassi (sajassi)]

Hi Matthew,

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

Regarding the two questions below:

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

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

Regards,
Ali

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

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

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

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

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

I will close this poll on 25th August 2021.

Regards

Matthew


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


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

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

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


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

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

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


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


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

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

[Ali Sajassi (sajassi)]

Hi Ben,

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

Cheers,
Ali

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

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

Yours Irrespectively,

John


Juniper Business Use Only

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

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

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

Thanks again,

Ben

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

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

[Ali Sajassi (sajassi)]

Hi Ben,

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


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

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

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

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

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

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

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

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

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

Hello,

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

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 4th May 2021.

Regards,
Matthew and Stephane


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

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

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

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

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

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

Hello,

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

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on April 12th 2021.

Regards,
Matthew and Stephane


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

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

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

[Ali Sajassi (sajassi)]

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

-Ali

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, December 9, 2020 at 1:23 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , , Cisco 
Employee , 
Resent-Date: Wednesday, December 9, 2020 at 1:22 AM

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [1].

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 23rd December 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



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

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

[Ali Sajassi (sajassi)]

Hi Ben,

I responded to your comments in the current thread but let me respond to your 
comments in the draft’s ballot page more specifically here so that you don’t 
have to go through that email. Please let me know if you have any further 
comments.


1)  I think draft-ietf-bess-evpn-irb-extended mobility needs to be a
normative reference, since "the procedures in [it] must be exercised"
incorporates its procedures by reference.

AS>  The draft-ietf-bess-evpn-irb-extended-mobility describes the mobility 
procedures when a host has several IP addresses and a single MAC address (or 
vise versa); whereas, this draft describes the mobility procedures when the 
host has a single IP address and a single MAC address.  As such the 
extended-mobility draft does not need to be a normative reference. There was 
some confusion about IPv6 Link Local address & host mobility and I provided 
further clarification in the corresponding paragraph which is cut & pasted 
below for your convenience.


  “Depending on the expexted TS's behavior, an NVE needs to handle at

   least the first bullet and should be able to handle the 2nd and the

   3rd bullet.  The following subsections describe the procedures for

   each of them where it is assumed that the MAC and IP addresses of a

   TS have one-to-one relationship (i.e., there is one IP address per

   MAC address and vice versa).  The procedures for host mobility

   detection in the presence of many-to-one relationship is outside the

   scope of this document and it is covered in

   [I-D.ietf-bess-evpn-irb-extended-mobility].  The many-to-one

   relationship means many host IP addresses corresponding to a single

   host MAC address or many host MAC addresses corresponding to a single

   IP address.  It should be noted that in case of IPv6, a link-local IP

   address does not count in many-to-one relationship because that

   address is confined to single Ethernet Segment and it is not used for

   host moblity (i.e., by definition host mobility is between two

   different Ethernet Segments).  Therefore, when an IPv6 host is

   configured with both a Global Unicast address (or a Unique Local

   address) and a Link Local address, for the purpose of host mobility,

   it is considered with a single IP address.”


2)  Similarly,
draft-ietf-idr-tunnel-encaps seems like a normative reference since we
require the RT-2 route used by this document to be advertised along with
the EC that indicates the tunnel type.

AS>  Yes, this draft needs to be normative and the correction has been made.


3)  I still think we need to discuss whether this document Updates: 7432.
RFC 7432 specifies the layout and interpretation of the RT-2 (MAC-IP
Advertisement Route) EVPN NRLI, but we extend it in several ways (e.g.,
the Label1 and Label2 (which we spell "Label-1" and "Label-2",
unfortunately) are only MPLS labels in 7432, but we expand that to also
allow VNI values in those fields; likewise, 7432 gives no semantics at
all for Label2, but we define some).  I understand that 7432 only covers
the L2 case but this document adds mixed L2/L3 (IRB), and furthermore
that the IRB case can be inferred based on the contets of the fields in
the advertisement, *if you know how to look for them*.  But I still
can't shake the feeling that this document should either be added as an
additional reference for EVPN Route Type 2, or listed as Updating 7432,
in order to indicate that we provide more details for the
interpretation and contents of the RT-2 NLRI.

AS> This document doesn’t introduce any new EVPN routes and it doesn’t expand 
the definition of existing routes. With regard to allowing Label1 and Label2 
being use as either MPLS labels or VxLAN VNIs, this document uses the 
precedence set in RFC8365. This document builds on top of RFC 7432 and RFC8365. 
RFC 8365 describes the use of Label1 field in RT-2 as VNI because of VxLAN 
encapsulation. Furthermore, the Lable2 field is not used at all in either RFC 
7432 or RFC 8365 because its only application is for IRB use cases and both 
7432 and 8365 are for pure layer-2 only.

Regards,
Ali

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

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

[Ali Sajassi (sajassi)]

Hi Ben,

Please see my replies marked with AS>>

On 10/29/20, 5:26 PM, "Benjamin Kaduk"  wrote:

Hi Ali,

Sorry for the delayed response.  Comments inline.

On Thu, Sep 03, 2020 at 06:17:01AM +0000, Ali Sajassi (sajassi) wrote:
> Hi Ben,
> 
> Thanks very much for your review and comments. Please refer to my replies 
inline marked with [AS].
> 
> On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker"  
wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut 
this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> (1) Possibly a "discuss discuss", but ...
> if I'm understanding correctly, the symmetric IRB case over an 
Ethernet
> NVO tunnel (not MPLS or IP NVO) described in this document is
> introducing a new scenario where traffic using router (PE) MAC 
addresses
> as source and destination is comingled on the same tunnel with traffic
> using tenant system MAC addresses as source and destination.  This
> places an obligation on the tunnel endpoints to properly isolate and
> process such "internal" tunnel traffic without hampering the ability 
of
> tenans systems to communicate.  In a world where tenant systems can
> appear at any time, using previously unknown MAC addresses, this
> represents a rather challenging problem: how will the PEs be able to
> pick (and avertise) MAC addresses that they know will not conflict 
with
> any present or future customer systems?  (A similar dilemma led to 
quite
> a delay in the processing of draft-ietf-bfd-vxlan, which in that case
> was resolved by limiting the BFD operation to just the "management 
VNI"
> which is not subject to MAC address conflict with customer systems.)  
In
> this docuement's case, we seem to be using a "well-known"/reserved MAC
> address range from RFC 5798; in principle, this should be enough to
> avoid conflicts, if customer systems are known to not squat on this
> reserved range.  However, this document has some text in Section 4.1
> that indicates that there must be external knowledge that auto-derived
> MAC addresses in the RFC 5798 ranges "[do] not collide with any 
customer
> MAC address".  So I'm left uncertain whether or not this potential
> problem is addressed or not.  (Also, I don't know if the limit on 255
> distinct such MAC addresses presents a scaling issue.)
> 
> [AS] Because the MAC addresses based on RFC 5798 is from a reserved 
range, there should be no conflict with customer MAC addresses that typically 
use their corresponding vendor OUI. If there was a conflict, then we would have 
the same issue with VRRP. However, this document doesn't want to give a blank 
check for auto-derivation of MAC addresses and that's why the statement about 
"... auto- derived MAC does not collide with any customer MAC address".

Okay, thanks for the extra explanation.

AS>> You're welcome!

> Also, is there any risk that the EVPN IRB setup might also want to use
> VRRPv3, and thus collide on the MAC addresses in a different manner?
> 
> [AS] No, because redundancy procedure in EVPN replaces VRRP protocol. 

Should we say something like that in the document ("because EVPN provides a
superset of VRRP functionality, VRRP MUST NOT be used when EVPN is used")?

AS>>  I am afraid that may be confusing to some people because EVPN main mode 
of multi-homing is All-Active which has no relevance in VRRP.

> (1.1) I'm less sure whether there's a similar collision risk for IP
> addresses -- we assign IP addresses to NVEs (e.g., for use as BGP Next
> Hop addresses) and these are used as VTEP addresses when encapsulating
> packets that are going inter-subnet. 

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

[Ali Sajassi (sajassi)]

Hi Erik,

Please see my reply marked w/ AS>>

On 12/9/20, 7:50 PM, "Erik Kline"  wrote:

Ali,

Thanks for your replies.

On Sun, Oct 11, 2020 at 9:06 PM Ali Sajassi (sajassi)  
wrote:
>
> Hi Erik,
>
> Thanks for your comments and sorry to missed them in first place, please 
see my replies in line marked w/ [AS]:
>
> On 7/14/20, 11:22 PM, "Erik Kline via Datatracker"  
wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss
>
>
> --
> DISCUSS:
> --
>
> [ general ]
>
> * Can you give an example of what happens to non-IPv4/IPv6 Ethernet 
packets
>   received at the NVE/PE?  Do they get bridged, and if so how far?  
What
>   happens if a host in BT1 ARPs for IPv4 address associated with a TS 
in
>   a different BT?
>
> [AS] L2 packet (non-ARP/ND packet) gets bridged; however, ARP/ND packets 
from the host for its IP default GW gets terminated at the PE and process by 
it. Section 4.1 describes this in details and it provides an example of it at 
the bottom of the section. Since the PE acts as the IP default GW for the host, 
all packets to other TSes in other subnets gets forwarded to the PE (to its IP 
default GW).
>
> * Where there are multiple prefixes in an IP-VRF, is there a 
constraint that
>   any other IP-VRF that contains one of the prefixes must contain all 
of them?
>   Perhaps that's in 7432...?
>
> [AS] IP and MAC addresses for a given host is advertised with its 
corresponding Route Targets as described at the bottom of section 3, and in 
sections 5.2, 6.2 9.1.1, and 9.2.1. Any PE that has an IP-VRF for that 
tenant/host, imports the IP route into its VRF upon receiving it.
>
> [ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]
>
> * Please document what happens to IPv4 TTL/IPv6 Hop Limit values as 
they
>   cross various NVEs/PEs.
>
> [AS] Added the following to section 4:
> "It should be noted that whenever a PE performs a host IP lookup for a 
packet,
>IPv4 TTL or IPv6 hop limit for that packet is decremented by one and 
if it
>reaches zero, the packet is discarded. In case of symmetric IRB, the 
TTL/hop
>limit is decremented by both ingress and egress PEs (once by each); 
whereas,
>in case of asymmetric IRB, the TTL/hop limit is decremented only once 
by the
>ingress PE."

I don't quite understand what this text should be telling me.  IPv6
Neighbor Solicitations must be sent with a Hop Limit of 255 (4861
S4.3) and "HL==255" is a validation check performed on receipt (4861
S7.1.1).  The same goes for the Neighbor Advertisement replies.

I think your answers above clarifying the mixed routing and bridging
situation (depending on configuration) probably address my original
concern (that NS/NA HLs would not get decremented since they're
bridged; when they're routed they obviously can't be forwarded).  If
that's true, it might be better to undo this particular paragraph
addition, and I apologize for my confusion.

AS>> I modified the 1st sentence to say "... whenever a PE performs a host IP 
lookup for a packet that is routed, ". This way we clarify that the TTL/HL 
decrement is for routed packets and NOT for bridged packets that are forwarded 
w/ TTL/HL intact or NS/NA that get terminated.  


> [AS] I also added similar sentences to sections 5.4, 5.5, 6.3, and 9.1.2, 
and 9.2.2. This addition is not applicable to section 6.4.
>
> [ section 7 ]
>
> * The two statements:
>
>   (1) "Although the language used in this section is for IPv4 ARP,
>   it equally applies to IPv6 ND."
>
>   (2) "If there is [a] many-to-one relationship such that there are 
many host
>   IP addresses correspond[ing] to a single host MAC address ..., 
then to
>   detect host mobility, the procedures in [IRB-EXT-MOBILITY] must 
be
>   exercised..."
>
>   are in direct conflict.  All IPv6 hosts having at least one 
non-link-local
>   unicast address will have more than one IP address per MAC and this 
section,
>   or even this document, would not apply?
>
> [AS] I modified the paragraph to call out non-link-local address for IPv6 
explicitly:
>
> “If there is many-to-one relationship such that there are many hos

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

[Ali Sajassi (sajassi)]

Hi Alvaro,

On 11/9/20, 12:33 PM, "Alvaro Retana"  wrote:

On October 13, 2020 at 2:55:07 AM, Ali Sajassi wrote:

Ali:

Hi!

> Thanks very much for your comments and sorry for the delay, please refer 
to
> my replies marked with [AS].

I looked at the replies and I'm clearing my DISCUSS.

There is one outstanding issue that I trust you to complete before
Martin approves:  The reference to draft-ietf-idr-tunnel-encaps needs
to be Normative.  Ben has this same point listed in his current
DISCUSS [1].

OK, changed it to be Normative.

Thank you for also addressing the questions from John Scudder about
multiple MAC ECs.

You're most welcome!
Cheers,
Ali

Alvaro.

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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Ali Sajassi (sajassi)]

I looked into the IPR, and it has been disclosed and it shows up for the 
individual version of the draft but for some reason not for the WG version of 
it!

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

Date: Tuesday, February 2, 2021 at 9:39 AM
To: "slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01

Support the WGLC. I think there is an IPR associated with this draft. I will 
look into and if it is the case, will disclose it ASAP.

Cheers,
Ali

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

Date: Monday, January 18, 2021 at 12:58 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


This email starts a two-week working group last call for 
draft-ietf-bess-evpn-irb-extended-mobility-01 [1]







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







This poll runs until February 1st.







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



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



There is currently no IPR disclosed.


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





Thank you,



Matthew & Stephane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!NEt6yMaO-gk!X5h4y9zD3js4IFT_XC9-diCFCY2KETdVMSaYYY3ihMfJkJT9ibnhUx4IgRXhv_vc$>

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

Re: [bess] draft-ietf-bess-evpn-ipvpn-interworking chair review

[Ali Sajassi (sajassi)]

Hi Stephane,

Jorge, John, DJ, and I met several times over the course of last two weeks to 
address DJ and some of the other outstanding comments and in doing so covering 
the following three cases as well:

  1.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/o a domain-path Attribute
  2.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/ a domain-path Attribute that contains a new SAFI and 
new a domain-id
  3.  Advertisements of routes learned over a local AC by a GW into the 
participating domains w/ a domain-path Attribute that contains a new SAFI and 
one of the existing domain-id

Jorge is working hard to incorporate the new changes and by end of the week he 
should have a new rev that address all the comments including yours below.

Cheers,
Ali

From: "Stephane Litkowski (slitkows)" 
Date: Friday, December 11, 2020 at 7:37 AM
To: "draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org" 

Cc: "bess@ietf.org" , "bess-cha...@ietf.org" 

Subject: draft-ietf-bess-evpn-ipvpn-interworking chair review
Resent-From: 
Resent-To: , Cisco Employee , 
, , , 
, 
Resent-Date: Friday, December 11, 2020 at 7:35 AM

Hi Authors,


Please find below my chair review related to 
draft-ietf-bess-evpn-ipvpn-interworking.

BTW, you need to refresh the draft now, it has expired.

Section 3:

  *   Nit:
s/uniqueness of the DOMAIN- ID/uniqueness of the DOMAIN-ID/


  *   a) I agree with DJ’s comment on: “This attribute list may contain zero, 
one or more segments". It is actually one or more.
  *   The section 3 contains both normative and non-normative language. If 
section 3 is intended to detail the normative behavior of adding/modifying 
D-PATH, it must use normative for any of the normative procedure. For instance 
b) may require normative language. While it is very good to have an example in 
b), one or more clear normative rules are required before talking about the 
example.
  *   b) talks about domain-ids attached to IP-VRF, this is fine. However, the 
text should provide a wider view so people don’t think that this is the only 
option. Domain-Ids may be assigned at VRF level, but also at more a higher 
level (BGP peer), or even lower level (bgp community…). We should not limit 
implementations here in the granularity domain-ids are defined.
  *   c) I don’t see why “MUST NOT”, it does not hurt to have a DOMAIN-ID 
associated with non ISF world (routes learned from IGP, static)… there could be 
design where people do BGP one leg and non-BGP on the other leg. We should 
probably relax that.

Would you mind adding a beautiful ASCII-ART for the attribute format ? It’s 
usually good to have when reading to see the attribute format rather than 
having to read the text.


You need to define the error handling procedures for D-PATH as per RFC7606 (you 
should have it as normative ref too).


Section 3.1
This sentence is misleading and does not match with the normative behavior of 
Section 3) d)

“In general, any interworking PE that imports an ISF route MUST flag

   the route as "looped" if its D-PATH contains a  
segment, where DOMAIN-ID matches a local DOMAIN-ID

   in the tenant IP-VRF.”

I don’t see the value of this section beyond providing an example. The 
normative behavior is already given in Section 3) d). Can’t the example be 
packed under d).

Also the pointed sentence still refers to a DOMAIN-ID per VRF, which is not 
good for a generic statement. My domain ID info could from the BGP peer config. 
Again, this option of per VRF is fine, but this is not the only one that can be 
implemented.


Section 4.1:
I don’t see why “no-propagation-mode” is the default mode. This is breaking 
existing propagation of attributes from SAFI 1 to SAFI 128. When we have a CE 
running BGP with a PE, the PE propagates the attributes (CTs, ASPATH, MED…) 
coming from the CE.
This section creates some ambiguity about the D-PATH attribute. Based on 
Section 3, D-PATH will be necessarily sent but received D-PATH may be dropped 
and new one created but the text of section 4.1 makes me think that it’s not 
the case in no-propagation mode.
I think setting D-PATH is orthogonal to the attribute propagation.
As section 4.1 tells, people may still want to rely on existing SoO for 
instance in some case in this case D-PATH may not be added.
I think section 3 and 4.1 have to be more clear on the normative procedures 
about D-PATH addition/modification.

Section 4.2:
Isn’t it dangerous to try to define which attributes needs to be propagated, 
and which one should not be ? We are always creating new attributes, should 
people update this doc each time a new attribute comes ? I don’t really see how 
this could be managed.

Isn’t there an indentation issue starting “When propagating an ISD route to a 
different ISF SAFI…” ?

The considerations about ASPATH look really implementation details to me (at 
least the way it is written). Basically the ASPATH propagation 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

[Ali Sajassi (sajassi)]

Support publication of this draft. I am not aware of any undisclosed IPR.

-Ali


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

Date: Monday, November 30, 2020 at 12:15
To: "draft-ietf-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for 
draft-ietf-bess-srv6-services-05 [1]

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

This poll runs until Monday 14th December 2020.

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

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

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

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] [**EXTERNAL**] Re: comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Please see my comments marked w/ [AS] below:


Just so that everyone is aware of the history, I introduced the control plane 
signaling concept for L2VPN,
as well as PW status signaling, capability exchange and PW QoS signaling for 
throttling the traffic.

EVPN utilized that idea and applied in EVPN signaling to offer related benefits.

https://tools.ietf.org/html/draft-shah-pwe3-control-protocol-extension-00


[AS] Himanshu, please do not make such unfounded claims as it may undermine 
your credibility. Making such claims is like saying EVPN is based on VPLS (RFC 
4762) because in that RFC, MAC list TLV is defined and can be signaled in 
control plane for a PW ☺
EVPN was designed to address a specific set of requirements listed in RFC 7209 
and you may want to enlighten people in this list on how your above draft 
addresses any of the requirements specified in that RFC (and please elaborate 
for everyone’s sake :-)
Since this is not a technical discussion anymore and Sami wants to address my 
concerns in the next rev of the draft, it is not productive to engage in any 
more discussions and I will wait till the next rev. is published to see how my 
raised issues with the so called “simple solution” are addressed.

-Ali


Control plane learning was used in arp-mediation (RFC 6575) and IPLS (RFC 7436).

(Just a note on the history).

Thanks,
Himanshu

From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Friday, November 20, 2020 at 2:15 AM
To: "Jeffrey (Zhaohui) Zhang" , "Sami com>" 

Cc: "bess@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] comments on 
draft-boutros-bess-elan-services-over-sr

Hi Sami and Jeffrey,

Please see some comments/replies in-line.

Thank you!
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, November 19, 2020 at 7:20 PM
To: Sami Boutros , Rabadan, Jorge (Nokia - US/Mountain 
View) 
Cc: bess@ietf.org 
Subject: RE: [bess] comments on draft-boutros-bess-elan-services-over-sr
To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.



Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,






On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.






@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


1.   While I see the anycast-SID as an interesting point, I disagree with 
the document’s motivation that EVPN needed to introduce control-plane learning 
due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?
[jorge] No, I didn’t make myself clear enough – control plane is needed with 
MP2P tunnels, yes, but what I meant is that in your motivation it *sounds* like 
control-plane learning was a necessary evil due to the need for MP2P tunnels to 
fix the scale issue. I see control-plane learning as an additional 
improvement/feature, as Jeffrey was saying.






1.   Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.







2.   Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.








3.   The document seems to claim fast mac move. How can that be guaranteed 
if the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.
[jorge] you are assuming that when that MAC moves to another port, it sends BUM 
traffic that is flooded and all the nodes can 

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,

Yes, EVPN has evolved over many years and that’s why it has such a big traction 
in industry (thanks to your contributions and many others) and we have always 
been open to improvements (mostly driven by our customers) and evaluated them 
objectively. So, if there is any suggestion wrt to Anycast ID, we can 
definitely evaluate it based on what use cases it covers, All-active mode (both 
equal and unequal LB), failure scenarios, convergence, impact to underlay and 
overlay protocols, as well as applicability to different encapsulations to name 
a few.

Cheers,
Ali

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee , "Jeffrey (Zhaohui) Zhang" 
, Sami Boutros 
Cc: "bess@ietf.org" 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

Hi Ali,

Yes, I understand it has pros and cons. What I meant is that, if using anycast 
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a 
completely new technology that needs to reinvent how to do all services (elan, 
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can 
apply anycast SIDs to existing EVPN.

Thanks.
Jorge

From: Ali Sajassi (sajassi) 
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
Jeffrey (Zhaohui) Zhang , Sami Boutros 

Cc: bess@ietf.org 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] [**EXTERNAL**] Re: Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Sami,

If you want to respond, please elaborate so anyone who is following this thread 
can benefit from the exchange; otherwise, it won’t be productive. Please see my 
responses marked w/ [AS].

From: "Boutros, Sami" 
Date: Friday, November 20, 2020 at 10:51 AM
To: Cisco Employee , Sami Boutros , 
"Ali Sajassi (sajassi)" 
Cc: "bess@ietf.org" 
Subject: Re: [**EXTERNAL**] Re: [bess] Issues w/ 
draft-boutros-bess-elan-services-over-sr

Hi Ali,

Please see inline.


Sighhh! The first section of your draft (section 1) and the first two 
paragraphs of that section talks about (1) and (2) that I mentioned in my 
email. Basically, Introduction section states these two reasons as the 
underlying reasons for your draft.

[Sami] In fact, it is not, this is simply an opening statement explaining the 
control plane complexity that we are trying to simplify and is by no mean 
objectives to either reduce # of PWs and # of MAC entries, our proposal is a 
control plane simplification that eliminates need for PWs or EVPN control plane 
distribute any # of mac entries. You know there is a difference between 
reducing control plane overhead and eliminating it!

[AS] This draft is a technical draft and not a marketing white paper, so when 
you talk about a 20 year-old VPLS technology and give example wrt its scale 
issue, then I’d like to know why you are not mentioning PBB-VPLS which 
eliminate the PW scale issue of VPLS. And if you think doing control-plane 
signaling in LDP or BGP for PBB-VPLS is complex, then why not mention you can 
use static PW setup (via a controller). Why these existing solutions are not 
enough to address your concern if you want to use the old-method of data-plane 
learning.

With respect to EVPN, every routes in EVPN has a purpose but if you want to use 
a subset of features and use data-plane learning, then EVPN allows for that. As 
you may know PBB-EVPN uses only a subset of EVPN routes & functions while doing 
data-plane learning. So, if you think EVPN control-plane is complex and do 
data-plane learning, then why not use PBB-EVPN? Can you detail for me what 
aspects of PBB-EVPN is too complex for you?

As I explained in details in my response, we have been there and done that long 
time ago; however, I don’t see any mention of the previous work and RFCs in 
your draft, so maybe you don’t know about them (History is the best teacher one 
can have).

[Sami] I love history and have a library of history books at home! Please list 
drafts and other previous work that talked about eliminating PW signaling and 
we will be more than happy to reference it!

[AS] I mentioned all those RFCs in my first email. And wrt VxLAN RFC, it is 
7348.

Also, you didn’t address any of them issues that I raise and instead. I will 
list them again here and please respond  clearly to each of them:


  1.  If you want to do data-plane learning over SR, why not use PBB-EVPN over 
SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with 
SR, MPLS, TE, etc.
[Sami] Our proposal is not about using complex control plane to setup PWs  or 
EVPN to start with, so why should we use it?

[AS] Again,  if you want to have technical discussions, please elaborate on 
exactly what aspects of PBB-EVPN  control plane is complex given PBB-EVPN uses 
ONLY a subset of EVPN routes and procedures/functions.

  1.  How does your solution take care of VxLAN encoding which is prevalent in 
DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 
10 years ago) is not applicable? Needless to say that both data-plane and 
control-plane solutions for VxLAN was introduced at the same time about 10 
years ago and industry decided in favor of control-plane!!
[Sami] We are not saying by any mean don’t use EVPN. And we do respect the 
industry and service providers choice, so can we leave it to service providers 
and industry to decide their choice of technology or control plane!

[AS] But that wasn’t my question. What I am saying is we have seen this play 
ten years ago and how is your proposal handle VxLAN encap and how it is 
different from RFC7348.

  1.  How do you want to address IRB in your proposal? Will IRB be never be 
used in your proposal?
[Sami] We will address IRB in the next rev of the draft, as we see our proposal 
will provide great benefits to Data Center customers specially when using SRv6.

[AS] Nice marketing ☺ but can you give us a technical explanation now in one 
paragraph?

  1.  How do you want to address unequal LB for All-Active MH?
[Sami] In fact, how to achieve unequal LB with our solution was clearly 
explained on the slides I presented

[AS] Sami, referring me to a slide-page that doesn’t explain it and saying “it 
was clearly explained” is not productive. The one to last slide only says:
“Packets destined to the MH CE connected to node 5 and node 6 can be 
load-balanced (ECMP/UCMP) across the core given that the MAC addressed were 
lea

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Sami,

Sighhh! The first section of your draft (section 1) and the first two 
paragraphs of that section talks about (1) and (2) that I mentioned in my 
email. Basically, Introduction section states these two reasons as the 
underlying reasons for your draft. As I explained in details in my response, we 
have been there and done that long time ago; however, I don’t see any mention 
of the previous work and RFCs in your draft, so maybe you don’t know about them 
(History is the best teacher one can have).

Also, you didn’t address any of them issues that I raise and instead. I will 
list them again here and please respond  clearly to each of them:


  1.  If you want to do data-plane learning over SR, why not use PBB-EVPN over 
SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with 
SR, MPLS, TE, etc.
  2.  How does your solution take care of VxLAN encoding which is prevalent in 
DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 
10 years ago) is not applicable? Needless to say that both data-plane and 
control-plane solutions for VxLAN was introduced at the same time about 10 
years ago and industry decided in favor of control-plane!!
  3.  How do you want to address IRB in your proposal? Will IRB be never be 
used in your proposal?
  4.  How do you want to address unequal LB for All-Active MH?
  5.  How do you want to address host mobility where a MAC is associated with 
multiple IP address?

Now, with respect to your two claims:

  1.  Simplification: A solution can be simplified if it doesn’t need to 
address much of anything ☺ I.e., if it doesn’t need to address IRB, to address 
unequal LB, to address multiple IP address for a MAC, to address optimum mcast 
for L2 simultaneously (IRB), etc.
  2.  Anycast SID: the notion of anycast SID and anycast IP address for 
All-Active multi-homing is not new and again has been done for ages. Cisco 
proprietary solution for All-Active multi-homing (called VPC) before EVPN was 
based on anycast IP address. However, there are drawback for it – one of which 
is underlay topology decides LB instead of the actual link BW of MCLAG!!
Cheers,
Ali

From: Sami Boutros 
Date: Thursday, November 19, 2020 at 6:32 PM
To: "Ali Sajassi (sajassi)" 
Cc: "bess@ietf.org" , Cisco Employee , Sami 
Boutros 
Subject: Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

Hi Ali,

The draft doesn’t state neither 1 or 2 below. I’m not sure if we are looking at 
the same draft.

Here is the text in the draft introduction


   The goal of the proposed approach is to greatly simplify control

   plane functions and minimize the amount of control plane messages PE

   nodes have to process.  In this version of the document, we assume

   Segment Routing (SR) underlay network.  A future version of this

   document will generalize the underlay network to both classical MPLS

   and SR technologies.



   The proposed approach does not require PW, and hence the control

   plane complexity and message overhead associated with signaling and

   maintaining PWs are eliminated.

Our goal is to simplify:

1- The control plane by signaling very few messages possibly 1 message per node 
to signal all ELAN services configured on that node, presenting each ELAN 
service as 1 bit in the control plane message.

2- The data plane by setting up much less control plane elements like PWs, 
tunnels etc., and more importantly leveraging SR redundancy mechanisms of any 
cast SID to remove the need of any overlay convergence or redundancy mechanisms.

Not sure if any the stuff u listed below can address any of the above!

Thanks,

Sami


On Nov 19, 2020, at 12:21 PM, Ali Sajassi (sajassi) 
mailto:sajassi=40cisco@dmarc.ietf.org>> 
wrote:

Sami,

Since we didn’t have time to discuss the issues during the BESS meeting, let me 
explain and elaborate them here:

The draft states the following two main objectives for its purpose but both 
have been addressed already !!


  1.  Reducing # of PWs in VPLS:

 *   VPLS (both BGP and LDP) is a 20-year old technology which is getting 
deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, 
a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 
and 7080) to address the PW scale issues along with few other things.

  1.  Reducing # of EVPN MAC route advertisements:

 *   This may have been an issue 10 years ago and that’s why we introduced 
simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses 
data-plane learning and it uses concepts of service-id, source B-MAC (for MAC 
learning) and destination B-MAC (for BUM ID), and same concepts are used in 
your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as 
Single-Active with all the improvements that came later including per-ISID 
c-mac flushing that Jorge presented during the call. Needless to say that 
PBB-EVPN is transport agn

[bess] Issues w/ draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Sami,

Since we didn’t have time to discuss the issues during the BESS meeting, let me 
explain and elaborate them here:

The draft states the following two main objectives for its purpose but both 
have been addressed already !!


  1.  Reducing # of PWs in VPLS:
 *   VPLS (both BGP and LDP) is a 20-year old technology which is getting 
deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, 
a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 
and 7080) to address the PW scale issues along with few other things.
  2.  Reducing # of EVPN MAC route advertisements:
 *   This may have been an issue 10 years ago and that’s why we introduced 
simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses 
data-plane learning and it uses concepts of service-id, source B-MAC (for MAC 
learning) and destination B-MAC (for BUM ID), and same concepts are used in 
your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as 
Single-Active with all the improvements that came later including per-ISID 
c-mac flushing that Jorge presented during the call. Needless to say that 
PBB-EVPN is transport agnostic and can work with SR, MPLS, TE, etc.

So,  my question is that: what is the point of this draft? Are you trying to 
have a bit more compressed header over what we currently have in PBB-EVPN 
because in terms of functionality, I don’t see much difference. However, I see 
even more issues than PBB-EVPN such as IRB handling  and Unequal load-balancing 
 for an ES.

The idea of breaking a PW in to three components of service-id, source-id, and 
dest-id has been around for almost twenty years. I introduced mvpls draft in 
2002, followed by PBB-VPLS. VxLAN RFC (which also talks about data-plane 
learning) is along the same idea introduced in 2010. And finally PBB-EVPN in 
2012. So, why do we need to re-invent the wheel again?

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

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Roman,

Thanks for your comments. Please see my replies inline marked with [AS]:

On 7/15/20, 6:45 PM, "BESS on behalf of Roman Danyliw via Datatracker" 
 wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

I support the DISCUSS ballot position of Erik Kline

I support the DISCUSS ballot position of Alvaro Retana

I support the DISCUSS ballot position of Ben Kaduk

Not much to add to the feedback of my peer ADs.

** Please respond to the SECDIR feedback (and thank you Chris Lonvick for 
doing
it!)

** Section 11.  As there is nothing documented to prevent this approach from
being used across administrative domains with different policies (i.e., 
there
is no applicability statement or normative language providing caution from
being used outside of the commonly reference data center use case) or any
security assumptions made about the elements involved, please reiterate that
there are no inherent security services being provided to protect the 
traffic. 
If this is desired it should provide through other means.

[AS] I added a paragraph to section 11 per another feedback to address this. It 
is reflected in rev10. 

Cheers,
Ali

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

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

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

[Ali Sajassi (sajassi)]

Hi Alvaro,

Thanks very much for your comments and sorry for the delay, please refer to my 
replies marked with [AS].

On 7/14/20, 10:51 AM, "Alvaro Retana via Datatracker"  wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
DISCUSS:
--

I'm balloting DISCUSS because the specification in §9.1.1 is not clear, and 
it
is not in sync with draft-ietf-idr-tunnel-encaps.  [Some of the points below
are not DISCUSS-worthy, but I'm including them here because they are 
related to
the larger point.]

§9.1.1 talks about using the Encapsulation Extended Community *and* the
Router's MAC Extended Community.  However, the requirement for these
communities to appear together is not explicit anywhere.  What are the
implications for only one of them being present?

[AS] These two ECs are intended for two different purposes - one is to indicate 
tunnel type and the other to indicate PE's MAC address when doing Ethernet NVO 
tunnel. These two ECs don't need to appear together all the time - only for a 
specific use case which is described in section 9.1.1.

The Router's MAC Extended Community "is only required when Ethernet NVO 
tunnel
type is used".  It seems to me that normatively requiring the extended
community is important in this case.

[AS] Changed the sentence to "The Router's MAC Extended 
   community MUST be added when Ethernet NVO tunnel is used."

What exactly is the "Ethernet NVO tunnel type"?  §1 (Terminology) says that
"Examples of this type of tunnels are VXLAN or GENEVE."  A standards track
document should be specific about when something is required.  For example, 
I
assume that it would also be required when using NVGRE.  The tunnel types 
are a
finite number, so please be specific.

[AS] I changed it as follow:
"Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels
   with Ethernet payload as specified for VxLAN in 
   and for NVGRE in .


Where is the GENEVE tunnel type (to be used in the Encapsulation Extended
Community) defined?  BTW, the [GENEVE] reference is also missing.

[AS] I removed GENEVE since it was just an example and I am not aware of any 
implementation that uses GENEVE tunnel type since it is not defined. 

§4 has this text: "the tunnel connecting these IP-VRFs can be either IP-only
tunnel (in case of MPLS or GENEVE encapsulation) or Ethernet NVO tunnel (in
case of VxLAN encapsulation)."  It confuses me because of the apparent
contradiction between GENEVE being an example of an Ethernet NVO tunnel 
type,
but also (?) an IP-only tunnel in this case.

[AS] Yes, GENEVE can do both tunnel types; whereas, VxLAN can only do Ethernet 
NVO. GPE which is evolution of VxLAN, can also do both. I changed the example 
from GENEVE to GPE because GPE tunnel type is defined but not GENEVE: 
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types.


§4.2/draft-ietf-idr-tunnel-encaps mentions possible conflicts created by the
Router's MAC Extended Community and how it may be ignored, but this document
doesn't mention using the Encapsulation Sub-TLVs (also from
draft-ietf-idr-tunnel-encaps) for the same function.  Can the same function 
be
achieved with the Encapsulation Sub-TLVs?

[AS] All the info that is needed is already in the EVPN route itself and that 
is why there is no need to use Encapsulation Sub-TLVs. The tunnel-encap draft 
does a good job to explain when the tunnel-type EC is sufficient and when not 
to send the attribute itself. We coordinated that with Eric Rosen and it looked 
good the last time I checked. 

"section 4.5 of [TUNNEL-ENCAP]" is mentioned a couple of times, but there 
is no
§4.5 in draft-ietf-idr-tunnel-encaps, and there's no reference either.  
Please
remove the specific section number (to avoid becoming out of sync), and 
instead
mention the Encapsulation Extended Community by name.  Add a Normative
reference to draft-ietf-idr-tunnel-encaps.

[AS] Sounds good. I took care of it. BTW, there is already an informative 
reference.


--
COMMENT:

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

[Ali Sajassi (sajassi)]

Hi Erik,

Thanks for your comments and sorry to missed them in first place, please see my 
replies in line marked w/ [AS]:

On 7/14/20, 11:22 PM, "Erik Kline via Datatracker"  wrote:

Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss


--
DISCUSS:
--

[ general ]

* Can you give an example of what happens to non-IPv4/IPv6 Ethernet packets
  received at the NVE/PE?  Do they get bridged, and if so how far?  What
  happens if a host in BT1 ARPs for IPv4 address associated with a TS in
  a different BT?

[AS] L2 packet (non-ARP/ND packet) gets bridged; however, ARP/ND packets from 
the host for its IP default GW gets terminated at the PE and process by it. 
Section 4.1 describes this in details and it provides an example of it at the 
bottom of the section. Since the PE acts as the IP default GW for the host, all 
packets to other TSes in other subnets gets forwarded to the PE (to its IP 
default GW).

* Where there are multiple prefixes in an IP-VRF, is there a constraint that
  any other IP-VRF that contains one of the prefixes must contain all of 
them?
  Perhaps that's in 7432...?

[AS] IP and MAC addresses for a given host is advertised with its corresponding 
Route Targets as described at the bottom of section 3, and in sections 5.2, 6.2 
9.1.1, and 9.2.1. Any PE that has an IP-VRF for that tenant/host, imports the 
IP route into its VRF upon receiving it.  

[ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]

* Please document what happens to IPv4 TTL/IPv6 Hop Limit values as they
  cross various NVEs/PEs.

[AS] Added the following to section 4:
"It should be noted that whenever a PE performs a host IP lookup for a packet,  
   IPv4 TTL or IPv6 hop limit for that packet is decremented by one and if it 
   reaches zero, the packet is discarded. In case of symmetric IRB, the TTL/hop
   limit is decremented by both ingress and egress PEs (once by each); whereas,
   in case of asymmetric IRB, the TTL/hop limit is decremented only once by the
   ingress PE."

[AS] I also added similar sentences to sections 5.4, 5.5, 6.3, and 9.1.2, and 
9.2.2. This addition is not applicable to section 6.4.

[ section 7 ]

* Is there a reference for IRB-EXT-MOBILITY?

[AS] Yes, there were couple of other comments on this and I have fixed that 
already. 

* The two statements:

  (1) "Although the language used in this section is for IPv4 ARP,
  it equally applies to IPv6 ND."

  (2) "If there is [a] many-to-one relationship such that there are many 
host
  IP addresses correspond[ing] to a single host MAC address ..., then to
  detect host mobility, the procedures in [IRB-EXT-MOBILITY] must be
  exercised..."

  are in direct conflict.  All IPv6 hosts having at least one non-link-local
  unicast address will have more than one IP address per MAC and this 
section,
  or even this document, would not apply?

[AS] I modified the paragraph to call out non-link-local address for IPv6 
explicitly: 

“If there is many-to-one relationship such that there are many host IP 
   addresses (non-link-local unicast addresses for IPv6)
   corresponding to a single host MAC address or there are many host MAC 
addresses 
   corresponding to a single IP address (non-link-local unicast address for 
IPv6), 
   then to detect host mobility, the procedures in
   
   must be exercised followed by the procedures described below.”


--
COMMENT:
--

[ general ]

* I believe this is true, but can you just state here (not in the doc) that
  there are no multi-link subnets that can be created with this model as
  defined in RFC 4903? It seems like everything is as it should be, but just
  to double-check.

[AS] I don’t see an multi-link subnet issue here. 

[ section 1 ]

* IP-VRF definition: s/VPN Routing.../Virtual Routing/?

[AS] Done.

[ section 3 ]

* 2nd to last paragraph: Is any of this still true for a setup that
  involves multiple IPv6 prefixes per BD, maybe I misunderstood
  (or maybe this assumed single prefix per broadcast domain w/ IPv4-only?).

  Perhaps avoid suggesting there's a 1:1 relationship and use phrases
  likes "at least as many X as there are Y" or something?

[AS] The paragraph says "typically", so it doesn't mandate 1:1 relationship.  

[ section 4 ]

* ARP table: a less IPv4-specific name, even though it's define to hold both
  IPv4 and IPv6 associations, would be "neighbor table".  That might be
  overloaded in routing contexts so no need to change it.

[AS] There was another comments 

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Ali Sajassi (sajassi)]

Hi John,

Thanks for your feedback. I was also thinking along the line of (2). I’ll take 
care of it in the next rev. soon.

Cheers,
Ali


From: John Scudder 
Date: Thursday, October 8, 2020 at 11:57 AM
To: Cisco Employee 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:57 AM

Thanks, Ali.

Yes, I think this should be explicit in the spec. I’d also suggest being 
explicit about what “ignore the rest” means. It could mean one of two things —

1. Don’t pay attention to the extra ones for purposes of computing the local 
forwarding table, but store them and propagate them.
2. Also don’t store or propagate them.

I’m guessing option 2 is better in this case. The problem with propagating them 
is sometimes implementations reorder things, so you could end up with 
inconsistency in the network.

—John


On Oct 8, 2020, at 2:42 PM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:



Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, October 8, 2020 at 11:12 AM
To: 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:stho...@cisco.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John



Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC Extended Communities (with different 
values) anyway, for example due to a bug or configuration error? This is a very 
real possibility since many BGP implementations allow policy to produce 
arbitrary communities.

Thanks,

—John

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

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Ali Sajassi (sajassi)]

Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder 
Date: Thursday, October 8, 2020 at 11:12 AM
To: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 

Cc: BESS 
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John


Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC Extended Communities (with different 
values) anyway, for example due to a bug or configuration error? This is a very 
real possibility since many BGP implementations allow policy to produce 
arbitrary communities.

Thanks,

—John

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

Re: [bess] WG adoption and IPR poll for draft-nr-bess-evpn-mh-split-horizon-03

[Ali Sajassi (sajassi)]

As a co-author, I support WG adoption of this draft and I am not aware of any 
relevant IPR.

Regards,
Ali

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

Date: Wednesday, September 9, 2020 at 3:43 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-nr-bess-evpn-mh-split-horizon-03

Hello,

This email begins a two-weeks WG adoption poll for 
draft-nr-bess-evpn-mh-split-horizon-03 [1].

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 23rd September 2020.

Regards,
Matthew and Stephane

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



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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Eric,

I add the following sentences in section 2 to provide further clarification to 
your point:
" It should be
   noted that if an IP-VRF in a NVE is configured for IPv6 and that NVE
   receives IPv4 traffic on the corresponding VLAN, then the IPv4
   traffic is treated as L2 traffic and it is bridged.  Also vise versa,
   if an IP-VRF in a NVE is configured for IPv4 and that NVE receives
   IPv6 traffic on the corresponding VLAN, then the IPv6 traffic is
   treated as L2 traffic and it is bridged." 

Cheers,
Ali

On 9/1/20, 1:46 AM, "Eric Vyncke (evyncke)"  wrote:

Thank you Ali for your reply.

My comments are non-blocking anyway but I am still not too happy with your 
reply to
- section 2, I still find the text not really clear
- unsure whether I understand the reasoning on section 4.1

Else, happy with all your changes => they will improve the document

Regards

-éric

-Original Message-
    From: "Ali Sajassi (sajassi)" 
Date: Tuesday, 1 September 2020 at 00:25
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Zhaohui Zhang 

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

Hi Eric,

Thanks for your review and your comments, please refer to my replies 
inline marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  
wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to 
all
email addresses included in the To and CC lines. (Feel free to cut 
this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/




--
COMMENT:

--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would 
appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many 
acronyms even for
short words (e.g., "SN" instead of "Subnet"). There are also very 
long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route 
inter-subnet IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, 
then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be 
clear enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the 
one used in
the initial ARP reply or ND Neighbor Advertisement (NA) for that 
TS." by "then
the IRB interface MAC address MUST be the one used in the initial 
ARP reply or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for 
that TS"
because routers MAC addresses are also advertised by Router 
Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP 
reply can be used 
In RA because it is a multicast packet - i.e., the MAC address of old 
IRB interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the 
first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds 
this TS's MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the 
Length field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is 
carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please 

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

[Ali Sajassi (sajassi)]

Hi Ben,

Thanks very much for your review and comments. Please refer to my replies 
inline marked with [AS].

On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
DISCUSS:
--

(1) Possibly a "discuss discuss", but ...
if I'm understanding correctly, the symmetric IRB case over an Ethernet
NVO tunnel (not MPLS or IP NVO) described in this document is
introducing a new scenario where traffic using router (PE) MAC addresses
as source and destination is comingled on the same tunnel with traffic
using tenant system MAC addresses as source and destination.  This
places an obligation on the tunnel endpoints to properly isolate and
process such "internal" tunnel traffic without hampering the ability of
tenans systems to communicate.  In a world where tenant systems can
appear at any time, using previously unknown MAC addresses, this
represents a rather challenging problem: how will the PEs be able to
pick (and avertise) MAC addresses that they know will not conflict with
any present or future customer systems?  (A similar dilemma led to quite
a delay in the processing of draft-ietf-bfd-vxlan, which in that case
was resolved by limiting the BFD operation to just the "management VNI"
which is not subject to MAC address conflict with customer systems.)  In
this docuement's case, we seem to be using a "well-known"/reserved MAC
address range from RFC 5798; in principle, this should be enough to
avoid conflicts, if customer systems are known to not squat on this
reserved range.  However, this document has some text in Section 4.1
that indicates that there must be external knowledge that auto-derived
MAC addresses in the RFC 5798 ranges "[do] not collide with any customer
MAC address".  So I'm left uncertain whether or not this potential
problem is addressed or not.  (Also, I don't know if the limit on 255
distinct such MAC addresses presents a scaling issue.)

[AS] Because the MAC addresses based on RFC 5798 is from a reserved range, 
there should be no conflict with customer MAC addresses that typically use 
their corresponding vendor OUI. If there was a conflict, then we would have the 
same issue with VRRP. However, this document doesn't want to give a blank check 
for auto-derivation of MAC addresses and that's why the statement about "... 
auto- derived MAC does not collide with any customer MAC address".

Also, is there any risk that the EVPN IRB setup might also want to use
VRRPv3, and thus collide on the MAC addresses in a different manner?

[AS] No, because redundancy procedure in EVPN replaces VRRP protocol. 

(1.1) I'm less sure whether there's a similar collision risk for IP
addresses -- we assign IP addresses to NVEs (e.g., for use as BGP Next
Hop addresses) and these are used as VTEP addresses when encapsulating
packets that are going inter-subnet.  I think that at this point in the
packet processing we may already know that we're in the the "IRB tunnel"
scope and that may be enough to de-conflict any potential IP address
collision between NVE and customer addresses.

[AS] customer IP addresses are from overlay-space; whereas, NVE addresses are 
from underlay space. Each customer has its own overlay address space that can 
overlap with other customers or underlay space but that doesn't cause an issue 
because they are kept in their own set of VRFs (its own set of routing tables). 
 

(2) Section 7 appears to reference (in a normative fashion)
[IRB-EXT-MOBILITY] but there is no such reference.

[AS] It is fixed now.

Similarly (as Murray notes), there are a couple apparent references to
[TUNNEL-ENCAP] that are also arguably normative, but the target of the
reference is not forthcoming (and the IANA registry does not show a "BGP
Encapsulation Extended Community" that is supposedly defined by
[TUNNEL-ENCAP]).

[AS]. "Encapsulation Extended Community" is in IANA registry: 
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml.
 


There is also not a listed reference for [EVPN-PREFIX], though one could
perhaps surmise that it is 

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Eric,

Thanks for your review and your comments, please refer to my replies inline 
marked with [AS].

On 7/14/20, 5:32 AM, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would appreciate 
a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

PS: as a side note, I found that this document uses too many acronyms even 
for
short words (e.g., "SN" instead of "Subnet"). There are also very long
sentences that, when combined with acronyms, make reading difficult.

== COMMENTS ==

-- Section 2 --
About "to bridge non-IP and intra-subnet traffic and to route inter-subnet 
IP
traffic": suggest to clarify the text when the IP-VRF is IPv6 only, then, (I
assume) that IPv4 packets will be bridged and not IP-forwarded (and 
vice-versa).

[AS] the above quoted text is provided as an example and it should be clear 
enough
Without making the sentence to verbose. 

-- Section 4.1 --
Suggest to replace "then the IRB interface MAC address MUST be the one used 
in
the initial ARP reply or ND Neighbor Advertisement (NA) for that TS." by 
"then
the IRB interface MAC address MUST be the one used in the initial ARP reply 
or
ND Neighbor Advertisement (NA) or Router Advertisement (RA) for that TS"
because routers MAC addresses are also advertised by Router Advertisements.

[AS] I don't think the IRB interface MAC address in the initial ARP reply can 
be used 
In RA because it is a multicast packet - i.e., the MAC address of old IRB 
interface and the
New IRB interface cannot be sent in a single multicast packet.

-- Section 5.1 --
Should also mention NDP when writing "(via an ARP request)" in the first
paragraph.

[AS] Done.

In the same vein, please add "NDP cache" to "Furthermore, it adds this TS's 
MAC
and IP address association to its ARP table".

[AS] Done.

As I am not an expert in EVPN, I am puzzled by the math about the Length 
field
"either 40 (if IPv4 address is carried) or 52 (if IPv6 address is carried)."

[AS] for IPv6, the NLRI has 12 additional bytes.

-- Section 5.2 --
This section also only mentions IPv4 ARP table, please add IPv6 NDP cache.

[AS] Done.

-- Section 6.1 --
Same comments as for section 5.1

AS] Done.

-- Section 6.2 --
Same comments as for section 5.2

[AS] Done.

-- Section 7 --
Good to state "Although the language used in this section is for IPv4 ARP, 
it
equally applies to IPv6 ND."; even if I would have preferred to use by 
default
IPv6 ND ;-)

[AS] yes, the quoted sentence already exist. 

Please note that in IPv6 there are often at least TWO IPv6 addresses per MAC
(one link-local fe80::... and one global); so, "In the following 
subsections,
it is assumed that the MAC and IP addresses of a TS have one-to-one
relationship (i.e., there is one IP address per MAC address and vice 
versa). "
is obviously never the case for IPv6. I understand that the rest of the
paragraph explains how to handle the case but it could be easier to treat 
IPv6
in a separate sentence.

-- Section 7.1 --
While about mobility, this section appears to be also applicable to 
Duplicate
Address Detection but is unclear on what to do when the same IP but 
different
MAC (i.e., an actual IP address collision). Or is it covered in other 
documents?

[AS] duplicate MACs are covered in RFC 7432.

== NITS ==

-- Section 1 --
"BD and subnet are equivalent terms" while in the rest of the document "IP
subnet" is often used. If "subnet IP" and "subnet" are synonyms, then I 
suggest
to keep using one for consistency or at least mention that "IP subnet" and
"subnet" are the same concept (or explain the difference if they are not
identical).

[AS] Added clarification that "subnet" means "IP subnet".




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

Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

[Ali Sajassi (sajassi)]

Sue,

I am afraid if we don’t clean up the draft, it can cause confusion as it has 
already and result in immediate errata filing for it after publication. A 
sub-bullet got added to the latest rev (rev17) that is not correct. It says 
that the VxLAN sub-tlv is sent with EVPN route when V bit not set. However, 
EVPN never uses this sub-tlv as its routes has all the needed info. 
Furthermore, RFC 8365 is very clear that EVPN uses Tunnel Encapsulation 
Extended Community (per section 4.1). As I said, I am not aware of any of the 
vendors using these sub-TVLs and it is easy to have a quick poll.

Regarding the paragraph that got omitted, it is making it much more ambiguous 
than it used to. I would opt for clarifying the paragraph rather than removing 
it. If needed I can provide an updated paragraph. Section 9 of RFC 8365 
specifies how a VPN multicast route can be advertised with PMSI tunnel 
attribute and Encapsulation extended community and has been implemented by many 
vendors.

Cheers,
Ali


From: Susan Hares 
Date: Friday, July 31, 2020 at 5:02 AM
To: Cisco Employee , "bess@ietf.org" , 
"i...@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: RE: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali:

It is wise to start with the RFC6514 and the 
draft-ietf-idr-tunnel-encapsulation draft.

[WG chair hat on]
The tunnel-encapsulation draft has passed general WG LC – so it is 
inappropriate to call for the request to remove these sections.  The WG LC that 
is currently running is whether to remove the “AS” field from the tunnel 
endpoint field, and replace it with a reserved field.

The implementation page is on:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations

If you wish to provide information on the cisco implementation, you are welcome 
to add information on the page.
I can call for an update to the page from vendors.

[WG chair hat off[
[Document shepherd hat on]

The issue is during the edits the text from RFC6514 from Eric Rosen was 
unclear.  The text was:



   It has been suggested that it may sometimes be useful to attach a
   Tunnel Encapsulation attribute to a BGP UPDATE message that is also
   carrying a PMSI (Provider Multicast Service Interface) Tunnel
   attribute [RFC6514<https://datatracker.ietf.org/doc/html/rfc6514>].  If the 
PMSI Tunnel attribute specifies an IP
   tunnel, the Tunnel Encapsulation attribute could be used to provide
   additional information about the IP tunnel.  The usage of the Tunnel
   Encapsulation attribute in combination with the PMSI Tunnel attribute
   is outside the scope of this document.

Since the text itself was unclear what additional information could be 
provided, the authors removed it from the draft.

As we had not received any feedback about active RFC6514 interactions on the 
list.

[document shepherd off]

If you have an implementation of the interaction between the RF6514 and tunnel 
encapsulation, it would be valuable to provide:

a)  either a draft specifying the interaction you wish to IDR WG, or
b)  comments that could replace the original the original text.

Since the IDR draft has gone through multiple WG LC and a very complete review 
from Alvaro – so a quick response would be appreciated.   IMHO a draft on the 
interaction between RFC6514 and the tunnel-encapsulation draft – would be the 
best thing at this point.  Let me know if you are interested in working on such 
a draft.

Sue


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Friday, July 31, 2020 1:54 AM
To: Susan Hares; bess@ietf.org; i...@ietf.org
Cc: 'Hu, Jun (Nokia - US/Mountain View)'
Subject: Re: IPSec Tunnels and draft-sajassi-bess-secure-evpn



Sue,

Before getting to the discussions of the three IPsec proposals, there are some 
elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have 
caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in 
sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has 
implemented these sub-tlvs because the info in these sub-tlv already exist in 
EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have 
implemented it. Therefore, all the vendors that I am aware of use Extended 
Community  defined in section 4.1  along with EVPN routes to signal VxLAN and 
GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! 
So, as the first step, we should remove these three sections from the draft if 
there is no objection.

Cheers,
Ali

From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee , "bess@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact 
draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been 
discu

[bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

[Ali Sajassi (sajassi)]

John, Jeff:

During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS WG 
meeting, you had a question/concern regarding why we are defining a new EC if 
we are doing conditional transitive. First, I’d like to make a correction to 
the preso by saying that the transitivity is not conditional and we will 
correct this in the next rev of the draft. So, the EC is simply transitive at 
all time. Given the EC defined in draft-ietf-idr-link-bandwidth-07.txt is 
non-transitive, we cannot use this EC for our application. That’s why we are 
defining a new one.

Cheers,
Ali

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

Re: [bess] IPSec Tunnels and draft-sajassi-bess-secure-evpn

[Ali Sajassi (sajassi)]

Sue,

Before getting to the discussions of the three IPsec proposals, there are some 
elements of draft-ietf-idr-tunnel-encaps-17.txt that I can see might have 
caused some confusions and I’d like to get those sorted out first.

The tunnel-encap draft specifies sub-tlv for VxLAN, VxLAN GDP, and NVGRE in 
sections 3.2.1, 3.2.2, and 3.2.3. I am not aware of any vendor that has 
implemented these sub-tlvs because the info in these sub-tlv already exist in 
EVPN routes (e.g., MAC addresses, Ethernet Tags, etc.) which they have 
implemented it. Therefore, all the vendors that I am aware of use Extended 
Community  defined in section 4.1  along with EVPN routes to signal VxLAN and 
GENEVE tunnel types. Furthermore, I am not aware of anyone using NVGRE encap! 
So, as the first step, we should remove these three sections from the draft if 
there is no objection.

Cheers,
Ali

From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:30 AM
To: Cisco Employee , "bess@ietf.org" 
Cc: "'Hu, Jun (Nokia - US/Mountain View)'" 
Subject: IPSec Tunnels and draft-sajassi-bess-secure-evpn

Ali and bess WG:

IDR has 3 proposals for IPsec tunnels that impact 
draft-ietf-idr-tunnel-encaps-17.txt.  As an IDR co-chair/shepherd,  I have been 
discussing these three drafts (Ali and two other authors sets) to try to find 
out if we can have one general solutions.

The discussion has been very fruitful to point up BGP issues of 
interoperability, security, privacy, manageability, and scaling.  For example, 
there is a lack of a clear specification between RFC6514 (PMSI tunnel 
attribute) and the tunnel-encaps draft that specifies how these drafts 
interoperate.  I suspect the bess and idr chairs will need to discuss if 
tunnel-encaps has to address this point.

I wrote up my ideas in draft-hares-idr-bgp-ipsec-analysis-00.txt so the authors 
could tell me what I misunderstood.   You’ll find this draft stops half way.  I 
have the rest of the draft written, but I wanted feedback from all the author 
teams before sending it out.

After hearing some of the details from the authors, I would like to sponsor an 
IDR interim so we could discuss these issues at length.   If you think this is 
a good idea, please let me know.

One other thing… unfortunately, I scheduled a set of meetings for EDT time 
after IETF meetings this week.   Your next response will occur from 11-16 UTC 
on Wednesday.

Cheerily, Sue


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

Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

[Ali Sajassi (sajassi)]

Sue,


From: Susan Hares 
Date: Tuesday, July 28, 2020 at 8:11 AM
To: Cisco Employee , "bess@ietf.org" 
Subject: RE: [bess] Why are you specifying two new tunnel types for 
encapsulation for EVPN?

Ali:

Three major high points from the discussion:

1) tunnel-encap and RFC6512 lack a clearly defined interoperability statement
If you are using RFC6512 PMSI tunnel attribute and Tunnel-encap attribute, 
this issue needs to be sorted out.

AS>  Secure-evpn draft doesn’t use RFC6512 PMSI tunnel attribute. It only uses 
Tunnel-encap. I was just providing an example wrt underlay tunnel type vs. 
overlay encap.


2)  If your draft depends on draft-carrell-ipsecme-controller-ike-00.txt,
 then the review at IETF 105 by security experts had concerns which have 
not been resolved.
(Also draft-carrell-ipsecme-controller-ike-01.txt has expired and there is not 
a replacement.)

AS> Secure-evpn relies on rekeying from 
draft-carrell-ipsecme-controller-ike-00.txt. If there is a better proposal for 
rekeying, then I am all ears. We’ll take care of the expired status of that 
draft shortly.

If your draft depends on general features of rekeying, nonces, security 
association databases, and security policy data bases, then I suggest revising 
the draft to point to existing features.

AS> secure-evpn draft does reference to carrell controller-ike draft regarding 
those features (e.g., section 4.4 for rekeying, section, 4.5 for ipsec 
databases).

3) [IDR-Shepherd-hat on]  A general solution for IPsec security association 
passing is wise

AS> That’s what is described here – i.e., a general solution that applies to 
EVPN and other type of VPNs because it uses an attribute that can be passed 
with any NLRI.

All of this points toward the creation of a general IPSEC functionality in BGP 
rather than EVPN specific work.If it is true, then we ought to create one 
solution in IDR for the 3 scenarios.

AS> As I said before, the solution applies to EVPN as well as other VPN types. 
That’s why I have a section that explain how other VPN solution can be 
beneficiary of the same solution. BTW, because we are talking about signaling 
for BGP Enable Services, this draft and any other related drafts in this area 
belong to BESS. Of course, IDR will be involved as always.

Cheers,
Ali

See my comments as Sue2>.  I use the following abbreviations


tunnel-encaps -  draft-ietf-idr-tunnel-encaps-17.txt
sajassi-s-evpn – draft-sajasssi-bess-secure-evpn-03.txt
RFC6514 – PMSI Tunnel Attribute (PMSI)

Cheerily, Sue

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Tuesday, July 28, 2020 9:45 AM
To: Susan Hares; bess@ietf.org
Subject: Re: [bess] Why are you specifying two new tunnel types for 
encapsulation for EVPN?

Sue,

Please see my responses below marked with AS>

From: BESS  on behalf of Susan Hares 
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "bess@ietf.org" 
Subject: [bess] Why are you specifying two new tunnel types for encapsulation 
for EVPN?

Ali:
From draft-sajassi-bess-secure-evpn:
6<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-6> BGP 
Encoding

This document defines two new Tunnel Types along with its associated

   sub-TLVs for The Tunnel Encapsulation Attribute 
[TUNNEL-ENCAP<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP>].
 These

   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as

   described in section 
4<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-4>. The 
following sub-TLVs apply to both tunnel

   types unless stated otherwise.


1.  Why are you specifying 2 new tunnel types?  What makes these special?

What in the use of the tunnel encapsulation draft does not support for the 
inner and outer tunnel requires you to specify a ESP-Transport and  
ESP-in-UDP-Transport?

AS> We need to differentiate between underlay tunnel and overlay encap. For 
example, in PMSI tunnel attribute, tunnel type can be PIM-SM or PIM-SSM; 
whereas, overlay encap can be VxLAN, NVGRE, GENVE, etc. So, similarly here, the 
underlay tunnel can be ESP-Transport or ESP-in-UDP-Transport and the overlay 
can be any of the overlay encap. If you think the existing tunnel-encap can 
address both underlay and overlay, please indicate how.

Sue2> One of my main concerns is the interoperability between tunnel-encaps and 
extensions to RFC6514.

AS>> No interop is needed as explained above.

tunnel-encaps  provides both outer encapsulation [see section 3.3] and inner 
encapsulation [see section 3.2].  The only overlay thing in sajassi-s-evpn 
which tunnel-encaps  which cannot be supported is GENVE.

Reviewers of tunnel-encaps have requested why GENVE was not included.  IDR 
requires 2 implementation of the code.  If sajassi-s-evpn has an implementation 
with GENVE, then tunnel-encaps should include it in the base tunnel-encaps 
draft.

I do not see a PIM-SM o

Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

[Ali Sajassi (sajassi)]

Sue,

Please see my responses below marked with AS>

From: BESS  on behalf of Susan Hares 
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "bess@ietf.org" 
Subject: [bess] Why are you specifying two new tunnel types for encapsulation 
for EVPN?

Ali:
From draft-sajassi-bess-secure-evpn:
6 BGP 
Encoding

This document defines two new Tunnel Types along with its associated

   sub-TLVs for The Tunnel Encapsulation Attribute 
[TUNNEL-ENCAP].
 These

   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as

   described in section 
4. The 
following sub-TLVs apply to both tunnel

   types unless stated otherwise.


1.  Why are you specifying 2 new tunnel types?  What makes these special?

What in the use of the tunnel encapsulation draft
does not support for the inner and outer tunnel requires
you to specify a ESP-Transport and  ESP-in-UDP-Transport?

AS> We need to differentiate between underlay tunnel and overlay encap. For 
example, in PMSI tunnel attribute, tunnel type can be PIM-SM or PIM-SSM; 
whereas, overlay encap can be VxLAN, NVGRE, GENVE, etc. So, similarly here, the 
underlay tunnel can be ESP-Transport or ESP-in-UDP-Transport and the overlay 
can be any of the overlay encap. If you think the existing tunnel-encap can 
address both underlay and overlay, please indicate how.

[see section 5.1 of your draft]

2.  What IPSEC security information is unique to the EVPN solution that is not 
general?

AS> They are general and not specific to EVPN.

Section 4 of  draft-sajassi-bess-secure-evpn-03.txt
describes the IPSEC DIM and security policies on in the following case:

a) you need to send IPSEC information – via RR mesh
b) you have policies that you want to use  the 
[draft-carrell-ipsecme-controller-ike-00.txt]
c) you want on demand re-keying
d) “policy” – undefined
on #a) there are multiple BGP IPsec proposal using the RR mesh

AS> What is the question wrt this draft?

on #b) can you tell me what is unique about 
[draft-carrell-ipsecme-controller-ike-00.txt]

AS> Again what is the specific question wrt this draft? What section/line of 
this draft is not clear?

on #c) isn’t on-demand re-keying a desire to prevent DDOS that is a good 
feature for all IPsec?

AS> Yes, re-keying is a requirement.

On #d) policy is normal for all IPsec

AS> You can have min. set with no SA policy, you can have a single SA policy, 
or you can have a SA policy list.

Cheers,
Ali

Thank you, Sue
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Questions about the ESP-Transport and ESP-in-UDP transport in SECURE-EVPN

[Ali Sajassi (sajassi)]

Linda,

Please see my responses inline marked with AS> …

From: Linda Dunbar 
Date: Tuesday, July 28, 2020 at 5:49 AM
To: Cisco Employee , "bess@ietf.org" 
Subject: Questions about the ESP-Transport and ESP-in-UDP transport in 
SECURE-EVPN

Ali,

Just follow up with my question in the BESS WG session.
Your draft introduced two Tunnel Types in 5.1: ESP-Transport and ESP-in-UDP 
Transport as below.


When standard IP Encapsulating Security Payload (ESP) is used
(without outer UDP header) for encryption of NVO packets, it is used
in transport mode as depicted below. When such encapsulation is used,
for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set
to ESP-Transport and the Tunnel Type of Encapsulation Extended
Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,
etc.). This implies that the customer packets are first encapsulated
using NVO encapsulation type and then it is further encapsulated &
encrypted using ESP-Transport mode.

Question 1:  Are you assuming that  using IPsec Transport mode? Instead of 
IPsec Tunnel mode?


AS> Not assuming but stating ☺ 1st line of section 5.1 says:

 “ … it is used in transport mode as depicted below”

Question 2: Your Figure 3 has two encodings, which one is “ESP-Transport”, 
which one is “ESP-in-UDP”?

AS> Figure 3 is for ESP-transport and Figure 4 is for ESP-in-UDP. Furthermore, 
section 5.1 is for ESP-transport and section 5.2 is for ESP-in-UDP.

Question 3: The NVO encapsulation (VxLAN, GENEVE, GRE) can also be inside the 
IPsec ESP tunnel. In that case, which type is used?

AS> The tunnel type of the attribute indicates what kind of underlay tunnel is 
used and the tunnel type of the extended community indicates what kind of 
overlay encap is used. Section 5.1 says:


   “the Tunnel Type of Tunnel Encapsulation TLV is set

   to ESP-Transport and the Tunnel Type of Encapsulation Extended

   Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,

   etc.).”

And section 5.2 says:

   “the Tunnel Type

   of Tunnel Encapsulation TLV is set to ESP-in-UDP-Transport and the

   Tunnel Type of Encapsulation Extended Community is set to NVO

   encapsulation type (e.g., VxLAN, GENEVE, GPE, etc.). “

Cheers,
Ali

Thanks, Linda

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

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Murray,

Thanks for your review and comments. Please see my responses inline marked with 
"AS>".

Cheers,
Ali

On 7/13/20, 10:50 PM, "Murray Kucherawy via Datatracker"  
wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

Bigger stuff:

I'll see Benjamin's DISCUSS (meaning I support it) and raise him the two
seemingly normative references to [TUNNEL-ENCAP], which is also undefined.

AS> Added the reference to tunnel-encap.

As someone not from the Routing Area, I found this a little hard to read
because it becomes quite dense with acronyms in some places.

Is Section 13 intended to remain in the final published version?  Is it 
needed?

AS> removed this one-line section since other RFCs don't have such an explicit 
IPR section.

In the Abstract, please expand all acronyms on first use in the abstract, 
per
the I-D Guidelines.

AS> Done.

Lesser stuff:

Thanks for the glossary in Section 1.  I note that, although defined in the
glossary here, the terms "DGW", "Ethernet A-D route", "GRE", "GW IP", "IPL",
"ML", and "VXLAN" are not used anywhere else in this document.

AS> removed the unused terms.

There are lots of places where a single hyphen is used to break up a 
sentence,
such as to introduce an example.  These should be em dashes, or commas, or
maybe semicolons, but not simply hyphens.

AS> done.

A few nits:

Section 2:

* "... all the inter-subnet forwarding are performed ..." -- s/are/is/

AS> done.

* "... connected to the same PE, wanted to communicate ..." -- remove the 
comma

AS> done.

Section 3:

* "A MAC-VRF can consists of one ..." -- either drop "can", or use "consist"

AS> done.


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

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)

[Ali Sajassi (sajassi)]

Hi Rob,

Thanks for your review and comments. Please see my reply inline marked with 
"AS>". 

On 7/16/20, 6:38 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



--
COMMENT:
--

I agree with the other ADs that this document seemed terse in places and 
won't
repeat those same comments here.

One question I have is whether it is possible to have a deployment where 
some
devices support synchronous mode and others support asynchronous mode.  Am I
right in presuming that this is not supported and if so is this capability
signaled in any way? Or is the expectation that this would be controlled via
deployment choice of network device, or though configuration management?

AS> The current deployments AFAIK are either symmetric or asymmetric. However, 
this  doesn't mean that we won't run into interop between symmetric and 
asymmetric IRB in the future. That's why we put out a draft to describe the 
interop between symmetric and asymmetric IRB modes about a year ago - 
https://tools.ietf.org/html/draft-krattiger-evpn-modes-interop-01.

Cheers,
Ali

Regards,
Rob




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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-lsp-ping

[Ali Sajassi (sajassi)]

Support as a co-author. I am not aware of any undisclosed IPR.

From: "slitkows.i...@gmail.com" 
Date: Friday, July 3, 2020 at 6:29 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-lsp-p...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-lsp-ping
Resent-From: 
Resent-To: , , Cisco Employee 
, , 
Resent-Date: Friday, July 3, 2020 at 6:29 AM

Hello WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-lsp-ping-02 [1].

This poll runs until * the 20th Of July *.


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

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

There is currently no IPR disclosed.



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



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



Thank you,

Stephane & Matthew

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

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

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-inter-subnet-forwarding-09

[Ali Sajassi (sajassi)]

Hi Joel,

Thanks for your review and comments, please see inline for my reply marked with 
AS>:

On 7/6/20, 8:06 PM, "Joel Jaeggli via Datatracker"  wrote:

Reviewer: Joel Jaeggli
Review result: Ready

greetings,

I have reviewed draft-ietf-bess-evpn-inter-subnet-forwarding on behalf of 
the
ops directorate.

as a datacenter operator something of a conflict appears for me in this 
work in
that  I struggle with the state explosion that IRBs each host / subnet
represent on the PE switches. As the document says:

   In other words, each PE participating in
   asymmetric IRB MUST maintain ARP entries for remote hosts (hosts
   connected to other PEs) as well as maintain MAC-VRFs/BTs and IRB
   interfaces for ALL subnets in an IP VRF including subnets that may
   not be locally attached.

We designed ourselves into  a corner where we need this document.

it would be helpful if section 4 would be more explicit for 
non-implementors on
when symetric or asymetric modules would be chosen, as it stands the 
variation
basically reads like the enumeration of the features of various 
implementations.

AS> There are tradeoffs between symmetric and asymmetric IRB among which the 
scale in terms of # of bridge tables, # of ARP entries, and # of MAC addresses 
that a PE need to keep. I will add a note to section 4 that for asymmetric IRB 
application, careful consideration needs to be given for these scale aspects.

Regards,
Ali

I think this document is ready to proceed and it clearly addresses needs in
these implementations.

joel



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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02

[Ali Sajassi (sajassi)]

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

Cheers,
Ali



From: "Bocci, Matthew (Nokia - GB)" 
Date: Monday, June 15, 2020 at 3:55 AM
To: "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, "bess@ietf.org" 
Subject: WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02
Resent-From: 
Resent-To: , Cisco Employee , 
, , 
Resent-Date: Monday, June 15, 2020 at 3:55 AM

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-oam-req-frmwk-02

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

This poll runs until Monday 29th June 2020.

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

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

Re: [bess] WG adoption and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

[Ali Sajassi (sajassi)]

This draft covers the different SDWAN use cases nicely and has come a long way 
since its initial rev. As a co-author I support adoption of this draft and I am 
not aware of any undisclosed IPRs related to this draft.

Cheers,
Ali

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

Date: Tuesday, June 23, 2020 at 5:14 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-dunbar-bess-bgp-sdwan-usage-07

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dunbar-bess-bgp-sdwan-usage-07 [1] ..

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

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

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

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

This poll for adoption closes on 7th July 2020.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/


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

Re: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05

[Ali Sajassi (sajassi)]

The issues raised during the email thread before the last IETF, have been 
addressed in this rev and the doc is ready to be progressed.

Cheers,
Ali

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

Date: Monday, May 18, 2020 at 12:54 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05

Hi WG,

Following the discussion and significant document update, we are starting a new 
Working Group Last Call on draft-ietf-bess-evpn-igmp-mld-proxy-05

This poll runs until the 1st of June.

Please read carefully the document and raise any concern about the changes that 
have been introduced.


Thanks,

Stephane & Matthew

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy

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

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Ali Sajassi (sajassi)]

Hi John,

To accommodate Jakob’s and Jeff’s comment, we can say:

“This field is not part of the route key. The originator MUST set the reserved 
field to Zero (because this field used to be part of the route key), the 
receiver SHOULD ignore it and if it needs to be propagated, it MUST propagate 
it unchanged”.

Once the new rev is published, we can comment and fine tune the text.

Cheers,
Ali

From: John Scudder 
Date: Tuesday, April 28, 2020 at 8:50 AM
To: Cisco Employee 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "Jakob Heitz (jheitz)" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

Hi Ali,

Yes, making the field reserved would be fine from my point of view, thanks.

Also to repeat the point that was raised at the mic during the meeting just 
now, there should be some text to the effect of “this field is reserved. It 
MUST be transmitted as zero. Any value MUST be accepted on receipt.”

Jakob added this comment in the WebEx chat: “Perhaps also, if propagated, it 
must be propagated the way it was received. For example RR”. That seems 
reasonable to me for an RR (or other device that propagates routes without 
consuming them, sometimes ASBRs can do this). So maybe this text? Jakob, what 
do you think?

“This field is reserved. It MUST be originated as zero. Any value MUST be 
accepted on receipt.”

I changed “transmitted” to “originated” to try to capture the distinction. I 
guess there might need to be some consideration of what exactly “accepted” 
means. I don’t mean that it should be part of the key, I just mean it shouldn’t 
be considered an error.

In any case this is a small detail to be ironed out in the final text, the 
approach Ali proposes is fine.

—John


On Apr 28, 2020, at 1:08 AM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:


Hi John,

My objection to using two code points for RT-8 and do a migration from old to 
new is two folds:

  1.  As I explained in my previous emails, there are vendors who have 
implemented both formats based on a single code point after our meeting around 
IETF 106 and I don’t want to have them yet again do another implementation. 
Basically, it is not fair to them.
  2.  One of the fundamental premise of EVPN is minimizing configuration and 
that’s why we have lots of auto-derivation / auto-configuration features in 
EVPN – e.g., auto-derivation of ESIs and auto-derivations of RTs, etc. I really 
don’t want to add any extra configuration knobs for BGP peer as to what format 
it supports considering how much efforts has gone into the EVPN protocol to 
minimize configurations.
AFAIK, there is only one vendor who implemented ONLY the existing format with 
deployments (your vendor) and there is only one vendor who implemented ONLY the 
new format with deployments (my vendor). Other vendors that I know (and we need 
to poll again) have either implemented both formats with a single code point or 
haven’t done the implementation yet.

So, after discussing the situation with my development team today, we are OK 
with using the old format and upgrade our field deployment toward that. This 
way we can avoid using two different code points and all the intricacies that 
comes with it – i.e.,  additional configuration knobs and migration stuff. So, 
we change the “Leave Synchronization Number” field to 4-byte reserved field (to 
be set zero upon transmission and ignored when received). It should also not be 
part of route-key processing of course.

Mankamana will present a few slides on this tomorrow and we will seek WG 
consensus on this. Once we have consensus, then the update of the draft is 
rather easy and we will move quickly on it.

Cheers,
Ali


From: John Scudder mailto:j...@juniper.net>>
Date: Monday, April 27, 2020 at 8:56 AM
To: Cisco Employee mailto:saja...@cisco.com>>
Cc: "Mankamana Mishra (mankamis)" 
mailto:manka...@cisco.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org<mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>>
Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:stho...@cisco.com>>, 
mailto:ke...@arrcus.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:w...@juniper.net>>
Resent-Date: Monday, April 27, 2020 at 8:56 AM

Hi Ali,

Yes, of course the current sad situation requires operators to exercise extra 
care (“good operational procedures”). The discussion is whether this shall 
continue indefinitely into the future (if we keep using the same code point) or 
if it has a clear end (if we move to a standardized code point).

As far as I can tell your argument for 

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Ali Sajassi (sajassi)]

Hi John,

My objection to using two code points for RT-8 and do a migration from old to 
new is two folds:

  1.  As I explained in my previous emails, there are vendors who have 
implemented both formats based on a single code point after our meeting around 
IETF 106 and I don’t want to have them yet again do another implementation. 
Basically, it is not fair to them.
  2.  One of the fundamental premise of EVPN is minimizing configuration and 
that’s why we have lots of auto-derivation / auto-configuration features in 
EVPN – e.g., auto-derivation of ESIs and auto-derivations of RTs, etc. I really 
don’t want to add any extra configuration knobs for BGP peer as to what format 
it supports considering how much efforts has gone into the EVPN protocol to 
minimize configurations.
AFAIK, there is only one vendor who implemented ONLY the existing format with 
deployments (your vendor) and there is only one vendor who implemented ONLY the 
new format with deployments (my vendor). Other vendors that I know (and we need 
to poll again) have either implemented both formats with a single code point or 
haven’t done the implementation yet.

So, after discussing the situation with my development team today, we are OK 
with using the old format and upgrade our field deployment toward that. This 
way we can avoid using two different code points and all the intricacies that 
comes with it – i.e.,  additional configuration knobs and migration stuff. So, 
we change the “Leave Synchronization Number” field to 4-byte reserved field (to 
be set zero upon transmission and ignored when received). It should also not be 
part of route-key processing of course.

Mankamana will present a few slides on this tomorrow and we will seek WG 
consensus on this. Once we have consensus, then the update of the draft is 
rather easy and we will move quickly on it.

Cheers,
Ali


From: John Scudder 
Date: Monday, April 27, 2020 at 8:56 AM
To: Cisco Employee 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Monday, April 27, 2020 at 8:56 AM

Hi Ali,

Yes, of course the current sad situation requires operators to exercise extra 
care (“good operational procedures”). The discussion is whether this shall 
continue indefinitely into the future (if we keep using the same code point) or 
if it has a clear end (if we move to a standardized code point).

As far as I can tell your argument for continuing to use code point 8 is “it 
would be extra work to move”. Well, yes. Progress requires effort. It’s not a 
lot of effort but it’s more than nil.

Regarding “we thought we had unanimous agreement” I am surprised to see this 
raised as some kind of justification, considering that the field has been 
present since -01 of the individual draft in October 2016, was in there for 
WGLC, and remains there up to this moment. As far as I can tell the first time 
the proposal to remove the field was discussed in the WG was at the IETF-106 
meeting, and I haven’t seen any consensus (either formal or informal) on the 
mailing list since then. Reviewing the recording of the 106 meeting, most of 
the issues I’ve raised were also raised then, in particular by Jeff Haas and 
Keyur Patel, who took some care to explain why it’s a problem from the BGP 
protocol operation side. Presenting this as a fait accompli based on private 
conversations would be poor form even if the proposal didn’t have technical 
deficiencies that were pointed out months ago.

Just because you can hold things together with spit and baling wire, doesn’t 
mean you should settle for that. I am perplexed as to why you’re so opposed to 
doing what is both the normal and the right thing.

—John



On Apr 26, 2020, at 6:07 PM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:


Hi John,

I think we need a good operational procedures similar to what we did for RT-4 
regardless of what approach we take because currently we have two deployments 
(by two vendors) that use the RT-8 with two different lengths. And without 
proper procedure, mixing these boxes can cause issues such as BGP session reset 
(which you also pointed out previously). So, I believe we need to have a proper 
procedure while we are upgrading them to interoperate with each other. And for 
interoperability, let me categorize the use of the two different code-points as 
the 3rd option. So for sake of completeness, let me repeat them here:


  1.  Just go with the new format and for multi-vendor deployment, making sure 
the new format is used. Considering the current deployments situations where 
intra-DCs and intra-sites are  done using a single vendor but different vendors 
are used for different sites and DCs, this can be feasible. Maybe that’s why we 
haven’t run into the interop issues because for the current depl

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Ali Sajassi (sajassi)]

RT-4 is a good example as we had the same issue of changing the length of the 
route and at the time there were deployments of EVPN/PBB-EVPN multi-homing as 
multi-homing is a key feature for EVPN. From your company Rahual Aggarwal was 
the EVPN contact and we closely coordinated this and later the baton got passed 
to John Drake. You may want to check with them regarding this history as you 
got involved much later.

As I explained in my emails, we would need a good operational procedure 
regardless of which approach to take and thus I will not repeat myself. Besides 
your vendor, all other vendors who responded are in favor of the new format and 
AFAIK these vendors who have responded and implemented it, they have 
implemented either to support for both formats or the length check for both 
formats. It is very easy to do the length check for both formats and by doing 
this, different multi-homing PE sets can be made interop with each other. Then 
for interop within a multi-homing set from different vendors, the support for 
the new format is needed.

Cheers,
Ali

From: Wen Lin 
Date: Sunday, April 26, 2020 at 9:58 PM
To: Cisco Employee , John Scudder 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

Hi All,

Thank you for bringing up the discussion on the WG mailing list.

I don’t think RT-4 is a good example to follow.  On the other hand, I am not 
sure if PBB-EVPN or EVPN multihoming was deployed in any real production 
network back in 2013 when the NLRI of RT-4 was updated.   In any case, the 
potential risk to the network is now clearly explained in this email thread.  
For type-8 we need a safe procedure to avoid any potential risk to the network.

Multihoming PEs may come from the same vendor in some networks, but we are 
talking about the standard procedure here.   Similarly, we have the standard in 
the EVPN DF election procedures among/between multihoming PEs.

Today EVPN is widely deployed, not only in DC, but also in service provider and 
enterprise networks.  We not only have PBB-EVPN, but also EVPN/VXLAN, 
EVPN/MPLS, EVPNoMPLSoUPD, etc.  EVPN is supported by many vendors today.

Thanks,
Wen

From: "Ali Sajassi (sajassi)" 
Date: Sunday, April 26, 2020 at 6:08 PM
To: John Scudder 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Sunday, April 26, 2020 at 6:08 PM

[External Email. Be cautious of content]

Hi John,

I think we need a good operational procedures similar to what we did for RT-4 
regardless of what approach we take because currently we have two deployments 
(by two vendors) that use the RT-8 with two different lengths. And without 
proper procedure, mixing these boxes can cause issues such as BGP session reset 
(which you also pointed out previously). So, I believe we need to have a proper 
procedure while we are upgrading them to interoperate with each other. And for 
interoperability, let me categorize the use of the two different code-points as 
the 3rd option. So for sake of completeness, let me repeat them here:


  1.  Just go with the new format and for multi-vendor deployment, making sure 
the new format is used. Considering the current deployments situations where 
intra-DCs and intra-sites are  done using a single vendor but different vendors 
are used for different sites and DCs, this can be feasible. Maybe that’s why we 
haven’t run into the interop issues because for the current deployment model.
  2.  Accommodate both lengths (i.e., bullet b) above) and turn on 
RT-constraint on the PEs that support old RT-8 format. This way, the RR can 
properly reflect both RT-8 formats. The PEs supporting the new format can be 
inserted into the network without issue. And the PEs supporting the old format 
can be gradually migrated to the new format.
  3.  Use a new code point for the new format and the new PEs need to support 
both code points and then deprecate the old code point
If we look at the vendor situation (AFAIK), since IETF in Nov, the vendors that 
have implemented this feature except one, have upgraded their implementation to 
support either both format or both lengths because we thought we had a 
unanimous agreement. So, that means all vendors except one can do option 1 and 
2. Now if we are asking everyone to implement option 3, then that would impose 
additional burden on the vendors that they have already implemented to support 
both formats/length with the same code point. I agree that if we weren’t in the 
current situation, option 3 would have been somewhat cleaner, but at this 
point, if we go with option 3, we will be asking these vendors to do yet 
another implementation.

With regard to my RT-constraint

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Ali Sajassi (sajassi)]

Hi John,

I think we need a good operational procedures similar to what we did for RT-4 
regardless of what approach we take because currently we have two deployments 
(by two vendors) that use the RT-8 with two different lengths. And without 
proper procedure, mixing these boxes can cause issues such as BGP session reset 
(which you also pointed out previously). So, I believe we need to have a proper 
procedure while we are upgrading them to interoperate with each other. And for 
interoperability, let me categorize the use of the two different code-points as 
the 3rd option. So for sake of completeness, let me repeat them here:


  1.  Just go with the new format and for multi-vendor deployment, making sure 
the new format is used. Considering the current deployments situations where 
intra-DCs and intra-sites are  done using a single vendor but different vendors 
are used for different sites and DCs, this can be feasible. Maybe that’s why we 
haven’t run into the interop issues because for the current deployment model.
  2.  Accommodate both lengths (i.e., bullet b) above) and turn on 
RT-constraint on the PEs that support old RT-8 format. This way, the RR can 
properly reflect both RT-8 formats. The PEs supporting the new format can be 
inserted into the network without issue. And the PEs supporting the old format 
can be gradually migrated to the new format.
  3.  Use a new code point for the new format and the new PEs need to support 
both code points and then deprecate the old code point
If we look at the vendor situation (AFAIK), since IETF in Nov, the vendors that 
have implemented this feature except one, have upgraded their implementation to 
support either both format or both lengths because we thought we had a 
unanimous agreement. So, that means all vendors except one can do option 1 and 
2. Now if we are asking everyone to implement option 3, then that would impose 
additional burden on the vendors that they have already implemented to support 
both formats/length with the same code point. I agree that if we weren’t in the 
current situation, option 3 would have been somewhat cleaner, but at this 
point, if we go with option 3, we will be asking these vendors to do yet 
another implementation.

With regard to my RT-constraint comment, allow me to clarify it as follow: The 
RT-8 is only intended to be exchanged among multi-homing PEs and 99% of 
multi-homing scenarios are dual-homing. Furthermore, the dual-homing PEs are 
from the same vendor. This means when this route is advertised by a PE in an 
EVPN network that has 100 PEs, it uses a route-target that is for only one 
other PE. So, in a network with PE1 to PE100 where PE1 and PE2 are dual-homed 
and PE1 advertised this route, then only PE2 needs to import this route and all 
other PEs need to discard when they receive. So, let’s assume, we have a 
network where PE1 to PE 50 run the old format and the PE51 through PE100 run 
option-2 (e.g., they either support both formats or both lengths). Then, when 
PE1 wants to advertise an RT-8 intended for PE2, it will be received by PE3 to 
PE100 and they will discard the route. Now, we need to make sure if PE100 
advertises a route for PE99 (its dual-homing counterpart) with the new format, 
it doesn’t cause an issue for PE1 to PE50. These PEs can use RT-constraint to 
have the RR only send the routes that they have imports for. So, PE1 will not 
receive the RT-8 route from PE100 to cause it any issue.

Regards,
Ali




From: John Scudder 
Date: Sunday, April 26, 2020 at 12:33 PM
To: Cisco Employee 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

Hi Ali,

Your option 1 is substantially what I proposed, the sole difference being that 
I propose following normal IETF procedure and moving to a new code point. 
Without moving to a new code point, the only thing standing in the way of a 
catastrophe is luck and good operational procedures, hardly a robust option. 
With moving to a new code point, there’s literally no way to trigger this 
scenario.

It’s the safer thing to do and the right thing to do. The code’s not hard, I’m 
tempted to call it trivial. We do this kind of thing all the time — one code 
point for prestandard, another for the standardized version. I see no downside, 
all upside.

Regarding RT-constrain, I don’t follow your reasoning for how it guarantees 
safety in a mixed network.

—John


On Apr 26, 2020, at 3:21 PM, Ali Sajassi (sajassi)  wrote:

John,

Thanks for your insightful input and suggestion. We have had other situations 
similar to this in the past and we have resolved them by the consensus and 
without having a “ticking time bomb” to cause a network meltdown. One such 
situation was the need to extend RT-4 to add the originator router’s address 
which changed the length of RT-4 route. At the time there were pre-RFC 
imple

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Ali Sajassi (sajassi)]

John,

Thanks for your insightful input and suggestion. We have had other situations 
similar to this in the past and we have resolved them by the consensus and 
without having a “ticking time bomb” to cause a network meltdown. One such 
situation was the need to extend RT-4 to add the originator router’s address 
which changed the length of RT-4 route. At the time there were pre-RFC 
implementation from several vendors already deployed in different networks and 
the vendors decided to go with the new RT-4 format and upgrade to it and making 
sure the interoperability is based on standard RFC and not pre-standard 
version. That worked fine as I and other colleagues from other vendors 
(including yours) are not aware of any issues regarding that update. We have a 
lesser situation in here because of the following implementation status:


  1.  Some vendors have implemented both format
  2.  Some vendors have allowed for both lengths (including my vendor) to avoid 
malformed NLRI. Allowing for both length doesn’t mean supporting both format 
but rather both lengths so that the PE that doesn’t need to import the route, 
doesn’t interpret the old format as malformed.
  3.  Vendors that haven’t implemented it, prefer new format
  4.  AFAIK, there is only a single vendor that implemented the v4-only format

So, based on the current data, I think we can have the following two options 
that IMO are simpler:

  1.  Just go with the new format and for multi-vendor deployment, making sure 
the new format is used. Considering the current deployments situations where 
intra-DCs and intra-sites are  done using a single vendor but different vendors 
are used for different sites and DCs, this can be feasible. Maybe that’s why we 
haven’t run into the interop issues because for the current deployment model.
  2.  Accommodate both lengths (i.e., bullet b) above) and turn on 
RT-constraint on the PEs that support old RT-8 format. This way, the RR can 
properly reflect both RT-8 formats. The PEs supporting the new format can be 
inserted into the network without issue. And the PEs supporting the old format 
can be gradually migrated to the new format.

I should just mention that for RT-4 changes that all the vendors did long time 
ago, the approach (1) was adopted.

Regards,
Ali


From: John Scudder 
Date: Friday, April 24, 2020 at 3:01 PM
To: "Mankamana Mishra (mankamis)" 
Cc: "bess@ietf.org" , 
"draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Friday, April 24, 2020 at 3:01 PM

Hi All,

Regarding the proposal to remove the Leave Group Synchronization field from the 
Multicast Leave Synch Route, the current proposal is inadequate. Below I 
discuss why, and provide an alternate suggestion. For those who don’t want to 
read my wall of text, my key motivation is simple:

- The current proposal is a ticking time bomb because it leaves in the field a 
situation where two incompatible implementations can exist undetectably.

And my proposal boils down to two things:

- For the new format NLRI that omits the field, allocate a new code point. 
Deprecate [*] code point 8 going forward.
- Optionally provide a somewhat more sophisticated interworking option for 
backward compatibility.

Nitty-gritty below including considerations for how to transition from code 
point 8 to the TBD code point.

As far as I can tell, there is consensus that the field is not useful. That’s a 
good start. The customary way of dealing with this would be to mark the field 
“reserved”, but evidently there are multiple divergent implementations in the 
field that use different formats for the Multicast Leave Synch Route, some that 
include the field and some that don’t. (I should disclose here that my 
employer’s implementation is in the “include” camp.)

There is an obvious interoperability problem here: BGP implementations are 
required to sanity-check the NLRI they receive (see RFC 4271 section 6.3, RFC 
4760 section 7, and RFC 7606 section 5.3). This checking is required whether or 
not there’s a route target present to cause the router to consume the NLRI, the 
standards require the NLRI to be checked regardless. The consequence of 
malformed NLRI is a session reset. This turns out to be a difficult problem in 
BGP, even though we’ve worked to reduce the number of error cases that require 
a session reset, malformed NLRI are one of the very bad cases we can’t paper 
over. The IDR WG worked on this very hard during the development of RFC 7606, 
it is a real problem. When an implementation expects one NLRI format and 
receives another, that’s a malformed NLRI, and can be expected to cause a 
session reset. To leave this situation in place would be BGP protocol 
malpractice.

As far as I can tell, this means it is only through dumb luck that we have had 
two different NLRI formats in the wild without a network meltdown. This seems 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-irb-mcast-04

[Ali Sajassi (sajassi)]

Support and not aware of any undisclosed IPR

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

Date: Wednesday, February 26, 2020 at 6:28 AM
To: 'BESS' 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-irb-mcast-04

Hi WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-irb-mcast-04 [2]

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

This poll runs until 11th March 2020.


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

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

There is currently one IPR disclosed.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-irb-mcast



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

 Thank you,

Stephane

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

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

Re: [bess] Chair review of draft-ietf-bess-evpn-virtual-eth-segment-05

[Ali Sajassi (sajassi)]

Hi Stephane,

Thanks for reviewing the new rev of the document and providing us with your 
comments. We’ll try to take care of your comments within next few days.

Regards,
Ali

From: "slitkows.i...@gmail.com" 
Date: Tuesday, March 3, 2020 at 1:29 AM
To: "draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org" 
, "Luc Andre Burdet 
(lburdet)" 
Cc: 'BESS' 
Subject: Chair review of draft-ietf-bess-evpn-virtual-eth-segment-05
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Tuesday, March 3, 2020 at 1:28 AM

Hi Authors,

Please find  below my chair review:

Nits:


  == Missing Reference: 'ETH-OAM' is mentioned on line 606, but not defined



  == Missing Reference: 'MPLS-OAM' is mentioned on line 612, but not defined



  == Missing Reference: 'PW-OAM' is mentioned on line 612, but not defined



  == Missing Reference: 'EVPN-IRB' is mentioned on line 746, but not defined


Introduction:
There should be an issue with XML source as the reference to RFC7432 is not a 
link.

Section 1.1:
The figure legend is not understandable as there are two many acronyms.

“Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI”



Or It may be good to put terminology section before.


Section 1.2:

Similar comment for Figure 2
In addition, I’m wondering if there are some issues with the figure itself 
regarding the attachment of EVCs.
Finally  section talks about Access MPLS Networks, but figure talks about 
Aggregation Network. Of course this is applicable to both cases, but 
legend/title/figure are not matching.



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



Which MPLS network are you talking about ? Aggregation or IP/MPLS ? This is 
ambiguous.





Section 3.1:

Can’t we merge R1a,b, c and d as a single requirement ?





Section 3.2:

I’m a bit concerned about the scaling requirements. Scaling is always a matter 
of platform resources and computing power. That’s fine to have these numbers in 
mind when building the protocol, however we can’t be sure that all platforms 
will be able to handle this numbers.





Section 3.4:

The requirements are not expressed correctly IMO. When reading R4a and b, this 
definition/requirement comes indirectly from RFC7432. Shouldn’t we use 
something more tied to vES requirement like: a vES SHOULD support EVCs based on 
a VLAN based/bundle service





Section 3.5

s/defult procedure/default procedure/
Needs also to comply to RFC8584 ?





Section 3.7

Need to create a new paragraph for R7b,c,d.



MHD and MHN are not expanded in terminology section.





Section 3.8:

Need a paragraph separation to introduce R8a.



Section 4.1:
Needs also to comply to RFC8584 ?



Brgds

Stephane

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

Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[Ali Sajassi (sajassi)]

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

Cheers,
Ali

From: "Bocci, Matthew (Nokia - GB)" 
Date: Tuesday, January 21, 2020 at 6:48 AM
To: "bess@ietf.org" 
Cc: "draft-brissette-bess-evpn-mh...@ietf.org" 
, "bess-cha...@ietf.org" 

Subject: WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04
Resent-From: 
Resent-To: , Cisco Employee , 
, , 

Resent-Date: Tuesday, January 21, 2020 at 6:48 AM

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-mh-pa-04 [1] .

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

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

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

Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on Tuesday 4th February 2020.

Regards,
Matthew and Stephane

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





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

Re: [bess] [Technical Errata Reported] RFC8584 (5900)

[Ali Sajassi (sajassi)]

Yes, This errata should be rejected because VLAN-bundle service requires ONLY a 
single BD - that is analogous to SVL mode in 802.1Q. It is VLAN-aware bundle 
service that requires multiple BDs!

Cheers,
Ali

On 11/12/19, 7:37 AM, "John E Drake"  wrote:

This should be rejected as well.

Sent from my iPhone

> On Nov 12, 2019, at 5:32 PM, RFC Errata System 
 wrote:
> 
> The following errata report has been submitted for RFC8584,
> "Framework for Ethernet VPN Designated Forwarder Election Extensibility".
> 
> --
> You may review the report below and at:
> 
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5900__;!8WoA6RjC81c!TpKkmNpLw0IxSEE-fJ1n-SvT2U3XV1WV-yf10zT1tAutFg-Xf1AC-VLo5hXdcR4$
 
> 
> --
> Type: Technical
> Reported by: Frank Lu 
> 
> Section: 1.1
> 
> Original Text
> -
> BD: Broadcast Domain.  An EVI may be comprised of one BD
>  (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware
>  Bundle services).
> 
> Corrected Text
> --
> BD: Broadcast Domain.  An EVI may be comprised of one BD
>  (VLAN-based) or multiple BDs (VLAN Bundle services 
> or VLAN-aware Bundle services).
> 
> Notes
> -
> By definition, tgere
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8584 (draft-ietf-bess-evpn-df-election-framework-09)
> --
> Title   : Framework for Ethernet VPN Designated Forwarder 
Election Extensibility
> Publication Date: April 2019
> Author(s)   : J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. 
Drake, K. Nagaraj, S. Sathappan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled Services
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG


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