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

From: Gregory Mirsky <[email-masked]>
Date: Tue, 1 Jul 2014 18:19:01 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: Mach Chen <[email-masked]>
Date: Wed, 2 Jul 2014 01:57:17 +0000

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

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> Sent: Wednesday, July 02, 2014 2:19 AM
> To: [email-masked]; [email-masked]
> 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.
> 
> 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/
> 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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 17:15:23 +0000

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:[email-masked]] 
Sent: Tuesday, July 01, 2014 6:57 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

Hi Greg,

Best regards,
Mach

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 3 Jul 2014 00:15:08 +0000

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

> Sent: Wednesday, July 02, 2014 1:15 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> 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
>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 3 Jul 2014 05:50:15 +0000

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:[email-masked]] 
Sent: Wednesday, July 02, 2014 5:15 PM
To: Gregory Mirsky; Mach Chen; [email-masked]
Cc: [email-masked]
Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

Hi Greg, et al,

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.

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.

GIM>> Thank you!

Thanks!

-Nobo

> Subject: RE: New Version Notification for 
> draft-mirsky-mpls-bfd-directed- 00.txt
> 
> Hi Mach,
> Subject: RE: New Version Notification for 
> draft-mirsky-mpls-bfd-directed- 00.txt
> 
> Hi Greg,
> 
> 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
> 
> > 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.
> >

---

From: Mach Chen <[email-masked]>
Date: Thu, 3 Jul 2014 10:17:25 +0000

Hi Greg,

Please see my comments inline...

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Thursday, July 03, 2014 1:50 PM
> To: Nobo Akiya (nobo); Mach Chen; [email-masked]
> Cc: [email-masked]
> many thanks for your review and thoughtful comments. Please find my answers
> and notes in-lined and tagged with GIM>>.
> 
> 	Regards,
> 		Greg
> 
> 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.
> > > Htmlized:
> http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed-00
> > >
> > >
> > > Abstract:

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 3 Jul 2014 13:09:10 +0000

Hi Greg, Mach,

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

I see where you are coming from Mach, but let counter-argue for the sake of discussion :)

Target FEC Stack TLV (TFS) is a TLV that is always present in an MPLS echo request message.

[Section 3.2 of RFC4379]
   An MPLS echo request MUST have a Target FEC Stack that describes the
   FEC Stack being tested.

So most other TLVs in the MPLS echo request assumes that TFS is present and has instructions to do foo for the FEC described in the TFS, which is perfectly fine IMO. So I think it is still arguable that if we were to have BFD-foo-1, BFD-foo-2 and BFD-foo-3 instructions, then perhaps it is more beneficial to bundle them into a single BFD-foo-TLV, and make each into sub-TLVs ... instead of having separate TLVs for 1/2/3.

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

That's a good point. If Greg's Reverse Path TLV also needs to describe FECs other than Segments, then we probably want to make sure that type does not collide with FEC types in the TFS.

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

[Classical BFD]
Well, yes classical BFD sessions are configured on the ingress, but not explicitly configured on the egress, hence the need for bootstrapping. Likely, egress will have configuration like "allow BFD boostrap request from these nodes" but not "allow BFD bootstrap request for these FECs from these nodes", because the latter will be very difficult to maintain not to mention it goes against the stateless nature of Segment Routing at the configuration level. Possibly:
a. BFD TLV can instruct egress to delete the session.
b. BFD TLV has "purge timer" field where egress is expected to delete the session after "purge timer" once the session goes down.
c. Just describe procedures for egress that it can delete the session after sometime once the session goes down.

[S-BFD]
Agree, I don't see how we can address this without egress becoming a little stateful. At the least, an SBFDReflector needs to keep [remote IP address, remote BFD discriminator] = return path. And ingress needs to be able to maintain this.

Thanks!

-Nobo

---

From: Mach Chen <[email-masked]>
Date: Fri, 4 Jul 2014 05:14:56 +0000

Hi Nobo and Greg,

> -----邮件原件-----
> 发件人: Nobo Akiya (nobo) [mailto:[email-masked]]
> 发送时间: 2014年7月3日 21:09
> 收件人: Mach Chen; Gregory Mirsky; [email-masked]
> 抄送: [email-masked]
> 主题: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt
> 
> Hi Greg, Mach,
> 
> > > GIM>> Though it is unlikely that both BFD Discriminator TLV and RP
> > > GIM>> 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.
> 
> So most other TLVs in the MPLS echo request assumes that TFS is present and
> has instructions to do foo for the FEC described in the TFS, which is perfectly
> fine IMO. So I think it is still arguable that if we were to have BFD-foo-1,
> BFD-foo-2 and BFD-foo-3 instructions, then perhaps it is more beneficial to
> bundle them into a single BFD-foo-TLV, and make each into sub-TLVs ... instead
> of having separate TLVs for 1/2/3.

Yes, I agree the principle. Let' continue discussing :-)

> > 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.
> 
> That's a good point. If Greg's Reverse Path TLV also needs to describe FECs
> other than Segments, then we probably want to make sure that type does not
> collide with FEC types in the TFS.

Exactly.

Best regards,
Mach
> > > 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.
> > > 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.
> 
> [Classical BFD]
> Well, yes classical BFD sessions are configured on the ingress, but not explicitly
> configured on the egress, hence the need for bootstrapping. Likely, egress will
> have configuration like "allow BFD boostrap request from these nodes" but not
> "allow BFD bootstrap request for these FECs from these nodes", because the
> latter will be very difficult to maintain not to mention it goes against the
> stateless nature of Segment Routing at the configuration level. Possibly:
> b. BFD TLV has "purge timer" field where egress is expected to delete the
> session after "purge timer" once the session goes down.
> Agree, I don't see how we can address this without egress becoming a little
> stateful. At the least, an SBFDReflector needs to keep [remote IP address,
> remote BFD discriminator] = return path. And ingress needs to be able to
> maintain this.
> 
> Thanks!
> 
> -Nobo

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 4 Jul 2014 13:28:34 +0000

Hello all, 
 Please find the submission Nobo refers to below at:

URL:            http://www.ietf.org/internet-drafts/draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vgovindan-mpls-extended-bfd-disc-tlv/
Htmlized:       http://tools.ietf.org/html/draft-vgovindan-mpls-extended-bfd-disc-tlv-00

Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Thursday, July 03, 2014 11:20 AM
To: Nobo Akiya (nobo); Mach Chen; [email-masked]
Cc: [email-masked]
Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt

Hi Nobo,

	Regards,
		Greg

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

Hi Greg, et al,

Thanks!

-Nobo