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