Subject: RE: Discovering IP address to use for uBFD sessions

From: Binny Jeshan <[email-masked]>
Date: Tue, 24 Sep 2013 20:49:23 +0530

I agree with Marc.

Regards,
Binny.

Sent from Nokia Lumia.

-----Original Message-----
From: "Marc Binderberger" <[email-masked]>
Sent: ‎24-‎09-‎2013 06:51 PM
To: "Jeffrey Haas" <[email-masked]>; "Nobo Akiya (nobo)" <[email-masked]>
Cc: "Jeff Haas ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]>
Subject: Re: Discovering IP address to use for uBFD sessions

Hello,

I think we can play on time regarding this topic. If there are specific 
requests they may drive the discussion again. Also over time network 
designs change. Who knows, in a few years the out-of-band 
synchronization between two network nodes may be a side effect of SDN 
and the "discovery" comes for free ;-)

Not sure how seamless BFD is fitting into scenarios with two-sided BFD 
like uBFD sessions. Each technology has it's area where it is the right 
fit; for seamless I see everything that is uni-directional and/or 
virtual - LSPs, tunnels, etc., as an excellent fit and seamless BFD as 
probably superior over our existing two-sided BFD. As long as something 
is fixed - either physical like a wire or fixed configured - I would 
see the existing BFD as the best fit.

Anyway, good discussions are always fine with me :-)

Regards, Marc

On Wed, 18 Sep 2013 17:57:59 -0400, Jeffrey Haas wrote:
> On Thu, Jul 11, 2013 at 07:49:11PM +0000, Nobo Akiya (nobo) wrote:
>> [hat on]
>> 
>> I had a discussion with Jeff on this topic.
>> 
>> We have concluded that there isn???t sufficient WG interest to 
>> pursue adoption of dynamic address discovery at this time. However 
>> note, such work, if interest appears, is in scope for the existing 
>> charter.
> 
> To bump this thread, the seamless BFD proposal may cover this use case.  
> 
> With regard to only BFD on LAG, it was the consensus of the initial
> developers and authors that configuration was sufficient for the time being
> and satisfied the original customer use case.  But as noted elsewhere,
> people keep asking about this. :-)
> 
> -- Jeff
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 25 Sep 2013 22:50:59 +0000

Hi Marc, Binny, et al,

I agree with your statement of "right fit" for seamless BFD and existing BFD.

> Anyway, good discussions are always fine with me :-)

Ok :)

Since SDN was mentioned, perhaps we can dive a bit further into that topic. I can see one approach being that SDN provisions BFD sessions on necessary nodes. Or in a network where there's clean(er) separation of control plane and data plane, then I can also see permanent monitor packets to be generated from the controller device. Such packets can anything as long as they originate from the controller device and terminates at the controller device. Problem is that packet instructed to take arbitrary path and back to self makes it difficult to guarantee that packet did "loop" at intended node. Thus there's a need for such permanent monitor packet to take arbitrary path to intended target, and have intended target generate a response packet back to the controller device. That means such packets cannot be anything, but must be defined.

To place more twist into this, statically provisioned LSPs (aka static LSP, MPLS static) is one network architecture where SDN-like is likely. If we want to use BFD initiated from controller devices, as above, we need something more than existing BFD. If we want to use traditional model of BFD provisioned at LSP ingress(es), then do we want to reuse RFC5884 with new FEC defined for static? 

I see S-BFD to be the "right fit" for these scenarios as well.

-Nobo

> From: Binny Jeshan [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2013 11:19 AM
> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas ([email-masked]); [email-masked]
> Subject: RE: Discovering IP address to use for uBFD sessions
> 
> I agree with Marc.
> 
> Regards,
> Binny.
> 
> Sent from Nokia Lumia.
> ________________________________________
> From: Marc Binderberger
> To: Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas ([email-masked]); [email-masked]

---

From: Glen Kent <[email-masked]>
Date: Thu, 26 Sep 2013 12:08:46 +0530

Nobo,

Why cant we use the existing BFD to form sessions between the controller
and the terminating routers in non MPLS scenarios (or when static LSPs are
provisioned)? I am afraid i did not get that point.

If we use the S-BFD, then the controller would be the "client" and the
egress routers, the "reflector", is it?

What do we gain by using S-BFD there?

Glen

On Thu, Sep 26, 2013 at 4:20 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> Since SDN was mentioned, perhaps we can dive a bit further into that
> topic. I can see one approach being that SDN provisions BFD sessions on
> necessary nodes. Or in a network where there's clean(er) separation of
> control plane and data plane, then I can also see permanent monitor packets
> to be generated from the controller device. Such packets can anything as
> long as they originate from the controller device and terminates at the
> controller device. Problem is that packet instructed to take arbitrary path
> and back to self makes it difficult to guarantee that packet did "loop" at
> intended node. Thus there's a need for such permanent monitor packet to
> take arbitrary path to intended target, and have intended target generate a
> response packet back to the controller device. That means such packets
> cannot be anything, but must be defined.
>
> To place more twist into this, statically provisioned LSPs (aka static
> LSP, MPLS static) is one network architecture where SDN-like is likely. If
> we want to use BFD initiated from controller devices, as above, we need
> something more than existing BFD. If we want to use traditional model of
> BFD provisioned at LSP ingress(es), then do we want to reuse RFC5884 with
> new FEC defined for static?
>
> > Sent: 24-09-2013 06:51 PM

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 26 Sep 2013 14:04:06 +0000

Hi Glen, et al,

> scenarios (or when static LSPs are
> provisioned)?

Allow me to start with this.

      |
      C
    /   \
  B       D
  |       |
- A       E-
    \   /
     G-F
     | |
     CON

Controller device CON wants to validate LSP{A, B, C} and LSP{E, D, C}.

LSP{A, B, C}: Since CON wants to test LSP starting from {A} and terminating on {C}, label stack imposed by CON should be {A}{C}.
LSP{E, D, C}: Since CON wants to test LSP starting from {E} and terminating on {C}, label stack imposed by CON should be {E}{C}.

This results in CON testing 4 paths.
LSP{CON, G, A}
LSP{A, B, C}
LSP{CON, F, E}
LSP{E, D, C}

If we extend RFC5884 for static LSPs, then we'll have a FEC defined for prefix.
CON would need to generate 4 LSP pings, corresponding to 4 LSPs mentioned above.
- One LSP ping destined for FEC{A}.
- One LSP ping for FEC FEC{E}.
- Two LSP pings for FEC{C}.

1. Larger number of LSP ping is one concerning point. LSP ping is a really powerful tool, but many implementations has scale/perf constraints compared to BFD.

In addition:

2. How will {C} differentiate between received LSP ping for  LSP{A, B, C} and LSP{E, D, C}? FEC will be the same, source IP address will be the same.
3. LSP ping for LSP{A, B, C} and LSP{E, D, C} may not be in-band.
    - If CON to C was ECMP, then LSP ping from CON to C for both LSPs could go on either paths.
    - If CON to C was non-ECMP, then LSP ping from CON to C for both LSPs will go on one path.

Of course for new LSP provisioned from X to C, it could take good chunk of time for CON to verify the LSP.

Some concerns are addressable (2), and some are moot (3) depending on who you ask. But when all is considered, it makes me wonder whether this is a good solution. This is an aspect which I'd like to hear from you and others.

> egress routers, the "reflector", is it?

That's correct.

> What do we gain by using S-BFD there?

No LSP ping is needed.
Verification is immediate.
Egress stateless (no sessions needed on target nodes).
Controller can slow down packet rate, speed up packet rate, stop, resume at any time.
Alert discriminator allows for fault isolation upon failure.

In above example, CON can send 4 types of packets.
Label{A}
Label{A}{C}
Label{E}
Label{E}{C}

For permanent monitor initiated from controller device, there are two general techniques.
a. OAM packet that has instruction for forward path as well as reverse path.
    - Weakness with this is that it's difficult to guarantee that forward path reached the target.
    - Strength with this is that reverse path is controlled.
    - Packet can be any (no standard required).
b. OAM packet that has instruction for forward path only.
    - Strength with this is that there's guarantee that forward path reached the target.
    - Weakness with this is that reverse path isn't controlled.
    - Packet must be pre-defined (standard required).

S-BFD is (b) technique. (a) and (b) complements either other, thus I see value in controller device initiated permanent monitor to provision both.

> in non MPLS scenarios

In IP scenario, if we want to perform permanent monitor from controller device, we would have to create a tunnel and pre-route the packet to starting node, so there's added complexity. It can be done but provisioning BFD (existing or seamless) at starting node still appears attractive.

I hope this helps.

With that said, S-BFD is still rough around the edges. Couple of authors are actively working on the next revision, but what's defined so far is a good starting point to allow BFD to better fit in some areas where existing BFD has concerns.

-Nobo

> From: Glen Kent [mailto:[email-masked]]
> Sent: Thursday, September 26, 2013 2:39 AM
> To: Nobo Akiya (nobo)
> Cc: Binny Jeshan; Marc Binderberger; Jeffrey Haas; Jeff Haas
> ([email-masked]); [email-masked]
> Since SDN was mentioned, perhaps we can dive a bit further into that topic.
> I can see one approach being that SDN provisions BFD sessions on necessary
> nodes. Or in a network where there's clean(er) separation of control plane
> and data plane, then I can also see permanent monitor packets to be
> generated from the controller device. Such packets can anything as long as
> they originate from the controller device and terminates at the controller
> device. Problem is that packet instructed to take arbitrary path and back to
> self makes it difficult to guarantee that packet did "loop" at intended node.
> Thus there's a need for such permanent monitor packet to take arbitrary
> path to intended target, and have intended target generate a response
> packet back to the controller device. That means such packets cannot be
> anything, but must be defined.
> 
> To place more twist into this, statically provisioned LSPs (aka static LSP,
> MPLS static) is one network architecture where SDN-like is likely. If we want
> to use BFD initiated from controller devices, as above, we need something
> more than existing BFD. If we want to use traditional model of BFD
> provisioned at LSP ingress(es), then do we want to reuse RFC5884 with new
> FEC defined for static?
>

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 27 Sep 2013 19:37:46 +0200

Hello Nobo et al.,

not sure I agree with the details of the example but I agree with the 
conclusions ;-)

>> egress routers, the "reflector", is it?

okay, that is possible but not sure I would go with this design :-) 
Multiple reasons: you want to check A->B->C/E->D->C , not making things 
more complex with the path CON<->A/E. (this is why in the past one used 
SNMP to trigger an IP ping between routers from the management 
station)  Also scale for receiving the packets may be challenging - the 
network device is designed to handle a certain BFD scale and not miss 
packets under high load - and the need to implement BFD (subset) on the 
controller.

Nevertheless, S-BFD compared to RFC5884 allows for ad-hoc checks to be 
done simpler. In a "true" SDN style I would expect the controller to 
activate an API on A to check for the path A->B->C with N packets and 
would get a report back. So with S-BFD the controller talks to A and E, 
gets a report, done. With RFC5884 you would need to setup (and tear 
down) a session between A-C and E-C. Possible but as mentioned in an 
earlier email by Nobo you then need to handle the "going up" time which 
is not (upper-)bounded.

Killer argument for S-BFD over RFC5884?  No but I think it's another 
reason on top of others.

Regards, Marc

On Thu, 26 Sep 2013 14:04:06 +0000, Nobo Akiya (nobo) wrote:
> LSP{A, B, C}: Since CON wants to test LSP starting from {A} and 
> terminating on {C}, label stack imposed by CON should be {A}{C}.
> LSP{E, D, C}: Since CON wants to test LSP starting from {E} and 
> terminating on {C}, label stack imposed by CON should be {E}{C}.
> 
> 1. Larger number of LSP ping is one concerning point. LSP ping is a 
> really powerful tool, but many implementations has scale/perf 
> constraints compared to BFD.
> 
> In addition:
> 
> 2. How will {C} differentiate between received LSP ping for  LSP{A, 
> B, C} and LSP{E, D, C}? FEC will be the same, source IP address will 
> be the same.
> Some concerns are addressable (2), and some are moot (3) depending on 
> who you ask. But when all is considered, it makes me wonder whether 
> this is a good solution. This is an aspect which I'd like to hear 
> from you and others.
> 
> S-BFD is (b) technique. (a) and (b) complements either other, thus I 
> see value in controller device initiated permanent monitor to 
> provision both.
> 
>> in non MPLS scenarios
> 
> In IP scenario, if we want to perform permanent monitor from 
> controller device, we would have to create a tunnel and pre-route the 
> packet to starting node, so there's added complexity. It can be done 
> but provisioning BFD (existing or seamless) at starting node still 
> appears attractive.
> 
> I hope this helps.
> 
> With that said, S-BFD is still rough around the edges. Couple of 
> authors are actively working on the next revision, but what's defined 
> so far is a good starting point to allow BFD to better fit in some 
> areas where existing BFD has concerns.
> 
> -Nobo
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 27 Sep 2013 21:43:17 +0000

Hi Marc, et al,

Thanks for taking time to respond!

> not sure I agree with the details of the example but I agree with the

I'm quite glad to hear that actually :)

I'm pushing for S-BFD as an infrastructure, by exhibiting some possible use cases. But exact provisioning model for various technologies, including static LSP, I believe that we will need requirements/discussions and time for WG/people to converge.

> >> If we use the S-BFD, then the controller would be the "client" and
> >> the egress routers, the "reflector", is it?
> >
> > That's correct.
> 

Ok we agree that egress must be reflector. For the question of where is the initiator, I don't agree nor disagree with you at this point (as indicated above, I'm not arguing for any particular provisioning model at this point). When there are S-BFD reflection points in the network, operator can provision one or the other, or both, or more if required.

What you pointed out very well may be for powerful products with rich feature set. Although, operators may still desire to run many OAM aspects from controller device(s), to allow for quicker deployments (removes feature request dependencies to multiple products/vendors) or for other reasons. For lower end products and/or products with minimal feature set, there may not be a choice but to run OAM from controller device(s). Reasons being those products may not have sufficient BFD support, or may not have sufficient BFD scale/perf numbers. Implementing just S-BFD reflector sessions will likely be far more simpler than implementing various flavors of BFD. If low end products can at least implement just S-BFD reflection points, then operators can perform much greater permanent monitor in their network centrally.

> Killer argument for S-BFD over RFC5884?  No but I think it's another reason
> on top of others.

:)

-Nobo

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Friday, September 27, 2013 1:38 PM
> To: Nobo Akiya (nobo); Glen Kent
> Cc: Binny Jeshan; Jeffrey Haas; Jeff Haas; [email-masked]
> >> If we use the S-BFD, then the controller would be the "client" and
> >> the egress routers, the "reflector", is it?
> >
> > That's correct.
> 
> okay, that is possible but not sure I would go with this design :-) Multiple
> reasons: you want to check A->B->C/E->D->C , not making things more
> complex with the path CON<->A/E. (this is why in the past one used SNMP
> to trigger an IP ping between routers from the management
> done simpler. In a "true" SDN style I would expect the controller to activate
> an API on A to check for the path A->B->C with N packets and would get a
> report back. So with S-BFD the controller talks to A and E, gets a report, done.
> With RFC5884 you would need to setup (and tear
> earlier email by Nobo you then need to handle the "going up" time which is
> not (upper-)bounded.
> 
> 
> Killer argument for S-BFD over RFC5884?  No but I think it's another reason
> on top of others.
> 
> 
> Regards, Marc
> 
> 
> 
> 
> topic.