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

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Oct 2017 10:21:38 -0400

Hi Tony,

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

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 2 Oct 2017 09:50:38 -0700

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

>> *optional*_ extensions”. We may be better off moving it into
>> “operational considerations” section, that’s true.
>>
>> c)      I don’t see how any _*valid*_ trigger will cause
>> interoperability problems with other possible triggers.
>>
>>
>>

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

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

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

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

>> 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*"*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 22 Oct 2017 07:16:38 +0000

Alia –

A new version of the draft has been posted which addresses your comments.

Sorry this was  not completed as quickly as you hoped, but reviewing the comments/changes led to some lively discussion among the co-authors – it took us a while to reach consensus on the changes.

Some responses inline.

From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, September 26, 2017 4:09 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: early AD review of draft-ietf-bier-isis-extensions-05

I have done an early AD review of draft-ietf-bier-isis-extensions-05 in preparation for receiving a request to publish it. First, I would like to thank the authors - Les, Tony, Sam and Jeffrey - for their work on this document.

In my ideal timing, this draft would be updated and ready for IETF Last Call by Oct 5 so that it could reach the IESG telechat on Oct 26 with draft-ietf-bier-mpls-encapsulation and draft-ietf-bier-ospf-bier-extensions. It would be great to have 4 drafts approved for RFC publication - or even some RFCs!  If we can't make this timeline, then it'll add at least a month or more.

I do see a number of issues to be addressed.

Major:

1) Sec 4.1: "At present, IS-IS support for a given BIER domain/sub-domain is
   limited to a single area - or to the IS-IS L2 sub-domain."
   Why is there this limitation?  Having just reviewed the ospf draft, the detail needed to handle inter-area seems straightforward there.  It'd be a pity to have different support in ISIS and OSPF...
I didn't see anything about such a limitation in the bier-architecture or bier-mpls-encapsulation drafts, so I'm startled to see it here.

At the very least, some explanation of why IS-IS can't handle inter-area and the implications for deployments is needed.

In Sec 4.2, this is enforced by "BIER sub-TLVs MUST NOT be included when a prefix reachability
      advertisement is leaked between levels." but I don't see any reasoning for why the BIER sub-TLVs couldn't be included...

[Les:] We have removed the restriction.

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

[Les:] This section has been removed.

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

[Les:] I believe this comment was resolved in the exchange between you and Tony.

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.

[Les:] Similarly, this was resolved in the email thread.

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

[Les:] Tony has already pointed out that the parent TLV has the MTID.

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

[Les:] Some clarifying text has been added.

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?

[Les:]  As you will see, we have deleted the tree type sub-TLV altogether. In its place we inserted a BIER Algorithm (BAR) octet in the BIER Info sub-TLV (replacing the “Reserved” field).  Equivalent changes will be forthcoming in the OSPF draft so the two drafts will remain aligned.

Minor:

a) Sec 2: "Invalid BFR-id: Unassigned BFR-id, consisting of all 0s."
A clearer definition might be "Invalid BFR-ID: The special value of 0 - used to indicate that there is not a valid BFR-ID"  The same comment applies to "Invalid BMP".

[Les:] Done.

b) Sec 5.7:  Please add some text about dampening the reports of misconfiguration - as usual.

[Les:] Done

Nits:

i) Sec 5.1: "supported bitstring lengths MLs "  All the other BIER drafts use the acronym  BSL (BitStringLength).  Consistency is frequently useful for clarity.

[Les:] As this section was removed the issue no longer exists.

ii) Sec 6.2: "Length: 1 octet."   Please specify the value!

[Les:] This sub-TLV was removed, so again the comment no longer applies.

   Les

Regards,
Alia

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 22 Oct 2017 16:24:23 +0000

Les, thanks for the work.

Alia, given some of the changes is a 7 days limited (i.e. only pertaining to changes introduced) WG LC appropriate?

--- tony

<[email-masked]<mailto:[email-masked]>> spake:

Alia –

Some responses inline.

Major:

Minor:

[Les:] Done.

[Les:] Done

Nits:

   Les

Regards,
Alia