Re: [bess] EVPN FECs in LSP Ping

[Alexander Vainshtein <[e-mail]>]

Parag hi,
Lots of thanks for your message and apologies for my delayed response.

I have looked up the draft and it seems to address my concerns.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

-----Original Message-----
From: Parag Jain (paragj) [mailto:[e-mail]] 
Sent: Monday, September 17, 2018 2:09 AM
To: Donald Eastlake <[e-mail]>; Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; Michael Gorokhovsky <[e-mail]>; Ron Sdayoor <[e-mail]>; [e-mail]; Rotem Cohen <[e-mail]>
Subject: Re: [bess] EVPN FECs in LSP Ping

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" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Sasha,
    
    Thanks for your questions. See below.
    
    On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein
    <[e-mail]> 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   [phone] (cell)
     1424 Pro Shop Court, Davenport, FL 33896 USA
     [e-mail]
    
    
    > Regards,
    > Sasha
    >
    > Office: [phone]
    > Cell:   [phone]
    > Email:  [e-mail]
    
    _______________________________________________
    BESS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/bess
    


___________________________________________________________________________

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