Jorge,
Lots of thanks for a prompt response.
As Donald has mentioned, 7432 simply left Ethernet service OAM out of scope, so
there are quite a few things tbat require specification in this area..
Regards
Thumb typed by Sasha Vainshtein
________________________________
From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>
Sent: Monday, September 24, 2018 12:37:13 PM
To: Alexander Vainshtein; Donald Eastlake
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org; Michael Gorokhovsky; Ron
Sdayoor; bess@ietf.org; Rotem Cohen
Subject: Re: [bess] EVPN FECs in LSP Ping
Sasha,
That is an excellent point. I agree the text should say that any MEP/MIP MAC
addresses local to the PE should be advertised in EVPN.
I would even add that, since those MACs are not subject to mobility, the PE
should advertise them as “static”, i.e., with sticky bit set.
Thanks.
Jorge
From: BESS <bess-boun...@ietf.org> on behalf of Alexander Vainshtein
<alexander.vainsht...@ecitele.com>
Date: Monday, September 24, 2018 at 8:13 AM
To: Donald Eastlake <d3e...@gmail.com>
Cc: "draft-salam-bess-evpn-oam-req-fr...@ietf.org"
<draft-salam-bess-evpn-oam-req-fr...@ietf.org>, Michael Gorokhovsky
<michael.gorokhov...@ecitele.com>, Ron Sdayoor <ron.sday...@ecitele.com>,
"bess@ietf.org" <bess@ietf.org>, Rotem Cohen <rotem.co...@ecitele.com>
Subject: Re: [bess] EVPN FECs in LSP Ping
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
Thumb typed by Sasha Vainshtein
From: Donald Eastlake
Sent: Sunday, September 23, 22:34
Subject: Re: EVPN FECs in LSP Ping
To: Alexander Vainshtein
Cc: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org, 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 d3e...@gmail.com > 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: draft-salam-bess-evpn-oam-req-fr...@ietf.org, bess@ietf.org,
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 d3e...@gmail.com > Regards, >
Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email:
alexander.vainsht...@ecitele.com
___________________________________________________________________________
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.
___________________________________________________________________________
___________________________________________________________________________
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
