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

[Tony Przygienda <[e-mail]>]

On Mon, Oct 2, 2017 at 7:21 AM, Alia Atlas <[e-mail]> wrote:

> 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.
>

*ok, action item would be "move 5.1 into operational considerations and
explain it's optional" *


>
>
>> 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).
>


*I read the 2.1.1.1 and honestly, it is pretty clear. We can remove it but
I find it helpful as a "hint, hint, nudge, nudge" to implementors. It has
no normative language. I don't see a way to improve it much and the
alignment between OSPF and ISIS here is IMO not worth bothering with. It's
optional operation technique*


>
>
>> 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.
>

*Flooding scope in OSPF was AD (if we choose to advertise type-3s). In ISIS
(which is being worked on) it's leaking so the leaking determines the
scope. *


>
>>  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.
>

*I thinks OSPF is very clear: *

*"The size of the label range is determined by the number of Set*

*      Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture
<https://tools.ietf.org/html/draft-ietf-bier-ospf-bier-extensions-07#ref-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."*


*As action item I agree we should add equivalent section to ISIS. *



>
> 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.
>
>
*We have two cases here:*

*1) SPF types. We have to specify the TLV today so in the future new tree
types will be deployable. Normally ISIS just ignores unknown TLVs but in
this case it will have to understand that tree types are mismatched and
remove itself from domain (or ignore routers with different tree types,
same thing). I think the text is good there. *
*2) With BML Conversion you're actually hitting on something. Old routers
can ignore it (in case it comes in the future) so we can actually rip this
section out completely. My bad. I don't go into details why new SPF with
BML conversion will be fine even if old routers don't understand the BML
capability and ignore it. *

*Action item suggested for OSPF & ISIS. Remove the section on "*Optional
BIER sub-domain BSL conversion sub-sub-TLV*"*