Early Review of draft-ginsberg-isis-sbfd-discriminator-00
review-ginsberg-isis-sbfd-discriminator-00-rtgdir-early-frost-2014-10-01-00

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