Hi, Alvaro, Thanks for your thorough review!
Before the point-by-point response, I wanted to provide some perspective on a small subset of your comments: > On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) <[email protected]> > wrote: > > As I mention in the review for draft-ietf-bfd-seamless-ip, please consider > merging the two documents. I will keep this document under AD Evaluation > (and not return it to the WG) unless the WG Chairs consider that it is > necessary to WGLC the resulting document. > > This is a recurring theme, one that you mention in every email about draft-ietf-bfd-seamless-*. It might be useful to share some additional context and perspective. When we first started drafting ideas and early text of S-BFD, there was a single document for base + IP. At some point, we started drafting what S-BFD for Segment Routing would look like, and different optimizations for different environments. At that point, we realized that it was more sensible to have a common -base specification, followed by a number of adjunct documents, each about a different environment/transport. Yes, draft-akiya-bfd-seamless-ip is quite basic and straightforward, specifying ports, addresses, and small specifics in procedures. And if there were only these two documents, it would make perfect sense (to me) to merge them. However, there’s more! :-) For example, draft-akiya-bfd-seamless-sr specifies S-BFD for Segment Routing, in which a different set of specifics are needed (given for example the ability to control the return path). Similarly, there are other uses of S-BFD such as S-BFD for Tunnels, S-BFD for Pseudowires (draft-ietf-pals-seamless-vccv), etc. All of these define very narrowly scoped specifics (IP vs. SR vs. PW) — however, all of those adjunct specifics would pollute and dramatically lower the SNR if all merged to the -base spec. Net-net, we opted for modularity in the specifications. The BFD WG chose to first progress -base and -ip, and only after those were more mature, then advance -sr. This would not imply that the first two documents on the sbfd set are the only ones. We did consider merging the two documents, even after we purposely split them. If these were the only two docs in the set, I’d support merging them (or not having split them). But in the larger constellation of S-BFD docs, I consider it best to advance the -base separated from all the different specifics. > Normative References > I-D.ietf-bfd-multipoint should clearly be Normative because of the new > bfd.SessionType state variable Great catch. The new bfd.SessionType state variable is new for both documents, and neither has a dependency on values of the variable from the other document. Consequently, I do wonder if this document should define the variable and bfd-multipoint refer to this — there is no serialization needed other than a common variable with independent use. > I-D.ietf-bfd-generic-crypto-auth should also be Normative because of how the > Security Considerations are written: pointing to is as a “MUST". Given that > (as far as I can tell) there aren’t implementations of > I-D.ietf-bfd-generic-crypto-auth, we could end up with a Normative reference > that blocks the publication of this document. I want to suggest that the > comments be reworded as a suggestion or pointer to potential solutions, not > as a mandate to use them. [Disclaimer: we will still need the SecDir to > review.] Another good point — thanks — given how the text is written. I am not sure, however, the text is written in the best way. :-) > Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion > mentioned. rfc5880 talks about some of the considerations. Are there new > congestion-related considerations that arise because of eliminating some of > the negotiation aspects? Thinking out loud: if a session doesn’t have to be > established (and everyone knows a remote discriminator), then there’s a > possibility of more nodes sending traffic to a specific reflector (just as an > example). Please include some text indicating any congestion issues — or at > least explaining why there aren’t any new ones. > Very much agree. I believe there are subtle differences in the congestion considerations, because if the simplified negotiation. Further, I believe those should live in the -base doc. That is missing, and we should fill in this gap. Thanks! — Carlos.
signature.asc
Description: Message signed with OpenPGP using GPGMail
