Early Review of draft-ginsberg-isis-sbfd-discriminator-00
Thanx for your thoughtful review.
> -----Original Message-----
> From: Dan Frost [
> 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
> 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.
> 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
> 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.