RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

[Gregory Mirsky <[e-mail]>]

Hi Nobo,
many thanks for your review and thoughtful comments. Please find my answers and notes in-lined and tagged with GIM>>.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[e-mail]] 
Sent: Wednesday, July 02, 2014 5:15 PM
To: Gregory Mirsky; Mach Chen; [e-mail]
Cc: [e-mail]
Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

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 :)
GIM>> Though it is unlikely that both BFD Discriminator TLV and RP TLV would be used in the same LSP ping, we didn't want to rule this out and thought that overloading RP with another role, conditional to presence of BFD TLV may bot such a good idea. But what we discussed was introduction of BFD Control TLV to have optional sub-TLV: BFD Discriminator sub-TLV, Return Path sub-TLV, etc. It may be that that was not a bad idea after all.

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.
GIM>> BFD (should we refer to it now as "classical" BFD) must be configured before it be bootstrapped by LSP ping. To clean up any residual state in the data plane operator would need just to remove corresponding  BFD session configuration. S-BFD would be different case. The far-end BFD peer is, in a way, stateless but if was instructed to use specific path via BFD Reverse Path TLV, then that will create a state in the data plane. Cleaning it up may be required to prevent exhaustion of a resource in the data plane. Certainly great topic for discussion in Toronto. 

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.
GIM>> Very interesting indeed. Looking forward to read the proposal.

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

Let's discuss in Toronto on how we can best define the most useful solution.
GIM>> Thank you!

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