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

[Stefan Plug <[e-mail]>]

Hi Jorge,

Thank you very much.

Stefan

On 09-07-14 16:43, Rabadan, Jorge (Jorge) wrote:
> 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
>>>>>
>>>>
>>>
>