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

"Les Ginsberg (ginsberg)" <> Sun, 22 October 2017 07:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABC45137054; Sun, 22 Oct 2017 00:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.619
X-Spam-Status: No, score=-12.619 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lqkmpOYcytnR; Sun, 22 Oct 2017 00:16:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F7B1136F5A; Sun, 22 Oct 2017 00:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=29442; q=dns/txt; s=iport; t=1508656601; x=1509866201; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RLDD+bcFIa12EJnyVlamuCgQ/Ca+d12MvhwMsJNB7ZU=; b=Lpde2g+qaoW4Y7WfCEMJinwjjvT8WZYZChgq4MoZ6lSi6YiRuZjt73pg 8Q5FLReZNX+9ILnMdDCxzwoX1okiHmNJoy1hCk7djKpEmnWMp1oF1/joN taBGSve/sZ69qtBWbbJpkt4D2JWbRA9shlU4qrqtclyOB//OhrSue+EBb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAD6ROxZ/40NJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5CLmRuJweDc4ofjz6BeohLjW4QggEKhTsCGoQiPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUdAQEBAQMjCkUXAgEIDgMBAwEBIQcDAgICHxEUAwYIAgQBEgiJNEwDF?= =?us-ascii?q?ap3gieHLg2DWQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DLoIHgVCBaAGCHYENgl6?= =?us-ascii?q?BdAELBwEHJhgQAoJcgmEFmHGIOTwCj3mEcIIehXqLEo0MiEMCERkBgTgBHziBA?= =?us-ascii?q?1h6FYMtglwcgWd2iB8PGIEMgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,415,1503360000"; d="scan'208,217";a="310784368"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2017 07:16:39 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9M7GddR008726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Oct 2017 07:16:39 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 22 Oct 2017 02:16:38 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Sun, 22 Oct 2017 02:16:38 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alia Atlas <>, "" <>, "" <>, "" <>
Thread-Topic: early AD review of draft-ietf-bier-isis-extensions-05
Thread-Index: AQHTNxx+v5jDaHzT9U67nRv4Be9ON6LvmeHg
Date: Sun, 22 Oct 2017 07:16:38 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_897c30c09e00424a8fcced735162bf97XCHALN001ciscocom_"
MIME-Version: 1.0
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: Sun, 22 Oct 2017 07:16:43 -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 []
Sent: Tuesday, September 26, 2017 4:09 PM
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.


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


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


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.