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

[Alia Atlas <[e-mail]>]

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

> Hi Alia,
>
> please see inline:
>
> On 02/10/17 16:41 , Alia Atlas wrote:
>
>> Hi Peter,
>>
>> On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <[e-mail]
>> <mailto:[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.
>>
>
> given that the encoding of the OSPFv3 is way different to OSPFv2 and the
> fact that the draft-ietf-ospfv3-lsa-extend is still a work in progress I
> would tend to keep the v2 and v3 extensions separate.
>

Given the second, that's ok - but usually the difference in encoding isn't
enough to require a different draft.
Please do talk to Acee about this. He's collecting OSPFv3 LSA extensions to
add to a separate draft when
draft-ietf-osfpv3-lsa-extend progresses - and that draft is just waiting on
the implementations (and there are
finally 2 of them) so I expect it to move along soon.


> When you say "discuss the IPv6 support in the write-up" do you mean to
> mention it in draft-ietf-bier-ospf-bier-extensions? If yes, why? This
> documents only specifies OSPFv2 extension.


No - I mean in the shepherd's write-up - though an informative reference to
an OSPFv3 draft or a common one would help.  At the moment, there's NOTHING
about IPv6 and that's going to make it harder to get IESG agreement on.


>
>> 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.
>>
>
> not that I disagree, but let's not get into that discussion here :)


Just calling your attention to the current atmosphere :-)


>         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.
>>
>
> not that I care too much, but I would like to keep the language same
> between documents. Unless you insist otherwise, keeping the "Variable,
> dependent on sub-TLVs" would make it consistent with other docs.


Well, I don't deeply care either (beyond bike-shed painting) - but there is
content to the TLV so it has length to be included in the calculation.


>         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?
>>
>
> right, that make sense. In such case, it should be defined outside of IGP
> BIER drafts, shouldn't it?


It's ok to have it here.  This is a BIER WG draft and it isn't needed until
this or the ISIS one.
Either can work.  It could be in the mpls-encap draft, but that's ready for
IETF Last Call and it isn't
used there - so it would need more explanation.


>         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.
>>
>
> let me try.
>

Thanks,
Alia


> thanks,
> Peter
>
>
>
>
>>
>>         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
>>
>>
>>
>>
>