Re: draft-ietf-l2vpn-evpn-07 L2 encapsulation?

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Hi Stefan,

We will make sure draft-rp-l2vpn-evpn-usage has the right wording (frame
vs packet) in the next revision.
Thank you for the feedback.

Jorge

-----Original Message-----
From: Stefan Plug <[e-mail]>
Date: Monday, July 7, 2014 at 8:08 AM
To: Jorge Rabadan <[e-mail]>om>, Stefan Plug
<[e-mail]>nl>, "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-l2vpn-evpn-07 L2 encapsulation?

>Hi Jorge,
>
>On 02-07-14 14:31, Rabadan, Jorge (Jorge) wrote:
>> Stefan,
>> 
>> The evpn draft is full of references to “Ethernet frames transported
>>over
>> IP/MPLS”, which in my opinion, along with the description in section 6
>>and
>> other sections should be enough to clarify the stack.
>> 
>This quote is indeed clear, however the draft is also full of references
>like "The advertising PE uses this label when it
>receives an MPLS-encapsulated packet to perform forwarding based on
>the destination MAC address toward the CE". The word packet indicates L3.
>
>I think that we should be careful when using either packet or frame
>terminology to avoid confusion.
>
>One more point I find unclear, is the entire frame including FCS
>encapsulated or is the original FCS stripped and recalculated at the
>egress PE, as is done in Pseudo Wires?
>rfc 4888 p6: "The ingress Native Service Processing (NSP) function
>strips the preamble and frame check sequence (FCS) from the Ethernet
>frame and transports the frame in its entirety across the PW [..] The
>egress NSP function receives the Ethernet frame from the PW and
>regenerates the preamble or FCS before forwarding the frame"
>
>
>> Having said that, in the WG, we agreed to publish a evpn use-case draft
>> that could help clarify the main control plane and data plane concepts
>>in
>> evpn:
>> http://tools.ietf.org/html/draft-rp-l2vpn-evpn-usage-02
>> 
>This draft contains many usages of the word packet, indicating L3, where
>the word frame in my opinion should be used. for example on page 13,
>point e:
>
>"e) The MPLS-encapsulated packet gets to PE2 and PE3. Since PE2 is
>non-DF for EVI1 on ESI12, and there is no other CE connected to
>PE2, the packet is discarded. At PE3, the packet is
>de-encapsulated, CE-VID translated if needed and replicated to
>CE3."
>
>The only indicator that I could find that indeed the entire frame is
>encapsulated is on page 26:
>"PE1 will push the MPLS Label(s) onto the original Ethernet frame and
>send the packet to the MPLS network"
>
>Again, I think that we should be careful when using either packet or
>frame terminology to avoid confusion.
>
>> 
>> What I would suggest is to use that draft as a way to clarify all those
>> things so that the evpn researcher/implementer can use it as a
>>reference.
>> If you agree, please go through it and suggest any additions. We would
>>be
>> happy to discuss and address them if possible.
>Thank you for your openness, I realize that my comments may seem to be
>nitpicking, but I think this point should be made clear and it should
>not be assumed that L2 encapsulation is clear from the beginning.
>especially when EVPN is to be implemented as a replacement to VPLS
>rfc4761, rfc4762 which both state in their introduction the use of
>Pseudo Wires.
>
>> 
>> Thanks.
>> Jorge
>> 
>> -----Original Message-----
>> From: Stefan Plug <[e-mail]>
>> Date: Wednesday, July 2, 2014 at 4:55 AM
>> To: "[e-mail]" <[e-mail]>
>> Subject: draft-ietf-l2vpn-evpn-07 L2 encapsulation?
>> 
>>> Hi all,
>>>
>>> In regards to draft-ietf-l2vpn-evpn-07:
>>>
>>> One thing is not clear to me from the draft, does the L2 frame get
>>> encapsulated by an MPLS tag as with Pseudo Wires, or does the L3 packet
>>> get encapsulated as with normal MPLS?
>>>
>>> I have got an answer that indeed the L2 frame in encapsulated, however
>>>I
>>> can find no reference to an RFC or details itself in this document
>>>where
>>> this is mentioned, to me therefore normal MPLS (RFC3031) applies and
>>> only the L3 packet is encapsulated.
>>>
>>> As this draft to my understanding proposes a replacement to VPLS I
>>>think
>>> it is necessary to mention or at least reference an RFC on how the
>>> entire L2 frame is to be encapsulated to avoid confusion.
>>>
>>> I would suggest a small part mentioning or referencing probably Pseudo
>>> Wires.
>>>
>>> Regards,
>>>
>>> Stefan Plug, Lutz Engels
>>> MSc Students
>>> System and Network Engineering (www.os3.nl)
>>> University of Amsterdam
>>>
>>> On 02-07-14 08:17, Henderickx, Wim (Wim) wrote:
>>>> The packet is encapsulated like a PW using the ETH frame in the MPLS
>>>>PW.
>>>>
>>>> On 02/07/14 02:08, "Stefan Plug" <[e-mail]> wrote:
>>>>
>>>> Dear evpn gurus
>>>>
>>>> I'm a Networking student at the University of Amsterdam researching
>>>> EVPN as a possible solution to the ARP flooding problem in IXPs.
>>>>
>>>> One thing is not clear to me from the draft, does the L2 frame get
>>>> encapsulated by an MPLS tag as with Pseudo Wires, or does the L3
>>>> packet get encapsulated as with normal MPLS?
>>>>
>>>> I cannot seem find any information on this in the draft?
>>>>
>>>> In the case that normal MPLS rules apply and only the L3 packet is
>>>> encapsulated, what then happens to the source mac address at the end
>>>> of the tunnel?
>>>>
>>>> I hope you can help me understand your protocol, it seems very
>>>> interesting!
>>>>
>>>> Regards,
>>>>
>>>> Stefan Plug
>>>> Student
>>>> System and Network Engineering (www.os3.nl)
>>>> University of Amsterdam
>>>>
>>>
>>