Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions

Uma Chunduri <> Thu, 21 May 2015 17:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09C791A00D6; Thu, 21 May 2015 10:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S3E-0wpxhGe9; Thu, 21 May 2015 10:56:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 474A51A006B; Thu, 21 May 2015 10:56:06 -0700 (PDT)
X-AuditID: c6180641-f79086d000001909-77-555db75406a9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 66.EC.06409.457BD555; Thu, 21 May 2015 12:45:41 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Thu, 21 May 2015 13:56:03 -0400
From: Uma Chunduri <>
To: "Stefano Previdi (sprevidi)" <>, Hannes Gredler <>
Thread-Topic: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQk9NU/0F/+gVeL0qCCi1USeL23J2G5gUA///PohA=
Date: Thu, 21 May 2015 17:56:03 +0000
Message-ID: <>
References: <20150507120728.GB3896@hannes-mba.local> <> <20150514195127.GB26771@hannes-mba.local> <> <20150518131042.GA37696@hannes-mba.local> <> <20150520162058.GE55346@hannes-mba.local> <> <20150521132647.GB62835@hannes-mba.local> <> <20150521143425.GA63432@hannes-mba.local> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXSPn27o9thQg5+rmCz67z1hszh66D2r xfrdj5gsjl/4zejA4jHl90ZWjyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CV8enWZPaCXvWK rrOCDYxP5boYOTkkBEwk3u7Yygxhi0lcuLeerYuRi0NI4CijRM/XTnYIZzmjxNfd05hAqtgE 9CQ+Tv3JDmKLCMRIbLp7DMxmFgiVuL/iP5gtLBAi0TX5F1RNqMS6xl2MELaVxMoVz1hBbBYB VYlpR6aAzeQV8JU4t2gH1LJHLBIPLpwDa+AUsJXYsnsimM0IdN73U2uYIJaJS9x6Mp8J4mwB iSV7zkO9ICrx8vE/VghbUWJf/3So43QkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKkaO0OLUsN93IcBMjMIqOSbA57mBc8MnyEKMAB6MSD++C0zGhQqyJZcWV uYcYpTlYlMR5L6qGhAoJpCeWpGanphakFsUXleakFh9iZOLglGpgdDXZbbB9/7/dEVdepW0W a5qSqPdmUXVlkcrbk2wVVhsDJmhELxbVY92Qs3HSQfX23t0RW6z/XfHYc/DPnk6LLRcV6iaW b43Yqf+aeeG2e6tK5zjUPgg+XLBnBe9S+ymcDSfkOOffvrxjy47y5ZN0lOsbWZaU3pkdKOmz 3WLpLvGVCyIfm5SJMyixFGckGmoxFxUnAgAWWbhpgwIAAA==
Archived-At: <>
Cc: "" <>, " list" <>
Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 May 2015 17:56:09 -0000

Hi Stefano,

Mostly agree but not clear on how we this. Hopefully and as I understood (may be wrong) this is one of the questions Hannes could be asking.

Any ways -
>An example is the deployment of IPv6 using MT-ISIS where all IPv6 information (prefixes, adjacencies) are advertised within topology ID 2.
> It wouldn't make sense to advertise IPv6/SID mappings without any topology identifier.

If we do that it *may*  become default topology (RFC 5308) and which  may not be what is intended.

But my unanswered question in this context is there is no topology information when we try to stitch the LDP path in mapping server context.
Perhaps that part need to be addressed too/before?? Or it could be orthogonal..

Uma C.

-----Original Message-----
From: Isis-wg [] On Behalf Of Stefano Previdi (sprevidi)
Sent: Thursday, May 21, 2015 9:44 AM
To: Hannes Gredler
Cc:; list
Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions

Hi Hannes,

On May 21, 2015, at 4:34 PM, Hannes Gredler <> wrote:
> hi stefano,
> On Thu, May 21, 2015 at 01:55:07PM +0000, Stefano Previdi (sprevidi) wrote:
> | [... ]
> | SP> Can you clarify in a new thread what is your problem in making the Binding TLV _not_ MT aware in ISIS ?
> very simple explanation:
> Binding TLV only carries non-IP (e.g. MPLS labels, SRGB Indexes) information
>   at no point it carries information which directly affects IP forwarding state. 

it propagates information about paths that are useable in a topology.

> in contrast all exisiting MT TLVs carry information which have direct relevance
>   to the generation of IP forwarding state (e.g.
>     -MT-ISREACH affects metrics for IP routes,
>     -MT-IPREACH affects advertisment and metrics for IP routes).
> what is not clear to me:
> why do we need to augment non-IP advertisments with extensions that 
> are only relevant for IP path construction. - the intersection between 
> the two seems zero to me.

ok, let's try to clarify the point then. 

ISIS is used to propagate information pertaining to prefixes and topology. This information has been contextualized with the introduction of MT-ISIS. This resulted into adding a MT-ID to each piece of topology advertised by ISIS, including prefixes and adjacencies.

SR introduced the Binding TLV which is also a piece of topology since it represents a useable path in the topology. 

Therefore, it makes sense to me to add a MT-ID to the Binding TLV. 

Note also that the Binding TLV is used by the Mapping Server. There too, the information propagated by the Mapping Server MAY be related to a topology. An example is the deployment of IPv6 using MT-ISIS where all IPv6 information (prefixes, adjacencies) are advertised within topology ID 2. It wouldn't make sense to advertise IPv6/SID mappings without any topology identifier. 

Therefore, to me, it is straightforward to enhance the Binding TLV with MT capability.

> | SP> Also, would you also suggest to make it _not_ MT aware in OSPF ? In such case we have to change the OSPF spec.
> same reasoning here: in case its not clear what/how to use MT in the binding TLV for, we should remove it.

well, it looks to me the ospf wg clearly understood and acknowledged the need of the MT-ID and I believe we did the right thing there.

Now, I'd be interested to know other people opinion on this (from both isis and spring wg's).


> /hannes
> | On May 21, 2015, at 3:26 PM, Hannes Gredler <> wrote:
> | 
> | > hi stefano,
> | > 
> | > On Thu, May 21, 2015 at 10:14:20AM +0000, Stefano Previdi (sprevidi) wrote:
> | > [ ... ]
> | > | > | SP> why not creating a new thread explaining the issue and including isis and spring wg ?
> | > | > 
> | > | > HG> thats a good suggestion  - please do it ! - we need to be 
> | > | > HG> clear on the protocol requirements *before* adding 
> | > | > HG> protocol extensions.
> | > | 
> | > | SP> well, we agreed already at multiple occasions (last one was 
> | > | SP> during the meeting in Dallas where you and me agreed to add MT support to the Binding TLV) so we're inline with the process, right ?
> | > 
> | > again this is meant as a friendly reminder to document (e.g. in 
> | > some of the SPRING documents where you have the pen) how you want to intend to use the MT extensions for the binding TLV.
> | > 
> | > its not yet clear to me and i'd like to get an answer on this 
> | > before progressing the protocol extensions in the ISIS and OSPF working groups.
> | > 
> | > /hannes
> | 

Isis-wg mailing list