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

Alia Atlas <> Mon, 02 October 2017 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9B37134654; Mon, 2 Oct 2017 07:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HkXahFgjPeQ8; Mon, 2 Oct 2017 07:21:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D50A5134660; Mon, 2 Oct 2017 07:21:40 -0700 (PDT)
Received: by with SMTP id k62so4074470wrc.9; Mon, 02 Oct 2017 07:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aFhG8ZLrZo4Fu28VW5XKpxlrVkvbcwlQWmwlz08NLio=; b=c9+wdwi03HnSRvx1Q/8944Zs5AR+CV3QUVvE1tg6tJR39+yMGQJANejVxWrekXmEd4 x7MxQlnr3YQGxqvuA+b0FTB3Do0d6GGLDVpntDKNXP31pZur7aPsiZkKQBFScdCsOyiM CMlMA/6686KFZ9EFiVQ+sX8kLKZAUDsYWPc6K+AteDWeQZRygtWDT6ryaZMPCxQkH4Zl +BhjX/7hgyX0GyfAsgmxTXhAyhgkJo6zzaMo+c9y4V9TjJRukgsX5Tw7MUS9fBstcI/u ARxECN3A9YeA9vcOnPF7lNC9X5tFu9S15dx0Ws1QTrcnd0knl47V9bf7fa0xRhmwUz8a 0abA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aFhG8ZLrZo4Fu28VW5XKpxlrVkvbcwlQWmwlz08NLio=; b=H/W1zaQrd920bvyfFuWInFYl7v194aniyWDaJukEOmDaLVaoqx2vESCaNqGSOCkteF HJuoPHcLDFUzfUAb+VtXmjdkhn6OdN+MPLqgTFC4+FdMf4+cRKT4LmGJZ0G9iyUKBud3 PZog+FckVkQBNsijmGjafLj0tggc3hFvrcSgsBNyXbLBuWeHWzuA90x4QQQrSvUyjhip Y8/cnCQafncsHFexVd2eJY0rp0qVjHNuUvv9jM9Ne71ijEbhqX9D/L7OJsoHPV62xPlx RkLOk/qYfsYtI8i0raG8t0NAsO7Alh3Xl/Tp1yoojtIc2r+oGXlJkqBYWeSIzaIk9eiz J3ww==
X-Gm-Message-State: AMCzsaVGW9zJbCgsiW72Puuuicsx211kGR5k7WyCjQ9xPGso4I565LBb XErxrS5OWRnFqojMx1X4BXHJTO/BRkufWDMMzwC0Ww==
X-Google-Smtp-Source: AOwi7QAiD10ldmtGJU+PpRfA+3b+FGTQ4kZdo56YhLUEeVhbhY1u/ZSTrpz59ULjRrTCYBOFMVijc7Wo4LYVIwShGlY=
X-Received: by with SMTP id o7mr500760wrf.119.1506954099214; Mon, 02 Oct 2017 07:21:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Oct 2017 07:21:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Alia Atlas <>
Date: Mon, 2 Oct 2017 10:21:38 -0400
Message-ID: <>
To: Antoni Przygienda <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="f403045fa464c6eba0055a911748"
Archived-At: <>
Subject: Re: [Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Oct 2017 14:21:48 -0000

Hi Tony,

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