From nobody Tue May 5 06:46:41 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581E1ACD83; Tue, 5 May 2015 06:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 i602QsPbjpET; Tue, 5 May 2015 06:46:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8A1ACD77; Tue, 5 May 2015 06:46:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505134637.10064.20664.idtracker@ietfa.amsl.com> Date: Tue, 05 May 2015 06:46:37 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 13:46:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Jeff Tantsura Edward Crabbe Filename : draft-ietf-spring-segment-routing-02.txt Pages : 19 Date : 2015-05-05 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing extension header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer in the routing extension header. Upon completion of a segment, the pointer is incremented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 00:20:27 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2DD1ACCE7 for ; Fri, 15 May 2015 00:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.041 X-Spam-Level: **** X-Spam-Status: No, score=4.041 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.793] autolearn=no 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 jR5zU3-ahNl3 for ; Fri, 15 May 2015 00:20:24 -0700 (PDT) Received: from owl2.lab.dtag.de (unknown [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id E68B71AD16B for ; Fri, 15 May 2015 00:20:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 5329FC17EC for ; Fri, 15 May 2015 09:20:22 +0200 (CEST) Received: from Martins-MacBook-Air.local (unknown [85.29.8.182]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 1D742C17EB for ; Fri, 15 May 2015 09:20:22 +0200 (CEST) Message-ID: <55559E35.9050802@nic.dtag.de> Date: Fri, 15 May 2015 10:20:21 +0300 From: Martin Horneffer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: spring@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] anycast segments and indexed SIDs X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 07:20:26 -0000 Hello everyone, there is a problem for networks that use spring on the MPLS forwarding plane: It seems it would not be feasible to use anycast segments for traffic engineering since we introduced indexed SIDs. I would really like to use of some well-defined anycast addresses to solve a number of traffic engineering use cases. I.e. an anycast address would stand for a certain property of possible paths and segment routing would be responsible to apply this property to the traffic which needs it. In other words I want to use a path with one anycast segment, followed by the usual node segment to the actual destination (typically an egress LER). The anycast segment itself is fine: it can be built in the usual way. However for the following node segment the spring source node cannot calculate the label value. The stack PUSHing router would not know at which node the second segment would actually start, and thus which SRGB to apply. If needed I could make a drawing to illustrate this problem. As I see it, there would be three different options to address this problem: 1) Abandon anycast segments completely. This would greatly reduce the usefulness of segment routing in my opinion. 2) Use a homogeneous SRGB, so that label values would effectively be the same for all nodes. But in this case, why did we introduce indexes at all? 3) Use a context label. E.g. as defined in draft-raszuk-mpls-domain-wide-labels. Since I really hate to add more labels to the stack than really needed, could we think of a way to only use context labels where needed? As far as I can see this would only be relevant for the segment immediately following an anycast segment. Are there any other options? Best regards, Martin From nobody Fri May 15 01:34:35 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1841B2EF3 for ; Fri, 15 May 2015 01:34:34 -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 AHvOYkNiMx1v for ; Fri, 15 May 2015 01:34:33 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA861B2EB5 for ; Fri, 15 May 2015 01:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2473; q=dns/txt; s=iport; t=1431678872; x=1432888472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hR7YwKot0PPxp4kj2kKOv/XXF2KAldgypu/NxmMrlpc=; b=Q9ZPHqmg837txvRFScnDYX1tRICAkn3xsi1X+rWOSpPLp+uYqUsxLPuf F1TNKLyexD96QMKIyLzorfiJxwk15vjhLjGgHEUq1bGUFyogMi66AMLpu 7B7HuGWJxWPxBfRqv18sOWLD0LZt6C10wkasvkFvHinsu9nHSOySMcQIE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBABSr1VV/5RdJa1cgw9UXgbDa2YJgU4KhSxKAoE/OBQBAQEBAQEBgQqEIgEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAgQOBYgkCA3WGQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEijiBAoQhMTMHgxeBFgWSYYpylnwjgWYjHIFSb4FFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,433,1427760000"; d="scan'208";a="150273173" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 15 May 2015 08:34:20 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4F8YKpI027203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 08:34:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.93]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 15 May 2015 03:34:20 -0500 From: "Stefano Previdi (sprevidi)" To: Martin Horneffer Thread-Topic: [spring] anycast segments and indexed SIDs Thread-Index: AQHQjuL2mEhkyIQZqEC/fmSOn8FjR519CeWA Date: Fri, 15 May 2015 08:34:19 +0000 Message-ID: References: <55559E35.9050802@nic.dtag.de> In-Reply-To: <55559E35.9050802@nic.dtag.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [spring] anycast segments and indexed SIDs X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:34:34 -0000 On May 15, 2015, at 9:20 AM, Martin Horneffer wrote: > Hello everyone, >=20 > there is a problem for networks that use spring on the MPLS forwarding pl= ane: It seems it would not be feasible to use anycast segments for traffic = engineering since we introduced indexed SIDs. well, yes, that's the price to pay if you can't use the same SRGB everywher= e. > I would really like to use of some well-defined anycast addresses to solv= e a number of traffic engineering use cases. I.e. an anycast address would = stand for a certain property of possible paths and segment routing would be= responsible to apply this property to the traffic which needs it. In other= words I want to use a path with one anycast segment, followed by the usual= node segment to the actual destination (typically an egress LER). >=20 > The anycast segment itself is fine: it can be built in the usual way. > However for the following node segment the spring source node cannot calc= ulate the label value. The stack PUSHing router would not know at which nod= e the second segment would actually start, and thus which SRGB to apply. >=20 > If needed I could make a drawing to illustrate this problem. >=20 > As I see it, there would be three different options to address this probl= em: >=20 > 1) Abandon anycast segments completely. > This would greatly reduce the usefulness of segment routing in my opinion= . >=20 > 2) Use a homogeneous SRGB, so that label values would effectively be the = same for all nodes. that's definitely the option I'd recommend, not to mention the simplicity o= f operations. > But in this case, why did we introduce indexes at all? because not all vendors have been capable of producing implementations usin= g the common SRGB. So far we have many vendors that agreed on using 16000-2= 3999 but not all... s. >=20 > 3) Use a context label. E.g. as defined in draft-raszuk-mpls-domain-wide-= labels. >=20 > Since I really hate to add more labels to the stack than really needed, c= ould we think of a way to only use context labels where needed? > As far as I can see this would only be relevant for the segment immediate= ly following an anycast segment. >=20 > Are there any other options? >=20 > Best regards, Martin >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Fri May 15 01:39:23 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10381B2DBE for ; Fri, 15 May 2015 01:39:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 u1zOoDLdawBn for ; Fri, 15 May 2015 01:39:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9154C1B2D9C for ; Fri, 15 May 2015 01:39:19 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.12) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.154.19; Fri, 15 May 2015 08:39:17 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 2C0F9132718C; Fri, 15 May 2015 10:39:07 +0200 (CEST) Date: Fri, 15 May 2015 10:39:07 +0200 From: Hannes Gredler To: Martin Horneffer Message-ID: <20150515083907.GA28569@hannes-mba.local> References: <55559E35.9050802@nic.dtag.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <55559E35.9050802@nic.dtag.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: BY1PR0201CA0004.namprd02.prod.outlook.com (25.160.191.142) To DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR05MB447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB447; X-Forefront-PRVS: 0577AD41D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(53754006)(97756001)(66066001)(87976001)(46406003)(47776003)(23726002)(76506005)(2950100001)(40100003)(122856001)(77156002)(62966003)(77096005)(15975445007)(92566002)(46102003)(122386002)(33656002)(98436002)(86362001)(5001960100002)(110136002)(83506001)(19580405001)(19580395003)(50986999)(54356999)(76176999)(189998001)(4001350100001)(50466002)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:hannes-mba.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2015 08:39:17.3043 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB447 Archived-At: Cc: spring@ietf.org Subject: Re: [spring] anycast segments and indexed SIDs X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:39:21 -0000 hi martin, IMO context labels are the agreed-upon vehicle to disambiguate label-space. in the past we have used that e.g. for egress-protection and upstream label-allocation. /hannes On Fri, May 15, 2015 at 10:20:21AM +0300, Martin Horneffer wrote: | Hello everyone, | | there is a problem for networks that use spring on the MPLS forwarding | plane: It seems it would not be feasible to use anycast segments for traffic | engineering since we introduced indexed SIDs. | | I would really like to use of some well-defined anycast addresses to solve a | number of traffic engineering use cases. I.e. an anycast address would stand | for a certain property of possible paths and segment routing would be | responsible to apply this property to the traffic which needs it. In other | words I want to use a path with one anycast segment, followed by the usual | node segment to the actual destination (typically an egress LER). | | The anycast segment itself is fine: it can be built in the usual way. | However for the following node segment the spring source node cannot | calculate the label value. The stack PUSHing router would not know at which | node the second segment would actually start, and thus which SRGB to apply. | | If needed I could make a drawing to illustrate this problem. | | As I see it, there would be three different options to address this problem: | | 1) Abandon anycast segments completely. | This would greatly reduce the usefulness of segment routing in my opinion. | | 2) Use a homogeneous SRGB, so that label values would effectively be the | same for all nodes. | But in this case, why did we introduce indexes at all? | | 3) Use a context label. E.g. as defined in | draft-raszuk-mpls-domain-wide-labels. | | Since I really hate to add more labels to the stack than really needed, | could we think of a way to only use context labels where needed? | As far as I can see this would only be relevant for the segment immediately | following an anycast segment. | | Are there any other options? | | Best regards, Martin | | _______________________________________________ | spring mailing list | spring@ietf.org | https://www.ietf.org/mailman/listinfo/spring From nobody Fri May 15 01:42:22 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5571A0A6A for ; Fri, 15 May 2015 01:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 XsCi-xOOCYfO for ; Fri, 15 May 2015 01:42:19 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DB91A000B for ; Fri, 15 May 2015 01:42:19 -0700 (PDT) Received: by oica37 with SMTP id a37so77239441oic.0 for ; Fri, 15 May 2015 01:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fu0lmZH+XcEHVAEiaN42/61QiMQJPSPn2eoVnO0AI/Q=; b=QjfuYjwr9tgYlhhv0AfzWxLwU8z1rTJbaROLHAT63XmIn0bHfvGWoFcRdXoxKi3JVN 0N44aSq4IRCKEOTEqpQefCHEOC/fdi/P5w+7SdViEJa2gunFir4rYlqNP8os931K2bDt jRIyQf43sFDpuQdYBbYnU7/YaUBbWbV9vF02dPQGfkIhkYwynR1qxob5pfCXlqhSEqd6 rZQCapm1lZY4lSGyk6egArlX5ihA72YdY6jWIiFsiL5hmY4nY+eRILa98gUq7mCxNIz4 rrNQSiWQcI9wbCwUSqutsE4f4UzeS1rFIAYPTquJBPVRMIoHYTVeGVP+3gZMPAIdRIBq JHkw== MIME-Version: 1.0 X-Received: by 10.202.96.8 with SMTP id u8mr7032064oib.77.1431679338478; Fri, 15 May 2015 01:42:18 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.202.179.193 with HTTP; Fri, 15 May 2015 01:42:18 -0700 (PDT) In-Reply-To: <20150515083907.GA28569@hannes-mba.local> References: <55559E35.9050802@nic.dtag.de> <20150515083907.GA28569@hannes-mba.local> Date: Fri, 15 May 2015 10:42:18 +0200 X-Google-Sender-Auth: zEw0h9WZkVfdP974Y9LhpmQMjIs Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: multipart/alternative; boundary=001a113d5b886702b405161ad240 Archived-At: Cc: Martin Horneffer , "spring@ietf.org" Subject: Re: [spring] anycast segments and indexed SIDs X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:42:21 -0000 --001a113d5b886702b405161ad240 Content-Type: text/plain; charset=UTF-8 I agree. I think introducing indexes especially that they do not solve all problems is not so great of an idea. That is why I proposed a new clean complete label space for SR in draft-raszuk-mpls-domain-wide-labels. Of course an alternative is not to use mpls as a transport at all :-)) Cheers, R. On Fri, May 15, 2015 at 10:39 AM, Hannes Gredler wrote: > hi martin, > > IMO context labels are the agreed-upon vehicle to disambiguate label-space. > in the past we have used that e.g. for egress-protection and upstream > label-allocation. > > /hannes > > On Fri, May 15, 2015 at 10:20:21AM +0300, Martin Horneffer wrote: > | Hello everyone, > | > | there is a problem for networks that use spring on the MPLS forwarding > | plane: It seems it would not be feasible to use anycast segments for > traffic > | engineering since we introduced indexed SIDs. > | > | I would really like to use of some well-defined anycast addresses to > solve a > | number of traffic engineering use cases. I.e. an anycast address would > stand > | for a certain property of possible paths and segment routing would be > | responsible to apply this property to the traffic which needs it. In > other > | words I want to use a path with one anycast segment, followed by the > usual > | node segment to the actual destination (typically an egress LER). > | > | The anycast segment itself is fine: it can be built in the usual way. > | However for the following node segment the spring source node cannot > | calculate the label value. The stack PUSHing router would not know at > which > | node the second segment would actually start, and thus which SRGB to > apply. > | > | If needed I could make a drawing to illustrate this problem. > | > | As I see it, there would be three different options to address this > problem: > | > | 1) Abandon anycast segments completely. > | This would greatly reduce the usefulness of segment routing in my > opinion. > | > | 2) Use a homogeneous SRGB, so that label values would effectively be the > | same for all nodes. > | But in this case, why did we introduce indexes at all? > | > | 3) Use a context label. E.g. as defined in > | draft-raszuk-mpls-domain-wide-labels. > | > | Since I really hate to add more labels to the stack than really needed, > | could we think of a way to only use context labels where needed? > | As far as I can see this would only be relevant for the segment > immediately > | following an anycast segment. > | > | Are there any other options? > | > | Best regards, Martin > | > | _______________________________________________ > | spring mailing list > | spring@ietf.org > | https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a113d5b886702b405161ad240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree.=C2=A0
=
I think introducing indexes especially that th= ey do not solve all problems is not so great of an idea.=C2=A0

That is why I proposed a new clean= complete label space for SR in=C2=A0draft-raszuk-mpls-domain-wide-labels.

Of course an alternative is not to use mpls = as a transport at all :-))

C= heers,
R.


On Fri, May 15, 2015 at 10:39 AM, Ha= nnes Gredler <hannes@juniper.net> wrote:
hi martin,

IMO context labels are the agreed-upon vehicle to disambiguate label-space.=
in the past we have used that e.g. for egress-protection and upstream label= -allocation.

/hannes

On Fri, May 15, 2015 at 10:20:21AM +0300, Martin Horneffer wrote:
| Hello everyone,
|
| there is a problem for networks that use spring on the MPLS forwarding | plane: It seems it would not be feasible to use anycast segments for traf= fic
| engineering since we introduced indexed SIDs.
|
| I would really like to use of some well-defined anycast addresses to solv= e a
| number of traffic engineering use cases. I.e. an anycast address would st= and
| for a certain property of possible paths and segment routing would be
| responsible to apply this property to the traffic which needs it. In othe= r
| words I want to use a path with one anycast segment, followed by the usua= l
| node segment to the actual destination (typically an egress LER).
|
| The anycast segment itself is fine: it can be built in the usual way.
| However for the following node segment the spring source node cannot
| calculate the label value. The stack PUSHing router would not know at whi= ch
| node the second segment would actually start, and thus which SRGB to appl= y.
|
| If needed I could make a drawing to illustrate this problem.
|
| As I see it, there would be three different options to address this probl= em:
|
| 1) Abandon anycast segments completely.
| This would greatly reduce the usefulness of segment routing in my opinion= .
|
| 2) Use a homogeneous SRGB, so that label values would effectively be the<= br> | same for all nodes.
| But in this case, why did we introduce indexes at all?
|
| 3) Use a context label. E.g. as defined in
| draft-raszuk-mpls-domain-wide-labels.
|
| Since I really hate to add more labels to the stack than really needed, | could we think of a way to only use context labels where needed?
| As far as I can see this would only be relevant for the segment immediate= ly
| following an anycast segment.
|
| Are there any other options?
|
| Best regards, Martin
|
| _______________________________________________
| spring mailing list
| spring@ietf.org
| https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

--001a113d5b886702b405161ad240-- From nobody Mon May 18 01:19:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758EF1A87AD for ; Mon, 18 May 2015 01:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BkI5E1l-8g_A for ; Mon, 18 May 2015 01:19:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05B51A87B2 for ; Mon, 18 May 2015 01:19:54 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id AE2FA374180 for ; Mon, 18 May 2015 10:19:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7F87515807F for ; Mon, 18 May 2015 10:19:53 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0235.001; Mon, 18 May 2015 10:19:53 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF hackathon Thread-Index: AQHQkIJM8LZGgbt+L0S+Yg+l0hVD352BZOtw Date: Mon, 18 May 2015 08:19:52 +0000 Message-ID: <4135_1431937193_5559A0A9_4135_1555_1_53C29892C857584299CBF5D05346208A0F585A92@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> In-Reply-To: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/mixed; boundary="_002_53C29892C857584299CBF5D05346208A0F585A92OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.13.120621 Archived-At: Subject: [spring] IETF hackathon X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:19:56 -0000 --_002_53C29892C857584299CBF5D05346208A0F585A92OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, FYI, in Prague the IETF will have a hackathon event: http://www.ietf.org/b= log/2015/05/ietf-hackathon/ "The strength of open source and other similar efforts is working with othe= rs. The Hackathon is an opportunity to work with others behind new software= projects and the technologies themselves." Bruno -----Original Message----- From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Sunday, May 17, 2015 11:17 AM To: IETF WG Chairs Subject: IETF hackathon Chairs, I wanted to highlight that in Prague we will have a hackathon event: http://www.ietf.org/blog/2015/05/ietf-hackathon/ Some of your working groups might have participants working actively on sof= tware who might benefit from some time together. Or could implement a small= enhancement during the weekend. An opportunity for your consideration. Jari ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_002_53C29892C857584299CBF5D05346208A0F585A92OPEXCLILM21corp_ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: signature.asc Content-Disposition: attachment; filename="signature.asc"; size=859; creation-date="Mon, 18 May 2015 08:19:52 GMT"; modification-date="Mon, 18 May 2015 08:19:52 GMT" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFJY0JBRUJDZ0FHQlFKVldGeWVBQW9KRU04MGdDVFFVNDZxQi9n UUFMN1AxL3B3eEpHaXVJamQvUG9QSmFnSg0KOXVxOEFveWxhVWwyYVpiYk5SWTZpaFJBNnFYTVlK OGdTRHhaZzl6Q0VGYk0wYkxRTkpMdjIycTVla2d3L3VDKw0KQXluYUpyYUFRRkw1ZGRXTjdXN2p0 eWRzcFJ0bXRXalplS2kzMnpiVHYydHV1ak9CQk1HbmYxOXdzSGJtUFUxag0KbEpHODNKSlRNdFVS OUpiQllUYXBlMndRSzVBNWZ5OFJjL25DRUFvMW1PZWhxaEh3Z1RlaFNMUHZTajgrb3labg0Kb2tZ blJKRVh3RHNFSHJ1VzlMMSs5T2JTSTdYTmhZUGlvb3lLMHYxdlFIWTRKQnhhV1dGYU12Y3llcVFF UklNWg0KUEdsejdHLzZsck1JeVBycmw4UUh1L0NxWnpwbmdsZmtZYVUxSlR0dnJIU0ZmYUtqM2ht R2pMbXNRZFcxbmNsdg0KVjdwVG1SMTd6N1N0aTV6cFZ0aUFLMFpnU3ArNWdzc0ZObmw2T3NJSGxj Nlh2THc2dW80blIxWkliQlU0Vmd4MA0KZ1BaOTNJQk9oRmRENWdheEMvVy91QmpEYURpUWRaem5B Zks1K0NOY1JmSlUvdFVGeEg5L08rQW9rWDJjUGdBZw0KcmpWd3FZaTdhNitubnFuT0hWY0htRE8y ajBTMW10K0k3THg3aCswc050RktGZ1h6cHdNQ1FPSU9VT3dCUm4zTA0KNC9ROHdWeEpVMDRjcjhO bVNwdmJmU1JKQUZQYXNCMEpQeTRQMzZMOXk4QjdIc0prRlczYkg4VGYxODk1cjdjTw0KS2lnNW1M WU1QTzVCT1NtNjcvaDZic3hKZUFLQUNEa09vOWM0T3JJV3lKUTE0SmxtaDZwUi9ZYjlISmJJdTE1 UQ0KWmFLbnVwbVdnTFFjMWw5MXhsTmUNCj1PN1REDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== --_002_53C29892C857584299CBF5D05346208A0F585A92OPEXCLILM21corp_-- From nobody Mon May 18 05:12:14 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1E1A8F33; Mon, 18 May 2015 05:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q3OYxJEhgaH; Mon, 18 May 2015 05:12:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0431A8BB2; Mon, 18 May 2015 05:12:09 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 51C862AC2AE; Mon, 18 May 2015 14:12:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 18ED0384072; Mon, 18 May 2015 14:12:08 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0235.001; Mon, 18 May 2015 14:12:08 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-bowers-spring-adv-per-algorithm-label-blocks-00 Thread-Index: AdCRY6NNtDQxGWQYQ1uPPmaKOgYh9A== Date: Mon, 18 May 2015 12:12:07 +0000 Message-ID: <30543_1431951128_5559D718_30543_8134_1_53C29892C857584299CBF5D05346208A0F585E6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.18.112715 Archived-At: Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [spring] draft-bowers-spring-adv-per-algorithm-label-blocks-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 12:12:12 -0000 Folks, This document discusses two options for configuring SID for additional IGP = algorithms such as SPF based on delay, MRT blue/red for Fast ReRoute... At first, the handling of additional IGP algorithms may be seen as a second= priority for the SPRING WG. However, this discussion may impact IGP encodi= ngs discussed in the OSPF and IS-IS WG. Such IGP extensions have been discu= ssed for some time, with multiple interoperable implementations and expecte= d deployments in the near future. Hence if change is needed, the more we wa= it, probably the harder. We feel that starting the discussion on the mailing list now would be bette= r than waiting for Pragues. So we'd like to encourage the WG to read this document and comment it on th= e mailing list. http://tools.ietf.org/id/draft-bowers-spring-adv-per-algorithm-label-blocks= -00.txt =09 Thanks, Bruno, John > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Chris Bowers > Sent: Friday, April 03, 2015 7:16 PM > To: spring@ietf.org > Subject: [spring] FW: New Version Notification for draft-bowers-spring-ad= v- > per-algorithm-label-blocks-00.txt >=20 > All, >=20 > I'd like to bring this new draft to the attention of the SPRING working g= roup. >=20 > The draft discusses two options for associating SR labels with destinatio= n- > based forwarding next-hops computed by different algorithms. It would be > useful for the SPRING working group to address this topic in order to pro= vide > guidance to the isis and ospf working groups with respect to encodings for > this functionality. >=20 > Chris >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, April 03, 2015 9:34 AM > To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; Pushpas= is > Sarkar; Hannes Gredler > Subject: New Version Notification for draft-bowers-spring-adv-per- > algorithm-label-blocks-00.txt >=20 >=20 > A new version of I-D, draft-bowers-spring-adv-per-algorithm-label-blocks- > 00.txt > has been successfully submitted by Chris Bowers and posted to the IETF > repository. >=20 > Name: draft-bowers-spring-adv-per-algorithm-label-blocks > Revision: 00 > Title: Advertising Per-Algorithm Label Blocks > Document date: 2015-04-03 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bowers-spring-a= dv- > per-algorithm-label-blocks-00.txt > Status: https://datatracker.ietf.org/doc/draft-bowers-spring-adv-= per- > algorithm-label-blocks/ > Htmlized: http://tools.ietf.org/html/draft-bowers-spring-adv-per- > algorithm-label-blocks-00 >=20 >=20 > Abstract: > Segment routing uses globally-known labels to accomplish destination- > based forwarding along shortest paths computed using Dijkstra's > algorithm with IGP metrics. This draft discusses how to use segment > routing to accomplish destination-based forwarding along paths > computed using other algorithms and metrics. In particular, the > draft contrasts two different options for associating labels with > different algorithms for computing forwarding next-hops. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Thu May 21 06:55:12 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C31A0193; Thu, 21 May 2015 06:55:10 -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 2gxVG8W7e7CE; Thu, 21 May 2015 06:55:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25FD1A0141; Thu, 21 May 2015 06:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1471; q=dns/txt; s=iport; t=1432216511; x=1433426111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9WlX48Wk+Q2ExnJ1HH1mRCKpGp470f75FmZc6RbbqvM=; b=RMI32YGdRKZRqvY8rTiTXYwmSXRA52VB5X5fsG0OSKxE9cSClGb0nj48 VvC23c8VIj0SEZNw2KaZ77+oop0R+CRtWWfr+OZxvsp6Om9ZuPe9leYD9 BN7B6bURN7gBjEWHvwvn/adHs3J51S2ED3j9f6BhXGx7Xryr/SoPf5LUb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeBQBV411V/5pdJa1cgxCBMgbCIog/AoFDTAEBAQEBAYELhCIBAQEDATo/BQsCAQgYHhAyJQIEDgWIJAjRRwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoRSMweDF4EWAQSSeosHgSiDa4ovhAKDWSOBZoISb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,469,1427760000"; d="scan'208";a="421551150" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 21 May 2015 13:55:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4LDt8lo025558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 13:55:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.6]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 21 May 2015 08:55:08 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQgPxXvBzpTyLq8EquUkRNFGr7jp1tQTsAgAISygCAADe9AP//rzGggAGTrAD//+YicIALm9KAgADtwZCABOuaAIAADViAgANMfICAASvogIAANcGAgAAH7gA= Date: Thu, 21 May 2015 13:55:07 +0000 Message-ID: References: <20150506165154.GB1769@hannes-mba.local> <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> In-Reply-To: <20150521132647.GB62835@hannes-mba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.100] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:55:11 -0000 Hannes, it's getting difficult to follow your reasoning because you switch from pro= tocol details concerns (which have been addressed) to ietf procedures... Can you clarify in a new thread what is your problem in making the Binding = TLV _not_ MT aware in ISIS ? Also, would you also suggest to make it _not_ MT aware in OSPF ? In such ca= se we have to change the OSPF spec. s. On May 21, 2015, at 3:26 PM, Hannes Gredler wrote: > hi stefano, >=20 > On Thu, May 21, 2015 at 10:14:20AM +0000, Stefano Previdi (sprevidi) wrot= e: > [ ... ] > | > | SP> why not creating a new thread explaining the issue and includin= g isis and spring wg ? > | >=20 > | > HG> thats a good suggestion - please do it ! -=20 > | > HG> we need to be clear on the protocol requirements *before* adding > | > HG> protocol extensions. > |=20 > | 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 ?=20 >=20 > again this is meant as a friendly reminder to document (e.g. in some of t= he SPRING documents > where you have the pen) how you want to intend to use the MT extensions f= or the binding TLV. >=20 > its not yet clear to me and i'd like to get an answer on this before prog= ressing the > protocol extensions in the ISIS and OSPF working groups. >=20 > /hannes From nobody Thu May 21 07:22:38 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18991ACCF5; Thu, 21 May 2015 03:14:26 -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 vbztqeCC_HMB; Thu, 21 May 2015 03:14:24 -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 ECE951ACC86; Thu, 21 May 2015 03:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10649; q=dns/txt; s=iport; t=1432203264; x=1433412864; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nsJOl5At26jYlGR9OUHjOr12zvrofNmoHFCvRZniSMA=; b=MzNGUnxEQACDkjCP98ud9zgbeWZ9zAQwfUDvOlK/i2j92Gxtfrd/F7i8 jcrmpWeDvcMlTgevl3CgOnYQKQfuDrSErv6gGEyHfDLeTuhW6nnNc+A5J GiqFOX0bDvRSpZE6iDckivpi3f40306BJ2YtcJfRWbKlQWogn2gSlrjo4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZBQDVrl1V/5pdJa1cgxCBMgbCH4hAAoFFTAEBAQEBAYELhCIBAQEDATotBxAHBAIBCBEEAQEBHgkHMhQJCAIEARKIJAjQQwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoIUgiYYOgaDEYEWAQSSd4sHgSiDa4J+hzGEAoNZI4FmJByBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,468,1427760000"; d="scan'208";a="421470818" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 21 May 2015 10:14:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4LAEL8W006177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 10:14:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.6]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 21 May 2015 05:14:21 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler , "Les Ginsberg (ginsberg)" , "Clarence Filsfils (cfilsfil)" , "Ahmed Bashandy (bashandy)" , Stephane Litkowski , "bruno.decraene@orange.com IMT/OLN" , Jeff Tantsura , "Wim (Wim) Henderickx" , Pushpasis Sarkar , "John G. Scudder" , Christian Hopps , "isis-wg@ietf.org list" , "" Thread-Topic: latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQgPxXvBzpTyLq8EquUkRNFGr7jp1tQTsAgAISygCAADe9AP//rzGggAGTrAD//+YicIALm9KAgADtwZCABOuaAIAADViAgANMfICAASvogA== Date: Thu, 21 May 2015 10:14:20 +0000 Message-ID: <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> References: <20150505055238.GA26250@hannes-mba.local> <20150506165154.GB1769@hannes-mba.local> <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> In-Reply-To: <20150520162058.GE55346@hannes-mba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <750C0439BB4B1B4E93EF82106B7399D8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 21 May 2015 07:22:37 -0700 Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:14:26 -0000 All, the thread below is about adding Multi Topology support in ISIS Segmen= t Routing Extensions draft and, more precisely, in the Binding TLV. While w= e initially all agreed that we should add MT capability to the Binding TLV,= it looks like we have some divergent opinions now. Please read the thread = below and feel free to comment. On May 20, 2015, at 6:20 PM, Hannes Gredler wrote: > hi stefano, >=20 > On Mon, May 18, 2015 at 01:58:22PM +0000, Stefano Previdi (sprevidi) wrot= e: > | On May 18, 2015, at 3:10 PM, Hannes Gredler wrote: > |=20 > | > hi les, > | >=20 > | > i am arguing that everything that we have standardized so far for MT = (222, 235, 237) > | > has clear semantics on how to calculate an *IP* path. > | >=20 > | > here comes the catch: > | > the sole information we are advertising in the binding TLV is related= to > | > *non-IP* paths. > | >=20 > | > the questions i'd like to get some answers now are: > | >=20 > | > 1) why do we need an MT extension for something which is carrying "no= n-IP" > | > related information. > |=20 > |=20 > | well, the mapping server carries mappings of prefixes to SIDs. This may= or may not be associated to a topology, we can argue on this. >=20 > does this mean that you intend to have a multi-topology mapping server ? one may want to have that, yes. > does that imply that you have a multi-topology deployment of LDP ? as far as I remember LDP, there are no advertisement in ISIS... > | However, for the other info carried by the binding TLV, don't you have = a FEC ? And the FEC isn't in the form of a IP reachability ? >=20 > a FEC describes an endpoint of an MPLS LSP. which may be useable by a given topology and not by another... nothing weir= d to me. Moreover, if IPv6 is deployed using MT-ISIS (topology identifier 2) it is o= bvious that all advertisements of IPv6 prefixes, mappings, etc are to be do= ne within that topology (and not as part of all topologies). > Advertisment of a FEC does not create IP forwarding state thats the funda= mental difference; >=20 > | > 2) is there a description ("use-case") how the "non-IP" related infor= mation in the > | > binding TLV information does influence the path decision of an IP p= ath. > | >=20 > | > since this is not an IS-IS related thing, but really SPRING relevant,= i'd like > | > also to see some open discussion on the SPRING list.=20 > |=20 > |=20 > | why not creating a new thread explaining the issue and including isis a= nd spring wg ? >=20 > thats a good suggestion - please do it ! - >=20 > we need to be clear on the protocol requirements *before* adding > protocol extensions. well, we agreed already at multiple occasions (last one was during the meet= ing in Dallas where you and me agreed to add MT support to the Binding TLV)= so we're inline with the process, right ?=20 Obviously, I'm perfectly ok to re-spin the discussion. Thanks. s. >=20 > /hannes >=20 >=20 > | > On Fri, May 15, 2015 at 03:05:19PM +0000, Les Ginsberg (ginsberg) wro= te: > | > | Hannes - > | > |=20 > | > | All we are doing here is providing Binding TLV w the same capabilit= ies as we have for Prefix Reachability TLVs. > | > | Are you arguing that we should NOT be able to advertise SIDs in TLV= s 235 and 237? > | > | > | > | If not then I simply don't see why your question is relevant. > | > |=20 > | > | Les > | > |=20 > | > |=20 > | > | > -----Original Message----- > | > | > From: Hannes Gredler [mailto:hannes@juniper.net] > | > | > Sent: Thursday, May 14, 2015 12:51 PM > | > | > To: Les Ginsberg (ginsberg) > | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil); Ahm= ed Bashandy > | > | > (bashandy); Stephane Litkowski; bruno.decraene@orange.com IMT/OLN= ; > | > | > Jeff Tantsura; Wim (Wim) Henderickx; Pushpasis Sarkar > | > | > Subject: Re: latest update of draft-ietf-isis-segment-routing-ext= ensions > | > | >=20 > | > | > les, > | > | >=20 > | > | > i do not think that i am confusing the two; > | > | >=20 > | > | > perhaps we can go with a practical example. > | > | >=20 > | > | > can you construct an example where you do NEED the MTID flavor of= the > | > | > binding SID. > | > | >=20 > | > | > /hannes > | > | >=20 > | > | > On Thu, May 07, 2015 at 03:48:38PM +0000, Les Ginsberg (ginsberg)= wrote: > | > | > | Hannes - > | > | > | > | > | > | You are confusing algorithm and topology - they are NOT the sam= e. > | > | > | > | > | > | Topologies (RFC 5120) are formed based on the set of nodes and = links > | > | > which advertise support for a given MTID. On that topology we run= (by > | > | > default) the same SPF algorithm (algorithm 0). Obviously other al= gorithms > | > | > could also be run. > | > | > | > | > | > | As I stated earlier, we have SR MT support via the IP/IPv6 Reac= hability TLVs > | > | > - but we overlooked this in the Binding TLV - we have now correct= ed that > | > | > oversight. > | > | > | > | > | > | Frankly, I think all of the questions you are raising are becau= se of a > | > | > misunderstanding on your part. > | > | > | > | > | > | Les > | > | > | > | > | > | > -----Original Message----- > | > | > | > From: Hannes Gredler [mailto:hannes@juniper.net] > | > | > | > Sent: Thursday, May 07, 2015 5:07 AM > | > | > | > To: Les Ginsberg (ginsberg) > | > | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil);= Ahmed > | > | > | > Bashandy (bashandy); Stephane Litkowski; bruno.decraene@orang= e.com > | > | > | > IMT/OLN; Jeff Tantsura; Wim (Wim) Henderickx; Pushpasis Sarka= r > | > | > | > Subject: Re: latest update of > | > | > | > draft-ietf-isis-segment-routing-extensions > | > | > | > > | > | > | > hi les, > | > | > | > > | > | > | > understood: where is the use-case for MT enabled Binding TLVs= and > | > | > | > what is the Path calculation algorithm that is being used for > | > | > | > attaching the information found in MT Binding TLVs. > | > | > | > > | > | > | > So far the major function that has been implemented using Bin= ding > | > | > | > TLVs has been the mapping server. - we have a doucment for th= at. > | > | > | > > | > | > | > where is a similar decription for the MT Binding TLV (e.g. "i= want > | > | > | > to do MT- LDP Mapping server") > | > | > | > > | > | > | > /hannes > | > | > | > > | > | > | > On Wed, May 06, 2015 at 05:07:51PM +0000, Les Ginsberg (ginsb= erg) > | > | > wrote: > | > | > | > | Hannes - > | > | > | > | > | > | > | > | If we support multiple topologies that means we can have di= fferent > | > | > | > | paths > | > | > | > in the forwarding plane for the same prefix in each topology.= If we > | > | > | > are using an MPLS dataplane that means we need different labe= ls for > | > | > | > the same prefix in each topology. (How packets are classified= into a > | > | > | > given topology is out of scope of this discussion). I therefo= re need > | > | > | > the ability to install topology specific labels in the forwar= ding > | > | > | > plane - which means I need to be able to advertise topology s= pecific > | > | > | > SIDs. As I mentioned in my earlier reply, we have the ability= to do > | > | > | > that in MT Reachability advertisements - but currently we did= not > | > | > | > include the same capability in the Binding TLV. The latest ve= rsion of the > | > | > draft corrects that omission. > | > | > | > | > | > | > | > | Les > | > | > | > | > | > | > | > | > | > | > | > | > -----Original Message----- > | > | > | > | > From: Hannes Gredler [mailto:hannes@juniper.net] > | > | > | > | > Sent: Wednesday, May 06, 2015 9:52 AM > | > | > | > | > To: Stefano Previdi (sprevidi) > | > | > | > | > Cc: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashand= y); > | > | > | > | > Stephane Litkowski; bruno.decraene@orange.com IMT/OLN; Je= ff > | > | > | > | > Tantsura; Wim (Wim) Henderickx; Les Ginsberg (ginsberg); > | > | > | > | > Pushpasis Sarkar > | > | > | > | > Subject: Re: latest update of > | > | > | > | > draft-ietf-isis-segment-routing-extensions > | > | > | > | > > | > | > | > | > On Wed, May 06, 2015 at 01:32:23PM +0000, Stefano Previdi > | > | > | > | > (sprevidi) > | > | > | > wrote: > | > | > | > | > | On May 5, 2015, at 7:52 AM, Hannes Gredler > | > | > | > | > | > | > | > | > wrote: > | > | > | > | > | > hi stefano, et al, > | > | > | > | > | > > | > | > | > | > | > i cannot get my head around the need/use-case for MTI= D for > | > | > | > | > | > binding > | > | > | > | > TLVs. > | > | > | > | > | > > | > | > | > | > | > my naive view is that MT information is generally use= d to > | > | > | > | > | > SPF computation for supporting non-congurent SPT tree= s. > | > | > | > | > | > > | > | > | > | > | > since SPT does not use any of the binding TLV informa= tion today: > | > | > | > | > | > for what use-case would one need the MT marker ? > | > | > | > | > | > > | > | > | > | > | > i seem to recall that this was brought up by E/// eng= ineers, > | > | > | > | > | > so maybe jeff et al can highlight a usecase where MT = for > | > | > | > | > | > binding TLV might be useful. > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | well, I presume a MT implementation would also like to = use paths > | > | > (i.e.: > | > | > | > | > binding TLVs) associated to a given topology... just gues= sing here. > | > | > | > | > > | > | > | > | > that was my initial guess as well - the catch with that i= s that > | > | > | > | > contents of the binding TLV are not yet explored in any o= f the > | > | > | > | > routw-calculation pieces (SPF) we have ... > | > | > | > | > > | > | > | > | > so whats the point on making them MT aware ? > | > | > | > | > > | > | > | > | > | > > | > | > | > | > | > On Mon, Apr 27, 2015 at 03:10:47PM +0000, Stefano Pre= vidi > | > | > | > | > | > (sprevidi) > | > | > | > | > wrote: > | > | > | > | > | > | . Introduced a new top level TLV: MT-Binding TLV. > | > | > | > | > | > | Originally we thought we could just add a MTID subT= LV to > | > | > | > | > | > | the existing > | > | > | > | > Binding TLV however, this may cause interop problems with > | > | > | > | > implementations not supporting the MTID and therefore ign= oring > | > | > | > | > it (which would have the effect of merging topologies). > | > | > | > | > | > |=20 From nobody Thu May 21 07:22:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB171A0398; Thu, 21 May 2015 06:27:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 har_z0KCSnbk; Thu, 21 May 2015 06:27:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726A91A1BA2; Thu, 21 May 2015 06:27:03 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; Received: from hannes-mba.local (193.110.55.11) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 13:27:00 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 96840136265A; Thu, 21 May 2015 15:26:47 +0200 (CEST) Date: Thu, 21 May 2015 15:26:47 +0200 From: Hannes Gredler To: "Stefano Previdi (sprevidi)" Message-ID: <20150521132647.GB62835@hannes-mba.local> References: <20150506165154.GB1769@hannes-mba.local> <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.11] X-ClientProxiedBy: HE1PR02CA0038.eurprd02.prod.outlook.com (25.162.33.48) To DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR05MB446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB446; X-Forefront-PRVS: 0583A86C08 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(93886004)(50466002)(68736005)(92566002)(83506001)(46102003)(122386002)(77156002)(40100003)(87976001)(64706001)(2950100001)(122856001)(47776003)(230783001)(110136002)(46406003)(50986999)(86362001)(5001830100001)(189998001)(33656002)(5001860100001)(101416001)(98436002)(105586002)(23726002)(77096005)(66066001)(106356001)(76506005)(5001960100002)(76176999)(54356999)(62966003)(97756001)(4001540100001)(81156007)(97736004)(4001350100001)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; 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 13:27:00.8961 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB446 Archived-At: X-Mailman-Approved-At: Thu, 21 May 2015 07:22:37 -0700 Cc: "Les Ginsberg \(ginsberg\)" , "" , "Ahmed Bashandy \(bashandy\)" , "isis-wg@ietf.org list" , "Clarence Filsfils \(cfilsfil\)" , Stephane Litkowski , Christian Hopps , Jeff Tantsura , "bruno.decraene@orange.com IMT/OLN" , Pushpasis Sarkar , "John G. Scudder" , "Wim \(Wim\) Henderickx" Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:27:05 -0000 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 From nobody Thu May 21 07:34:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@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 To: "Stefano Previdi (sprevidi)" Message-ID: <20150521143425.GA63432@hannes-mba.local> References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: 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: 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: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 | From nobody Thu May 21 08:15:45 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03101A8731; Thu, 21 May 2015 08:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6zrm02t3m9G; Thu, 21 May 2015 08:15:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BFE1A870B; Thu, 21 May 2015 08:15:00 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D0E061B8440; Thu, 21 May 2015 17:14:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfeda07.si.francetelecom.fr (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 From: To: Hannes Gredler , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQgPxXvBzpTyLq8EquUkRNFGr7jp1tQTsAgAISygCAADe9AP//rzGggAGTrAD//+YicIALm9KAgADtwZCABOuaAIAADViAgANMfICAASvogIAANcGAgAAH7gD//5WgAAAFmhpA 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> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.21.142416 Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 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=20 -----Message d'origine----- De=A0: spring [mailto:spring-bounces@ietf.org] De la part de Hannes Gredler Envoy=E9=A0: jeudi 21 mai 2015 16:34 =C0=A0: Stefano Previdi (sprevidi) Cc=A0: spring@ietf.org; isis-wg@ietf.org list Objet=A0: Re: [spring] latest update of draft-ietf-isis-segment-routing-ext= ensions 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 Bi= nding 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.=20 in contrast all exisiting MT TLVs carry information which have direct relev= ance 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). =20 what is not clear to me: why do we need to augment non-IP advertisments with extensions that are onl= y relevant for IP path construction. - the intersection between the two see= ms zero to me. | SP> Also, would you also suggest to make it _not_ MT aware in OSPF ? In s= uch case we have to change the OSPF spec. same reasoning here: in case its not clear what/how to use MT in the bindin= g TLV for, we should remove it. /hannes | On May 21, 2015, at 3:26 PM, Hannes Gredler wrote: |=20 | > hi stefano, | >=20 | > On Thu, May 21, 2015 at 10:14:20AM +0000, Stefano Previdi (sprevidi) wr= ote: | > [ ... ] | > | > | SP> why not creating a new thread explaining the issue and includ= ing isis and spring wg ? | > | >=20 | > | > HG> thats a good suggestion - please do it ! - we need to be=20 | > | > HG> clear on the protocol requirements *before* adding protocol=20 | > | > HG> extensions. | > |=20 | > | SP> well, we agreed already at multiple occasions (last one was=20 | > | SP> during the meeting in Dallas where you and me agreed to add MT su= pport to the Binding TLV) so we're inline with the process, right ? | >=20 | > again this is meant as a friendly reminder to document (e.g. in some=20 | > of the SPRING documents where you have the pen) how you want to intend = to use the MT extensions for the binding TLV. | >=20 | > its not yet clear to me and i'd like to get an answer on this before=20 | > progressing the protocol extensions in the ISIS and OSPF working groups. | >=20 | > /hannes |=20 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Thu May 21 09:43:56 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6459F1A8892; Thu, 21 May 2015 09:43:53 -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 WQeOs-LibDAi; Thu, 21 May 2015 09:43:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248B71A1B81; Thu, 21 May 2015 09:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3787; q=dns/txt; s=iport; t=1432226630; x=1433436230; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O63aetnnZHjjnarsa1q/k/qkQljN2jT9TOjGEaRSJ+w=; b=fidlV4HloyFKOwOlX69R7JwTNh4axcg9dWQMDe4Y12DOqOMQYleej3hB T0m9jWx7IwUuE8TpTc2gWCCTBQ6qpKVxUEImaQo0mBKYyI99fvvlVd8FZ +r4pLd2libq0l7Qg7MtR5u+WKImM4QKMEq1KRZ/z5PJ4mycR1dJyHc60S Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBAAlCl5V/4YNJK1cgxCBMgbCJWYJh1ACgUg4FAEBAQEBAQGBCoQiAQEBAwE6LRIFCwIBCBgeEDIlAgQOBYgkCNI1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hDoYMweDF4EWBZJ6iweBKINrii+EAoNZI4FmJByBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,470,1427760000"; d="scan'208";a="152276957" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 21 May 2015 16:43:49 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4LGhneT025645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 16:43:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.6]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 21 May 2015 11:43:49 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQk9NEzjFgALlbsU+FvbpWwseGIp2G9s4A Date: Thu, 21 May 2015 16:43:48 +0000 Message-ID: <48857DE7-3CA6-45D1-A66E-B98C427C844F@cisco.com> References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <20150521143425.GA63432@hannes-mba.local> In-Reply-To: <20150521143425.GA63432@hannes-mba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DCB77571C1EA14F9FCDA7AF6D390312@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:43:53 -0000 Hi Hannes, On May 21, 2015, at 4:34 PM, Hannes Gredler wrote: > hi stefano, >=20 > On Thu, May 21, 2015 at 01:55:07PM +0000, Stefano Previdi (sprevidi) wrot= e: > | [... ] > | SP> Can you clarify in a new thread what is your problem in making the = Binding TLV _not_ MT aware in ISIS ? >=20 > very simple explanation: >=20 > Binding TLV only carries non-IP (e.g. MPLS labels, SRGB Indexes) informat= ion > at no point it carries information which directly affects IP forwarding= state.=20 it propagates information about paths that are useable in a topology. > in contrast all exisiting MT TLVs carry information which have direct rel= evance > 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). >=20 > 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.=20 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 I= SIS, including prefixes and adjacencies. SR introduced the Binding TLV which is also a piece of topology since it re= presents a useable path in the topology.=20 Therefore, it makes sense to me to add a MT-ID to the Binding TLV.=20 Note also that the Binding TLV is used by the Mapping Server. There too, th= e 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 informa= tion (prefixes, adjacencies) are advertised within topology ID 2. It wouldn= 't make sense to advertise IPv6/SID mappings without any topology identifie= r.=20 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. >=20 > same reasoning here: in case its not clear what/how to use MT in the bind= ing TLV for, we should remove it. well, it looks to me the ospf wg clearly understood and acknowledged the ne= ed 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. >=20 > /hannes >=20 > | On May 21, 2015, at 3:26 PM, Hannes Gredler wrote: > |=20 > | > hi stefano, > | >=20 > | > 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 incl= uding isis and spring wg ? > | > | >=20 > | > | > HG> thats a good suggestion - please do it ! -=20 > | > | > HG> we need to be clear on the protocol requirements *before* add= ing > | > | > HG> protocol extensions. > | > |=20 > | > | SP> well, we agreed already at multiple occasions (last one was dur= ing the meeting in Dallas > | > | SP> where you and me agreed to add MT support to the Binding TLV) s= o we're inline with the process, right ?=20 > | >=20 > | > 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 extensio= ns for the binding TLV. > | >=20 > | > 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. > | >=20 > | > /hannes > |=20 From nobody Thu May 21 10:56:12 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C791A00D6; Thu, 21 May 2015 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3E-0wpxhGe9; Thu, 21 May 2015 10:56:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474A51A006B; Thu, 21 May 2015 10:56:06 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-77-555db75406a9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 66.EC.06409.457BD555; Thu, 21 May 2015 12:45:41 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) 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: <1B502206DFA0C544B7A60469152008633F6E9FD5@eusaamb105.ericsson.se> References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <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: [147.117.188.9] 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: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 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 (m= ay 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 informat= ion (prefixes, adjacencies) are advertised within topology ID 2. > It wouldn't make sense to advertise IPv6/SID mappings without any topolog= y identifier. If we do that it *may* become default topology (RFC 5308) and which may n= ot be what is intended. But my unanswered question in this context is there is no topology informat= ion 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 orthogon= al.. -- Uma C. -----Original Message----- From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano Previd= i (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-ext= ensions Hi Hannes, On May 21, 2015, at 4:34 PM, Hannes Gredler wrote: > hi stefano, >=20 > On Thu, May 21, 2015 at 01:55:07PM +0000, Stefano Previdi (sprevidi) wrot= e: > | [... ] > | SP> Can you clarify in a new thread what is your problem in making the = Binding TLV _not_ MT aware in ISIS ? >=20 > very simple explanation: >=20 > Binding TLV only carries non-IP (e.g. MPLS labels, SRGB Indexes) informat= ion > at no point it carries information which directly affects IP forwarding= state.=20 it propagates information about paths that are useable in a topology. > in contrast all exisiting MT TLVs carry information which have direct rel= evance > 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). >=20 > what is not clear to me: > why do we need to augment non-IP advertisments with extensions that=20 > are only relevant for IP path construction. - the intersection between=20 > the two seems zero to me. ok, let's try to clarify the point then.=20 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 I= SIS, including prefixes and adjacencies. SR introduced the Binding TLV which is also a piece of topology since it re= presents a useable path in the topology.=20 Therefore, it makes sense to me to add a MT-ID to the Binding TLV.=20 Note also that the Binding TLV is used by the Mapping Server. There too, th= e 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 informa= tion (prefixes, adjacencies) are advertised within topology ID 2. It wouldn= 't make sense to advertise IPv6/SID mappings without any topology identifie= r.=20 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. >=20 > same reasoning here: in case its not clear what/how to use MT in the bind= ing TLV for, we should remove it. well, it looks to me the ospf wg clearly understood and acknowledged the ne= ed 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. >=20 > /hannes >=20 > | On May 21, 2015, at 3:26 PM, Hannes Gredler wrote: > |=20 > | > hi stefano, > | >=20 > | > 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 incl= uding isis and spring wg ? > | > | >=20 > | > | > HG> thats a good suggestion - please do it ! - we need to be=20 > | > | > HG> clear on the protocol requirements *before* adding=20 > | > | > HG> protocol extensions. > | > |=20 > | > | SP> well, we agreed already at multiple occasions (last one was=20 > | > | 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 ? > | >=20 > | > again this is meant as a friendly reminder to document (e.g. in=20 > | > some of the SPRING documents where you have the pen) how you want to = intend to use the MT extensions for the binding TLV. > | >=20 > | > its not yet clear to me and i'd like to get an answer on this=20 > | > before progressing the protocol extensions in the ISIS and OSPF worki= ng groups. > | >=20 > | > /hannes > |=20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu May 21 11:14:41 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEC1A1A7E; Thu, 21 May 2015 11:14:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 RwPiUFeDS0Yx; Thu, 21 May 2015 11:14:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59231A1A00; Thu, 21 May 2015 11:14:35 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (25.162.224.23) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 21 May 2015 18:14:33 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([25.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([25.162.224.23]) with mapi id 15.01.0166.017; Thu, 21 May 2015 18:14:33 +0000 From: Pushpasis Sarkar To: "Stefano Previdi (sprevidi)" , Hannes Gredler Thread-Topic: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQk/H8cI/ruWo7QE2epG7fuO7eHA== Date: Thu, 21 May 2015 18:14:32 +0000 Message-ID: References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <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: user-agent: Microsoft-MacOutlook/14.5.0.150423 authentication-results: spf=none (sender IP is ) smtp.mailfrom=psarkar@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.15] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; x-microsoft-antispam-prvs: 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)(51704005)(479174004)(199003)(377454003)(57704003)(189002)(24454002)(5001770100001)(66066001)(97736004)(5001860100001)(62966003)(77156002)(5001830100001)(105586002)(50986999)(19580405001)(122556002)(99286002)(4001540100001)(81156007)(83506001)(87936001)(92566002)(4001350100001)(86362001)(101416001)(19580395003)(64706001)(2656002)(40100003)(1941001)(230783001)(106356001)(106116001)(36756003)(2950100001)(2900100001)(76176999)(15975445007)(54356999)(102836002)(189998001)(46102003)(5001960100002)(68736005)(93886004)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3B3C757FA9F4DD49A1D1AB2F4944CEC3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 18:14:32.8403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:14:38 -0000 Hi Stefano, As much I understand the LDP mapping server functionality the Label-Binding TLV shall be used to map a SR Node-SID-Index with a FEC originated by SR-incapable node. Now in regular SPRING domain a SR-capable node does not generate one Node-SID-Index for a given node address (loopback) per topology. The index is still one for the address across all topologies. Do you suggest that there should be a Node-SID-Index configured for every topology? If not, then I don=B9t see a need of mapping different node-sid-index for the same prefix under different topology. Thanks -Pushpasis On 5/21/15, 10:13 PM, "Stefano Previdi (sprevidi)" wrote: >Hi Hannes, > >On May 21, 2015, at 4:34 PM, Hannes Gredler wrote: >> hi stefano, >>=20 >> 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 ? >>=20 >> very simple explanation: >>=20 >> 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). >>=20 >> 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. >>=20 >> 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). > >s. > > >>=20 >> /hannes >>=20 >> | On May 21, 2015, at 3:26 PM, Hannes Gredler >>wrote: >> |=20 >> | > hi stefano, >> | >=20 >> | > 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 ? >> | > | >=20 >> | > | > HG> thats a good suggestion - please do it ! - >> | > | > HG> we need to be clear on the protocol requirements *before* >>adding >> | > | > HG> protocol extensions. >> | > |=20 >> | > | 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 ? >> | >=20 >> | > 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. >> | >=20 >> | > 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. >> | >=20 >> | > /hannes >> |=20 > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri May 22 12:44:19 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD601A874F; Fri, 22 May 2015 12:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-sUshBnAO_s; Fri, 22 May 2015 12:44:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190AA1A874E; Fri, 22 May 2015 12:44:06 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-ef-555f221651dd Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F3.D9.06409.6122F555; Fri, 22 May 2015 14:33:26 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Fri, 22 May 2015 15:44: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/+gVeL0qCCi1USeL23J2G5gUAgAF/6YA= Date: Fri, 22 May 2015 19:44:03 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F6EB1EE@eusaamb105.ericsson.se> References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <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: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPlK6YUnyowe6V4hb9956wWRw99J7V Yv3uR0wWxy/8ZnRg8ZjyeyOrx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DKaJm3lqngs0pF y/HDLA2Mf2W6GDk5JARMJP6cPM8KYYtJXLi3nq2LkYtDSOAoo8Sh71MYIZzljBJTulpYQKrY BPQkPk79yQ5iiwjESGy6ewzMZhYIlbi/4j+YLSwQItE1+RdUTajEusZdjBC2lcSha8/A4iwC qhKXl+1mBrF5BXwltje/ZIFY9ohF4sGFc2ANnAK2Elt2TwSzGYHO+35qDRPEMnGJW0/mM0Gc LSCxZM95ZghbVOLl439Q7yhJTFp6jhWiXkdiwe5PbBC2tsSyha+hFgtKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3MQLj6JgEm+MOxgWfLA8xCnAwKvHwLuiNCxViTSwr rsw9xCjNwaIkzntRNSRUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P5d7llXw7216szxgbK NQWc3snFvDo7+sT0dwt2Nd1R1di42fZcflPt4fdiX186PxV9d/1siHrfxKbdT07V84oecTnM wXFoXh5PNfeUE8E/jFV7J5bwvMgR+nirZNWjBwuPPFesy3z9aZd3jIB4efvO/fqHFoVtCHv6 cj2fZvDpD7Enk3SOMUUqsRRnJBpqMRcVJwIAIhv2lYQCAAA= Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 19:44:09 -0000 I see this - As today binding TLVs can be used for advertising both=20 a. prefixes (for mapping server functionality on behalf of unsupported SR n= odes) as well as to=20 b. advertise paths/ERO/Backup-EROs/Etc... 1. We *may* need MT ID if we are trying to achieve #a above (again doing MT= for e.g., even for V4 only with LDP is a different question though).=20 2. We don't need MT ID for #b above. This need to be clarified IMO, in the draft. -- Uma C. -----Original Message----- From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano Previd= i (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-ext= ensions Hi Hannes, On May 21, 2015, at 4:34 PM, Hannes Gredler wrote: > hi stefano, >=20 > On Thu, May 21, 2015 at 01:55:07PM +0000, Stefano Previdi (sprevidi) wrot= e: > | [... ] > | SP> Can you clarify in a new thread what is your problem in making the = Binding TLV _not_ MT aware in ISIS ? >=20 > very simple explanation: >=20 > Binding TLV only carries non-IP (e.g. MPLS labels, SRGB Indexes) informat= ion > at no point it carries information which directly affects IP forwarding= state.=20 it propagates information about paths that are useable in a topology. > in contrast all exisiting MT TLVs carry information which have direct rel= evance > 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). >=20 > what is not clear to me: > why do we need to augment non-IP advertisments with extensions that=20 > are only relevant for IP path construction. - the intersection between=20 > the two seems zero to me. ok, let's try to clarify the point then.=20 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 I= SIS, including prefixes and adjacencies. SR introduced the Binding TLV which is also a piece of topology since it re= presents a useable path in the topology.=20 Therefore, it makes sense to me to add a MT-ID to the Binding TLV.=20 Note also that the Binding TLV is used by the Mapping Server. There too, th= e 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 informa= tion (prefixes, adjacencies) are advertised within topology ID 2. It wouldn= 't make sense to advertise IPv6/SID mappings without any topology identifie= r.=20 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. >=20 > same reasoning here: in case its not clear what/how to use MT in the bind= ing TLV for, we should remove it. well, it looks to me the ospf wg clearly understood and acknowledged the ne= ed 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. >=20 > /hannes >=20 > | On May 21, 2015, at 3:26 PM, Hannes Gredler wrote: > |=20 > | > hi stefano, > | >=20 > | > 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 incl= uding isis and spring wg ? > | > | >=20 > | > | > HG> thats a good suggestion - please do it ! - we need to be=20 > | > | > HG> clear on the protocol requirements *before* adding=20 > | > | > HG> protocol extensions. > | > |=20 > | > | SP> well, we agreed already at multiple occasions (last one was=20 > | > | 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 ? > | >=20 > | > again this is meant as a friendly reminder to document (e.g. in=20 > | > some of the SPRING documents where you have the pen) how you want to = intend to use the MT extensions for the binding TLV. > | >=20 > | > its not yet clear to me and i'd like to get an answer on this=20 > | > before progressing the protocol extensions in the ISIS and OSPF worki= ng groups. > | >=20 > | > /hannes > |=20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri May 22 22:34:19 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@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)" To: "Stefano Previdi (sprevidi)" , Hannes Gredler 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: References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <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: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.=20 A label - to borrow a phrase used by others - is an instruction to the forw= arding plane to send a packet along a given path. Clearly, when IGPs calcul= ate paths they do so in the context of a topology. So if we are going to us= e 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 rea= chability TLVs defined in RFC 5120. When a mapping server is used in place of advertising SIDs in prefix reacha= bility 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 Prev= idi > (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 >=20 > Hi Hannes, >=20 > 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 th= e > 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 forwardi= ng state. >=20 [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 val= ues advertised by the IGPs is how the topology specific instruction for a g= iven prefix are passed to the forwarding plane.=20 >=20 > it propagates information about paths that are useable in a topology. >=20 >=20 > > 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. >=20 >=20 > ok, let's try to clarify the point then. >=20 > 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. >=20 > SR introduced the Binding TLV which is also a piece of topology since it > represents a useable path in the topology. >=20 > Therefore, it makes sense to me to add a MT-ID to the Binding TLV. >=20 > 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 IP= v6 > information (prefixes, adjacencies) are advertised within topology ID 2. = It > wouldn't make sense to advertise IPv6/SID mappings without any topology > identifier. >=20 > Therefore, to me, it is straightforward to enhance the Binding TLV with M= T > capability. >=20 >=20 > > | 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 advertis= e 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 >=20 >=20 > 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. >=20 > Now, I'd be interested to know other people opinion on this (from both is= is > and spring wg's). >=20 > s. >=20 >=20 > > > > /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 M= T > 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 > > | >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri May 22 22:53:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ABF1A90D3; Fri, 22 May 2015 22:53:37 -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 wK0MDr1CAtIz; Fri, 22 May 2015 22:53:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0F81A9087; Fri, 22 May 2015 22:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7392; q=dns/txt; s=iport; t=1432360414; x=1433570014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qO8vJje2MegboiQjgv2oo8KcHmKWYdvcZvzMUJNWtfE=; b=LF/UAvesU4lpt0j/lPTgA8jckFVQoaqM+sEEU22Hzpv2DBcJqtHXlrX1 u8I2safe1B4DNp02FF8vLU5Af8uL9pVKuM8fyMfA9FwHXSw0Kh5NxLq6I UYKRwLimzYuy6OYbhe3E8Fc5+eZIsoYQFZrIZP9zKT/AJQz8723ZutjHa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D+AwCrFGBV/4oNJK1cgxBUXgbDHAmBTwqFdwKBMDgUAQEBAQEBAYEKhCIBAQEDAQEBATctBwsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiBwIDdM5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOoQsDhoxBwaDEYEWBZMIjDiDcYo2hAaDWSOBZiQcgVJvgQNDgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,480,1427760000"; d="scan'208";a="152728857" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2015 05:53:33 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4N5rVAv012943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 May 2015 05:53:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sat, 23 May 2015 00:53:31 -0500 From: "Les Ginsberg (ginsberg)" To: Uma Chunduri , "Stefano Previdi (sprevidi)" , Hannes Gredler Thread-Topic: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions Thread-Index: AQHQk+9vdkq/tOoMA0K6+YtcZtOA552JDFhg Date: Sat, 23 May 2015 05:53:31 +0000 Message-ID: References: <20150507120728.GB3896@hannes-mba.local> <20150514195127.GB26771@hannes-mba.local> <20150518131042.GA37696@hannes-mba.local> <20150520162058.GE55346@hannes-mba.local> <3A2A07D9-AA43-496E-83FE-642A935D59F9@cisco.com> <20150521132647.GB62835@hannes-mba.local> <20150521143425.GA63432@hannes-mba.local> <48857DE7-3CA6-45D1-A66E-B98C427C844F@cisco.com> <1B502206DFA0C544B7A60469152008633F6E9FD5@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F6E9FD5@eusaamb105.ericsson.se> 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: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" Subject: Re: [spring] [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 05:53:37 -0000 Uma - > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Uma Chunduri > Sent: Thursday, May 21, 2015 10:56 AM > To: Stefano Previdi (sprevidi); Hannes Gredler > Cc: spring@ietf.org; isis-wg@ietf.org list > Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing- > extensions >=20 > Hi Stefano, >=20 > 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. >=20 > 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. >=20 > If we do that it *may* become default topology (RFC 5308) and which may > not be what is intended. [Les:] This isn't a logical conclusion - what is being done actually makes = what you suggest LESS likely. There are two ways to support IPv6 Reachability advertisements in IS-IS tod= ay: 1)RFC 5308 (TLV 236) This is often called "single topology IPv6" because the MTID for all advert= isements of this type is implied to be 0 - which means the paths to IPv6 de= stinations are calculated on a single topology which is shared with IPv4 (T= LV 135). 2)RFC 5120 (TLV 237) This is often called "multitopology IPv6" because the IPv6 Reachability adv= ertisements are explicitly identified with a separate and potentially incon= gruent topology (w respect to topology #0) There are multiple implementations of both forms of IPv6 support deployed t= oday. Making the Binding TLV have MTID support aligns it with the existing suppor= t in IS-IS today. And it means that Binding TLV can now be used to support = BOTH RFC 5308 and RFC 5120 based deployments of IPv6. RFC 5120 technology can be (and has been) used as a means of supporting mul= tiple topologies for a given address family - as well as multiple topologie= s each of which supports multiple address families. It is wrong to think we= are limited to "one IPv4 topology" and "one IPv6 topology" just because th= at is the most common use case today. If one runs standard SPF on two incon= gruent topologies clearly topology unique paths for the same destination ca= n result - and prefix-SID advertisements (whether in prefix reachability TL= Vs or Binding TLV) need to be able to support this. >=20 > 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.. [Les:] Please see my other reply in this thread. Les >=20 > -- > Uma C. >=20 > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano Prev= idi > (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 >=20 > Hi Hannes, >=20 > 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 th= e > 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 forwardi= ng state. >=20 >=20 > it propagates information about paths that are useable in a topology. >=20 >=20 > > 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. >=20 >=20 > ok, let's try to clarify the point then. >=20 > 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. >=20 > SR introduced the Binding TLV which is also a piece of topology since it > represents a useable path in the topology. >=20 > Therefore, it makes sense to me to add a MT-ID to the Binding TLV. >=20 > 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 IP= v6 > information (prefixes, adjacencies) are advertised within topology ID 2. = It > wouldn't make sense to advertise IPv6/SID mappings without any topology > identifier. >=20 > Therefore, to me, it is straightforward to enhance the Binding TLV with M= T > capability. >=20 >=20 > > | 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. >=20 >=20 > 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. >=20 > Now, I'd be interested to know other people opinion on this (from both is= is > and spring wg's). >=20 > s. >=20 >=20 > > > > /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 M= T > 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 > > | >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu May 28 06:38:40 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162F31A88C8; Thu, 28 May 2015 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SyzqbyLUjr7i; Thu, 28 May 2015 06:38:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B83CF1A889D; Thu, 28 May 2015 06:38:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528133837.14587.74348.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 06:38:37 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:38:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-03.txt Pages : 19 Date : 2015-05-28 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing extension header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer in the routing extension header. Upon completion of a segment, the pointer is incremented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 08:01:21 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5C11A924A; Fri, 29 May 2015 08:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JkbYCY15qquU; Fri, 29 May 2015 08:01:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDBF1A9231; Fri, 29 May 2015 08:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529150116.22701.53886.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 08:01:16 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:01:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : Segment Routing with MPLS data plane Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Jeff Tantsura Edward Crabbe Filename : draft-ietf-spring-segment-routing-mpls-01.txt Pages : 14 Date : 2015-05-29 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/