Hi,

Some questions on the draft:

- Section 4 mentions that LSP-Ping is needed to exchange discriminators
because the MPLS label stack doesn¹t contain enough information to
disambiguate the sender of the session. Isn¹t the IP hdr enough?

- Section 7.1.1 mentions SH label, I believe this is the ESI label as per
section 8.3 of RFC7432?

- There are alternative encapsulation formats with sub-TLVs for unicast
and multicast. Is it an alternative to the label stack or on top of the
label stack? Even if obvious, I think the advantage of those alternative
formats should be stated.

Regards,
Reshad.




On 2016-07-19, 4:24 AM, "Rtg-bfd on behalf of Vengada Prasad Govindan
(venggovi)" <[email protected] on behalf of [email protected]>
wrote:

>Hello all,
>  draft-gmsm-bess-evpn-bfd-00.txt was presented by Greg Mirsky at IETF 96
>MPLS WG and is scheduled for presentation at BESS and BFD WG meetings.
>Authors request comments/ suggestions on this draft.
>Thanks
>Prasad
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: Wednesday, July 06, 2016 6:11 PM
>To: MALLIK MUDIGONDA (mmudigon) <[email protected]>; MALLIK MUDIGONDA
>(mmudigon) <[email protected]>; Greg Mirsky
><[email protected]>; Vengada Prasad Govindan (venggovi)
><[email protected]>; Gregory Mirsky <[email protected]>; Ali
>Sajassi (sajassi) <[email protected]>
>Subject: New Version Notification for draft-gmsm-bess-evpn-bfd-00.txt
>
>
>A new version of I-D, draft-gmsm-bess-evpn-bfd-00.txt has been
>successfully submitted by Vengada Prasad Govindan and posted to the IETF
>repository.
>
>Name:          draft-gmsm-bess-evpn-bfd
>Revision:      00
>Title:         Fault Management for EVPN networks
>Document date: 2016-07-06
>Group:         Individual Submission
>Pages:         10
>URL:            
>https://www.ietf.org/internet-drafts/draft-gmsm-bess-evpn-bfd-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/
>Htmlized:       https://tools.ietf.org/html/draft-gmsm-bess-evpn-bfd-00
>
>
>Abstract:
>   This document proposes a proactive, in-band network OAM mechanism to
>   detect loss of continuity and miss-connection faults that affect
>   unicast and multi-destination paths, used by Broadcast, unknown
>   Unicast and Multicast traffic, in an EVPN network.  The mechanisms
>   proposed in the draft use the principles of the widely adopted
>   Bidirectional Forwarding Detection protocol.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>

_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to