Subject: Re: New Version Notification for draft-akiya-bfd-seamless-base-01.txt

From: Tom Sanders <[email-masked]>
Date: Tue, 3 Sep 2013 21:49:05 +0530

Nobo et. al,

Am i correct in saying that the main idea behind the draft is to create
pseudo reflector BFD sessions that respond to the incoming BFD packets
without maintaining any BFD neighbor state machine? As a result its only
the nodes that initiate BFD packets that need to maintain the session
state; the reflector BFD nodes are essentially stateless.

While i can see the advantage to some extent, i am really not sure if we
indeed need such an extension to BFD! Is maintaining BFD session state
really hard when doing BFD in ASICs? Would love to hear what others have to
say here.

Toms

On 21 August 2013 20:51, Nobo Akiya (nobo) <[email-masked]> wrote:

>
> Hello BFD WG Members,
>
> We have published S-BFD Base -01.
>
> URL:
> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-base-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base
> Htmlized:
> http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-base-01
>
> We have reworded several sections to improve the readability aspect.
> There are few technical changes as well. If you have read -01, please
> visit the diff link to see what has changed.
>
> Authors are looking into various aspects of S-BFD next. Carlos and myself
> will be looking into further defining Segment Routing scenarios (S-BFD SR
> draft) and will be seeking some help to on that front. And progress of that
> requires the "base" to be solidified, and we are need your help. Please
> point out anything that is unclear, confusing and/or questionable.
>
> Regards,
> Authors
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, August 21, 2013 10:55 AM
> > To: David Ward (wardd); Manav Bhatia; David Ward (wardd); Carlos
> > Pignataro (cpignata); Nobo Akiya (nobo)
> > Subject: New Version Notification for
> draft-akiya-bfd-seamless-base-01.txt
> >
> >
> > A new version of I-D, draft-akiya-bfd-seamless-base-01.txt
> > has been successfully submitted by Nobo Akiya and posted to the IETF
> > repository.
> >
> > Filename:      draft-akiya-bfd-seamless-base
> > Revision:      01
> > Title:                 Seamless Bidirectional Forwarding Detection (BFD)
> with
> > MPLS Label Verification Extension
> > Creation date:         2013-08-21
> > Group:                 Individual Submission
> > Number of pages: 20
> > URL:
> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-
> > base-01.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base
> > Htmlized:
> http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-base-
> > 01
> >
> > Abstract:
> >    This document defines a simplified mechanism to use Bidirectional
> >    Forwarding Detection (BFD) with large portions of negotiation aspects
> >    eliminated, that allows full and partial reachability verification.
> >    For MPLS based BFD, extensions to the generic mechanism are defined
> >    that allows BFD to perform a level of label verification.
> >
> >
> >
> >
> >
> > 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
>
>

-- 
Toms.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 4 Sep 2013 02:57:08 +0000

Hi Tom,

Thank you for reading and commenting on this document!

> the nodes that initiate BFD packets that need to maintain the session state;
> the reflector BFD nodes are essentially stateless.

Seamless BFD is sort of like being able to do BFD echo over single-hop/multi-hop/IP/MPLS/SR, except you are using BFD control packets & sender can only get response back if transmitted packet "u-turns" at expected network node. So yes, what you stated is absolutely correct.

> really hard when doing BFD in ASICs?

Maintaining less BFD session state is just a side effect in some cases.

Proposal brings forth several benefits.

1. Provides great control to initiator.
  - Reachability validation is virtually immediate as session bringup/bootstrap sequences are no longer required.
  - Initiator can choose to suspect/resume at its own will without affecting peer state. 

2. Session no longer tied to pair of addresses.
  - Imagine multiple unnumbered tunnels (ex: GRE) between a pair of loopbacks, can't do it with RFC5881, very difficult with RFC5883.
  - Allowing BFD redundancy (ex: having multiple sessions per pair of addresses) is a great benefit to products with distributed BFD architecture.

3. Separation of transport (IP dst or label stack) and target (your discriminator).
  - Reachability check does not always have to be end-to-end.

4. Level of MPLS label verification.
  - This is a topic not yet widely discussed (from what I can tell), but BFD being able to perform Adj SID forwarding correctness adds great value to Segment Routing.

Of course, as you stated, egress state maintenance is essentially not required for uni-directional reachability check scenarios (static route, uni-directional tunnel/LSP).

And one of my personal favorite about this proposal is the fact it becomes a building block for further interesting possibilities.

> Would love to hear what others have to say here.

Me too.

- Nobo

> From: Tom Sanders [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 12:19 PM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]; David Ward (wardd); Carlos Pignataro (cpignata)
> Subject: Re: New Version Notification for draft-akiya-bfd-seamless-base-
> 01.txt
> 
> Nobo et. al,
> 
> the nodes that initiate BFD packets that need to maintain the session state;
> the reflector BFD nodes are essentially stateless.
> 
> really hard when doing BFD in ASICs? Would love to hear what others have
> to say here.
> 
> Toms
> 
> URL:             http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-
> base-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base
> Htmlized:        http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-base-
> 01
> 
> There are few technical changes as well. If you have read -01, please visit
> the diff link to see what has changed.
> 
> > Subject: New Version Notification for draft-akiya-bfd-seamless-base-
> 01.txt
> >
> >
> > Title:                 Seamless Bidirectional Forwarding Detection (BFD) with
> > URL:             http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-
> > base-01.txt
> > Status:          http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base
> > Htmlized:        http://tools.ietf.org/html/draft-akiya-bfd-seamless-base-01
> > Diff:            http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-
> base-
> > 01
> >
> > Abstract:

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 6 Sep 2013 16:01:23 +0000

Dear Nobo, Authors, et. al,
I'd like to pick one aspect of the conversation.
" Seamless BFD is sort of like being able to do BFD echo over single-hop/multi-hop/IP/MPLS/SR ..."
And it confirmed my impression that Seamless BFD idea is so much Echo-like. Hence my question to Authors Why not to use Echo BFD in the first place? You've certainly considered that and I'm very interested to learn why you've decided not to take this path. true, new registries might be required if information in BFD Echo Request expected to be processed and results reported in BFD Echo Reply but we know how to do that, we've done that many times before. So, why not BFD Echo to achieve what Seamless BFD does?

And couple minor notes:
•       section 10.1 of draft-akiya-bfd-seamless-base-01 and section 7 of draft-akiya-bfd-seamless-sr-00 refer to EXP field of label element in “(label value + EXP)” but it should be Traffic Class (TC) field as it been renamed in RFC 5462
•       don’t see much of normative behavior defined in draft-akiya-bfd-seamless-sr-00 but more informational. Perhaps  some re-balancing work between BFD-S base and BFD-S for SR will help.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, September 03, 2013 7:57 PM
To: Tom Sanders
Cc: David Ward (wardd); [email-masked]; Carlos Pignataro (cpignata)
Subject: RE: New Version Notification for draft-akiya-bfd-seamless-base-01.txt

Hi Tom,

> Am i correct in saying that the main idea behind the draft is to
> create pseudo reflector BFD sessions that respond to the incoming BFD
> packets without maintaining any BFD neighbor state machine? As a
> result its only the nodes that initiate BFD packets that need to
> maintain the session state; the reflector BFD nodes are essentially stateless.

> While i can see the advantage to some extent, i am really not sure if
> we indeed need such an extension to BFD! Is maintaining BFD session
> state really hard when doing BFD in ASICs?

Me too.

- Nobo

> Cc: [email-masked]<mailto:[email-masked]>; David Ward (wardd); Carlos Pignataro (cpignata)
> Subject: Re: New Version Notification for
> draft-akiya-bfd-seamless-base- 01.txt
>
> Nobo et. al,
>
> Am i correct in saying that the main idea behind the draft is to
> create pseudo reflector BFD sessions that respond to the incoming BFD
> packets without maintaining any BFD neighbor state machine? As a
> result its only the nodes that initiate BFD packets that need to
> maintain the session state; the reflector BFD nodes are essentially stateless.
>
> While i can see the advantage to some extent, i am really not sure if
> we indeed need such an extension to BFD! Is maintaining BFD session
> state really hard when doing BFD in ASICs? Would love to hear what
> others have to say here.
>
> Toms
>
> On 21 August 2013 20:51, Nobo Akiya (nobo) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello BFD WG Members,
>
> Authors are looking into various aspects of S-BFD next. Carlos and
> myself will be looking into further defining Segment Routing scenarios
> (S-BFD SR
> draft) and will be seeking some help to on that front. And progress of
> that requires the "base" to be solidified, and we are need your help.
> Please point out anything that is unclear, confusing and/or questionable.
>
> Regards,
> Authors
>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> > Title:                 Seamless Bidirectional Forwarding Detection
> > (BFD) with MPLS Label Verification Extension Creation date:
> > 2013-08-21
> > Group:                 Individual Submission Number of pages: 20
> > URL:

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 6 Sep 2013 17:47:36 +0000

Hi Greg,

Thank you for comments. Let me start with more obvious part.

If we were to use existing BFD echo, then ...

1. We cannot do proposed mechanism for IP multihop as destination IP is self (initiator).
2. If we were to scope the proposed mechanism to IP singlehop and MPLS, initiator receiving back BFD echo cannot conclude that packet u-turned at intended node. For example, broken LSP causing transit node to incorrectly pop the label can cause packet to be returned back to sender due to destination IP having address of initiator.

Thus desire for a mechanism where only intended target can "u-turn" the packet or send the "pong" packet.

I know your question was not about above, but I felt that it'll be beneficial to state those first.

Now to your actual question ... the reason why authors did not want to define a new protocol or even new BFD packet format (async v1/v2 or echo) is because we wanted to maximize the reuse of existing standard & implementations, and we concluded that existing BFD control header definition is sufficient. We can add this topic into the document if you think this will be beneficial, let us know.

> • section 10.1 of draft-akiya-bfd-seamless-base-01 and section 7 of draft-
> akiya-bfd-seamless-sr-00 refer to EXP field of label element in “(label value
> + EXP)” but it should be Traffic Class (TC) field as it been renamed in RFC
> 5462

You are right, thanks for catching this. We will correct this in next revision.

> • don’t see much of normative behavior defined in draft-akiya-bfd-
> seamless-sr-00 but more informational. Perhaps  some re-balancing work
> between BFD-S base and BFD-S for SR will help.

Good comment, yes we will work on this.

I want to leave one comment before sending this email off. In additions to capabilities listed as reply to Tom, once a network has S-BFD reflection points setup, BFD really becomes an infrastructure where freedom and flexibility are provided to any initiators on what can be done. Alert discriminator document is just one example. This ultimately will provide better protections and services by the BFD protocol.

-Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Friday, September 06, 2013 12:01 PM
> To: Nobo Akiya (nobo); Tom Sanders
> And it confirmed my impression that Seamless BFD idea is so much Echo-
> like. Hence my question to Authors Why not to use Echo BFD in the first
> place? You've certainly considered that and I'm very interested to learn why
> you've decided not to take this path. true, new registries might be required
> if information in BFD Echo Request expected to be processed and results
> reported in BFD Echo Reply but we know how to do that, we've done that
> many times before. So, why not BFD Echo to achieve what Seamless BFD
> does?
> 
> And couple minor notes:
> • section 10.1 of draft-akiya-bfd-seamless-base-01 and section 7 of draft-
> akiya-bfd-seamless-sr-00 refer to EXP field of label element in “(label value
> + EXP)” but it should be Traffic Class (TC) field as it been renamed in RFC
> 5462
> • don’t see much of normative behavior defined in draft-akiya-bfd-
> seamless-sr-00 but more informational. Perhaps  some re-balancing work
> between BFD-S base and BFD-S for SR will help.
> 
>         Regards,
>                 Greg
> 
> Seamless BFD is sort of like being able to do BFD echo over single-
> hop/multi-hop/IP/MPLS/SR, except you are using BFD control packets &
> sender can only get response back if transmitted packet "u-turns" at
> expected network node. So yes, what you stated is absolutely correct.
> 
>   - Reachability validation is virtually immediate as session
> bringup/bootstrap sequences are no longer required.
>   - Imagine multiple unnumbered tunnels (ex: GRE) between a pair of
> loopbacks, can't do it with RFC5881, very difficult with RFC5883.
>   - Allowing BFD redundancy (ex: having multiple sessions per pair of
> addresses) is a great benefit to products with distributed BFD architecture.
> 
>   - This is a topic not yet widely discussed (from what I can tell), but BFD
> being able to perform Adj SID forwarding correctness adds great value to
> Segment Routing.
> 
> Of course, as you stated, egress state maintenance is essentially not
> required for uni-directional reachability check scenarios (static route, uni-
> directional tunnel/LSP).
> 
> And one of my personal favorite about this proposal is the fact it becomes a
> building block for further interesting possibilities.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Sep 2013 17:43:21 -0400

> really hard when doing BFD in ASICs? Would love to hear what others have to

It turns out that the need to actively provision BFD sessions on both sides
of a resource is occasionally a significant pain operationally.  One of the
repeated items that has popped up on the list over the years has been
thoughts on auto-provisioning mechanisms.  

The "seamless" proposal covers a significant part of the auto-provisioning
space.  It also raises the possibilities of interesting headaches as well,
e.g. security.

I'd like to request the WG to actively review the use cases covered by the
drafts and the suggested implementation.  We'll be scheduling a WG session
for the upcoming Vancouver IETF and discussing these use cases and proposals
will be part of the agenda.

With regard to the segment routing (SR) use cases, while they're a
reasonable match for the functionality in the drafts, the drafts seem to
have enough substance to stand on their own for the time being.  This is
important because our ADs haven't placed where SR specific work will happen.
I'd recommend the working group focus on the non-SR use cases primarily
for the time being.

A note for the record, since Nobo is an active author on these drafts, I
will be the managing chair for matters relating to them.

-- Jeff