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

[Peter Psenak <[e-mail]>]

Hi Alia,

please see inline:


On 27/09/17 00:12 , Alia Atlas wrote:
> 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.

BIER extension for OSPFv3 will be covered in a separate draft. It will 
be based on draft-ietf-ospf-ospfv3-lsa-extend draft. This is similar to 
what we did for SR and other extensions.

>
> 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).

will change to "Variable, dependent on sub-TLVs" language as we did in 
SR draft.

>
> 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?

I hope this has been clarified by Andrew and Tony already.

>
> 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.

will add description for value 0. Will also add the need for new 
registry in "IANA Considerations" section.


>
> 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.

can you please clarify what type of diagram do you have in mind?

I tend to agree with Andrew that we have similar section in many other 
documents and we've never included any diagram really. Anyway, I don't 
have a problem adding it if it helps.

>
> 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?/

top for bits are ignored. I'll spell that out explicitly.

thanks,
Peter

>
> Thanks,
> Alia