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

[Alia Atlas <[e-mail]>]

Hi Acee,

On Tue, Oct 3, 2017 at 10:56 AM, Acee Lindem (acee) <[e-mail]> wrote:

> Hi Alia,
>
> I spoke to Peter and I think the OSPFv3 Bier Extensions should go into a
> separate OSPFv3 draft. Heretofore, all the work has been done in the BIER
> working group and it seems it would make sense to do it here rather than
> mix much into the overflow draft. As for the OSPF WG, the priority needs to
> be to publish the OSPFv3 Extended LSA draft. I’ll ask Abhay to start the WG
> last call and concurrently post the implementation information.
>

Ok - that works for BIER.  For OSPF, getting that draft done will help a
great deal with enabling feature parity for IPv6.

Thanks for all your work on it.

Regards,
Alia


> Thanks,
> Acee
>
> From: Alia Atlas <[e-mail]>
> Date: Monday, October 2, 2017 at 2:32 PM
> To: "Peter Psenak (ppsenak)" <[e-mail]>, Acee Lindem <
> [e-mail]>
> Cc: "[e-mail]" <[e-mail]>, OSPF WG List <[e-mail]>, "
> [e-mail]" <draft-ietf-bier-ospf-bier-
> [e-mail]>
> Subject: Re: early AD review of draft-ietf-bier-ospf-bier-extensions-07
>
>
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>