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

Hannes Gredler <hannes@juniper.net> Thu, 21 May 2015 14:34 UTC

Return-Path: <hannes@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6010B1A1BA4; Thu, 21 May 2015 07:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbL107ZFMSuU; Thu, 21 May 2015 07:34:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB881A1B77; Thu, 21 May 2015 07:34:52 -0700 (PDT)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net;
Received: from hannes-mba.local (193.110.55.11) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 21 May 2015 14:34:37 +0000
Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 5F7381363688; Thu, 21 May 2015 16:34:26 +0200 (CEST)
Date: Thu, 21 May 2015 16:34:26 +0200
From: Hannes Gredler <hannes@juniper.net>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Message-ID: <20150521143425.GA63432@hannes-mba.local>
References: <20150507120728.GB3896@hannes-mba.local> <F3ADE4747C9E124B89F0ED2180CC814F593C4EE2@xmb-aln-x02.cisco.com> <20150514195127.GB26771@hannes-mba.local> <F3ADE4747C9E124B89F0ED2180CC814F593D2E51@xmb-aln-x02.cisco.com> <20150518131042.GA37696@hannes-mba.local> <D3583CD5-2522-432F-BBC8-4F730E37F9C2@cisco.com> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <D5CE1388-1D35-492D-92EE-7E03ACE192AD@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D5CE1388-1D35-492D-92EE-7E03ACE192AD@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Originating-IP: [193.110.55.11]
X-ClientProxiedBy: DB4PR05CA0027.eurprd05.prod.outlook.com (25.160.40.37) To BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435;
X-Microsoft-Antispam-PRVS: <BLUPR05MB435CB445BE876A94F6ACDABCBC10@BLUPR05MB435.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB435; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435;
X-Forefront-PRVS: 0583A86C08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(57704003)(377454003)(2950100001)(33656002)(106356001)(122856001)(98436002)(110136002)(189998001)(77096005)(46102003)(68736005)(93886004)(5001960100002)(76176999)(54356999)(97756001)(83506001)(81156007)(4001540100001)(92566002)(4001350100001)(105586002)(5001830100001)(97736004)(66066001)(62966003)(77156002)(5001860100001)(87976001)(50986999)(122386002)(19580405001)(19580395003)(64706001)(76506005)(23726002)(230783001)(40100003)(86362001)(101416001)(50466002)(47776003)(46406003)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:hannes-mba.local; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:34:37.4759 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/t16HRcqpOmij9cNM2Co-WirUb_I>
Cc: "spring@ietf.org" <spring@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2015 14:34:55 -0000

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.

/hannes

| On May 21, 2015, at 3:26 PM, Hannes Gredler <hannes@juniper.net> 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 ! - 
| > | > HG> we need to be clear on the protocol requirements *before* adding
| > | > HG> protocol extensions.
| > | 
| > | SP> well, we agreed already at multiple occasions (last one was during the meeting in Dallas
| > | SP> 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
|