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

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Sep 2017 18:12:41 -0400

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.

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

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?

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.

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.

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

Thanks,
Alia

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 27 Sep 2017 02:45:09 +0000

Alia,

Thanks, so quick comments:

From: Alia Atlas <[email-masked]>
Date: Wednesday, September 27, 2017 at 6:12 AM
To: "[email-masked]" <[email-masked]>, OSPF List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: early AD review of draft-ietf-bier-ospf-bier-extensions-07
Resent-From: <[email-masked]>
Resent-To: Peter Psenak <[email-masked]>, <[email-masked]>, "(Ice) IJsbrand Wijnands" <[email-masked]>, Andrew Dolganow <[email-masked]>, <[email-masked]>, Jeffrey Zhang <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, September 27, 2017 at 6:12 AM

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.
ad> agree – the way the draft is written is v2 only.  need to address that.

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

ad> Repeating may not be clarifying. How about we say “Variable, dependent on sub-TLVs” to use RFC7684-like text for the Extended prefix TLV. I could not find a single example where we list what sub-TLVs are carried either. That is done – as in this draft – in sub-TLV sections.

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?

ad>set-identifiers provide a scaling for BIER sub-domains based on supported BitString lengths. Conceptually we forward in sub-domains, thus advertising label ranges for a sub-domain (as a base “unit” of forwarding) makes sense. The extra level of granularity would break that sub-domain consistency. Sometimes just because we could provide a higher granularity I do not think we should. This sub-domain granularity makes advertising and processing simpler.

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.

ad> agree this would need to be fixed

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.

ad> again without arguing against diagram, I can only say this text is consistent with other similar paragraphs in other drafts/RFCs (like 7684). I could not find an example when we do put a diagram (but only looked at about 5 OSPF RFCs.

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

ad> I assume you mean 2.2 section, yes MBZ.

Andrew

Thanks,

Alia

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 27 Sep 2017 17:13:03 -0700

inlined into inlines ;-)

On Tue, Sep 26, 2017 at 7:45 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> *From: *Alia Atlas <[email-masked]>
> *Date: *Wednesday, September 27, 2017 at 6:12 AM
> *To: *"[email-masked]" <[email-masked]>, OSPF List <[email-masked]>, "
> [email-masked]" <draft-ietf-bier-ospf-bier-
> [email-masked]>
> *Subject: *early AD review of draft-ietf-bier-ospf-bier-extensions-07
> *Resent-From: *<[email-masked]>
> *Resent-To: *Peter Psenak <[email-masked]>, <[email-masked]>,
> "(Ice) IJsbrand Wijnands" <[email-masked]>, Andrew Dolganow <
> [email-masked]>, <[email-masked]>, Jeffrey Zhang <
> [email-masked]>, <[email-masked]>
> *Resent-Date: *Wednesday, September 27, 2017 at 6:12 AM
>
>
>
> 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.
>
>
>
> 1)      RFC7684 is just for OSPFv2.  How is the information carried for
> OSPFv3? We need a mechanism that works for IPv6 also.
>

+1

> ad> Repeating may not be clarifying. How about we say “Variable, dependent
> on sub-TLVs” to use RFC7684-like text for the Extended prefix TLV. I could
> not find a single example where we list what sub-TLVs are carried either.
> That is done – as in this draft – in sub-TLV sections.
>

+1 RFC7684-like text is good. Allegedly it's tad underspecified (unless you
know other drafts), i.e. it should mention whether TLV header is included
in the length or not. That's the most common implementation disagreement

> ad>set-identifiers provide a scaling for BIER sub-domains based on
> supported BitString lengths. Conceptually we forward in sub-domains, thus
> advertising label ranges for a sub-domain (as a base “unit” of forwarding)
> makes sense. The extra level of granularity would break that sub-domain
> consistency. Sometimes just because we could provide a higher granularity I
> do not think we should. This sub-domain granularity makes advertising and
> processing simpler.
>
>
>

Yes, to keep sub-TLVs compact and computation simple (missing labels would
create complex error criteria) we agreed to base @ SI=0 always and require
that all BFER-ids are covered by the range.

> ad> agree this would need to be fixed

yes, parallel to ISIS draft. Right now missing or value = 0 is SPF. Needs
in IANA section a registry request

>
>
> 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.
>
>
>
> ad> again without arguing against diagram, I can only say this text is
> consistent with other similar paragraphs in other drafts/RFCs (like 7684).
> I could not find an example when we do put a diagram (but only looked at
> about 5 OSPF RFCs.
>
>
>

I don't consider it particularly necessary given it's basically RFC7684
behavior and easily understood by anyone who implemented type-3, type-1
behavior in OSPF. We don't summarize or play any tricks (given the draft
mandates /32 and N bit).

> ad> I assume you mean 2.2 section, yes MBZ.

yepp, needs adding

Ultimate observation: We should add that if the BML translation TLV is
present, it indicates that the node CAN translate between all BMLs it
advertised itself in SD and NOT all possible downstream BMLs. Important
clarification if we end up running multi-BML computations or a BFER has to
decide which BML to inject in a mix environ (doesn't look like we go there
but it's better be safe than sorry and it's a small addition making the
spec water-tighter).

Overall, stuff doesn't look like any major items popped up and too much
work overall. Given Les made noises to rev ISIS BIER towards start next
week I'm sure Peter as editor of OSPF BIER doesn't want to be bested
(nudge, nudge ;-P

--- tony