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

Alia Atlas <akatlas@gmail.com> Mon, 02 October 2017 14:21 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B37134654; Mon, 2 Oct 2017 07:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkXahFgjPeQ8; Mon, 2 Oct 2017 07:21:45 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50A5134660; Mon, 2 Oct 2017 07:21:40 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id k62so4074470wrc.9; Mon, 02 Oct 2017 07:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.223.196.199 with SMTP id o7mr500760wrf.119.1506954099214; Mon, 02 Oct 2017 07:21:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.193.68 with HTTP; Mon, 2 Oct 2017 07:21:38 -0700 (PDT)
In-Reply-To: <0E80CAB4-D769-4912-B432-99E48CC92143@juniper.net>
References: <CAG4d1rcBQDVQBYJ3nu8S4t_u_90UaCBR_KYVErO=dwz=3KRFzQ@mail.gmail.com> <0E80CAB4-D769-4912-B432-99E48CC92143@juniper.net>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 2 Oct 2017 10:21:38 -0400
Message-ID: <CAG4d1rfGizyYtRH=y4YFbx0=RKW5fEC4VhCJQCDFqeDa-Fx0+Q@mail.gmail.com>
To: Antoni Przygienda <prz@juniper.net>
Cc: "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-bier-isis-extensions@ietf.org" <draft-ietf-bier-isis-extensions@ietf.org>
Content-Type: multipart/alternative; boundary="f403045fa464c6eba0055a911748"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/lUgzpfaxxANrhIWyxfd2LqASq0Y>
Subject: Re: [Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=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 <prz@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