Re: [Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05

[Alia Atlas <[e-mail]>]

Hi Tony,

On Tue, Sep 26, 2017 at 11:10 PM, Antoni Przygienda <[e-mail]> 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