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

<> Thu, 21 May 2015 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E03101A8731; Thu, 21 May 2015 08:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f6zrm02t3m9G; Thu, 21 May 2015 08:15:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89BFE1A870B; Thu, 21 May 2015 08:15:00 -0700 (PDT)
Received: from (unknown [xx.xx.xx.200]) by (ESMTP service) with ESMTP id D0E061B8440; Thu, 21 May 2015 17:14:58 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 9C4821580A6; Thu, 21 May 2015 17:14:58 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0235.001; Thu, 21 May 2015 17:14:58 +0200
To: Hannes Gredler <>, "Stefano Previdi (sprevidi)" <>
Thread-Topic: [spring] latest update of draft-ietf-isis-segment-routing-extensions
Date: Thu, 21 May 2015 15:14:57 +0000
Message-ID: <28203_1432221298_555DF672_28203_7643_1_27B26A2868951342946169C453A0DF4B22A8C483@OPEXCLILM23.corporate.adroot.infra.ftgroup>
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: <20150521143425.GA63432@hannes-mba.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.5.21.142416
Archived-At: <>
X-Mailman-Approved-At: Tue, 26 May 2015 01:33:22 -0700
Cc: "" <>, " list" <>
Subject: Re: [Isis-wg] [spring] 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 15:15:44 -0000

I am out dsl 

-----Message d'origine-----
De : spring [] De la part de Hannes Gredler
Envoyé : jeudi 21 mai 2015 16:34
À : Stefano Previdi (sprevidi)
Cc :; list
Objet : Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions

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. 

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.

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


| 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 protocol 
| > | > HG> 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

spring mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.