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

[Mach Chen <[e-mail]>]

Hi Greg,

Please see my comments inline...

> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Thursday, July 03, 2014 1:50 PM
> To: Nobo Akiya (nobo); Mach Chen; [e-mail]
> Cc: [e-mail]
> Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt
> 
> 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

I may have different view here, thinking about the current LSP Ping based bootstrapping, the echo request will carry both Target stack FEC TLV and BFD Discriminator TLV, Target stack FEC TLV is used to identify the LSP to which that the BFD session is bound, BFD Discriminator TLV is used to indicate this is a BFD bootstrapping instead of a normal LSP Ping. Analog to this, if we want to specify the return path of BFD session, seems add the RP TLV to identify the return path is natural choice. And for the segment routing, we just need define new sub-TLVs. 

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

Currently, Target Stack FEC TLV and Reply Path TLV share the same sub-TLVs. At the beginning, Reply Path TLV wants its own registry and hope to borrow some sub-TLVs from the Target Stack FEC TLV, but it turned out to be an unsuccessful choice, and it was very painful to determine how to process the registry, there was a long long discussion about when publish RFC7110. 

So, if you introduce the new BFD Control TLV, the same situation will occur again, you have make a decision whether BFD Control TLV has its own registry, which sub-TLVs can be carried in BFD Control TLV, how to process the future defined Reply Path sub-TLVs, etc.  

Best regards,
Mach
> 
> 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