Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Greg, et al,

I agree with the topic and usefulness of controlling the BFD return path, especially in Segment Routing.

A question and couple comments.

One way to achieve the same sematic is to introduce "Segment Routing MPLS Tunnel sub-TLV" and "Segment Routing IPv6 Tunnel sub-TLV" under Reply Path (RP) TLV defined in RFC7110. Is there any particular reason why new TLV was introduced? I'm mainly just curious :)

There are couple of things worth highlighting about the BFD Discriminator TLV (defined in RFC5884), not directly in the scope of your document but very relevant when looking at using your proposal in Segment Routing.

1. The BFD Discriminator TLV allows bootstrapping of one BFD session per FEC. When bootstrapping more than one BFD session per FEC, it is difficult to do so without making assumptions, as there is no defined fields/procedures to do so. This will become more of an issue with Segment Routing, when there are multiple explicit paths created between a pair of nodes.

2. Maintenance of bootstrapped BFD sessions is fuzzy, meaning when should the egress delete bootstrapped BFD sessions. One could implement such that the egress deletes BFD sessions when corresponding FEC is deleted, or X amount of time after sessions go "down". There's no FEC/state on the egress for Segment Routing.  Thus only remaining option today is to delete the session after X seconds/minutes once the session is in "down" state. Perhaps this fuzziness is reasonable, or perhaps we want explicit "delete" instruction from the ingress to the egress.

I believe my colleague is about to roll out a document for Extended BFD Discriminator TLV which addresses (1) and (2) above. Primary motivation of that document is EVPN BFD, but it looks very applicable to Segment Routing as well.

Lastly, how do we use this for S-BFD? :)

Let's discuss in Toronto on how we can best define the most useful solution.

Thanks!

-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Gregory
> Mirsky
> Sent: Wednesday, July 02, 2014 1:15 PM
> To: Mach Chen; [e-mail]
> Cc: [e-mail]
> Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-
> 00.txt
> 
> Hi Mach,
> thank you for your feedback.
> Indeed, both drafts have commonalities.
> I'm looking forward to the discussion in Toronto and how we can bring this
> idea further.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: Mach Chen [mailto:[e-mail]]
> Sent: Tuesday, July 01, 2014 6:57 PM
> To: Gregory Mirsky
> Cc: [e-mail]
> Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-
> 00.txt
> 
> Hi Greg,
> 
> I have a quick review on the draft, well written and useful draft!
> 
> Couple years ago, we submitted a draft (http://tools.ietf.org/html/draft-
> chen-mpls-bfd-enhancement-01) that intend to solve the similar issue, glad
> we have the similar thought:-).
> 
> It also defines extensions to LSP Ping to direct the choose of the return path
> of BFD control packets. Please take a look.
> 
> Best regards,
> Mach
> 
> > -----Original Message-----
> > From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Gregory
> > Mirsky
> > Sent: Wednesday, July 02, 2014 2:19 AM
> > To: [e-mail]; [e-mail]
> > Subject: FW: New Version Notification for
> > draft-mirsky-mpls-bfd-directed-00.txt
> >
> > Dear All,
> > we've posted a new draft. LSP Ping already is used to bootstrap a BFD
> > session with BFD Discriminator TLV. A new BFD Reverse Path TLV is
> > introduced in order to instruct a far-end BFD peer to use particular
> > path for reverse direction of the BFD session.
> >
> > Greatly appreciate your questions, comments.
> >
> > 	Regards,
> > 		Greg
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Monday, June 30, 2014 4:15 PM
> > To: Gregory Mirsky; Ilya Varlashkin; Jeff Tantsura; Gregory Mirsky;
> > Jeff Tantsura; Ilya Varlashkin
> > Subject: New Version Notification for
> > draft-mirsky-mpls-bfd-directed-00.txt
> >
> >
> > A new version of I-D, draft-mirsky-mpls-bfd-directed-00.txt
> > has been successfully submitted by Greg Mirsky and posted to the IETF
> > repository.
> >
> > Name:		draft-mirsky-mpls-bfd-directed
> > Revision:	00
> > Title:		Bidirectional Forwarding Detection (BFD) Directed Return
> Path
> > Document date:	2014-06-30
> > Group:		Individual Submission
> > Pages:		8
> > URL:
> > http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd-directed-00.
> > txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/
> > Htmlized:       http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed-00
> >
> >
> > Abstract:
> >    Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
> >    directional paths.  When forward direction of a BFD session is to
> >    monitor explicitly routed path there is\ a need to be able to direct
> >    far-end BFD peer to use specific path as reverse direction of the BFD
> >    session.
> >
> >
> >
> >
> > 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