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
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
