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

Uma Chunduri <uma.chunduri@ericsson.com> Fri, 27 March 2015 16:57 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 6AB991A871C for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 09:57:20 -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 xp46FuSNb7Ng for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 09:57:18 -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 BB0921A8713 for <isis-wg@ietf.org>; Fri, 27 Mar 2015 09:57:17 -0700 (PDT)
X-AuditID: c618062d-f79686d0000030a8-27-551536050355
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 16.2C.12456.50635155; Fri, 27 Mar 2015 11:50:45 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Fri, 27 Mar 2015 12:57:09 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQaA0CPcbBxr1K1Eywyf7MfwUdkJ0vk/cAgAD2v6A=
Date: Fri, 27 Mar 2015 16:57:08 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61A944@eusaamb105.ericsson.se>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com> <1B502206DFA0C544B7A60469152008633F61A11D@eusaamb105.ericsson.se> <20150326213646.GB14373@hannes-mba.local> <F3ADE4747C9E124B89F0ED2180CC814F57402267@xmb-aln-x02.cisco.com>
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F57402267@xmb-aln-x02.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPny6rmWiowdej1haLF7xit9jwZyO7 Rf+9J2wWRw+9Z7VYv/sRkwOrx5TfG1k9liz5yeRxvekqu8eXy5/ZAliiuGxSUnMyy1KL9O0S uDLW//rFUnDNqmJGw3PWBsYdel2MnBwSAiYSS87PYYOwxSQu3FsPZHNxCAkcYZQ4sGI9E4Sz nFHixa/dTCBVbAJ6Eh+n/mQHsUUEIiU+vt7GDlLELPCAUWLZ/n1go4QFwiW6fq5jhCiKkFh9 9jRQMweQbSXxbr0bSJhFQFViR+9TFhCbV8BXonfuNFaIZe8ZJR79ngS2gBMocbZ1IVgRI9B5 30+tATuCWUBc4taT+UwQZwtILNlznhnCFpV4+fgfK4StJDHn9TVmiHodiQW7P7FB2NoSyxa+ ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIytYxJsujsY97y0 PMQowMGoxMNb0C8SKsSaWFZcmXuIUZqDRUmcd9GDgyFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGEvmKT3XVD7pm9KYPb3h+SNRi09VvN/2/Vp24+MatfWzOK9p650yi5fZcn6F7FvbF5E7 GCKMF4j+Fl31XD7af/6lRs0925NsUw/zWSzvnl2m9SKxl2tqDMdjlaMZCerZkj2+Hybc8GVM V2deWCUT43/BYvmza96MVWud7RxEMrUbFokyH/l7QImlOCPRUIu5qDgRACMUE9+OAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/XurP-EA-o6SZyvtxY0nic_LgzdQ>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>, "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: Fri, 27 Mar 2015 16:57:20 -0000

Hi Hannes,

> don't you have concerns that fragment-0 might get a too crowded space ?

Of course it could  be crowded but when I sent the mail I was just thinking on how can we ensure 
SRGB always if it is indeed provisioned on a node   in "all" situations (shrinking/HA cases for a particular node etc..). 

As we agree, unlike any other TLV/Prefix the impact of not having this in transient cases can cause complete label 
withdrawals on all receiving nodes and  have lot of impact/churn  on end-to-end LSPs using these labels.

If not fragment-0 make it mandatory to have the required stickiness (as you indicated) in the same fragment.  
Probably adding more text clarifying this would be better

Hi Les,

> This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

Perhaps "wise" but as explained above this is not about "convenience" rather avoiding potential transient loops and churn as this is a "critical" piece 
of information like area ID example you gave!

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
Sent: Thursday, March 26, 2015 5:02 PM
To: Hannes Gredler; Uma Chunduri
Cc: isis-wg@ietf.org list; 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

(Hannes beat me to it! :-) )

Restricting TLVs to LSP #0 is a BAD IDEA!!

The only think special about LSP #0 is that it is required to be present in order to make use of any other LSP generated by the same system. The protocol has historically not imposed restricting TLVs to LSP #0 except in some very special cases (e.g. area addresses). This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

   Les
'

> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes 
> Gredler
> Sent: Thursday, March 26, 2015 2:37 PM
> To: Uma Chunduri
> Cc: isis-wg@ietf.org list; 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 uma,
> 
> don't you have concerns that fragment-0 might get a too crowded space ?
> 
> /hannes
> 
> On Thu, Mar 26, 2015 at 07:34:51PM +0000, Uma Chunduri wrote:
> | Dear Stefano and authors,
> |
> | Proposed modifications (though not exact text)  are very thoughtful 
> | and IMO this is really good and I don't see any backward 
> | compatibility issues (I didn't see many vendors yet advertise multiple SRGBs).
> |
> |  >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).
> |
> | "SAME" ==> fragment-0 perhaps this would ensure SRGB is ALWAYS there 
> | (as this is critical for SR to even begin)  in the same fragment 
> | regardless on non-zero fragments have any data which are and can 
> | change,
> shrink etc.. (may be it could be too restrictive, but if this is to be 
> considered this is the best time)?
> |
> | And I have posted my comments earlier on flags to be changed to 
> | MT-ID and yet to see response and changes surrounding the same.
> |
> | --
> | Uma C.
> |
> | -----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