Alia,
Thanks, so quick comments:
From: Alia Atlas <akat...@gmail.com>
Date: Wednesday, September 27, 2017 at 6:12 AM
To: "b...@ietf.org" <b...@ietf.org>, OSPF List <ospf@ietf.org>,
"draft-ietf-bier-ospf-bier-extensi...@ietf.org"
<draft-ietf-bier-ospf-bier-extensi...@ietf.org>
Subject: early AD review of draft-ietf-bier-ospf-bier-extensions-07
Resent-From: <alias-boun...@ietf.org>
Resent-To: Peter Psenak <ppse...@cisco.com>, <naiku...@cisco.com>, "(Ice)
IJsbrand Wijnands" <i...@cisco.com>, Andrew Dolganow
<andrew.dolga...@nokia.com>, <p...@juniper.net>, Jeffrey Zhang
<zzh...@juniper.net>, <aldrin.i...@gmail.com>
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.
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.
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.
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?
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
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
