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

[Stefan Plug <[e-mail]>]

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
>>>
>>
>