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

[Peter Psenak <[e-mail]>]

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.

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.

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


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

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

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