Hi Tony, On Tue, Sep 26, 2017 at 11:10 PM, Antoni Przygienda <p...@juniper.net> wrote:
> > > 2) Sec 5.1: This section has concern about restricting the advertisement > of BIER information in IS-IS for scalability - but it doesn't discuss at > all when a router would stop advertising the BIER sub-TLVs. It feels like > the section is hunting for a bit of a manageability or operational > considerations section. I'm not comfortable with the interoperability > issues posed by not indicating what triggers should cause advertisements or > withdrawals. Receiving an advertisement from a BFER seems like a > reasonable trigger to me, since it indicates an active receiver for the > <MT, SD>. > > > > Have to disagree to large extent: > > a) Section is basically saying “it’s outside the scope of this doc > but here’s a couple of hints”. We should probably say “those are all _ > *optional*_ extensions”. We may be better off moving it into “operational > considerations” section, that’s true. > > b) Suggested trigger is possible one but smarter ones are possible, > e.g. a node may know it’s not on any BIER computed tree (SPF or other) and > save memory by not advertising. All that are implementation techniques and > the draft is kind of overspecifying here a bit. > > c) I don’t see how any _*valid*_ trigger will cause interoperability > problems with other possible triggers. > > > > In summary, let’s say “it’s all optional” and generate an “operational > considerations” section with this text? > Sure - that's fine. > 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in > draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, > labels only have to be assigned if they are > going to be used. If a particular BIER domain supports BSLs 256 and > 512, but some SD, say SD 1, only uses BSL 256, then it is not > necessary to assign labels that correspond to the combination of SD 1 > and BSL 512." > > > > > > Actually, I don’t think so. The encaps draft talks about BIER _*domain*_ > doing 256+512 while _*sub*_domain_1 does only 256. The ISIS draft talks > about the _*sub*_domain, i.e. in a subdomain everyone must advertise > enough labels for BSLs they support while in a _*domain*_ each _ > *subdomain*_ may do different things. Observe that we have the future > capability of converting BSLs in a subdomain and it may come handy later > (we can send smaller BMLs if we see lots zeroes or bunch things up together > if we see really small BSLs flying or support BSL migration in a > subdomain). For now we don’t have conversion and with that we may blackhole > if people disagree on the BSLs they support in a subdomain. > Ok - I see the contradiction between the drafts. If ISIS and OSPFv2 both implement it as needing to allocate all the labels, then it's not a tragedy. It would be nice to clean up the wording in Sec 2.1.1.1 of draft-ietf-mpls-encapsulation-08 to clarify that this is just a potential optimization (or simply remove it). > 4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of > the BIER advertisments." This doesn't leave scope for expanding to > inter-area in the future because the issue is not the flooding scope but > rather the distribution. > > > > ? within the scope the BFR-ids must be unique per BFER says it all. I > think that’s consistent with any scope, inter-, intra- or planetary reach … > ;-) > > Ah - sure BFR-ids unique per BFER is fine of course. The flooding scope is less than that. > 5) Sec 6.1: " The sub-TLV advertises a single <MT,SD> combination followed > by > optional sub-sub-TLVs as described in the following sections." > > The figure and field descriptions do not include the MT-ID. There is > clearly the reserved octet intended for that?? > > > > Nope. ISIS MT is built very, very cleanly in this respect, i.e. the TLVs > are all already annotated and provide the MT scope. Hence it doesn’t show > up anywhere here. Did I say ISIS is very, very clean when it comes to MT ;-) > Now you see how long it's been since I looked at MT for IS-IS! Thanks for the correction. > 6) Sec 6.2: This section needs to clearly define the relationship > between the labels and the Set Index in the specified <MT, SD>. It's also > unclear whether it is better to advertise all the labels ever needed or be > able to advertise only labels for a particular sequential number of SIs. > The restriction that only one sub-sub-TLV with the same BitStringLength > makes that impossible (but so does the lack of explicit starting SI). > > > > That goes far back. We agreed to use a set-0-based range covering all > BFR-ids. IGP TLVs are scarce resource and it makes for a much simpler > processing on computation. Labels are not _*that*_ scarce given how many > routers we cover by each label. I don’t think we’ll move that. > Ok as far as advertising all labels - but please add text defining the relationship between labels and Set Index. 7) Sec 6.3: The values for the Length & Tree Type field need to be clearer > after the figure. Also, is Tree Type an IANA-managed field?? I don't see > it in the IANA considerations. Ca it be different between IS-IS and OSPF? > > > > Good catch, needs adding in IANA section. > > > > Another one: > > > > 6.4 is possibly underspecified. It should explicitly state that \cap_C > implies that the router can convert only between _*all*_ the BSLs that it > advertises (and not any arbitrary downstream BSL from it). > That would be helpful. It's quite unspecified as to what it does/can do or how it would be turned on. Thanks, Alia
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
