WG, thanks for the thread on this topic. Most of the discussion has focused on "other ways to solve the problem" and I'm pleased to hear that that discussion has decided to get out of the way of this document and to focus on revisions or new drafts.
Wrt this specific document, the only discussion of this text change that I heard was resolved in favor of the current text. I'll tell the RFC Editor to go ahead. Thanks, Adrian > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Adrian Farrel > Sent: 01 February 2015 20:02 > To: [email protected] > Subject: [bess] Auth48 changes to EVPN draft > > Hi BESS WG, > > During the final stages of processing draft-ietf-l2vpn-evpn the authors > requested some changes to section 6.3 "VLAN-Aware Bundle Service Interface" > > Because these changes are a little more than editorial in nature, I want to run > them passed the working group. > > Please comment on this list before February 8th if you find these changes > unacceptable. In that case, please state your reasoning and preferably supply an > alternative. > > OLD > With this service interface, an EVPN instance consists of several > broadcast domains (e.g., several VLANs) with each VLAN having its > own bridge domain -- i.e., multiple bridge domains (one per VLAN) are > maintained by a single MAC-VRF corresponding to the EVPN instance. > > 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 MPLS-encapsulated > frames, and an Ethernet Tag ID translation function MUST be supported > in the data path. This translation MUST be performed in the data > path on both the imposition and disposition PEs (translating to a > normalized Ethernet Tag ID on the imposition PE and translating to a > local Ethernet Tag ID on the disposition PE). The Ethernet Tag ID in all > EVPN > routes MUST be set to the normalized value assigned by the > EVPN provider. > NEW > With this service interface, an EVPN instance consists of multiple > broadcast domains (e.g., multiple VLANs) with each VLAN having its > own bridge table -- i.e., multiple bridge tables (one per VLAN) are > maintained by a single MAC-VRF corresponding to the EVPN instance. > > Broadcast, unknown unicast, or multicast (BUM) traffic is sent only > to the CEs in a given broadcast domain; however, the broadcast > domains within an EVI either MAY each have their own P-Tunnel or MAY > share P-Tunnels -- e.g., all of the broadcast domains in an EVI MAY > share a single P-Tunnel. > > 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 Label1 in the > MAC/IP Advertisement route 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, it 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 normalized Ethernet Tag ID assigned by the > EVPN provider. > END > > Thanks, > Adrian > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
