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

Uma Chunduri <uma.chunduri@ericsson.com> Tue, 14 April 2015 20:48 UTC

Return-Path: <uma.chunduri@ericsson.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 BF9D51B2FA3 for <isis-wg@ietfa.amsl.com>; Tue, 14 Apr 2015 13:48:45 -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 eSWr6r7zX2K8 for <isis-wg@ietfa.amsl.com>; Tue, 14 Apr 2015 13:48:43 -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 426DD1B2A7B for <isis-wg@ietf.org>; Tue, 14 Apr 2015 13:48:43 -0700 (PDT)
X-AuditID: c618062d-f79686d0000030a8-f4-552d2656b948
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.FA.12456.6562D255; Tue, 14 Apr 2015 16:38:14 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Tue, 14 Apr 2015 16:48:40 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQdrGCC0lpQMLAZ0ufGRQFOzAce51M+PSA
Date: Tue, 14 Apr 2015 20:48:40 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F626FCC@eusaamb105.ericsson.se>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com> <13738_1429015784_552D0CE8_13738_6154_1_53C29892C857584299CBF5D05346208A0EBA0D52@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <13738_1429015784_552D0CE8_13738_6154_1_53C29892C857584299CBF5D05346208A0EBA0D52@PEXCVZYM11.corporate.adroot.infra.ftgroup>
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+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPn26Ymm6owY2d4hY/dsxhtli84BW7 xdFD71kt1u9+xOTA4jHl90ZWjyVLfjJ5tDw7yebx5fJntgCWKC6blNSczLLUIn27BK6Mf2c3 sRfMMK54NGUvewPjbs0uRk4OCQETiUXTXjBC2GISF+6tZ+ti5OIQEjjKKHFtxnFmCGc5o8Tx Ha/ZQarYBPQkPk79yQ6SEBGYwyjx58kyNpAEs0CtxI4v08GKhAXCJbp+rgMbKyIQIbH67Gkm CNtIYvb3LWA2i4CqxOsbv1lBbF4BX4mJax9Crd7FKHHz5jqw1ZwCHYwSi7+uYAapYgQ68Pup NUwQ28Qlbj2ZzwRxuIDEkj3nmSFsUYmXj/+xQtiKEvv6IS5iFtCRWLD7E9Sl2hLLFr5mhtgs KHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy2MQIjKpjEmy6Oxj3vLQ8xCjA wajEw6vAohMqxJpYVlyZe4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY AzdI7HrA8iFPgMFFU26F2d7+pq+tj3ziuTuqvCerht/uqErIP3f9SNX694fvOCYcu7bUT2fP 92XTanJm611v7158u1as7c3BbX7VKk1Cf9uOmn7zqd1YPuu6941/i7h4zZUSviYvEzBPjl1n 1D1hZtVFlSsBlm0PKpI2aqcdE199IG1xQeJlJZbijERDLeai4kQAoTOdeosCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/bDXQDFNMULTkTKOE5lBEaDAntwI>
Cc: "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, 14 Apr 2015 20:48:45 -0000

First, the proposed changes are fair and I fully support those.

> In general, it would be good to document in appendix the non-compatible changes being 
> introduced in a revision, so that this can be tracked for deployment.

Agree with Bruno on this. 

"If at all if" any non-compatible changes are being and have to be made, keeping in view of the final 
Specification, it's better to make those now and document "those"  changes.

Though a non-compatible change will have some cost now, it would be way less cheaper as there are not
 many deployments yet (only interoperable implementations and field trials). Thx!

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, April 14, 2015 5:50 AM
To: Stefano Previdi (sprevidi); isis-wg@ietf.org list
Cc: draft-ietf-isis-segment-routing-extensions@tools.ietf.org
Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Hi Stefano, all

In short: I support the proposed change.

Long version:
- 1rst point (multiple SRGB ranges): I strongly support the proposed change (needed & backward compatible)
- 2nd point (encoding of multiple ranges): I'm not fan of introducing non backward compatible change in shipped and interoperable implementations. However, since no implementation seems to have an issue with this (probably since AFAIK no shipping implementation send multiple ranges) I'm fine with this.
- If we all agree, the sooner the draft gets updated, the better. (Idem for implementations ;-) )

In general, it would be good to document in appendix the non-compatible changes being introduced in a revision, so that this can be tracked for deployment. (e.g. an implementation A implementing -03 may be non-compatible with an implementation B implementing -04)

Thanks,
Regards,
Bruno


> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Stefano 
> Previdi
> (sprevidi)
> Sent: Wednesday, March 25, 2015 12:42 PM
> 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg