Subject: [bess] EVPN FECs in LSP Ping

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 6 Sep 2018 13:58:16 +0000

Dear authors of the EVPN OAM requirements and Framework<https://tools.ietf.org/html/draft-salam-bess-evpn-oam-req-frmwk-00> draft,
I have looked up the draft, and it looks to me as a good starting point for work on EVPN OAM.
I would like to clarify two points with regard to the draft:

1.       In order to pass unicast EAOM frames (LBM/LBR and LTR), the local MAC-VRF must learn the MAC address of the customer MEP and advertise it to remote PEs as a MAC/IP Advertisement route. Should this be considered as a special case of learning from the control plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC 7432)?

2.       Tre draft seems to propose extension of LSP Ping to test/verify connectivity to the FECs advertised as NRLI of EVPN routes. I have checked the IANA Registry, and no values for these FECs have been allocated yet.  Do you plan any specific work on this?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 16 Sep 2018 18:43:15 -0400

Hi Sasha,

Thanks for your questions. See below.

On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein
<[email-masked]> wrote:
>
> Dear authors of the EVPN OAM requirements and Framework draft,
>

Thanks.

> 1.  In order to pass unicast EAOM frames (LBM/LBR and LTR), the
> local MAC-VRF must learn the MAC address of the customer MEP and
> advertise it to remote PEs as a MAC/IP Advertisement route. Should
> this be considered as a special case of learning from the control
> plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC
> 7432)?

Yes, the MAC address of the customer MEP needs to be learned but
Section 9.1 of RFC 7432 includes the following text, which seems
adequate to me:

   The PEs in a particular EVPN instance MUST support local data-plane
   learning using standard IEEE Ethernet learning procedures.

> 2. The draft seems to propose extension of LSP Ping to test/verify
> connectivity to the FECs advertised as NRLI of EVPN routes. I have
> checked the IANA Registry, and no values for these FECs have been
> allocated yet.  Do you plan any specific work on this?

LSP Ping is one mechanism indirectly referenced in Section 2.4 of the
draft via the reference to RFC 6425 but there are others.

Since OAM messages need to follow the same path as data, as far as
practical, it seem to me there should not be any FECs allocated for
OAM beyond those already needed for data. Probably wording in the
draft related to FECs should be checked/adjusted.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: "Parag Jain (paragj)" <[email-masked]>
Date: Sun, 16 Sep 2018 23:09:08 +0000

Hi Sasha

There is an accompanying LSP ping draft for evpn:

https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

Thanks
Parag

On 2018-09-16, 6:43 PM, "BESS on behalf of Donald Eastlake" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Sasha,

    
    Thanks.

    

    
    
    Thanks,
    Donald

    > Email:  [email-masked]
    
    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 21 Sep 2018 17:02:48 +0000

Donald,
Lots of thanks for your response.

I would like to clarify my question regarding learning of the MAC address ofcthe cudtomer MEP.

I fully agree that this address will be locally learned by the PE to whic the relevant customer site is attached.

But will this address advertised to remote PEs?

My reading of 7432 is that in most cases PEs advertise MAC addresses that have been locally learned from some CP protocol; 7432 specifically mentiones ARP/NDP and DHCP/DHCPv6.

I think that in order to learn and adverise MAC addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM frames (trap is required for LTM frames if MIP us intanciated in the PE).

Does this make sense to you?

Regards

Thumb typed by Sasha Vainshtein

From: Donald Eastlake
Sent: Monday, September 17, 01:43
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: [email-masked], [email-masked], Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen

Hi Sasha, Thanks for your questions. See below. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I have looked up the draft, and it looks to me as a good starting > point for work on EVPN OAM. Thanks. > I would like to clarify two points with regard to the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > local MAC-VRF must learn the MAC address of the customer MEP and > advertise it to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a special case of learning from the control > plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the following text, which seems adequate to me: The PEs in a particular EVPN instance MUST support local data-plane learning using standard IEEE Ethernet learning procedures. > 2. The draft seems to propose extension of LSP Ping to test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I have > checked the IANA Registry, and no values for these FECs have been > allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism indirectly referenced in Section 2.4 of the draft via the reference to RFC 6425 but there are others. Since OAM messages need to follow the same path as data, as far as practical, it seem to me there should not be any FECs allocated for OAM beyond those already needed for data. Probably wording in the draft related to FECs should be checked/adjusted. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA [email-masked] > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 23 Sep 2018 15:34:06 -0400

Hi Sasha,

On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein
<[email-masked]> wrote:
> I would like to clarify my question regarding learning of the MAC address of the customer MEP.
>
> My reading of 7432 is that in most cases PEs advertise MAC addresses that have been locally learned from some CP protocol; 7432 specifically mentions ARP/NDP and DHCP/DHCPv6.
>
> I think that in order to learn and advertise MAC addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM frames (trap is required for LTM frames if MIP us intanciated in the PE).
>

I would agree that a PE has to advertise the MAC addresses it learns
from the local reception Ethernet Service OAM frames if it wants to
support that service and it would be reasonable to mention this in the
EVPN OAM framework document. RFC 7432 was not considering OAM.

Thanks,
Donald

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 24 Sep 2018 06:13:06 +0000

Donald,
Lots of thanks again for a primpt response.
Explicitly stafing that an EVPN PE supporting customer level Ethernet service OAM MUST adverise locally learned MAC addresses of the customer's MEPS would address my concerns.

Regards

From: Donald Eastlake
Sent: Sunday, September 23, 22:34
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: [email-masked], [email-masked], Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen

Hi Sasha, On Fri, Sep 21, 2018 at 1:02 PM Alexander Vainshtein wrote: > > Donald, > Lots of thanks for your response. > > I would like to clarify my question regarding learning of the MAC address of the customer MEP. > > I fully agree that this address will be locally learned by the PE to whic the relevant customer site is attached. > > But will this address advertised to remote PEs? > > My reading of 7432 is that in most cases PEs advertise MAC addresses that have been locally learned from some CP protocol; 7432 specifically mentions ARP/NDP and DHCP/DHCPv6. > > I think that in order to learn and advertise MAC addresses of customer MEPs, the PE should trap or snoop Ethernet Service OAM frames (trap is required for LTM frames if MIP us intanciated in the PE). > > Does this make sense to you? I would agree that a PE has to advertise the MAC addresses it learns from the local reception Ethernet Service OAM frames if it wants to support that service and it would be reasonable to mention this in the EVPN OAM framework document. RFC 7432 was not considering OAM. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA [email-masked] > Regards > > Thumb typed by Sasha Vainshtein > > From: Donald Eastlake > Sent: Monday, September 17, 01:43 > Subject: Re: EVPN FECs in LSP Ping > To: Alexander Vainshtein > Cc: [email-masked], [email-masked], Michael Gorokhovsky, Ron Sdayoor, Rotem Cohen > > Hi Sasha, Thanks for your questions. See below. On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein wrote: > > Dear authors of the EVPN OAM requirements and Framework draft, > > I have looked up the draft, and it looks to me as a good starting > point for work on EVPN OAM. Thanks. > I would like to clarify two points with regard to the draft: > > 1. In order to pass unicast EAOM frames (LBM/LBR and LTR), the > local MAC-VRF must learn the MAC address of the customer MEP and > advertise it to remote PEs as a MAC/IP Advertisement route. Should > this be considered as a special case of learning from the control > plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC > 7432)? Yes, the MAC address of the customer MEP needs to be learned but Section 9.1 of RFC 7432 includes the following text, which seems adequate to me: The PEs in a particular EVPN instance MUST support local data-plane learning using standard IEEE Ethernet learning procedures. > 2. The draft seems to propose extension of LSP Ping to test/verify > connectivity to the FECs advertised as NRLI of EVPN routes. I have > checked the IANA Registry, and no values for these FECs have been > allocated yet. Do you plan any specific work on this? LSP Ping is one mechanism indirectly referenced in Section 2.4 of the draft via the reference to RFC 6425 but there are others. Since OAM messages need to follow the same path as data, as far as practical, it seem to me there should not be any FECs allocated for OAM beyond those already needed for data. Probably wording in the draft related to FECs should be checked/adjusted. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA [email-masked] > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email-masked]