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

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 3 Mar 2014 04:26:30 +0000

Hi Vincent,

We will clarify this section indicating that this auto-derivation is
applicable for general Ethernet-tag field where RT is of type 0x00 (e.g.,
2-byte AS), OR this auto-derivation is applicable for Ethernet-tag field
of VLAN-ID where RT can be any type.

Cheers,
Ali

On 2/28/14 12:30 AM, "Zhuangshunwan" <[email-masked]> wrote:

>Dear Authors,
>I have a minor question, see inline.
>
>8.4.1.1.1 Auto-Derivation from the Ethernet Tag ID
>
>   The following is the procedure for deriving the RT attribute
>   automatically from the Ethernet Tag ID associated with the
>   advertisement:
>
>        +    The Global Administrator field of the RT MUST
>             be set to the Autonomous System (AS) number that the PE
>             belongs to.
>
>Vincent:  Here Global Administrator field contains a 2 octets long number,
>but the Autonomous System (AS) number could be 4 octets, how to handle
>such
>case?
>
>        +    The Local Administrator field of the RT contains a 4
>             octets long number that encodes the Ethernet Tag-ID. If the
>             Ethernet Tag-ID is a two octet VLAN ID then it MUST be
>             encoded in the lower two octets of the Local Administrator
>             field and the higher two octets MUST be set to zero.
>
>
>Regards,
>Vincent
>
>-----邮件原件-----
>发件人: L2vpn [mailto:[email-masked]] 代表 Ali Sajassi (sajassi)
>发送时间: 2014年2月14日 9:07
>收件人: Jakob Heitz; [email-masked]
>主题: Re: I-D Action: draft-ietf-l2vpn-evpn-05.txt
>
>
>Hi Jakob,
>
>The reason the diff looks large is because some of the sections have been
>reshuffled. Here are the main changes to this rev:
>
>1. Modified section 5 to have a generalized format for ESI w/ additional
>ESI types
>
>2. Clarified the advertisement of Ethernet A-D per ES route when the
>number of associated RTs is more than the limit to be advertised with a
>single route. In such case, instead of a single Ethernet A-D per ES route,
>a set of such routes is advertised
> 
>3. Added a 2nd MPLS label to the MAC route. This label is optional
>
>4. Added text to security section
>
>5. Added text to IANA section
>
>Cheers,
>Ali
>
>
>
>
>
>On 2/13/14 4:30 PM, "Jakob Heitz" <[email-masked]> wrote:
>
>>The diff is large, but much seems to be language rewrites and
>>clarification.
>>Could the authors please submit a list of substantive changes.
>>
>>Thanks,
>>Jakob.
>>
>>-----Original Message-----
>>From: L2vpn [mailto:[email-masked]] On Behalf Of
>>[email-masked]
>>Sent: Thursday, February 13, 2014 4:11 PM
>>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: Duwenhua <[email-masked]>
Date: Thu, 13 Mar 2014 05:56:20 +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

> Sent: Friday, February 14, 2014 8:11 AM
>  This draft is a work item of the Layer 2 Virtual Private Networks Working
> Group of the IETF.
> 
> 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.
>