Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Pushpasis Sarkar <psarkar@juniper.net> Tue, 31 March 2015 19:37 UTC
Return-Path: <psarkar@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9381AC44A for <isis-wg@ietfa.amsl.com>; Tue, 31 Mar 2015 12:37:11 -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 Te5RSeT5iSEA for <isis-wg@ietfa.amsl.com>; Tue, 31 Mar 2015 12:37:09 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75CC1AC449 for <isis-wg@ietf.org>; Tue, 31 Mar 2015 12:37:08 -0700 (PDT)
Received: from BY1PR0501MB1240.namprd05.prod.outlook.com (25.160.200.139) by CO1PR05MB298.namprd05.prod.outlook.com (10.141.70.25) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 31 Mar 2015 19:36:49 +0000
Received: from BY1PR0501MB1240.namprd05.prod.outlook.com ([25.160.200.139]) by BY1PR0501MB1240.namprd05.prod.outlook.com ([25.160.200.139]) with mapi id 15.01.0118.022; Tue, 31 Mar 2015 19:36:48 +0000
From: Pushpasis Sarkar <psarkar@juniper.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>, Chris Bowers <cbowers@juniper.net>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQa+oHGkwI/lFmWkmO0VaF1wNBNg==
Date: Tue, 31 Mar 2015 19:36:48 +0000
Message-ID: <D1406DD2.245C0%psarkar@juniper.net>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com> <BLUPR05MB2924095A24F0706DBE3AA28A9090@BLUPR05MB292.namprd05.prod.outlook.com> <5519E31D.6040603@cisco.com> <D140559F.24587%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F574070A1@xmb-aln-x02.cisco.com>
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F574070A1@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB298;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(13464003)(377454003)(52604005)(2656002)(230783001)(106116001)(46102003)(2950100001)(2501003)(2900100001)(99286002)(92566002)(87936001)(50986999)(66066001)(19580405001)(40100003)(62966003)(15975445007)(77156002)(102836002)(93886004)(36756003)(86362001)(83506001)(54356999)(19580395003)(122556002)(76176999)(427584002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB298; H:BY1PR0501MB1240.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <CO1PR05MB2989145A280255BB56C3187BCF40@CO1PR05MB298.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB298; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB298;
x-forefront-prvs: 0532BF6DC2
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <F4931D3C0653444B83FDDB8187E35B7D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 19:36:48.2458 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB298
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/eCRtRv4kdEk2j2DEPq-6kSk8I90>
Cc: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" <draft-ietf-isis-segment-routing-extensions@tools.ietf.org>
Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 19:37:11 -0000
Hi Les, Thanks for correcting the bounce issue.. Hope it does not go the bounce list anymore... More comments inline.. On 3/31/15, 3:04 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote: >Pushpasis - > >(Your mailer continues to insert the "bounce" alias for the WG instead of >the WG address - please see if you can fix this as it means your posts >won't be sent to the list. I have corrected this in my reply.) > >As outlined in my post, the changes being requested are NOT minimal. They >make fundamental changes in the way SRGBs are defined/used - and have >implications in the way routers implement local label allocation. > >Given there is a strong desire to minimize backwards compatibility issues >(publicly expressed by multiple people) it is hard for me to understand >how you can suggest that now it is OK to introduce a much more disruptive >change. [Pushpasis] All we are asking is an extra ALGO field in the SR-Cap-SubTLV.. Existing implementations (that do SPF only) just adds a Algo field with value '0'... Is it so hard to implement? I don't think I sound so ridiculous... :) If people have to make some code changes to accommodate the changes being proposed originally in this thread.. Might as well add few lines for this Algo field... >Further, this change is NOT essential to support the use case you have in >mind. [Pushpasis] I agree to disagree.. This makes perfect sense the way forward to do MRT and other kinds of algorithms... Thanks and Regards, -Pushpasis > > > Les > >> -----Original Message----- >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Pushpasis >> Sarkar >> Sent: Tuesday, March 31, 2015 10:50 AM >> To: Ahmed Bashandy (bashandy); Chris Bowers; isis-wg@ietf.org list >> Cc: Stefano Previdi (sprevidi); draft-ietf-isis-segment-routing- >> extensions@tools.ietf.org >> Subject: Re: [Isis-wg] Proposed Changes in >>draft-ietf-isis-segment-routing- >> extensions >> >> Hi Ahmed, Les, Stephano et al. >> >> What we are saying that while we are making other non-backward- >> compatible changes in the next version of this draft, let us consider >>if we can >> also add some minimal more to be able address some proper kind of >>support >> for multiple algorithms(like MRT_blue and MRT_red)Š >> >> Does it not look sensible? I think we are making this request in the >>interest of >> all those who also wants to do MRT with SPRING (instead of LDP)Š I >>request >> you all to reconsider this. >> >> Thanks >> -Pushpasis >> >> On 3/30/15, 7:58 PM, "Ahmed Bashandy" <bashandy@cisco.com> wrote: >> >> >I think the primary purpose of this email thread is to seek the opinion >> >of the community on the very minor changes that Stefano proposed. If >> >there is a feeling that other modifications are necessary or desirable, >> >then a different email thread would avoid an ever growing discussion >> > >> >Ahmed >> > >> > >> >On 3/27/2015 6:22 AM, Chris Bowers wrote: >> >> All, >> >> >> >> Since the changes being proposed to the ISIS SR extensions will break >> >>backwards compatibility, I would like to suggest that that working >> >>group consider taking advantage of this opportunity to improve the way >> >>that SR extensions support forwarding based on algorithms other than >> SPF. >> >> >> >> Currently, in order to establish forwarding next-hops based on >> >>another algorithm, each node must be configured with an additional >>node- >> SID, >> >>each unique in the IGP domain. The configuration and management of >> >>unique node-SIDs on a per-algorithm basis can be avoided by having >> >>each node assign a label block for each algorithm and advertise label >> >>blocks on a per-algorithm basis. In this way, a given node only needs >> >>to have a single unique node-SID configured, while still supporting >> >>forwarding next-hops computed by different algorithms. >> >> >> >> As far as I can tell, the main drawback of this approach is that it >> >>would break backwards compatibility with existing implementations >> >>since the current extensions do not support the association of an >> >>algorithm with a label block. However, if we group this change >> >>together with other non-backwards compatible changes, that drawback is >> >>minimized or eliminated. >> >> >> >> It may also make sense to take this opportunity to improve support >> >>for multi-topology routing in SR by introducing a mechanism to allow >> >>the SR-related sub-TLVs carried in the Router Capability TLV to be >> >>associated with a given MT-ID. >> >> >> >> Chris >> >> >> >> -----Original Message----- >> >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano >> >>Previdi (sprevidi) >> >> Sent: Wednesday, March 25, 2015 6:42 AM >> >> To: isis-wg@ietf.org list >> >> Cc: draft-ietf-isis-segment-routing-extensions@tools.ietf.org >> >> Subject: [Isis-wg] Proposed Changes in >> >>draft-ietf-isis-segment-routing-extensions >> >> >> >> All, >> >> >> >> The authors of draft-ietf-isis-segment-routing-extensions would like >> >>to expose the following proposed changes to SRGB advertisement which >> >>are being considered. >> >> >> >> 1. Single Vs. Multiple SRGB ranges >> >> Currently, section 3.1. SR-Capabilities Sub-TLV defines that: >> >> >> >> "A router not supporting multiple occurrences of the SR-Capability >> >> sub-TLV MUST take into consideration the first occurrence in the >> >> received set." >> >> >> >> The authors would like to remove above text so that a compliant >> >> implementation MUST support the receiving of multiple ranges. >> >> >> >> 2. Encoding the SR-Cap in a single LSP Fragment Vs. Single TLV >> >> Currently, section 3.1. SR-Capabilities Sub-TLV defines that: >> >> >> >> "The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY >> >> appear multiple times inside the Router Capability TLV and has >> >> following format [...]" >> >> >> >> and >> >> >> >> "Only the Flags in the first occurrence of the sub-TLV are to be >> >> taken into account" >> >> >> >> and >> >> >> >> "The originating router MUST encode ranges each into a different >> >> SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded >> >> within the same LSP fragment." >> >> >> >> and >> >> >> >> "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the >> >> LSP fragment is decided by the originating router and hence the >> >> receiving routers MUST NOT re-order the received ranges. This >> >> is required for avoiding label churn when for example a >> >> numerical lower Segment/Label Block gets added to an already >> >> advertised Segment/Label Block." >> >> >> >> Authors agreed that: >> >> . the encoding scheme is suboptimal and doesn't make best use of >> >> the TLV/LSP space (e.g.: flags field is replicated and unused). >> >> . we want to preserve the requirement of NOT sorting the received >> >> srgb ranges in order to avoid churns and downtime when a change >> >> is advertised (typically when the srgb is extended). >> >> >> >> Therefore a possible option is to restrict the advertisement of >> >> multiple srgb's into the SAME SR-Cap SubTLV where flags get >> >> defined once and srgb ranges encoded within the same (unique) >> >> SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges). >> >> >> >> Now, doing this will improve the encoding and clarity of the spec >> >> but introduces a backward compatibility issue with current >> >> version of the draft. Therefore it is important that all >> >> implementors make themselves known and tell the authors how >> >> difficult this change is from an implementation perspective. >> >> >> >> Among the authors we have 4 implementors for which the change >> >> seems not to be a problem but other implementations of ISIS, >> >> Segment Routing extension may exists and so it is necessary to >> >> check whether anyone has a problem with the proposed change. >> >> >> >> Thanks. >> >> s. >> >> >> >> _______________________________________________ >> >> Isis-wg mailing list >> >> Isis-wg@ietf.org >> >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> >> >> _______________________________________________ >> >> Isis-wg mailing list >> >> Isis-wg@ietf.org >> >> https://www.ietf.org/mailman/listinfo/isis-wg >> > >> >_______________________________________________ >> >Isis-wg mailing list >> >Isis-wg@ietf.org >> >https://www.ietf.org/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg
- [Isis-wg] Proposed Changes in draft-ietf-isis-seg… Stefano Previdi (sprevidi)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Uma Chunduri
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Hannes Gredler
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Chris Bowers
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Pushpasis Sarkar
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Uma Chunduri
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Uma Chunduri
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Uma Chunduri
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Stefano Previdi (sprevidi)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Hannes Gredler
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Ahmed Bashandy
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Henderickx, Wim (Wim)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Pushpasis Sarkar
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Chris Bowers
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Pushpasis Sarkar
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Stefano Previdi (sprevidi)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Ahmed Bashandy
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… bruno.decraene
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Stefano Previdi (sprevidi)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Henderickx, Wim (Wim)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Jeff Tantsura
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… bruno.decraene
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Uma Chunduri
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… Stefano Previdi (sprevidi)
- Re: [Isis-wg] Proposed Changes in draft-ietf-isis… stephane.litkowski