inlined into inlines ;-)
On Tue, Sep 26, 2017 at 7:45 PM, Dolganow, Andrew (Nokia - SG/Singapore) < andrew.dolga...@nokia.com> wrote: > 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. > > > +1 > 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. > +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 > > > 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. > > > 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. > 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 > 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). > 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. > > > 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
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
