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

From: Stefan Plug <[email-masked]>
Date: Wed, 02 Jul 2014 13:55:12 +0200

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" <[email-masked]> 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
>

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 2 Jul 2014 12:31:57 +0000

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.

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

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.

Thanks.
Jorge

---

From: Stefan Plug <[email-masked]>
Date: Mon, 07 Jul 2014 17:08:22 +0200

Hi Jorge,

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

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

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

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 9 Jul 2014 14:43:31 +0000

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 <[email-masked]>
Date: Monday, July 7, 2014 at 8:08 AM
To: Jorge Rabadan <[email-masked]>, Stefan Plug
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-l2vpn-evpn-07 L2 encapsulation?

---

From: Stefan Plug <[email-masked]>
Date: Wed, 09 Jul 2014 16:54:58 +0200

Hi Jorge,

Thank you very much.

Stefan