Re: [OSPF] early AD review of draft-ietf-bier-ospf-bier-extensions-07

["Dolganow, Andrew (Nokia - SG/Singapore)" <[e-mail]>]

Alia,

Thanks, so quick comments:

From: Alia Atlas <[e-mail]>
Date: Wednesday, September 27, 2017 at 6:12 AM
To: "[e-mail]" <[e-mail]>rg>, OSPF List <[e-mail]>rg>, "[e-mail]" <[e-mail]>
Subject: early AD review of draft-ietf-bier-ospf-bier-extensions-07
Resent-From: <[e-mail]>
Resent-To: Peter Psenak <[e-mail]>om>, <[e-mail]>om>, "(Ice) IJsbrand Wijnands" <[e-mail]>om>, Andrew Dolganow <[e-mail]>om>, <[e-mail]>et>, Jeffrey Zhang <[e-mail]>et>, <[e-mail]>
Resent-Date: Wednesday, September 27, 2017 at 6:12 AM

I have done an early AD review of draft-ietf-bier-ospf-bier-extensions-07 in preparation for the publication request.

First, I would like to thank the many authors for their work on this draft. Given that there are currently 7 authors listed, I'd recommend appointing a few editors or otherwise reducing down to 5 or fewer. Of course, I am also willing to consider extraordinary circumstances where the shepherd can explain to me privately the deep technical contribution made by each author.

I do see a number of major issues.

Major Issues:


1)      RFC7684 is just for OSPFv2.  How is the information carried for OSPFv3? We need a mechanism that works for IPv6 also.
ad> agree – the way the draft is written is v2 only.  need to address that.

2) In Sec 2.1, the Length is defined as variable and the figure includes additional sub-TLVs. Please clarify in the text what other sub-TLVs can be carried & how the length is calculated (yes, same as always - but clarity helps with interoperability).

ad> Repeating may not be clarifying. How about we say “Variable, dependent on sub-TLVs” to use RFC7684-like text for the Extended prefix TLV. I could not find a single example where we list what sub-TLVs are carried either. That is done – as in this draft – in sub-TLV sections.

3) Sec 2.2 "The size of the label range is determined by the number of Set
      Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that
      are used in the network.  Each SI maps to a single label in the
      label range.  The first label is for SI=0, the second label is for
      SI=1, etc.:

This implies that there is no way to indicate only a label for SI=1 or a range for SI=1 to 3. That seems unfortunate and assumes that the BFR-ids are always allocated from SI=0 up.   Is there a reason not to use some of the reserved bits to indicate the starting SI value?

ad>set-identifiers provide a scaling for BIER sub-domains based on supported BitString lengths. Conceptually we forward in sub-domains, thus advertising label ranges for a sub-domain (as a base “unit” of forwarding) makes sense. The extra level of granularity would break that sub-domain consistency. Sometimes just because we could provide a higher granularity I do not think we should. This sub-domain granularity makes advertising and processing simpler.

4) Sec 2.3: The Tree type is a 1 octet value - that doesn't appear to have any IANA allocation or meaning clearly indicated - beyond the parenthetical that 0=SPF.  Please fix this.

ad> agree this would need to be fixed

5) Sec 2.5: This section could benefit greatly from a diagram - showing the advertising router for a prefix, the ABR, and what is then flooded for the BIER MPLS Sub-TLV for the new areas.

ad> again without arguing against diagram, I can only say this text is consistent with other similar paragraphs in other drafts/RFCs (like 7684). I could not find an example when we do put a diagram (but only looked at about 5 OSPF RFCs.

Minor:

4) Sec 2.3: "Label Range Base: A 3 octet field, where the 20 rightmost bits represent the first label in the label range."  What about the top 4 bits?  Are they Must Be Zero (MBZ)?  How about making that explicit?  Are they potential future flags?/

ad> I assume you mean 2.2 section, yes MBZ.

Andrew



Thanks,

Alia