Subject: [Isis-wg] QA review of draft-ginsberg-isis-sbfd-discriminator-00

From: Dan Frost <[email-masked]>
Date: Mon, 29 Sep 2014 14:16:45 +0100

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.

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.

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.

6. Are there any chicken-and-egg problems here arising from potential
mutual dependency between IS-IS and BFD?

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.

Thanks,
-d