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 protected], [email protected], 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 protected] > Regards, >
Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email:
[email protected]
___________________________________________________________________________
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.
___________________________________________________________________________
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
