Dan - Thanx for your thoughtful review. Answers inline. > -----Original Message----- > From: Dan Frost [ mailto:frost at mm.st] > Sent: Monday, September 29, 2014 6:17 AM > To: draft-ginsberg-isis-sbfd-discriminator at tools.ietf.org > Cc: isis-wg at ietf.org > Subject: QA review of draft-ginsberg-isis-sbfd-discriminator-00 > > Hi, > > I have been asked by the Routing ADs and WG chairs to do a QA review of > draft-ginsberg-isis-sbfd-discriminator-00 as a candidate for potential > WG adoption. > > Draft Summary > ------------- > This is a brief draft that describes how Seamless BFD (S-BFD) > [draft-ietf-bfd-seamless-base] discriminator information can be > advertised throughout an IS-IS area or routing domain using the IS-IS > CAPABILITY TLV [RFC 4971]. > > Review Summary > -------------- > This draft limits itself to specifying the proposed new sub-TLV > encoding. Provided the WG is happy with the flooding of such data via > the CAPABILITY TLV, the draft seems like a fine basis for a WG document. > > Comments > -------- > 1. The draft abstract is meaningless to anyone without specialized > knowledge of S-BFD or IS-IS TLVs. A paragraph or two of context here > would improve the draft quality. > > 2. Similarly, some extra context in the introduction as to what S-BFD is > and how it relates to the routing protocol would make the draft more > readable. Mentioning the rationale for area/domain-wide flooding of > BFD-related information would be especially helpful, as BFD is generally > seen as a matter between peers. LES: Let me reply to #1 and #2 together. I am NOT a fan of duplicating the content of one specification into another. At best the text is redundant - at worst it is inconsistent w the source. If you want to know about S-BFD go look at the S-BFD reference. :-) Sorry if that seems rude - but I do feel strongly about this point. I can see some benefit in discussing why you might want to flood info domain wide - I will put that on the list for the next version. In light of the above I really don't know what else you think the abstract should have in it. I don't expect a person who is unfamiliar w both S-BFD and IS-IS to get much from reading this draft (or any other IS-IS draft) and I don't think it is the responsibility of the draft to provide this context. This is intended to be a normative specification and as such should confine itself to specifying the protocol behavior. > > 3. The [S-BFD] reference, which is rather important here, points to > draft-akiya-bfd-seamless-base-03 while the current version of that draft > is draft-ietf-bfd-seamless-base-03. LES: The reference was current at the time this version of the draft was written. A new version of the draft (WG-00) has already been submitted and the reference has been updated. Look for this to be posted as soon as the WG chairs approve it. > > 4. It is not clear from the draft why the CAPABILITY TLV was chosen as > the preferred mechanism as compared to other possibilities like GENINFO > [RFC 6823]. Perhaps this is implicitly understood by the WG, but some > rationale might be valuable if this is indeed one of several viable > approaches. > > 5. For some time, there has been a trend of leveraging routing protocols > to store and flood more and more ancillary information. This must be > done with care. I would expect a draft like this to discuss how much > additional data this extension might push into the network and the > databases of all routers in the routing domain, and what impact this is > expected to have. > LES: Answering #4 and #5 together. The GENINFO vs Router Capability question question is valid and was brought up in the WG meeting in Toronto. The answer I gave at the time was: Strictly speaking GENINFO is more appropriate - but such a solution is more expensive from a deployment/implementation standpoint. Note that GENINFO REQUIRES the use of Multi-Instance - which I think would be considerable overkill in this case. Given that the IGP is a likely client of S-BFD I think the expediency of using Router Capability is justifiable. As regards the concern regarding the quantity of data to be advertised I fully expect one discriminator value to be sufficient and since there is no need for the discriminator value to be changed once advertised there should be no churn. > 6. Are there any chicken-and-egg problems here arising from potential > mutual dependency between IS-IS and BFD? LES: No - I don't think so. RFC 6213 describes how the protocol uses BFD as a prerequisite to forming an adjacency in cases where both neighbors support BFD. But this is standard single hop BFD - NOT S-BFD. So there is no dependency on knowing S-BFD discriminators before IS-IS can form neighbors and/or flood link state info. > > 7. The sister document for OSPF [draft-bhatia-ospf-sbfd-discriminator] > describes some considerations in the last few paragraphs of Section 2.2 > that don't appear entirely OSPF-specific. Do any of these deserve > mentioning in this draft? It might be helpful if these two drafts were > kept closely in sync, perhaps with the assistance of a common editor. > LES: There has been informal coordination between the authors of the two drafts and I would expect that to continue. That said, much of Section 2.2 is discussing RI LSA procedures. The equivalent functionality for IS-IS can be found in RFC 4971 Section 3. Given my predisposition for NOT repeating normative text from one specification in another specification (see my reply to #1 and #2 above) I prefer NOT to follow the OSPF draft in this regard. Les > Thanks, > -d