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

Alia Atlas <akatlas@gmail.com> Tue, 26 September 2017 23:09 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CE134499; Tue, 26 Sep 2017 16:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5zYqF698LnnA; Tue, 26 Sep 2017 16:09:16 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 53CB413202D; Tue, 26 Sep 2017 16:09:13 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id m72so12598585wmc.1; Tue, 26 Sep 2017 16:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XMFJjiAeFHmH8hcn3QUGUsigL/tZeZ3VKuFBrzak85Q=; b=MpahHf6/7yK76hAL0+WDn0Qk0fG7W0/zFGAw5CbqMo1khxbxlhORZy9uRVd0Vjj3xr vCi8xr/bkmb2wi1ozqDA3+sjGTCmfQchMCwjSeiRPqC4B7aTMrn+IVznbDqQLZzWkII/ OChg12OtYQm9dVFe16Y4sA6HhxUor+Ees463ndYT9Lw8qNrLrYkIfKUKFMuPmXwOolcl jUma79Bld83wQEUhNtUMfLnJ6lXxPsf9Pri/Y5e4CgwQEhsl0EKS3vqZfbXoecGT30Dm 73F+zJ14OcFiK60RttUctjXULtEviYaBchJH46Ffaf5zs7j58rL84BvmsuI/OKSN102R qNug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XMFJjiAeFHmH8hcn3QUGUsigL/tZeZ3VKuFBrzak85Q=; b=B2PdP7Oefdmy1CQhmrtIuy+6kIlIt/tgw8lU6XPcOZr8msU4p/9srG3KNoGv9btzry uxdjJoGtaaskgF33CuvHOlQW2xdwQZSI0PeX2kJ6xGM+5mWCis0HbdCMwiBwQQrkzSfX Qs45JYFZ+kHQmHI2QBKy0zyFBlJzsiAVK6Ub5Jlovv1PXc3c815VXhMuMHecNJ+vY87p TvNybYCB03JlbNyOMDG+ZxQh+MJPJs470HAtB+94BWLOpA8jz0v5FXajigelkvLo/T15 PWquleDojvTzy94B2D7OauuatUNoxcvqUtpzibh1lp/UL/p70oTFEpWF99UUiOvwImXQ 4KVw==
X-Gm-Message-State: AHPjjUhVi4rGboyrkrE7vdIs/D4O8+d01WikudvsqeypBh4nrMyDmuRb JtsBA0Smv3m/kBctegPbBKOfWuwSYVKejJq2jbjQI67N
X-Google-Smtp-Source: AOwi7QDD7AXP3JMoY5/qpO4asDit9Jf9edYxIbF5Z3iAoPrl1mXJTqKLUx3t5oeDMwZAyEoWvo9VHNi3SE6s6s8f03k=
X-Received: by with SMTP id 201mr3896404wms.135.1506467351476; Tue, 26 Sep 2017 16:09:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Sep 2017 16:09:11 -0700 (PDT)
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 26 Sep 2017 19:09:11 -0400
Message-ID: <CAG4d1rcBQDVQBYJ3nu8S4t_u_90UaCBR_KYVErO=dwz=3KRFzQ@mail.gmail.com>
To: "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, draft-ietf-bier-isis-extensions@ietf.org
Content-Type: multipart/alternative; boundary="001a1145b02c59be6c055a1fc3e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/plMVR_JcA5Y35LwttHTrMzEMVlM>
Subject: [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: Tue, 26 Sep 2017 23:09:18 -0000

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

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.


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

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

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

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

5) Sec 6.1: " The sub-TLV advertises a single <MT,SD> combination followed
   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??

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

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?


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

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


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

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