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

[Alia Atlas <[e-mail]>]

Hi Peter,

On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <[e-mail]> wrote:

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


I understand that theory - but I think it is getting less tractable.  How
far along is that draft? I'll need to at least
reference it and discuss the IPv6 support in the write-up.  Once
draft-ietf-ospfv3-lsa-extend is published as an RFC, I would really expect
this to stop happening.

I don't know if you noticed that draft-ietf-sunset4-ipv6-ietf-01 ("IETF:
End Work on IPv4") is in IETF Last Call.
Of course, it has lots of caveats and is getting a number of concerned
comments - but the trend is obvious
as is the deployment of IPv6 and the need for feature parity.


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


Sounds good - Variable, 4 + length of sub-TLVs  I think.  I.e., be clear on
the length
contributed by this TLV as well as the included sub-TLVs.


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


Sure - I'm fine with what the WG wants here - and labels aren't too
limited. My concern
was about efficiency and future flexibility.


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


Cool - unless there's a reason, could it be a BIER-related registry that
both the IS-IS work and OSPF work
can refer to?


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

A fairly simple one :-) where there are 3 areas - with the middle being the
backbone.
Have a BFER in each area.  Describe what is advertised by each BFER and
then by
the ABR.


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


Frankly, the language/phrasing was such that I had to stop and think about
it for 5 minutes or so to be
confident that I understood and agreed with what was there.  That's
generally my sign that added clarity
could be useful - but it could just be me or a bad day.



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

Sounds good.

I look forward to getting these from the WG.  If I can put them into IETF
Last Call by the end of the
week, then we can have them on the Oct 26 telechat and hopefully approved
before IETF 100.

Regards,
Alia


> thanks,
> Peter
>
>
>> Thanks,
>> Alia
>>
>
>