Subject: S-BFD Requirements (RE: BFD v2?)

From: Gregory Mirsky <[email-masked]>
Date: Sun, 23 Mar 2014 18:19:06 +0000

Hi Nobo,
I completely agree that we must always keep requirements in perspective.
For #2 can we just say "in-band continuity check"?
#3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths being monitored at any given time. I believe that as case of composite link ECMP/UCMP should be monitored on composite link level, e.g. like micro-BFD on LAG.
#4 - I believe that almost all required instrumentation is there already
#5 - that is, IMHO, unnecessary.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Sunday, March 23, 2014 8:47 AM
To: Gregory Mirsky; Bhatia, Manav (Manav); Marc Binderberger ([email-masked])
Cc: [email-masked]
Subject: RE: BFD v2?

I *think* there are things which protocols/people are *hoping/wanting* OAM to be able to do (perhaps by BFD, perhaps X together with BFD or perhaps not involving BFD at all) ... small[er] items not mentioned.

1. Rapid verification of path/service availability.
2. In-band monitoring via controller device.
3. Per ECMP/UCMP path in-band monitoring.
4. Controlling the return path of in-band monitoring.
5. Deterministically differentiating link-failure vs. node-failure.

[1-3] Solved by S-BFD (3 solved only with specific hashing (ex: EL)).

[4] http://datatracker.ietf.org/doc/rfc7110/ provides one solution, but there is no generic solution.

[5] Nothing out there?

I agree that v2 definition should be driven by specific requirements. Those can be driven by vendors or operators, but we need to have specific requirements before jumping on to defining the v2.

-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory 
> Mirsky
> Sent: Thursday, March 20, 2014 11:24 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: RE: BFD v2?
> 
> Hi Manav,
> regarding IP Performance Measurement I can point to IPPM WG. 
> Everything that is related to measurement of performance of IP 
> transports (UDP, TCP) and IP-based applications is in scope of IPPM 
> WG. As mentioned earlier, OWAMP and TWAMP protocols support 
> measurement of delay and delay variation both one-way and two-way 
> metrics. As for link trace, I think that traceroute does that already.
> The problem of "in-band" OAM does exist and Nobo and I recently talked 
> about it on this thread. I agree with Nobo that if an operator needs 
> in-band OAM over ECMP then hashing must exclude Destination and Source 
> UDP ports.
> What's left? That is good question, particularly for operators that 
> plan to use Segment Routing with IPv6 dataplane.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Thursday, March 20, 2014 12:18 AM
> To: Gregory Mirsky
> Cc: [email-masked]
> Subject: RE: BFD v2?
> 
> Hi Greg,
> 
> Ideally the demand should come from the operators in case they need 
> enhanced IP OAM capabilities (loss measurement, an equivalent of a 
> link trace, etc) for pure IP networks. Has anybody ever asked for 
> this? I am aware of the ECMP issue where the IP OAM does not follow 
> the traffic. But besides that, is there anything else that folks have been asking for?
> 
> Cheers, Manav
> 
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:[email-masked]]
> > Sent: Thursday, March 20, 2014 12:31 PM
> > To: Bhatia, Manav (Manav)
> > Cc: [email-masked]
> > Subject: RE: BFD v2?
> >
> > Hi Manav,
> > right, MPLS OAM is much functionally closer to Y.1731 though there 
> > are some missing functions among them experimental and 
> > vendor-specific might be of interest for us. But I'll note that MPLS 
> > Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need 
> > metrics definitions at least.
> > Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, 
> > considering that MPLS dataplane may make MPLS OAM re-usable in
> SPRING.
> > (That to be seen after we finish SPRING OAM Requirements and gap 
> > analysis).
> >
> > 	Regards,
> > 		Greg
> >
> > -----Original Message-----
> > From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> > Sent: Wednesday, March 19, 2014 11:45 PM
> > To: Gregory Mirsky
> > Cc: [email-masked]
> > Subject: RE: BFD v2?
> >
> > >
> > > Don't we have most of what Y.1731 offers available for MPLS networks?
> > > Did you mean the gaps in OAM for pure IP (non-MPLS) networks?
> >
> > And gaps in OAM for segment routed networks.
> >
> > Cheers, Manav

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 24 Mar 2014 13:13:55 +0000

Hi Greg,

> For #2 can we just say "in-band continuity check"?

I think that's a fair naming.

> #3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths
> being monitored at any given time.

I agree, best we can do is to have frequent fresh rate to update the paths (and entropies).

> I believe that as case of composite link
> ECMP/UCMP should be monitored on composite link level, e.g. like micro-
> BFD on LAG.

That approach definitely fits better in some scenarios, and provides better scalability (i.e. distributes monitor packet processing). Although my one concern with that approach is that we will not be truly testing the packet path into each composite and out from each composite (i.e. monitor packets are locally generated from composite ingress and terminated on composite egress). If we want the coverage to include such, then doing the monitoring LSP end-to-end with LSP path trace for entropy discovery may be the way to go (with LSRs employing EL load balancing). For IP based network, what you suggested may be the only way at this moment (with composite ingress pre-routing into each composite link), as there is no tools to discover the entropies yet.

> #4 - I believe that almost all required instrumentation is there already

That's a good news. Can you send me list of techniques that are on your radar?

> #5 - that is, IMHO, unnecessary.

I hope so, it's a very difficult problem ... I do see some standard track drafts, that rely on node failure detection, progressing. Let's see if any requirements comes flying into BFD WG direction [or not].

-Nobo

> Sent: Sunday, March 23, 2014 2:19 PM
> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger
> ([email-masked])
> Cc: [email-masked]
> Subject: S-BFD Requirements (RE: BFD v2?)
> 
> Hi Nobo,
> #3 - I think that there's no way to ensure which of ECMP/UCMP sub-paths
> being monitored at any given time. I believe that as case of composite link
> ECMP/UCMP should be monitored on composite link level, e.g. like micro-
> BFD on LAG.
> I *think* there are things which protocols/people are *hoping/wanting*
> OAM to be able to do (perhaps by BFD, perhaps X together with BFD or
> perhaps not involving BFD at all) ... small[er] items not mentioned.
> 
> I agree that v2 definition should be driven by specific requirements. Those
> can be driven by vendors or operators, but we need to have specific
> requirements before jumping on to defining the v2.
> 
> -Nobo
>