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

[Alia Atlas <[e-mail]>]

On Mon, Oct 2, 2017 at 2:26 PM, Peter Psenak <[e-mail]> wrote:

> Hi Alia,
>
> please see inline:
>
> On 02/10/17 17:33 , Alia Atlas wrote:
>
>> On Mon, Oct 2, 2017 at 11:07 AM, Peter Psenak <[e-mail]
>> <mailto:[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]>
>>         <mailto:[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.
>>
>
> would stating in this document that OSPFv3 BIER extension will be covered
> in a separate draft help?


It would need more than that.  Let's see what Acee thinks is a reasonable
approach.
My tendency would be to reference the draft that is collecting OSPV3
Extended LSA TLVs - but I'm not
sure if that draft is still merely conceptual.


>         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.
>>
>
> ok, I define it here.
>

Sounds good.  Thanks!

Alia


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