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

Antoni Przygienda <> Wed, 27 September 2017 03:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99F161320D8; Tue, 26 Sep 2017 20:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 G7ajaAaoyWcr; Tue, 26 Sep 2017 20:10:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62E8B1326ED; Tue, 26 Sep 2017 20:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UCPeY/XiXShef450FVUaQmhe/32EamJq6cCILMdV4Tk=; b=VVfp9srjlbiCaXJJQG+grKluI3Nb7xTEDJTiCa1EgWqTz0gjTvWrEc9MFCExdId8SWmU3wMTn0p2VJ3GX1zwI8DuCYqLDMDedpFcgcD4rvtPumyzoIsvfsreZMvH//oDeRb5crBZ1dPPdNVJagOy9ccvSWUMeSfsVZJXy19v75E=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Wed, 27 Sep 2017 03:10:25 +0000
Received: from ([fe80::44f9:85fe:ebae:1d90]) by ([fe80::44f9:85fe:ebae:1d90%13]) with mapi id 15.20.0077.016; Wed, 27 Sep 2017 03:10:25 +0000
From: Antoni Przygienda <>
To: Alia Atlas <>, "" <>, "" <>, "" <>
Thread-Topic: early AD review of draft-ietf-bier-isis-extensions-05
Thread-Index: AQHTNxx9cAv4l1sQ5UqmujPSGH/jaKLHmMAA
Date: Wed, 27 Sep 2017 03:10:25 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1440; 6:SF2GBg2CuPbBlxRucn4Wp1JRoxYuFkEvQ3jDyGkIcSewtngr6arjJSYsihZdX0g2h6GfINw/oYww4nKgjuPlt/idwRlvRlIiHVejeuxusxQ7Php90RC2qjAbf2LYe0U6AQ5o2qiTJPw47GG3pVVjbQ03BjCGUnZOKRyKTnRatjmUrZg8tWp23uDD13MCbXgUJFd7Y7b7KD+6GkBZHpbjc0AQCEWKLZFxynhFupMFyB9ixKdqRbCDgmZi0YqKBsDbwLd7RTp2btMEqK36pxPK22pG+Kbdgt4CroC09XcadhaIRcgrcf4EAtKo7oNXNZfOK7DlZASO5hSWUZvu3SPV2w==; 5:nI1cFbEwE0jOoE7PtbpJHBReGuta0aOkFD/bJc6E0r5dwXSdX/xQPWPxtRDX/bjupWWVPJqIwNuFzIt8cCDi+t0M9t9byEho0gbDDUTji8IUglKy5AkWWalG+jiSYeNNPnfjUiHjgxU4lObmvD6/8w==; 24:AnieWFsolfNMnyHTVBKRJVItNJ0UIP7sgPSIu2qIWgbf969782TjLCnIie6BF5afUTGdeiWW+2UPWq0z7ASWbtGaREbA6FJ7aeJf11rFRbw=; 7:fWhFk+N6y9b6QCxtVRn4IeXQBi98ppUSb9cX9okGqiOmN1NH7jL3dXowUFPdaFtcLbxr2Murjzs0RJ4ka373tfFGdMeymKBdv2fp0vOiUhK6YEZP60obAauAtBjFjqe8Facyx0viUKeVIvuPZqdQNeRtmoRZaZd5Y4B9UKqBphK+fdZQN3PHvF/nckKEVJJAHvsjXqny2BqPF4B2/BqB57ITBABo/iy+puCHrXF3Xmc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 48ec5bde-d2d7-42d8-f60a-08d505554c2d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0501MB1440;
x-ms-traffictypediagnostic: DM2PR0501MB1440:
x-exchange-antispam-report-test: UriScan:(190756311086443)(21748063052155);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0501MB1440; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0501MB1440;
x-forefront-prvs: 04433051BF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(51444003)(189002)(199003)(106356001)(229853002)(58126008)(82746002)(7736002)(33656002)(53936002)(14454004)(25786009)(2900100001)(6486002)(6436002)(54896002)(3280700002)(36756003)(6116002)(105586002)(39060400002)(76176999)(54356999)(3846002)(99286003)(189998001)(6306002)(6512007)(102836003)(5660300001)(6506006)(101416001)(2201001)(50986999)(2906002)(97736004)(478600001)(110136005)(2950100002)(2501003)(3660700001)(8676002)(83716003)(83506001)(5250100002)(68736007)(316002)(66066001)(86362001)(8936002)(6246003)(230783001)(81156014)(81166006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1440;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0E80CAB4D7694912B43299E48CC92143junipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 03:10:25.0764 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1440
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: Wed, 27 Sep 2017 03:10:29 -0000

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?

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.

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 … ;-)

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

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.

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