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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sat, 23 May 2015 05:34 UTC

Return-Path: <ginsberg@cisco.com>
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 230751A90BF; Fri, 22 May 2015 22:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 wnb086wROqCw; Fri, 22 May 2015 22:34:12 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BC01A90B9; Fri, 22 May 2015 22:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5790; q=dns/txt; s=iport; t=1432359252; x=1433568852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jHas4gALbmw1as/QJctLt4SQgywGtae/MsH/1XF9HdM=; b=JB8pAMgJc27kwEPi5ltomfA1nRatdq1ek7gmIQySg0Nvp819qIkMR6PW UBbCecB9m83OMs120BiO96821rC1FDXfVYa1fLf6HAytQo/EF2paODAw6 Wk/j9PCS/8OruTmo2FJTNtFslFJ1H/yuouqirVYlbPNNLFZcF5eU1yRNb E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQDqEGBV/4UNJK1cgxBUXgbEdAqFdwKBMEwBAQEBAQGBC4QiAQEBAwEBAQE3LQcLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgcCA3TOAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizqEOhoxBwaDEYEWBZBMgjyMOINxijaEBoNZI4FmJByBUm+BRoEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,480,1427760000"; d="scan'208";a="422010564"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 23 May 2015 05:34:10 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4N5YAcI007903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 May 2015 05:34:10 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sat, 23 May 2015 00:34:10 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQk9NUFCp/PTku6U6y8U0s3mGW8p2G9skAgAIPR0A=
Date: Sat, 23 May 2015 05:34:09 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F5940A87D@xmb-aln-x02.cisco.com>
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> <20150521143425.GA63432@hannes-mba.local> <48857DE7-3CA6-45D1-A66E-B98C427C844F@cisco.com>
In-Reply-To: <48857DE7-3CA6-45D1-A66E-B98C427C844F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.8.213]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/xJpX9GZFy4xBjc5eNBiKUbPe8Zw>
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: Sat, 23 May 2015 05:34:16 -0000

Stefano is correct - and I find it hard to understand the positions of the objectors. 

A label - to borrow a phrase used by others - is an instruction to the forwarding plane to send a packet along a given path. Clearly, when IGPs calculate paths they do so in the context of a topology. So if we are going to use a SID as a means of encoding the IGP calculated topology specific path to the forwarding plane clearly SIDs MUST be topology specific.

This is why the prefix-SID sub-TLV in IS-IS is allowed in the MT prefix reachability TLVs defined in RFC 5120.
When a mapping server is used in place of advertising SIDs in prefix reachability TLVs, clearly MTID also needs to be supported.

 A few more remarks inline.


> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano Previdi
> (sprevidi)
> Sent: Thursday, May 21, 2015 9:44 AM
> To: Hannes Gredler
> Cc: spring@ietf.org; isis-wg@ietf.org 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 <hannes@juniper.net> 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.
> 
[Les:] This seems to me to be an abuse of terminology. The differentiation between "IP forwarding" and "MPLS forwarding" refers to how the forwarding logic implemented. What is being defined in the forms of the prefix-SID values advertised by the IGPs is how the topology specific instruction for a given prefix are passed to the forwarding plane. 

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

[Les:] It is very clear in the case when mapping server is used to advertise prefix-SIDs. The only mistake that was made was that the earlier versions of the IS-IS draft overlooked the need for MTID in the binding TLV.

   Les

> 
> 
> 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).
> 
> s.
> 
> 
> >
> > /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 ! - 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
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg