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

From: Peter Psenak <[email-masked]>
Date: Mon, 02 Oct 2017 16:05:15 +0200

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.

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

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

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

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

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.

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

thanks,
Peter

> Thanks,
> Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Oct 2017 10:41:20 -0400

Hi Peter,

On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <[email-masked]> wrote:

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

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.

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

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

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

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

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

> 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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 02 Oct 2017 17:07:35 +0200

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Alia,
>
>     please see inline:
>
>
>     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
> 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.

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

>     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

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.

> both the IS-IS work and OSPF work

right, that make sense. In such case, it should be defined outside of 
IGP BIER drafts, shouldn't it?

> A fairly simple one :-) where there are 3 areas - with the middle being
> the backbone.
>     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

let me try.

thanks,
Peter

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

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Oct 2017 11:33:58 -0400

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

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

> not that I disagree, but let's not get into that discussion here :)

Just calling your attention to the current atmosphere :-)

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

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

Thanks,
Alia

---

From: Peter Psenak <[email-masked]>
Date: Mon, 02 Oct 2017 20:26:13 +0200

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 <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hi Alia,
>
>              please see inline:
>
>
>     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
>     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?

>                  2) In Sec 2.1, the Length is defined as variable and
>         the figure
>                  includes
>     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
>                          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
>     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

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

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Oct 2017 14:32:06 -0400

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

>>                  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
>>                  the shepherd can explain to me privately the deep
>> technical
>>                  contribution
>>                  made by each author.
>>
> 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.

>>                  additional sub-TLVs. Please clarify in the text what
>> other
>>                  sub-TLVs can
>>                  4) Sec 2.3: The Tree type is a 1 octet value - that
>> doesn't
>>                  appear to

Sounds good.  Thanks!

Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 3 Oct 2017 14:56:21 +0000

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.

Thanks,
Acee

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 2, 2017 at 2:32 PM
To: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: early AD review of draft-ietf-bier-ospf-bier-extensions-07

On Mon, Oct 2, 2017 at 2:26 PM, Peter Psenak <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi Alia,

    please see inline:

        Hi Peter,

        On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:

             Hi Alia,

             please see inline:

                 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.

                 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.

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.

                 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.

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

                 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?

ok, I define it here.

Sounds good.  Thanks!

Alia

thanks,
Peter

             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.

    let me try.

Thanks,
Alia

    thanks,
    Peter

                 Minor:

        Sounds good.

        Regards,
        Alia

             thanks,
             Peter

                 Thanks,
                 Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 3 Oct 2017 10:59:03 -0400

Hi Acee,

On Tue, Oct 3, 2017 at 10:56 AM, Acee Lindem (acee) <[email-masked]> 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 <[email-masked]>
> To: "Peter Psenak (ppsenak)" <[email-masked]>, Acee Lindem <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>, OSPF WG List <[email-masked]>, "
> [email-masked]" <draft-ietf-bier-ospf-bier-
> [email-masked]>

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 3 Oct 2017 15:51:49 +0000

I spoke to Peter and I think the OSPFv3 Bier Extensions should go into a separate OSPFv3 draft.

+1 …

--- tony