From nobody Tue Sep 2 08:12:30 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D071A876E; Tue, 2 Sep 2014 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1UcT_DdvdJWp; Tue, 2 Sep 2014 08:12:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DC41A701F; Tue, 2 Sep 2014 08:12:21 -0700 (PDT) Received: from DM2PR05MB304.namprd05.prod.outlook.com (10.141.103.24) by DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 15:12:20 +0000 Received: from DM2PR05MB303.namprd05.prod.outlook.com (10.141.103.15) by DM2PR05MB304.namprd05.prod.outlook.com (10.141.103.24) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 2 Sep 2014 15:12:19 +0000 Received: from DM2PR05MB303.namprd05.prod.outlook.com ([10.141.103.15]) by DM2PR05MB303.namprd05.prod.outlook.com ([10.141.103.15]) with mapi id 15.00.1019.015; Tue, 2 Sep 2014 15:12:19 +0000 From: Chris Bowers To: "spring@ietf.org" Thread-Topic: carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: Ac/Gv/F9w1x680bbTQ+xOgAabVdPGQ== Date: Tue, 2 Sep 2014 15:12:18 +0000 Message-ID: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(164054003)(31966008)(74662001)(74502001)(15202345003)(108616004)(4396001)(85306004)(19580395003)(33646002)(50986999)(54356999)(99396002)(83322001)(46102001)(110136001)(21056001)(64706001)(85852003)(101416001)(83072002)(90102001)(79102001)(80022001)(15975445006)(2501002)(66066001)(2656002)(86362001)(81542001)(105586002)(81342001)(87936001)(76576001)(20776003)(2351001)(77982001)(229853001)(107046002)(74316001)(95666004)(99286002)(76482001)(92566001)(106356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB304; H:DM2PR05MB303.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_13e9516b591b49948e5ec155c4b681b4DM2PR05MB303namprd05pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/nvGgBRpoovf7mfFzY7Q3d_OFSQQ Cc: "isis-wg@ietf.org" Subject: [Isis-wg] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 15:12:26 -0000 --_000_13e9516b591b49948e5ec155c4b681b4DM2PR05MB303namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has there been any discussion about how to carry both IPv6 and IPv4 packets= with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfils-= spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls-03= addresses this scenario. In the context of shortest-path forwarding using Node-SID labels, there wou= ld seem to be two main approaches to consider. One could distinguish betwe= en IPv6 and IPv4 packets by using two different Node-SID labels for the sam= e node. Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on t= he bottom of the label stack by the SR ingress router. Do the authors of these drafts or other working group participants have an = opinion on the best way to address this scenario? Thanks, Chris --_000_13e9516b591b49948e5ec155c4b681b4DM2PR05MB303namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Has there been any discussion about how to carry both IPv6 and IPv4 pa= ckets with SPRING/SR MPLS labels?  From what I can tell, neither draft= -filsfils-spring-segment-routing-04 nor draft-filsfils-spring-segment-routi= ng-mpls-03 addresses this scenario.
 
In the context of shortest-path forwarding using Node-SID labels, ther= e would seem to be two main approaches to consider.  One could disting= uish between IPv6 and IPv4 packets by using two different Node-SID labels f= or the same node.  Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bottom of the label stack by= the SR ingress router.
 
Do the authors of these drafts or other working group participants hav= e an opinion on the best way to address this scenario?
 
Thanks,
Chris
 
 
 
--_000_13e9516b591b49948e5ec155c4b681b4DM2PR05MB303namprd05pro_-- From nobody Tue Sep 2 08:21:13 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA41A0642; Tue, 2 Sep 2014 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 z_wCj6EB1PoE; Tue, 2 Sep 2014 08:21:08 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D001A0424; Tue, 2 Sep 2014 08:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1417; q=dns/txt; s=iport; t=1409671268; x=1410880868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oXjrXo5fq1YAZ4tqcu+idrhxcak41V9ViQuI/CLotnM=; b=URfarWFRf80X0tvdapOx5wxEOxDXJEmG/rQC98iA91kJgnB/wLKzW8j4 GKNT/Et7VOWGyPsJn/O81ifDm7Fo06b1LCaQzvpR670mL5+ilBKM8Z8tD k3GFe9Knt5VVMu6gSp+m4JpjQ338h51VoFz+tFVVdZ5uENe1+Ng5EGRoL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAETfBVStJA2B/2dsb2JhbABagw1TVwTIDwqGeVMBgRMWd4QDAQEBAwEBAQE3NAsFCwIBCA4KHhAnCyUBAQQOBYg6CA27SAETBI8aMweDL4EdBZExiyuVHoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="74249362" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 02 Sep 2014 15:21:02 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s82FL2X5032272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 15:21:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 10:21:02 -0500 From: "Stefano Previdi (sprevidi)" To: Chris Bowers Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: Ac/Gv/F9w1x680bbTQ+xOgAabVdPGQAK3cGA Date: Tue, 2 Sep 2014 15:21:01 +0000 Message-ID: <5FF3A838-09FF-47DA-B516-21F7E3733E22@cisco.com> References: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> In-Reply-To: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FAAADED90851F499B360BFA3EE2F1E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/SL7rrWjPIDwNO9yJAacR8dGaaso Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 15:21:10 -0000 Hi Chris, On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: > Has there been any discussion about how to carry both IPv6 and IPv4 packe= ts with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfil= s-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls-= 03 addresses this scenario. sid's are assigned to ip addresses (e.g. intf addresses). A node having two= loopbacks (v4/v6) will have a sid for the ipv4 address and another one for= the ipv6. Then you compute your spt's or explicit paths based on your af-topology and= you pick the right sid's stack. =20 > In the context of shortest-path forwarding using Node-SID labels, there w= ould seem to be two main approaches to consider. One could distinguish bet= ween IPv6 and IPv4 packets by using two different Node-SID labels for the s= ame node. correct. this is same as above: one sid per address (one for v4 and one for= v6). s. > Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bot= tom of the label stack by the SR ingress router. > =20 > Do the authors of these drafts or other working group participants have a= n opinion on the best way to address this scenario? > =20 > Thanks, > Chris > =20 > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Sep 2 09:17:10 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F21A0700; Tue, 2 Sep 2014 09:17:07 -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 I5nnSwbZd3wy; Tue, 2 Sep 2014 09:17:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33CA1A06EE; Tue, 2 Sep 2014 09:17:04 -0700 (PDT) Received: from DM2PR05MB303.namprd05.prod.outlook.com (10.141.103.15) by DM2PR05MB302.namprd05.prod.outlook.com (10.141.103.12) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 16:17:02 +0000 Received: from DM2PR05MB303.namprd05.prod.outlook.com ([10.141.103.15]) by DM2PR05MB303.namprd05.prod.outlook.com ([10.141.103.15]) with mapi id 15.00.1019.015; Tue, 2 Sep 2014 16:17:02 +0000 From: Chris Bowers To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: AQHPxsGIbHxG5LVgDE+GjGvmzRmylpvt/13w Date: Tue, 2 Sep 2014 16:17:01 +0000 Message-ID: <153cb0838cff4c8b95afb611689f8e06@DM2PR05MB303.namprd05.prod.outlook.com> References: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> <5FF3A838-09FF-47DA-B516-21F7E3733E22@cisco.com> In-Reply-To: <5FF3A838-09FF-47DA-B516-21F7E3733E22@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(24454002)(377454003)(199003)(51704005)(164054003)(189002)(13464003)(4396001)(74662001)(83072002)(101416001)(90102001)(64706001)(83322001)(80022001)(79102001)(87936001)(74502001)(77982001)(81542001)(85306004)(85852003)(19580405001)(81342001)(20776003)(46102001)(15975445006)(76482001)(2656002)(21056001)(86362001)(33646002)(99396002)(50986999)(95666004)(54356999)(76176999)(92566001)(110136001)(19580395003)(99286002)(106116001)(31966008)(108616004)(66066001)(76576001)(105586002)(106356001)(74316001)(107046002)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB302; H:DM2PR05MB303.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/JdpB3P40K8keKAFiRlIFsOX4p2E Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:17:07 -0000 Stefano, Thanks. Is there a mechanism to advertise different label blocks for v4 an= d v6 and have a single unique index value associated with the node? This w= ould still result in different label values being used for v4 and v6 packet= s destined for the same node, but the network operator only has to assign a= single unique index value to each node. Chris -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Tuesday, September 02, 2014 10:21 AM To: Chris Bowers Cc: spring@ietf.org; isis-wg@ietf.org Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with M= PLS dataplane Hi Chris, On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: > Has there been any discussion about how to carry both IPv6 and IPv4 packe= ts with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfil= s-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls-= 03 addresses this scenario. sid's are assigned to ip addresses (e.g. intf addresses). A node having two= loopbacks (v4/v6) will have a sid for the ipv4 address and another one for= the ipv6. Then you compute your spt's or explicit paths based on your af-topology and= you pick the right sid's stack. =20 > In the context of shortest-path forwarding using Node-SID labels, there w= ould seem to be two main approaches to consider. One could distinguish bet= ween IPv6 and IPv4 packets by using two different Node-SID labels for the s= ame node. correct. this is same as above: one sid per address (one for v4 and one for= v6). s. > Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bot= tom of the label stack by the SR ingress router. > =20 > Do the authors of these drafts or other working group participants have a= n opinion on the best way to address this scenario? > =20 > Thanks, > Chris > =20 > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Sep 2 09:39:39 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4B41A0235; Tue, 2 Sep 2014 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 Eo_JKDhRmJYu; Tue, 2 Sep 2014 09:39:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBF11A011D; Tue, 2 Sep 2014 09:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2546; q=dns/txt; s=iport; t=1409675967; x=1410885567; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BRytTP+uwRhbn2bztwyPgS+3/e+YRrC4/py/cBwKSvI=; b=B4uzar6YUFBsjPEFVomVMvQo5Z1uc8AHbG4vwTv81UFkP2QbFsQW3tK2 hbiNAVYkfw1YWbzUiFjSxlUs4wVizZqfWcIfWCNwpNxP1DYtQ6hhGjG4L IuZdRnHsq6XlBPuDzOGImVrixhm7uNY6rFKLRj69hRWZCGPKMpmJFJbjH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAPjxBVStJA2N/2dsb2JhbABagw1TVwTIGAqGeVMBgRMWd4QDAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQEeCQcnCxQJCAEBBA4FiDoIDbtsARMEjxozBwaDKYEdBZExiyuVHoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,450,1406592000"; d="scan'208";a="74280167" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 02 Sep 2014 16:39:26 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s82GdQgX010296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 16:39:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 11:39:26 -0500 From: "Stefano Previdi (sprevidi)" To: Chris Bowers Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: Ac/Gv/F9w1x680bbTQ+xOgAabVdPGQAK3cGAAAH0+oAAAMf5gA== Date: Tue, 2 Sep 2014 16:39:26 +0000 Message-ID: <4A4E21C4-B261-4327-B3C5-AD74D7843B23@cisco.com> References: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> <5FF3A838-09FF-47DA-B516-21F7E3733E22@cisco.com> <153cb0838cff4c8b95afb611689f8e06@DM2PR05MB303.namprd05.prod.outlook.com> In-Reply-To: <153cb0838cff4c8b95afb611689f8e06@DM2PR05MB303.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.173.109] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B83152AFF0B9C4BA026F3BDF1373913@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/6jYqIpOqpG_g-nahSqr6e2BVtlE Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:39:29 -0000 On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote: > Stefano, >=20 > Thanks. Is there a mechanism to advertise different label blocks for v4 = and v6 and have a single unique index value associated with the node? there's a mechanism that allows you to advertise multiple label blocks and = the index is used across all of them (see isis/ospf sr extensions drafts). = Not sure if you need to explicitly advertise the af of the label block know= ing that a sid corresponds to a prefix which implies its af. s. > This would still result in different label values being used for v4 and = v6 packets destined for the same node, but the network operator only has to= assign a single unique index value to each node. >=20 > Chris >=20 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Sent: Tuesday, September 02, 2014 10:21 AM > To: Chris Bowers > Cc: spring@ietf.org; isis-wg@ietf.org > Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with= MPLS dataplane >=20 > Hi Chris, >=20 > On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: >> Has there been any discussion about how to carry both IPv6 and IPv4 pack= ets with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfi= ls-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls= -03 addresses this scenario. >=20 >=20 > sid's are assigned to ip addresses (e.g. intf addresses). A node having t= wo loopbacks (v4/v6) will have a sid for the ipv4 address and another one f= or the ipv6. >=20 > Then you compute your spt's or explicit paths based on your af-topology a= nd you pick the right sid's stack. >=20 >=20 >> In the context of shortest-path forwarding using Node-SID labels, there = would seem to be two main approaches to consider. One could distinguish be= tween IPv6 and IPv4 packets by using two different Node-SID labels for the = same node. >=20 >=20 > correct. this is same as above: one sid per address (one for v4 and one f= or v6). >=20 > s. >=20 >=20 >> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bot= tom of the label stack by the SR ingress router. >>=20 >> Do the authors of these drafts or other working group participants have = an opinion on the best way to address this scenario? >>=20 >> Thanks, >> Chris >>=20 >>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 From nobody Tue Sep 2 09:51:16 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FED1A0712; Tue, 2 Sep 2014 09:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 7WNwEJR_5kI8; Tue, 2 Sep 2014 09:51:06 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7D51A06C0; Tue, 2 Sep 2014 09:51:05 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-dc-5405a05b9ce3 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E1.A1.05330.B50A5045; Tue, 2 Sep 2014 12:47:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 12:50:55 -0400 From: Gregory Mirsky To: "Stefano Previdi (sprevidi)" , Chris Bowers Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: AQHPxsyB149dWSO+d02ubzttPX0IapvuDYSw Date: Tue, 2 Sep 2014 16:50:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82992B@eusaamb103.ericsson.se> References: <13e9516b591b49948e5ec155c4b681b4@DM2PR05MB303.namprd05.prod.outlook.com> <5FF3A838-09FF-47DA-B516-21F7E3733E22@cisco.com> <153cb0838cff4c8b95afb611689f8e06@DM2PR05MB303.namprd05.prod.outlook.com> <4A4E21C4-B261-4327-B3C5-AD74D7843B23@cisco.com> In-Reply-To: <4A4E21C4-B261-4327-B3C5-AD74D7843B23@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82992Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonXDd6AWuIwdkP+hY/1rtaHD30ntVi /e5HTBbHL/xmdGDxmPJ7I6vHkiU/mTyuN11lD2CO4rJJSc3JLEst0rdL4Mpo2PCKveCIa0XH xhnMDYwnrLoYOTkkBEwk/nU9ZoewxSQu3FvP1sXIxSEkcJRRYvWUqUwQzjJGie9vWhlBqtgE jCRebOwB6xARiJb4/+QAWJxZwE9iwaKnYHFhgSiJo8+fMMPUnO79yAhhG0kcf9MOFmcRUJFY 2/yTFcTmFfCV2NUMs6ydSWLFlqtMIAlOAVuJBW/usoHYjEDnfT+1hglimbjErSfzmSDOFpBY suc8M4QtKvHy8T9WCFtJYs7ra8wQ9fkSS3f+YIdYJihxcuYTlgmMorOQjJqFpGwWkjKIuI7E gt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipGjtDi1LDfdyGATIzDqjkmw6e5g3PPS8hCjAAej Eg+vwhaWECHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKzV uTP/pYifoffjvbcZNucf+R8o2FfkG1Rz1PrRw3ZvV7Xe040TGVPerllyTLHmfEv2z/yZOxz3 HP6kd5W/5Y74tjjORh61Rhlzplc6By4at6hseOnpLHfqc5LWYoN80Z8qEkv3bHBhnjj7SCGv UdwGjbC5Z1m6vBW+twUxMk+JTjaKX5E0TYmlOCPRUIu5qDgRANtiw3ubAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/_xGuUNkMAEBgp8TWarPajwecSfk Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:51:13 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82992Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, another method been used to differentiate IPv4 and IPv6 payload over MPLS L= SP by LERs: * IPv4 Explicit Null label for IPv4 payload; * IPv6 Explicit Null label for IPv6 payload. Regards, Greg -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Stefano Previdi = (sprevidi) Sent: Tuesday, September 02, 2014 9:39 AM To: Chris Bowers Cc: spring@ietf.org; isis-wg@ietf.org Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with M= PLS dataplane On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote: > Stefano, > > Thanks. Is there a mechanism to advertise different label blocks for v4 = and v6 and have a single unique index value associated with the node? there's a mechanism that allows you to advertise multiple label blocks and = the index is used across all of them (see isis/ospf sr extensions drafts). = Not sure if you need to explicitly advertise the af of the label block know= ing that a sid corresponds to a prefix which implies its af. s. > This would still result in different label values being used for v4 and = v6 packets destined for the same node, but the network operator only has to= assign a single unique index value to each node. > > Chris > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Sent: Tuesday, September 02, 2014 10:21 AM > To: Chris Bowers > Cc: spring@ietf.org; isis-wg@ietf.org > Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with= MPLS dataplane > > Hi Chris, > > On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: >> Has there been any discussion about how to carry both IPv6 and IPv4 pack= ets with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfi= ls-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls= -03 addresses this scenario. > > > sid's are assigned to ip addresses (e.g. intf addresses). A node having t= wo loopbacks (v4/v6) will have a sid for the ipv4 address and another one f= or the ipv6. > > Then you compute your spt's or explicit paths based on your af-topology a= nd you pick the right sid's stack. > > >> In the context of shortest-path forwarding using Node-SID labels, there = would seem to be two main approaches to consider. One could distinguish be= tween IPv6 and IPv4 packets by using two different Node-SID labels for the = same node. > > > correct. this is same as above: one sid per address (one for v4 and one f= or v6). > > s. > > >> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bot= tom of the label stack by the SR ingress router. >> >> Do the authors of these drafts or other working group participants have = an opinion on the best way to address this scenario? >> >> Thanks, >> Chris >> >> >> >> _______________________________________________ >> 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 --_000_7347100B5761DC41A166AC17F22DF1121B82992Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
another method been used to differentiate IPv4 and IPv6 payload over M= PLS LSP by LERs:
  • IPv4 Explicit Null label for IPv4 payload;
  • IPv6 Explicit Null l= abel for IPv6 payload.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of Stefano Previdi (sprevidi)
Sent: Tuesday, September 02, 2014 9:39 AM
To: Chris Bowers
Cc: spring@ietf.org; isis-wg@ietf.org
Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with M= PLS dataplane
 
On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote:
> Stefano,
>
> Thanks.  Is there a mechanism to advertise different label b= locks for v4 and v6 and have a single unique index value associated with th= e node?
 
 
there's a mechanism that allows you to advertise multiple label blocks= and the index is used across all of them (see isis/ospf sr extensions draf= ts). Not sure if you need to explicitly advertise the af of the label block= knowing that a sid corresponds to a prefix which implies its af.
 
s.
 
 
 
>  This would still result in different label values being use= d for v4 and v6 packets destined for the same node, but the network operato= r only has to assign a single unique index value to each node.
>
> Chris
>
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
> Sent: Tuesday, September 02, 2014 10:21 AM
> To: Chris Bowers
> Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING= /SR with MPLS dataplane
>
> Hi Chris,
>
> On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote:
>> Has there been any discussion about how to carry both IPv6 an= d IPv4 packets with SPRING/SR MPLS labels?  From what I can tell, neit= her draft-filsfils-spring-segment-routing-04 nor draft-filsfils-spring-segm= ent-routing-mpls-03 addresses this scenario.
>
>
> sid's are assigned to ip addresses (e.g. intf addresses). A node = having two loopbacks (v4/v6) will have a sid for the ipv4 address and anoth= er one for the ipv6.
>
> Then you compute your spt's or explicit paths based on your af-to= pology and you pick the right sid's stack.
>
>
>> In the context of shortest-path forwarding using Node-SID lab= els, there would seem to be two main approaches to consider.  One coul= d distinguish between IPv6 and IPv4 packets by using two different Node-SID= labels for the same node.
>
>
> correct. this is same as above: one sid per address (one for v4 a= nd one for v6).
>
> s.
>
>
>> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed= on the bottom of the label stack by the SR ingress router.
>>
>> Do the authors of these drafts or other working group partici= pants have an opinion on the best way to address this scenario?
>>
>> Thanks,
>> Chris
>>
>>
>>
>> _______________________________________________
>> spring mailing list
>
 
_______________________________________________
spring mailing list
 
--_000_7347100B5761DC41A166AC17F22DF1121B82992Beusaamb103erics_-- From nobody Tue Sep 2 15:55:47 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041971A88FA; Tue, 2 Sep 2014 15:55:44 -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 YFIFXu6jAIqh; Tue, 2 Sep 2014 15:55:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F2A1A88CD; Tue, 2 Sep 2014 15:55:42 -0700 (PDT) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 22:55:40 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.1019.015; Tue, 2 Sep 2014 22:55:40 +0000 From: Chris Bowers To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: Ac/HAHNIi5mjAeiDRUuQj4rS83oDug== Date: Tue, 2 Sep 2014 22:55:40 +0000 Message-ID: <28acb42d55754debaac4ede15e2f6cfa@BLUPR05MB292.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(51704005)(189002)(13464003)(164054003)(199003)(19580405001)(20776003)(19580395003)(92566001)(101416001)(46102001)(90102001)(76576001)(83322001)(2656002)(86362001)(15975445006)(33646002)(107046002)(64706001)(79102001)(74316001)(50986999)(54356999)(21056001)(99396002)(81542001)(74502001)(105586002)(83072002)(85852003)(95666004)(85306004)(80022001)(108616004)(4396001)(99286002)(74662001)(31966008)(106356001)(66066001)(76482001)(87936001)(110136001)(77982001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB289; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/b6o8iFJ-cdGDE_DfHqK-5zuI1e0 Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:55:45 -0000 Stefano, Thanks. I have a similar question regarding node-SID index values for diff= erent algorithms. Does each node need to advertise a unique index value fo= r each algorithm? For example, in a network supporting 3 algorithms, woul= d each node need to be assigned 3 unique index values for IPv4 forwarding? I was hoping to be able to assign a single unique index value to each node,= and then have each node advertise a different label block for each algorit= hm. This would achieve the same result as assigning a unique index value f= or each node for each algorithm, and it would simplify network operations. = The current versions of the ISIS and OSPF SR extensions don't appear to su= pport advertising a different label block for each algorithm, but I wanted = to make sure I'm not misreading the drafts. Thanks, Chris -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Tuesday, September 02, 2014 11:39 AM To: Chris Bowers Cc: spring@ietf.org; isis-wg@ietf.org Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with M= PLS dataplane On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote: > Stefano, >=20 > Thanks. Is there a mechanism to advertise different label blocks for v4 = and v6 and have a single unique index value associated with the node? there's a mechanism that allows you to advertise multiple label blocks and = the index is used across all of them (see isis/ospf sr extensions drafts). = Not sure if you need to explicitly advertise the af of the label block know= ing that a sid corresponds to a prefix which implies its af. s. > This would still result in different label values being used for v4 and = v6 packets destined for the same node, but the network operator only has to= assign a single unique index value to each node. >=20 > Chris >=20 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Sent: Tuesday, September 02, 2014 10:21 AM > To: Chris Bowers > Cc: spring@ietf.org; isis-wg@ietf.org > Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with= MPLS dataplane >=20 > Hi Chris, >=20 > On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: >> Has there been any discussion about how to carry both IPv6 and IPv4 pack= ets with SPRING/SR MPLS labels? From what I can tell, neither draft-filsfi= ls-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls= -03 addresses this scenario. >=20 >=20 > sid's are assigned to ip addresses (e.g. intf addresses). A node having t= wo loopbacks (v4/v6) will have a sid for the ipv4 address and another one f= or the ipv6. >=20 > Then you compute your spt's or explicit paths based on your af-topology a= nd you pick the right sid's stack. >=20 >=20 >> In the context of shortest-path forwarding using Node-SID labels, there = would seem to be two main approaches to consider. One could distinguish be= tween IPv6 and IPv4 packets by using two different Node-SID labels for the = same node. >=20 >=20 > correct. this is same as above: one sid per address (one for v4 and one f= or v6). >=20 > s. >=20 >=20 >> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bot= tom of the label stack by the SR ingress router. >>=20 >> Do the authors of these drafts or other working group participants have = an opinion on the best way to address this scenario? >>=20 >> Thanks, >> Chris >>=20 >>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 From nobody Tue Sep 2 17:29:13 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2A61A8911; Tue, 2 Sep 2014 17:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 xEtilsl7FKA6; Tue, 2 Sep 2014 17:29:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8A1A6EF7; Tue, 2 Sep 2014 17:29:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D266618047F; Tue, 2 Sep 2014 17:28:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140903002827.D266618047F@rfc-editor.org> Date: Tue, 2 Sep 2014 17:28:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/xoSj2uMcofiPxxTKkBjl64XVZ4s Cc: drafts-update-ref@iana.org, isis-wg@ietf.org, rfc-editor@rfc-editor.org Subject: [Isis-wg] RFC 7356 on IS-IS Flooding Scope Link State PDUs (LSPs) X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 00:29:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7356 Title: IS-IS Flooding Scope Link State PDUs (LSPs) Author: L. Ginsberg, S. Previdi, Y. Yang Status: Standards Track Stream: IETF Date: September 2014 Mailbox: ginsberg@cisco.com, sprevidi@cisco.com, yiya@cisco.com Pages: 23 Characters: 46089 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isis-fs-lsp-02.txt URL: https://www.rfc-editor.org/rfc/rfc7356.txt Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 3 00:45:25 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94161A007A; Wed, 3 Sep 2014 00:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 zCNvPwcWDjS0; Wed, 3 Sep 2014 00:45:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0991D1A0046; Wed, 3 Sep 2014 00:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4084; q=dns/txt; s=iport; t=1409730322; x=1410939922; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3iysoY0X/lnGDhY0GE+vYt2/uMIbWTaTCM54FqI3bYg=; b=EveD7ZEK30fLMdUySxg76pdnkntyoQkNU4Mc6hW7jrQgXULrpuJKytAN hhMbfPDs0XWko30idgPBpsCHAfb34Kd/u+DstCHmNJKSVRdRTkt8svxn8 4RX+pZnTmr4FdaQznOpChoxGVJMr5DZqzmabFnjZXxSFdZ/DFqcMnF37F 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMrGBlStJA2H/2dsb2JhbABagw1TVwTIMwqGeVMBgQ0Wd4QDAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQEeCQcnCxQJCAEBBA4FiDoIDb1AARMEjxozBwaDKYEdBZExiyuVHoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,455,1406592000"; d="scan'208";a="352175574" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 03 Sep 2014 07:45:06 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s837j4hd031432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 07:45:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 02:45:04 -0500 From: "Stefano Previdi (sprevidi)" To: Chris Bowers Thread-Topic: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane Thread-Index: Ac/HAHNIi5mjAeiDRUuQj4rS83oDugAdGxkA Date: Wed, 3 Sep 2014 07:45:03 +0000 Message-ID: <7B3B15DE-FB21-4384-837A-9AD41EA8500A@cisco.com> References: <28acb42d55754debaac4ede15e2f6cfa@BLUPR05MB292.namprd05.prod.outlook.com> In-Reply-To: <28acb42d55754debaac4ede15e2f6cfa@BLUPR05MB292.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.210.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/lhK9u-_Z2CfnJdyJmkLWsegIBxY Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [Isis-wg] [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 07:45:23 -0000 On Sep 3, 2014, at 12:55 AM, Chris Bowers wrote: > Stefano, >=20 > Thanks. I have a similar question regarding node-SID index values for di= fferent algorithms. Does each node need to advertise a unique index value = for each algorithm? For example, in a network supporting 3 algorithms, wo= uld each node need to be assigned 3 unique index values for IPv4 forwarding= ? yes. > I was hoping to be able to assign a single unique index value to each nod= e, and then have each node advertise a different label block for each algor= ithm. This would achieve the same result as assigning a unique index value= for each node for each algorithm, and it would simplify network operations= . The current versions of the ISIS and OSPF SR extensions don't appear to = support advertising a different label block for each algorithm, but I wante= d to make sure I'm not misreading the drafts. that's correct. Note that we don't really have documented a use case for th= e algorithm field. Yet another way to do multi-topology... in case we don't= have enough of them already... s. >=20 > Thanks, > Chris >=20 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Sent: Tuesday, September 02, 2014 11:39 AM > To: Chris Bowers > Cc: spring@ietf.org; isis-wg@ietf.org > Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with= MPLS dataplane >=20 > On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote: >> Stefano, >>=20 >> Thanks. Is there a mechanism to advertise different label blocks for v4= and v6 and have a single unique index value associated with the node? >=20 >=20 > there's a mechanism that allows you to advertise multiple label blocks an= d the index is used across all of them (see isis/ospf sr extensions drafts)= . Not sure if you need to explicitly advertise the af of the label block kn= owing that a sid corresponds to a prefix which implies its af. >=20 > s. >=20 >=20 >=20 >> This would still result in different label values being used for v4 and = v6 packets destined for the same node, but the network operator only has to= assign a single unique index value to each node. >>=20 >> Chris >>=20 >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 >> Sent: Tuesday, September 02, 2014 10:21 AM >> To: Chris Bowers >> Cc: spring@ietf.org; isis-wg@ietf.org >> Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR wit= h MPLS dataplane >>=20 >> Hi Chris, >>=20 >> On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote: >>> Has there been any discussion about how to carry both IPv6 and IPv4 pac= kets with SPRING/SR MPLS labels? From what I can tell, neither draft-filsf= ils-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpl= s-03 addresses this scenario. >>=20 >>=20 >> sid's are assigned to ip addresses (e.g. intf addresses). A node having = two loopbacks (v4/v6) will have a sid for the ipv4 address and another one = for the ipv6. >>=20 >> Then you compute your spt's or explicit paths based on your af-topology = and you pick the right sid's stack. >>=20 >>=20 >>> In the context of shortest-path forwarding using Node-SID labels, there= would seem to be two main approaches to consider. One could distinguish b= etween IPv6 and IPv4 packets by using two different Node-SID labels for the= same node. >>=20 >>=20 >> correct. this is same as above: one sid per address (one for v4 and one = for v6). >>=20 >> s. >>=20 >>=20 >>> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bo= ttom of the label stack by the SR ingress router. >>>=20 >>> Do the authors of these drafts or other working group participants have= an opinion on the best way to address this scenario? >>>=20 >>> Thanks, >>> Chris >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>=20 >=20 From nobody Fri Sep 19 06:14:23 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5F11A0135 for ; Fri, 19 Sep 2014 06:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 xJAkXdKT3Onx for ; Fri, 19 Sep 2014 06:14:14 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F361A0127 for ; Fri, 19 Sep 2014 06:14:14 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id hz1so27858pad.11 for ; Fri, 19 Sep 2014 06:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=c28vHBXM41YWZ56R7MyxV1Sn7KZrp8SEJXBYNtz+4rE=; b=OyJaYFDR+wFaH2S9/GNJsitoIgkXuul/PtWfab83bbHlvY6a19NvCJjH7sQRXTf8kX +zUoP7OcbxWMAA4BLxQAI5pMPmj7w/KaRZag1Ucuz0K2tEpZV6GKEGcoBmrvz4cRBG3A 6g9GItOpoRdkhCLo7K1sC7YkI67ukiDJnwwiRFjPPQjBxA+Oa3KzgJP9m0CMJgK6xHbU z1FR+/UFv/vNsm8QAE8RTK7yzDDET6e1E/oUPZUGGoBWua2l+RbS8GlhkMcb/3k+kMZT 1daj/sjo+cUlNrK+Ta0nQBJSRtpocVA3Lct0dmvDAxTrmiGtx7uzBQvEBMDnVM2/1opk PZSQ== X-Gm-Message-State: ALoCoQkC2AAFgt2aq8ejwlYca5mVQ5N16bvJkze21ylnU8yOvCcIol3C+JbWGzhonqrVvgPFuauY X-Received: by 10.70.96.74 with SMTP id dq10mr1143603pdb.112.1411132454085; Fri, 19 Sep 2014 06:14:14 -0700 (PDT) Received: from [10.21.79.79] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id uy2sm1915168pac.13.2014.09.19.06.14.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 06:14:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Christian Hopps In-Reply-To: <67EAAA5F-DB0C-4F7A-ADCB-5528EDEE1136@rawdofmt.org> Date: Fri, 19 Sep 2014 09:14:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67EAAA5F-DB0C-4F7A-ADCB-5528EDEE1136@rawdofmt.org> To: "isis-wg@ietf.org list" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/XUo573SjvKPq_Ynu1HWe4zvmnPw Cc: Hannes Gredler , Christian Hopps , "Les Ginsberg \(ginsberg\)" Subject: Re: [Isis-wg] Proposed isis-wg documents. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:14:17 -0000 We've had no objections to adopting SBFD or YANG, so we will move = forward with those. More on the other draft in another email. Thanks, Chris & Hannes. On Aug 19, 2014, at 7:47 AM, Christian Hopps = wrote: > Hi Folks, >=20 > During the last meeting in Toronto there was good support for making = the below drafts WG documents. Unless objections are posted to the list = by Friday we will move forward with doing this. >=20 > Proposed WG Documents: >=20 > draft-ginsberg-isis-sbfd-discriminator-00 > draft-ginsberg-isis-route-preference-00 > draft-litkowski-isis-yang-isis-cfg-01 >=20 > Thanks, > Chris & Hannes. From nobody Fri Sep 26 07:11:08 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386731A8897; Fri, 26 Sep 2014 07:10:49 -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 hzRxc25ng86w; Fri, 26 Sep 2014 07:10:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7E91A6FA9; Fri, 26 Sep 2014 07:10:46 -0700 (PDT) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB289.namprd05.prod.outlook.com (10.141.23.19) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 14:10:44 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.1039.011; Fri, 26 Sep 2014 14:10:44 +0000 From: Chris Bowers To: "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" Thread-Topic: New Version Notification for draft-bowers-spring-advertising-lsps-with-sr-00.txt Thread-Index: AQHP2OvQFL5Yiqc+HkqeM+vB/XjqmZwTYirA Date: Fri, 26 Sep 2014 14:10:44 +0000 Message-ID: <82ba0346d2de44b7ac3533328012fa7d@BLUPR05MB292.namprd05.prod.outlook.com> References: <20140925180907.27662.88544.idtracker@ietfa.amsl.com> In-Reply-To: <20140925180907.27662.88544.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB289; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(199003)(377454003)(377424004)(189002)(13464003)(83322001)(2201001)(19580395003)(19580405001)(92566001)(101416001)(76482002)(105586002)(106116001)(31966008)(85306004)(64706001)(4396001)(15202345003)(86362001)(79102003)(81542003)(81342003)(74662003)(80022003)(120916001)(66066001)(46102003)(20776003)(95666004)(74502003)(10300001)(87936001)(85852003)(108616004)(77982003)(99286002)(107046002)(83072002)(107886001)(15975445006)(99396003)(2656002)(54356999)(230783001)(76176999)(2501002)(21056001)(74316001)(76576001)(50986999)(97736003)(33646002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB289; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/Yo9z_B1EQhoEbw9LSuMXaE0yPxc Subject: [Isis-wg] FW: New Version Notification for draft-bowers-spring-advertising-lsps-with-sr-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 14:10:49 -0000 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc2V2ZXJhbCB1c2UgY2FzZXMgZm9yIHVzaW5nIHNlZ21l bnQgcm91dGluZyB0byBhZHZlcnRpc2UgbGFiZWwgYmluZGluZ3MgY29ycmVzcG9uZGluZyB0byBM U1BzLg0KDQpBdCB0aGUgSVNJUyBXRyBtZWV0aW5nIGluIFRvcm9udG8gYXMgd2VsbCBhcyBmb2xs b3ctdXAgZGlzY3Vzc2lvbiBvbiB0aGUgSVNJUyBhbmQgU1BSSU5HIGxpc3RzLCBzZXZlcmFsIHBl b3BsZSBhZ3JlZWQgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgc2VwYXJhdGUgKG9yIGFkZGl0 aW9uYWwpIGRvY3VtZW50IGluIHRoZSBTUFJJTkcgV0cgY292ZXJpbmcgQmluZGluZyBUTFYgdXNl IGNhc2VzIHRoYXQgY2FuIHJlZmVyZW5jZWQgZnJvbSBib3RoIElTSVMgYW5kIE9TUEYgcHJvdG9j b2wgZXh0ZW5zaW9ucyBkb2N1bWVudHMsIGluIG9yZGVyIHRvIGFsbG93IHRoZSBwcm90b2NvbCBl eHRlbnNpb25zIGRvY3VtZW50cyB0byBmb2N1cyBvbiBiaXRzIGFuZCBieXRlcy4NCg0KVGhpcyBk b2N1bWVudCBpcyBhbiBhdHRlbXB0IHRvIGFkZHJlc3MgdGhhdCBuZWVkLiAgQ29tbWVudHMgYXJl IHdlbGNvbWUuDQoNCkNocmlzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjA5IFBNDQpUbzogVW1hIENo dW5kdXJpOyBIYW5uZXMgR3JlZGxlcjsgQ2hyaXMgQm93ZXJzOyBDaHJpcyBCb3dlcnM7IFVtYSBD aHVuZHVyaTsgSGFubmVzIEdyZWRsZXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYm93ZXJzLXNwcmluZy1hZHZlcnRpc2luZy1sc3BzLXdpdGgtc3ItMDAudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNp bmctbHNwcy13aXRoLXNyLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBDaHJpcyBCb3dlcnMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtYm93ZXJzLXNwcmluZy1hZHZlcnRpc2luZy1sc3BzLXdpdGgtc3INClJldmlzaW9u OgkwMA0KVGl0bGU6CQlBZHZlcnRpc2luZyBMU1BzIHdpdGggU2VnbWVudCBSb3V0aW5nDQpEb2N1 bWVudCBkYXRlOgkyMDE0LTA5LTI1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmctbHNwcy13aXRoLXNyLTAwLnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJv d2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmctbHNwcy13aXRoLXNyLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvd2Vycy1zcHJpbmctYWR2ZXJ0aXNpbmct bHNwcy13aXRoLXNyLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IHJvdXRpbmcgdXNlcyBn bG9iYWxseS1rbm93biBsYWJlbHMgdG8gYWNjb21wbGlzaCBmb3J3YXJkaW5nDQogICBhbG9uZyBz aG9ydGVzdCBwYXRocywgYW5kIGxhYmVsIHN0YWNrcyB0byBhY2NvbXBsaXNoIGV4cGxpY2l0IHJv dXRpbmcNCiAgIGFsb25nIGFyYml0cmFyeSBwYXRocy4gIFRoZXNlIGxhYmVscyBhcmUgYWR2ZXJ0 aXNlZCB1c2luZyBhbiBJR1AuDQogICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBob3cgbGFiZWwgYmlu ZGluZ3MgY29ycmVzcG9uZGluZyB0byBSU1ZQLCBMRFAsDQogICBCR1AgbGFiZWxlZC11bmljYXN0 LCBhbmQgc3RhdGljIExTUHMgYXJlIGFkdmVydGlzZWQgaW4gc2VnbWVudA0KICAgcm91dGluZyBh bmQgaG93IHRoZXNlIGxhYmVscyBjYW4gYmUgY29tYmluZWQgd2l0aCBvdGhlciBzZWdtZW50DQog ICByb3V0aW5nIGxhYmVscyB0byBjcmVhdGUgZm9yd2FyZGluZyBwYXRocy4gIFRoaXMgZHJhZnQg YWxzbyBkZXNjcmliZXMNCiAgIGhvdyBjb250ZXh0IGxhYmVscyBmb3IgZWdyZXNzIG5vZGUgcHJv dGVjdGlvbiBhcmUgYWR2ZXJ0aXNlZCBpbiB1c2luZw0KICAgc2VnbWVudCByb3V0aW5nIElHUCBl eHRlbnNpb25zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Sep 26 14:15:40 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581741A0361; Fri, 26 Sep 2014 14:15:34 -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 3TEfhsnQEcsg; Fri, 26 Sep 2014 14:15:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CFC1A1BE0; Fri, 26 Sep 2014 14:15:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: sprevidi@cisco.com, Spencer.giacalone@thomsonreuters.com, wardd@cisco.com, jdrake@juniper.net, akatlas@juniper.net, cfilsfil@cisco.com, sunseawq@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926211532.21096.915.idtracker@ietfa.amsl.com> Date: Fri, 26 Sep 2014 14:15:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/Wut5SygvLpem54i8QPUGZdgkcVI Cc: chopps@rawdofmt.org, isis-wg@ietf.org, hannes@juniper.net, adrian@olddog.co.uk, ipr-announce@ietf.org Subject: [Isis-wg] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ospf-te-metric-extensions-06 and draft-ietf-isis-te-metric-extensions-03 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 21:15:34 -0000 Dear Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, Wenson Wu: An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS Traffic Engineering (TE) Metric Extensions" (draft-ietf-isis-te-metric-extensions) was submitted to the IETF Secretariat on 2014-09-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2442/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ospf- te-metric-extensions-06 and draft-ietf-isis-te-metric-extensions-03.""); The IETF Secretariat From nobody Mon Sep 29 02:01:25 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C325E1A8721 for ; Mon, 29 Sep 2014 02:01:23 -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 Wyt2GdGGfFF6 for ; Mon, 29 Sep 2014 02:01:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4261A8720 for ; Mon, 29 Sep 2014 02:01:21 -0700 (PDT) Received: from hannes-mba.local (193.110.55.10) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 09:00:58 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id EA9BB3D624E; Mon, 29 Sep 2014 11:00:43 +0200 (CEST) Date: Mon, 29 Sep 2014 11:00:43 +0200 From: Hannes Gredler To: "isis-wg@ietf.org list" Message-ID: <20140929090043.GA65720@hannes-mba.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.10] X-ClientProxiedBy: AM3PR07CA0019.eurprd07.prod.outlook.com (10.141.45.147) To DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Forefront-PRVS: 034902F5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(106356001)(87976001)(46406003)(95666004)(105586002)(83322001)(19580395003)(54356999)(76482002)(50986999)(83072002)(85852003)(98436002)(83506001)(101416001)(102836001)(33656002)(97736003)(23726002)(85306004)(21056001)(20776003)(15975445006)(4396001)(230783001)(77096002)(81542003)(15202345003)(229853001)(50466002)(10300001)(99396003)(120916001)(81342003)(74502003)(92566001)(74662003)(86362001)(80022003)(79102003)(64706001)(110136001)(97756001)(77982003)(47776003)(46102003)(92726001)(76506005)(90102001)(31966008)(107046002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/J3fK4YD4tOuZXSqKOwXpNPTFGR4 Cc: draft-psarkar-isis-node-admin-tag@tools.ietf.org, Christian Hopps Subject: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 09:01:23 -0000 fellow ISIS-WG, The authors have requested ISIS-WG draft-psarkar-isis-node-admin-tag-02 as a working group document. note there has been already a decent level of discussion around applicability and use on the OSPF-WG mailing list. please see: http://www.ietf.org/mail-archive/web/ospf/current/maillist.html grep for 'WG adoption of draft-hegde-ospf-node-admin-tag' please state support/no-support. thanks, hannes & chris From nobody Mon Sep 29 05:57:02 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3E1A872A for ; Mon, 29 Sep 2014 05:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xeR7Kt8WlBHf for ; Mon, 29 Sep 2014 05:56:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06C81A8727 for ; Mon, 29 Sep 2014 05:56:58 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id C366E19016F; Mon, 29 Sep 2014 14:56:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id A7853C806E; Mon, 29 Sep 2014 14:56:56 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 14:56:56 +0200 From: To: Hannes Gredler , Christian Hopps Thread-Topic: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance Thread-Index: AQHP28P0SXzN45nYYUmeViEuCQWBOpwYEP+g Date: Mon, 29 Sep 2014 12:56:56 +0000 Message-ID: <30876_1411995416_54295718_30876_15025_1_53C29892C857584299CBF5D05346208A07218777@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20140929090043.GA65720@hannes-mba.local> In-Reply-To: <20140929090043.GA65720@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.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.29.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/6sZ6GdIn30MntTM7CQMFE-w5s94 Cc: "draft-psarkar-isis-node-admin-tag@tools.ietf.org" , "isis-wg@ietf.org list" Subject: Re: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 12:57:01 -0000 Hi Hannes, all I support adoption of draft-psarkar-isis-node-admin-tag-02. This is useful for network operator to express policy based on node capabil= ities/performance/roles (e.g. PE/P/ASBR/BNG, access/aggregation/POP/Core, o= dd/even.). In particular I support uses cases 2, 3 and TE/explicit routing policy (a l= a CSPF excluding "even" or "ASBR" nodes, in particular in the SPRING contex= t). Thanks, Bruno > From Hannes Gredler Sent: Monday, September 29, 2014 11:01 AM > fellow ISIS-WG, >=20 > The authors have requested ISIS-WG draft-psarkar-isis-node-admin-tag-02 > as a working group document. >=20 > note there has been already a decent level of discussion around applicabi= lity > and use on the OSPF-WG mailing list. please see: >=20 > http://www.ietf.org/mail-archive/web/ospf/current/maillist.html > grep for 'WG adoption of draft-hegde-ospf-node-admin-tag' >=20 > please state support/no-support. >=20 > thanks, >=20 > hannes & chris >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg ___________________________________________________________________________= ______________________________________________ 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 Mon Sep 29 09:24:54 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6746E1A8774 for ; Mon, 29 Sep 2014 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 vS8-MCJDXB7q for ; Mon, 29 Sep 2014 09:24:50 -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 859D31A1B45 for ; Mon, 29 Sep 2014 09:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1733; q=dns/txt; s=iport; t=1412007891; x=1413217491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N71jtffTU3tXptHBZagQhWEJo4bkNwuQPkt85OYKSfs=; b=a+XNdpO0e0Nd3ogqdSBMbvc5CZ1ViaO1wv1uSv108oG1ArufbosmO+gf f2i+qec5+oAVW1fuFlUJjDRmwp+jmvhnyXYz8Zrht8F1cy6VSz46LhCCr fwSVACjhM9tYJRM8xrl5N3ZAZl+L8bRteECo1R/PVmsgEhrU+N/5Ag34j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAP+GKVStJV2b/2dsb2JhbABggmsjU1cEygsKh04CgRIWAXuEAwEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgBiDUBDL80ARePTQEBHjECBQaDKIEdBZFloSCDY2wBgQ45gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="359209643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2014 16:24:49 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8TGOmm1008313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 16:24:48 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 11:24:48 -0500 From: "Les Ginsberg (ginsberg)" To: Hannes Gredler , "isis-wg@ietf.org list" Thread-Topic: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance Thread-Index: AQHP28P8/MIwnB1jyE6OEDyTAcu145wYSuaA Date: Mon, 29 Sep 2014 16:24:47 +0000 Message-ID: References: <20140929090043.GA65720@hannes-mba.local> In-Reply-To: <20140929090043.GA65720@hannes-mba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/Xv0Xqi123mJyo7khit9twnPy5hc Cc: "draft-psarkar-isis-node-admin-tag@tools.ietf.org" , Christian Hopps Subject: Re: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:24:52 -0000 I support making this a WG document - but I have the same concern which I p= reviously expressed regarding the companion OSPF document i.e. a much more = complete discussion regarding the tradeoffs between using node tags vs capa= bility identifiers needs to be included . As Hannes has referenced there has been a lively discussion of this point o= n the OSPF-WG list - all of which I think is applicable to the IS-IS draft.= It would be good if any discussion of that issue in the future was copied = to both lists. Also, I would prefer that the Applications content which is found in Sectio= n 5 of http://www.ietf.org/id/draft-hegde-ospf-node-admin-tag-02.txt be rep= eated in the IS-IS draft rather than referenced. Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes > Gredler > Sent: Monday, September 29, 2014 2:01 AM > To: isis-wg@ietf.org list > Cc: draft-psarkar-isis-node-admin-tag@tools.ietf.org; Christian Hopps > Subject: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance >=20 > fellow ISIS-WG, >=20 > The authors have requested ISIS-WG draft-psarkar-isis-node-admin-tag-02 > as a working group document. >=20 > note there has been already a decent level of discussion around > applicability and use > on the OSPF-WG mailing list. please see: >=20 > http://www.ietf.org/mail-archive/web/ospf/current/maillist.html > grep for 'WG adoption of draft-hegde-ospf-node-admin-tag' >=20 > please state support/no-support. >=20 > thanks, >=20 > hannes & chris >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Mon Sep 29 09:59:11 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467FA1A88B1 for ; Mon, 29 Sep 2014 09:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 hBdrc7fBGUHf for ; Mon, 29 Sep 2014 09:59:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48291A87EA for ; Mon, 29 Sep 2014 09:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5829; q=dns/txt; s=iport; t=1412009948; x=1413219548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BGKxMYSY48l46rov6WZFUyEDcGm/4uJfJSof8Z5d3DU=; b=Yz4pmqrgtckRHIUHPDB8cMx/plkU5XRx1XBJ+1GaGrbg2opo/muNdpIO M6Qmkgq7lHzFMrcUFvE91QPIpwbRj1kl7HAr71gFGAO0zl5f/S5cYxVZ5 1fRm+8PqKGsauoXWjIij7azIg0LYLcdZj7NPIln5ElhqFTI6xzNu8GaMk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAPaOKVStJA2L/2dsb2JhbABggmsjgSoE0WMCgRIWAXuEAwEBAQMBOj8FBwQCAQgRBAEBCxQJBzIUCQgCBAENBQgTiA8DCQgBuC4UhwcBF49tMQcGgyiBHQEEhiiJAYI8oSCDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,621,1406592000"; d="scan'208";a="359228609" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 29 Sep 2014 16:59:05 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8TGx5Dc027754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 16:59:05 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 11:59:05 -0500 From: "Les Ginsberg (ginsberg)" To: Dan Frost , "draft-ginsberg-isis-sbfd-discriminator@tools.ietf.org" Thread-Topic: QA review of draft-ginsberg-isis-sbfd-discriminator-00 Thread-Index: AQHP2+ejhiijd6poGkaCw11XhnOmGZwYTVFw Date: Mon, 29 Sep 2014 16:59:04 +0000 Message-ID: References: <1411996605.559647.172949773.17DE141D@webmail.messagingengine.com> In-Reply-To: <1411996605.559647.172949773.17DE141D@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/CGUTjepufM9O8DU61dQsnCOyH3w Cc: "isis-wg@ietf.org" Subject: Re: [Isis-wg] QA review of draft-ginsberg-isis-sbfd-discriminator-00 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:59:10 -0000 Dan - Thanx for your thoughtful review. Answers inline. > -----Original Message----- > From: Dan Frost [mailto:frost@mm.st] > Sent: Monday, September 29, 2014 6:17 AM > To: draft-ginsberg-isis-sbfd-discriminator@tools.ietf.org > Cc: isis-wg@ietf.org > Subject: QA review of draft-ginsberg-isis-sbfd-discriminator-00 >=20 > Hi, >=20 > I have been asked by the Routing ADs and WG chairs to do a QA review of > draft-ginsberg-isis-sbfd-discriminator-00 as a candidate for potential > WG adoption. >=20 > Draft Summary > ------------- > This is a brief draft that describes how Seamless BFD (S-BFD) > [draft-ietf-bfd-seamless-base] discriminator information can be > advertised throughout an IS-IS area or routing domain using the IS-IS > CAPABILITY TLV [RFC 4971]. >=20 > Review Summary > -------------- > This draft limits itself to specifying the proposed new sub-TLV > encoding. Provided the WG is happy with the flooding of such data via > the CAPABILITY TLV, the draft seems like a fine basis for a WG document. >=20 > Comments > -------- > 1. The draft abstract is meaningless to anyone without specialized > knowledge of S-BFD or IS-IS TLVs. A paragraph or two of context here > would improve the draft quality. >=20 > 2. Similarly, some extra context in the introduction as to what S-BFD is > and how it relates to the routing protocol would make the draft more > readable. Mentioning the rationale for area/domain-wide flooding of > BFD-related information would be especially helpful, as BFD is generally > seen as a matter between peers. LES: Let me reply to #1 and #2 together.=20 I am NOT a fan of duplicating the content of one specification into another= . At best the text is redundant - at worst it is inconsistent w the source.= If you want to know about S-BFD go look at the S-BFD reference. :-) Sorry if that seems rude - but I do feel strongly about this point. I can see some benefit in discussing why you might want to flood info domai= n wide - I will put that on the list for the next version. In light of the above I really don't know what else you think the abstract = should have in it. I don't expect a person who is unfamiliar w both S-BFD a= nd IS-IS to get much from reading this draft (or any other IS-IS draft) and= I don't think it is the responsibility of the draft to provide this contex= t. This is intended to be a normative specification and as such should con= fine itself to specifying the protocol behavior. >=20 > 3. The [S-BFD] reference, which is rather important here, points to > draft-akiya-bfd-seamless-base-03 while the current version of that draft > is draft-ietf-bfd-seamless-base-03. LES: The reference was current at the time this version of the draft was wr= itten. A new version of the draft (WG-00) has already been submitted and th= e reference has been updated. Look for this to be posted as soon as the WG = chairs approve it. >=20 > 4. It is not clear from the draft why the CAPABILITY TLV was chosen as > the preferred mechanism as compared to other possibilities like GENINFO > [RFC 6823]. Perhaps this is implicitly understood by the WG, but some > rationale might be valuable if this is indeed one of several viable > approaches. >=20 > 5. For some time, there has been a trend of leveraging routing protocols > to store and flood more and more ancillary information. This must be > done with care. I would expect a draft like this to discuss how much > additional data this extension might push into the network and the > databases of all routers in the routing domain, and what impact this is > expected to have. >=20 LES: Answering #4 and #5 together. The GENINFO vs Router Capability question question is valid and was brought= up in the WG meeting in Toronto. The answer I gave at the time was: Strictly speaking GENINFO is more appropriate - but such a solution is more= expensive from a deployment/implementation standpoint. Note that GENINFO R= EQUIRES the use of Multi-Instance - which I think would be considerable ove= rkill in this case. Given that the IGP is a likely client of S-BFD I think = the expediency of using Router Capability is justifiable. As regards the co= ncern regarding the quantity of data to be advertised I fully expect one di= scriminator value to be sufficient and since there is no need for the disc= riminator value to be changed once advertised there should be no churn. > 6. Are there any chicken-and-egg problems here arising from potential > mutual dependency between IS-IS and BFD? LES: No - I don't think so. RFC 6213 describes how the protocol uses BFD as= a prerequisite to forming an adjacency in cases where both neighbors suppo= rt BFD. But this is standard single hop BFD - NOT S-BFD. So there is no dep= endency on knowing S-BFD discriminators before IS-IS can form neighbors and= /or flood link state info. >=20 > 7. The sister document for OSPF [draft-bhatia-ospf-sbfd-discriminator] > describes some considerations in the last few paragraphs of Section 2.2 > that don't appear entirely OSPF-specific. Do any of these deserve > mentioning in this draft? It might be helpful if these two drafts were > kept closely in sync, perhaps with the assistance of a common editor. > LES: There has been informal coordination between the authors of the two dr= afts and I would expect that to continue. That said, much of Section 2.2 is= discussing RI LSA procedures. The equivalent functionality for IS-IS can b= e found in RFC 4971 Section 3. Given my predisposition for NOT repeating no= rmative text from one specification in another specification (see my reply = to #1 and #2 above) I prefer NOT to follow the OSPF draft in this regard. Les =20 > Thanks, > -d From nobody Mon Sep 29 10:43:33 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8B1A90F5 for ; Mon, 29 Sep 2014 10:43:31 -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 Uxli6Dy32BRr for ; Mon, 29 Sep 2014 10:43:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8807C1A9008 for ; Mon, 29 Sep 2014 10:43:29 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-52-54299a3ee114 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.20.21334.E3A99245; Mon, 29 Sep 2014 19:43:27 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 13:43:24 -0400 From: Uma Chunduri To: Hannes Gredler , "isis-wg@ietf.org list" Thread-Topic: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance Thread-Index: AQHP28P2jd6krKtJakCn7EUAjGc215wYYLeQ Date: Mon, 29 Sep 2014 17:43:22 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F3B91E6@eusaamb105.ericsson.se> References: <20140929090043.GA65720@hannes-mba.local> In-Reply-To: <20140929090043.GA65720@hannes-mba.local> 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+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rtd+lmaIwfoTUhb/7t9gtlgx9yur Rf+9J2wWRw+9Z3Vg8Viy5CeTx/Wmq+wed173sHt8ufyZLYAlissmJTUnsyy1SN8ugSvjwcf3 jAXLOSuWfbzG1sD4mr2LkZNDQsBEYtr0d6wQtpjEhXvr2boYuTiEBI4yShz8upUJwlnOKHHt yGQWkCo2AT2Jj1N/gnWLCIRKnPrwkQWkiFlgCqPE+S9nwYqEBTwlnuxaAWRzABV5STx7GglR byTxds57NhCbRUBV4vzJd8wgNq+Ar8Te7uNgtpCAqcTMq/PB5nMKmEl8v/4fbCQj0HXfT61h ArGZBcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/9BfaMosa9/OjtEvY7Egt2f2CBsbYllC19D7RWU ODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERtrB Lb91dzCufu14iFGAg1GJh1dhr0aIEGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphakFsUX leakFh9iZOLglGpgVNNYcmHfelFxCe7GDcq5H87FCOo1dNjb8e/1vhmX//vnCT1/ju8XBNRm cdYm+8ss/t0s0BX4rPlep8LKP68nzM26ZnDvw7TjU/v+PD1TsFXzcpHvH/u3Kzd0clQpvA4I /+LAN7PvRv82n7TYTfXKH6xvbA++1GXnlXBXb8dU5wSlHaXd9QVqSizFGYmGWsxFxYkA10Ll XJUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/LgtHQmDpEHcVml160gengjIPQiI Cc: "draft-psarkar-isis-node-admin-tag@tools.ietf.org" , Christian Hopps Subject: Re: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 17:43:31 -0000 Support. Application of node tags can be very interesting and could be creative to e= xercise different operator policies. One small comment-=20 IMO, granularity of the tag per topology/AF can be useful in MT deployments= . Authors may think over on this. -- Uma C. -----Original Message----- From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler Sent: Monday, September 29, 2014 2:01 AM To: isis-wg@ietf.org list Cc: draft-psarkar-isis-node-admin-tag@tools.ietf.org; Christian Hopps Subject: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance fellow ISIS-WG, The authors have requested ISIS-WG draft-psarkar-isis-node-admin-tag-02 as a working group document. note there has been already a decent level of discussion around applicabili= ty and use on the OSPF-WG mailing list. please see: http://www.ietf.org/mail-archive/web/ospf/current/maillist.html grep for 'WG adoption of draft-hegde-ospf-node-admin-tag' please state support/no-support. thanks, hannes & chris _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From nobody Mon Sep 29 18:48:20 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC01A00B9 for ; Mon, 29 Sep 2014 18:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_32=0.6, 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 hBcjg2GWDgaC for ; Mon, 29 Sep 2014 18:48:16 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC331A000A for ; Mon, 29 Sep 2014 18:48:16 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so2371433wid.13 for ; Mon, 29 Sep 2014 18:48:15 -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=xmCXdOQsNv6b5Thg9yI69Xlx3qv/dTrTgOSgGNv3vNQ=; b=KwmadvcFPr2cyb92f4aLnI4EDwBPaKEVAlvUy70SK9IOeEOPGxxq2j+BaS28A3N3Ib 0wtbGJQxfhCFVLpfhPthkEO7X/fuqXG6XzCYub4Drv8/lHnCs99iGAI930KDyQ9s34Q3 X+Y2xhN50oi7Vu/Scq0AywdXGv+CeWeP2bGwP/FyD2lwkKGWwx1hVdzm1TzmW2ri6PgM Gl1kWXkbguZ6MMBQa4mfzK/LMBQ7S2B23DZT+wJqUGguGhAcN+yhtBgicfvv6JirsSM3 Fr67K7PFWYTnKQsqnXzdzd5mmI3C5TJKluR7b9CYZTmj6N6vAxH560Zrtk65KSeQTeWC IN2Q== MIME-Version: 1.0 X-Received: by 10.194.48.44 with SMTP id i12mr48011950wjn.83.1412041695149; Mon, 29 Sep 2014 18:48:15 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.195.11.165 with HTTP; Mon, 29 Sep 2014 18:48:15 -0700 (PDT) In-Reply-To: <20140929090043.GA65720@hannes-mba.local> References: <20140929090043.GA65720@hannes-mba.local> Date: Tue, 30 Sep 2014 07:18:15 +0530 X-Google-Sender-Auth: 5jRPNRx7yfV7a-PJOgDM_kjgugk Message-ID: From: Dhruv Dhody To: Hannes Gredler Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/M9Zc9ZjqCN2NvglqQsGRfg6b9O4 Cc: draft-psarkar-isis-node-admin-tag@tools.ietf.org, Christian Hopps , "isis-wg@ietf.org list" Subject: Re: [Isis-wg] draft-psarkar-isis-node-admin-tag-02 WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 01:48:18 -0000 Hi All, Support moving this work along. Similar to the ospf draft[1], I have following comment... Explicit text should be added for - - Minimum one tag must be present in the 'Per-node Admin Tag' sub-TLV - What happens if the implementation does not know the Interpretation of the tag value - No IANA registry is required to store the meaning or interpretation of.the tag values. - Backward compatibility behavior - unknown sub-TLV Nits - Remove reference from abstract for [ISO10589],[RFC1195] - space between 'of' and 'the' is missing in "...grouping ofthe nodes in an IS-IS domain..." - expand LFA,TE, on first use Regards, Dhruv [1] http://www.ietf.org/mail-archive/web/ospf/current/msg07118.html On Mon, Sep 29, 2014 at 2:30 PM, Hannes Gredler wrote: > fellow ISIS-WG, > > The authors have requested ISIS-WG draft-psarkar-isis-node-admin-tag-02 > as a working group document. > > note there has been already a decent level of discussion around applicability and use > on the OSPF-WG mailing list. please see: > > http://www.ietf.org/mail-archive/web/ospf/current/maillist.html > grep for 'WG adoption of draft-hegde-ospf-node-admin-tag' > > please state support/no-support. > > thanks, > > hannes & chris > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Tue Sep 30 17:11:48 2014 Return-Path: X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA791A889B; Tue, 30 Sep 2014 17:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.688 X-Spam-Level: X-Spam-Status: No, score=-107.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 CemgTae6GVKq; Tue, 30 Sep 2014 17:11:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE61A01EE; Tue, 30 Sep 2014 17:11:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BA67918001B; Tue, 30 Sep 2014 17:11:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141001001116.BA67918001B@rfc-editor.org> Date: Tue, 30 Sep 2014 17:11:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/CHVvRsPZd6YWwFRkITMOqPBIAEU Cc: drafts-update-ref@iana.org, isis-wg@ietf.org, rfc-editor@rfc-editor.org Subject: [Isis-wg] RFC 7370 on Updates to the IS-IS TLV Codepoints Registry X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 00:11:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7370 Title: Updates to the IS-IS TLV Codepoints Registry Author: L. Ginsberg Status: Standards Track Stream: IETF Date: September 2014 Mailbox: ginsberg@cisco.com Pages: 7 Characters: 12318 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isis-tlv-codepoints-02.txt URL: https://www.rfc-editor.org/rfc/rfc7370.txt This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC