Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Sun, 29 March 2015 22:06 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3A1A6F07 for <isis-wg@ietfa.amsl.com>; Sun, 29 Mar 2015 15:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZnb3x_SUqma for <isis-wg@ietfa.amsl.com>; Sun, 29 Mar 2015 15:06:12 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082241A6F05 for <isis-wg@ietf.org>; Sun, 29 Mar 2015 15:06:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6068; q=dns/txt; s=iport; t=1427666772; x=1428876372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ijmvn6r5acqko4EXvkJeBfov2qaLnEOOWalg0dXl7m8=; b=SIB7ol18dlmHUqCQKutGP9fW5otE3lWYChvkthMCJIBGO1jCedYyYuuJ JP1P5SiakNaQnjg78oWvAVLb6ETF4oc45Q82NZGiHcXlEzx6/mYyvLGIi c75NAhNmJjiZO/oy4wOxMIhKj8b3w5tYEZFLtVLIg45NSeJwO7Ro/e/rz k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BeCADEdhhV/49dJa1cgwZSXATCdoIxCoVzAoEgTAEBAQEBAX2EFAEBAQMBAQEBNy0HBgUFBwQCAQgOAwQBAQEVCQkHJwsUCQgCBAENBYgnCA3KJAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiymEFTAzBwYEgw2BFgWOToIOhVg/g12BHI9Rg0giggIcgVBvgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.11,490,1422921600"; d="scan'208";a="136441941"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 29 Mar 2015 22:06:11 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2TM6AVt012829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Mar 2015 22:06:10 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 29 Mar 2015 17:06:10 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Pushpasis Sarkar <psarkar@juniper.net>, Chris Bowers <cbowers@juniper.net>
Thread-Topic: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQaJKdiRqEvmZz80COImsTMSpnZp00W8aA
Date: Sun, 29 Mar 2015 22:06:08 +0000
Message-ID: <B5C81E8E-D5D2-4BF7-A06C-707BC24F0885@cisco.com>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com> <BLUPR05MB2924095A24F0706DBE3AA28A9090@BLUPR05MB292.namprd05.prod.outlook.com> <D13AC54D.2421F%psarkar@juniper.net>
In-Reply-To: <D13AC54D.2421F%psarkar@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.68.123]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7348C0FB89E0014CAB62DB80060EB438@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/rxOoT5iKpIziN4N7M6UdYhLOEo4>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>, "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: Sun, 29 Mar 2015 22:06:14 -0000

Hi Chris, Pushpasis,

sorry but I disagree.

The current proposal is a minor change that, will not incur ANY backward compatibility change (since nobody advertises multiple srgb's at this stage) while your proposal makes a radical change in the format of the sr-cap subtlv that would impact current deployments.

s.


On Mar 27, 2015, at 2:33 PM, Pushpasis Sarkar <psarkar@juniper.net> wrote:

> Hi Chris,
> 
> I fully agree to your proposal of a separate SRGB per algorithm (e.g. SPF,
> MRT-Blue, MRT-Red).
> 
> Regarding your comment on Multi-topology.. Today, MT in ISIS is different
> than MT in OSPF. I think OSPF already has MT built-in the OSPF protocol
> extension. However there is no such need to extend that for ISIS, unless
> we intend to do OSPF-like MTR.
> 
> Thanks,
> -Pushpasis
> 
> On 3/27/15, 8:22 AM, "Chris Bowers" <cbowers@juniper.net> 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
>