Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06

Chris Bowers <> Thu, 27 October 2016 12:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E98A4129449 for <>; Thu, 27 Oct 2016 05:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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 IzvX33nnEdM5 for <>; Thu, 27 Oct 2016 05:51:21 -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 5F1D41294C9 for <>; Thu, 27 Oct 2016 05:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rvydlBckzW/sefYCo8WZP086oYfICHa9wb1hnp9hTKI=; b=Se+3ZqFsXCXKcKKT4EPXOhrBUia4AnOWduxQm8e+tO7tS9M5raUdRSUvJHxasC3j0tJ6gNJ+Quv9PWcM0DljX0iC3f/RRouG7wMhvhdyLWXrUW8KstpU7T+G58jCfUJyYMWaF2S7RHuDJ+sVNQXwqoPP0ftQ/daciAVYoWcYdJE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 12:51:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.0679.015; Thu, 27 Oct 2016 12:51:19 +0000
From: Chris Bowers <>
To: David Lamparter <>, " list (" <>, "" <>
Thread-Topic: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
Thread-Index: AQHSKYc86FF4oumBi0W1MElku2Gyc6C8KTvw
Date: Thu, 27 Oct 2016 12:51:19 +0000
Message-ID: <>
References: <20161018213247.GQ639535@eidolon>
In-Reply-To: <20161018213247.GQ639535@eidolon>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: b6616ef5-b4d1-4403-b9e1-08d3fe67f29f
x-microsoft-exchange-diagnostics: 1; MWHPR05MB2832; 7:byDzlbgN605PleWPJclWmCaGMDKyrEXpbukVkO78Z4iCSTQ5Apz6o4VWbUibBg0BmwvBfQLv+RdaTgDw3Z/MopkwVpxebCqFRk5rBR90qBT3Phf4qKYxQZE3j+NjUQO+D5z/eYub97dZmqKHEJ2sKM5T5pQ0UaJkzf58jng15ccAynYWEFsP2Z9/ifd6fFV3aIv6IX+uCLyB2CE38NyS2BNhVshsbpFvzQngZ9goYOEs8T+WDi3Wy7d+YvmXKETNeo3PyyhOuNjx3TjfVFd2UaJZj2IBzylB6hgFci7oQVzBu60p/X20cn4zXOG9ltAJyEJLRvTV5fC9NA9nX7PA2oJx5uenOHbhcpdjHDwDAX8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB2832;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR05MB2832; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2832;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(86362001)(66066001)(33656002)(99286002)(54356999)(106116001)(106356001)(105586002)(101416001)(50986999)(76176999)(230783001)(19580405001)(19580395003)(7696004)(2950100002)(3660700001)(3280700002)(11100500001)(5660300001)(2906002)(81156014)(81166006)(2501003)(10400500002)(7736002)(7846002)(74316002)(305945005)(102836003)(4326007)(6116002)(3846002)(586003)(122556002)(87936001)(9686002)(68736007)(8936002)(92566002)(77096005)(5001770100001)(5002640100001)(97736004)(2900100001)(15975445007)(76576001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2832;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 12:51:19.3231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2832
Archived-At: <>
Cc: "" <>
Subject: Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 12:51:26 -0000


I have two main comments/questions on this.

1)  If I understand correctly, one reason to use existing multi-topology routing mechanisms for 
this is the requirement to support deployments where only a partial subset of 
routers support source address dependent routing.  Ideally, this would allow an enterprise site to
start by upgrading a subset of routers to support SADR, starting at the site egress routers.  

However, this statement from section 2.3 seems to imply that all of the routers in the enterprise network
would need to support multi-topology even if they don't support SADR.  

   As this compatibility mechanism is not considered optional, M-ISIS
   MUST therefore be implemented for supporting the protocol outlined in
   this document.  Even installations that previously used only MTID 0
   (i.e.  no M-ISIS) would need to start using MTID TBD-MT0.

It would be good to clarify this statement.  I interpret it to mean that all prefix advertisements
to use TLV#237, so that even routers that are currently using TLV#236 to advertise IPv6 prefixes
would need to start using TLV#237 instead.  But it is not clear what MT-ID a router not supporting
SADR should use when advertising a prefix in TLV#237, since it can't use MT-ID=0.

In any case, it would be good to clarify overall if and how this solution achieves the goal of 
requiring only a subset of routers to be upgraded from a basic non-MT deployment of ISIS.  
As part of this, it would be good to explain how TLV#222 and TLV#229 (the other multi-topology
TLVs) are used in the partial deployment case.

2)  For addressing PA multi-homing for IPv6 w/o NAT in existing enterprises,  I would 
guess that >90% of enterprises running a link-state routing protocol are running 
OSPF as opposed to ISIS.  Is the expectation that enterprises will switch to ISIS 
in order to address this problem?   I would like to better understand what use cases this work 
is targeted at from a practical point of view.


-----Original Message-----
From: Isis-wg [] On Behalf Of David Lamparter
Sent: Tuesday, October 18, 2016 4:33 PM
To: list ( <>;
Subject: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06

Hello IS-IS wg,

I'd like to request/suggest WG adoption of



which describes the IS-IS bits of source/destination routing and would also like to head for early-allocation[*] of codepoints and MTID values (all marked "TBD" in the document).  The rtgwg counterpart, draft-ietf-rtgwg-dst-src-routing[-02], was adopted by rtgwg a year ago.

I'm also unaware of any IPR related to this draft, responding "no" to the boilerplate according to RFC 6702 Appendix A.3 :)

The -06 version is identical to -05 except for updating Fred's author block.  I don't expect significant changes in protocol operation and am unaware of open feedback in that direction (thus also the early-allocation request).

As there haven't been any changes I'm unsure whether I should re-present the document; it'd probably end up being a repeat wasting people's time but I'd be happy to bring it up...



[*] early-allocation seems to not apply for blocks under "Expert Review"
    procedure, not sure if there is a process there?

Isis-wg mailing list