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



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

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