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

2023-01-05 Thread 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&url2=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

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

2023-01-05 Thread internet-drafts 


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&url2=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

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

2023-01-05 Thread 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 
substan