RE: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt

["Nobo Akiya (nobo)" <[e-mail]>]

+ draft-ietf-bfd-seamless-use-case authors

Hi Greg,

Many thanks for comments. Honestly I was expected bigger tomatoes to be thrown by you, but you were very kind with your comments. I hope you weren't just warming up :P

Please see my responses in-line.

> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Friday, October 24, 2014 8:10 PM
> To: Nobo Akiya (nobo); [e-mail]
> Subject: RE: New Version Notification for draft-akiya-bfd-seamless-alert-
> discrim-03.txt
> 
> Hi Nobo, Authors, et. al,
> please kindly consider my comments:
> • Section 2. Why not to add these to draft-ietf-bfd-seamless-use-case
> document?

I think it was a good idea to keep these "extended use cases" out from the draft-ietf-bfd-seamless-use-case document initially. They may have sounded too extreme and could have prevented S-BFD core functionalities to progress. However, given where we are, I agree. I think it's reasonable for them to be migrated over to draft-ietf-bfd-seamless-use-case document.

> • Section 2.1
> • use of S-BFD as inter-AS OAM. Perhaps this use case suggest need for BGP
> extension to advertise S-BFD discriminator(s).

I agree that use of BGP extension to advertise S-BFD discriminator(s) is one solution to address inter-AS scenario. The usage of alert discriminator with "discovery" diag is another way. IGP extensions to advertise S-BFD discriminator(s) is a necessary function. Not only does that allow S-BFD discriminator(s) to be advertised within the IGP domain, it also allows S-BFD discriminator conflicts within the IGP domain. For other protocol extensions to advertise S-BFD discriminator(s), I think some will still make sense. However, having a simpler common way for discovering the target S-BFD discriminator will also allow for faster deployment of S-BFDs. So, although BGP extension is a valid solution, I think there's a benefit in considering the mechanism described in this document.

> • Lack of control plane. MPLS-TP without control plane assumes centralized
> provisioning and I think it would be reasonable to expect that S-BFD can be
> administered in the same manner.

True, this can be achieved with centralized provisioning devices. With the "discovery" mechanism described, it does simplify the centralized provisioning devices in terms of instructions it needs to perform to start up S-BFD. Additionally with the "discovery" mechanism described, it will simplify scenarios where there is no or there is no "smart" centralized provisioning devices.

> • “To accommodate the two scenarios described …” you’ve listed three –
> which one can be ignored? ☺

Oops, thanks for catching that lol. Although you provided some alternate solutions, I still do see three use cases :)

> • Section 2.2
> • I don’t think that IP OAM should be concerned with disjointness of paths
> taken by different OAM packets over ECMP if network is properly designed
> and IGP convergence time is not much bigger than OAM defect detection
> time. (Otherwise there’s no reason to report and investigate what well
> could be false negative defect.)

For half of what you said, I agree. For the other half, I don't agree :) IP data plane is fairly good: run single-hop BFD on every link, run BFD on LAG on every LAG, and make sure IGP converges based on these, etc. However, there's a big gap when it comes to ECMP on MPLS data plane (whether it's LDP or RSVP or Segment Routing). One of the major contributor of traffic black holing on the MPLS data plane is the disconnect between control plane and data plane (i.e. missing expected in/out labels from data plane). Single-hop BFD cannot detect this since IP connectivity is fine. BFD on LAG cannot detect this since LAG (and the IP on the LAG) is fine. Single BFD over MPLS session end-to-end can verify one arbitrary path of the ECMP, but not all ... meaning it's blind to problems.

> • I think that this section talks more about need of defect correlation.

I couldn't understand this one. Can you elaborate?

> • Section 3
> • Have you considered Alert Discriminator as update to draft-ietf-bfd-
> seamless-base? Otherwise, if Alert Discriminator is not part of S-BFD base,
> not mandatory but optional, capability, then, I think, it must be advertised.

That's a good point, I didn't think about putting this in the draft-ietf-bfd-seamless-base. I think this is a reasonable option if the WG thinks these functions are useful.

> • Section 5
> • I think that requirement to protect ones NEs from potential DDoS using
> Alert Discriminator is very serious operational limitation.

I fully agree that the alert discriminator must be used with care, such as good filtering of who you accept alert discriminator from. I think more contents on this section will be good.

I plan to present S-BFD update at IETF91, I'll bring up 2 things.
1. Feel of the audience on migrating the 2 use cases to draft-ietf-bfd-seamless-use-case.
2. Feel of the audience on migrating the alert discriminator to draft-ietf-bfd-seamless-base.

Thanks!

-Nobo

> 
> Regards,
>                 Greg
> 
> -----Original Message-----
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Nobo Akiya
> (nobo)
> Sent: Tuesday, October 21, 2014 2:48 PM
> To: [e-mail]
> Subject: New Version Notification for draft-akiya-bfd-seamless-alert-
> discrim-03.txt
> 
> Dear BFD WG,
> 
> The last of the S-BFD documents, and likely the most controversial one, has
> been updated and published.
> 
> In summary, let's reserve S-BFD discriminator zero(0) as the alert
> discriminator.
> 
> We'd appreciate comments.
> 
> Thanks!
> 
> -Nobo, ducking for cover
> 
> 
> [snip]
> A new version of I-D, draft-akiya-bfd-seamless-alert-discrim-03.txt
> has been successfully submitted by Nobo Akiya and posted to the IETF
> repository.
> 
> Name:           draft-akiya-bfd-seamless-alert-discrim
> Revision:       03
> Title:          Seamless Bidirectional Forwarding Detection (S-BFD) Alert
> Discriminator
> Document date:  2014-10-21
> Group:          Individual Submission
> Pages:          9
> URL:            http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-
> alert-discrim-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-
> discrim/
> Htmlized:       http://tools.ietf.org/html/draft-akiya-bfd-seamless-alert-
> discrim-03
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-alert-
> discrim-03
> 
> Abstract:
>    This document defines the Alert Discriminator which operates on the
>    Seamless Bidirectional Forwarding Detection (S-BFD), and Alert
>    Discriminator Diagnostic Codes which operates on the Alert
>    Discriminator.
> [snip]
> 
>