Subject: FW: I-D Action: draft-ietf-l2vpn-evpn-05.txt

From: Duwenhua <[email-masked]>
Date: Thu, 13 Mar 2014 11:42:51 +0000

Dear Authors,

      Please see my comments inline.

> 6.1 VLAN Based Service Interface
>    translation for frames destined to its attached CEs. In such
>    scenarios, the Ethernet frames transported over MPLS/IP network
>    SHOULD remain tagged with the originating VID and a VID translation
>    MUST be supported in the data path and MUST be performed on the
>    disposition PE. The Ethernet Tag Identifier in all EVPN routes MUST
>    be set to 0.
     [Du Wenhua] Problem: 1)It will be confused for the disposition PE to received different originating VIDs from different remote PEs; 
                       2)Originating has no use to disposition PE(or egress PE); 
     Suggestion:  translating to normalized tag on imposition PE and translating to local tag on disposition PE.
 
> 
> 9.2.1. Constructing the BGP EVPN MAC/IP Address Advertisement
> 
>    The MAC address length field is in bits and it is typically set to
>    48. However this specification enables specifying the MAC address as
>    a prefix; in which case, the MAC address length field is set to the
>    length of the prefix. This provides the ability to aggregate MAC
>    addresses if the deployment environment supports that.  The 
> encoding
      [Du Wenhua] Problem: 1) It is not easy for DC PE to support MAC prefix. MAC lookup is handled by Hash method instead of by TCAM , 
                           especially when MAC table has more than 1M entries in DC.
                         2) MAC prefix has little use when considering about MAC Move in DC.
     Suggestion: Would you please remove MAC prefix? 
                                                           Du Wenhua

> -----Original Message-----
> From: L2vpn [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, February 14, 2014 8:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-l2vpn-evpn-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Layer 2 Virtual Private Networks 
> Working Group of the IETF.
> 
>         Title           : BGP MPLS Based Ethernet VPN
>         Authors         : Ali Sajassi
>                           Rahul Aggarwal
>                           Wim Henderickx
>                           Aldrin Isaac
>                           James Uttaro
> 	Filename        : draft-ietf-l2vpn-evpn-05.txt
> 	Pages           : 49
> 	Date            : 2014-02-13
> 
> Abstract:
>    This document describes procedures for BGP MPLS based Ethernet VPNs
>    (EVPN).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-evpn-05
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 13 Mar 2014 14:28:04 +0000

Hi,

I am not an author but I am interested in clarifying your first comment:

Why do you think it is confusing for the disposition PE to receive
different originating VIDs? I would leave it as it is in the draft due to
the following reasons:

- The VID at the disposition PE is only used in case of VLAN aware service
interfaces, where there are several bridge domains per MAC-VRF and you
need a normalized VID so that it can give you the right context for the
egress MAC lookup. This model uses qualified learning and needs the
normalized VID that you are talking about, and that is the way it is
written in the draft.

- In VLAN based service interfaces the VID is not used at the disposition
PE for anything other than carrying the customer frame dot1p bits. Hence
you don¹t need any specific VID value.

In other words, you are suggesting to impose ingress translation (and
eth-tag signaling), which to me is completely unnecessary for VLAN-based
service interfaces. I would not put it in the draft.

Thanks.
Jorge

-----Original Message-----
From: Duwenhua <[email-masked]>
Date: Thursday, March 13, 2014 at 4:42 AM
To: "[email-masked]'" <[email-masked]'>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: FW: I-D Action: draft-ietf-l2vpn-evpn-05.txt

>     [Du Wenhua] Problem: 1)It will be confused for the disposition PE to
>received different originating VIDs from different remote PEs;
>     Suggestion:  translating to normalized tag on imposition PE and
>translating to local tag on disposition PE.
> 
>> 
>      [Du Wenhua] Problem: 1) It is not easy for DC PE to support MAC
>prefix. MAC lookup is handled by Hash method instead of by TCAM ,

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 13 Mar 2014 18:49:41 +0000

Hi Duwenhua,

>translating to local tag on disposition PE.

For VLAN-based service, at the disposition PE, the MPLS EVI label (and in
turn bridge domain ID) can identify what local VID to be used. So, there
is no need for translating VID to a normalized VID at the ingress and do
another translation at the egress. All is needed, is to re-write the
receiving VID with the local VID value identified by MPLS EVI label (and
bridge domain ID).

>     Suggestion: Would you please remove MAC prefix?

We can do that since AFAIK, there is not much demand for it.

Cheers,
Ali

---

From: Duwenhua <[email-masked]>
Date: Fri, 14 Mar 2014 00:50:12 +0000

Hi, Ali and Jorge
   Thanks for your clarify.
   I agree with your answer on the two questions.

> From: Rabadan, Jorge (Jorge) [mailto:[email-masked]]
> Sent: Thursday, March 13, 2014 10:28 PM
> To: Duwenhua; [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt
> 
> Hi,
> 

> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 2:50 AM
> To: Duwenhua
> Cc: [email-masked]
> Subject: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt
> 
> 
> Hi Duwenhua,
> 
> >     [Du Wenhua] Problem: 1)It will be confused for the disposition PE
> >to received different originating VIDs from different remote PEs;
> For VLAN-based service, at the disposition PE, the MPLS EVI label (and in turn
> bridge domain ID) can identify what local VID to be used. So, there is no
> need for translating VID to a normalized VID at the ingress and do another
> translation at the egress. All is needed, is to re-write the receiving VID with
> the local VID value identified by MPLS EVI label (and bridge domain ID).
> 
> 
> >
> >>
> >                           especially when MAC table has more than
> 1M
> >entries in DC.
> >                                                           Du
> Wenhua