Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Uma Chunduri <uma.chunduri@ericsson.com> Fri, 27 March 2015 17:30 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 600D71ACECC for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 10:30:08 -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 3FBo-pBiUvoO for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 10:30:06 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FB51A8897 for <isis-wg@ietf.org>; Fri, 27 Mar 2015 10:30:05 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-bc-5515318f33e2
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 58.6F.17241.F8135155; Fri, 27 Mar 2015 11:31:43 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Fri, 27 Mar 2015 13:30:04 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Uma Chunduri <uma.chunduri@ericsson.com>, "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/cAgAD2v6CAAEtwAP//v2XggAABa7A=
Date: Fri, 27 Mar 2015 17:30:03 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61A9E2@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> <1B502206DFA0C544B7A60469152008633F61A944@eusaamb105.ericsson.se> <F3ADE4747C9E124B89F0ED2180CC814F57402D7C@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F61A9CB@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F61A9CB@eusaamb105.ericsson.se>
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+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPuG6/oWiowYJ7ShaLF7xit9jwZyO7 Rf+9J2wWRw+9Z7VYv/sRkwOrx5TfG1k9liz5yeRxvekqu8eXy5/ZAliiuGxSUnMyy1KL9O0S uDK6z+1hLVjlW/HvwiymBsbFtl2MnBwSAiYSGw6cYYKwxSQu3FvP1sXIxSEkcIRR4vevOywQ znJGiU873jKDVLEJ6El8nPqTHSQhItDMKNF2+BQriMMs8IBRYtn+fWwgVcIC4RJdP9cxgtgi AhESq8+eBtrBAWT7SWy4WwQSZhFQlfj1/hlYCa+Ar0T/u0tQ23YxS3zf+5oFJMEJVP/0TjPY fYxA930/tQbMZhYQl7j1ZD7U3QISS/acZ4awRSVePv7HCmErScx5fY0Zol5HYsHuT2wQtrbE soWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAqPrmASb4w7G BZ8sDzEKcDAq8fAW9IuECrEmlhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QDY5Nb8pHS29tiVM/HaTmpqZTniLnuKV05cd0X/YrkXLGSXXaRP7503Cu2uC4hvHX+ r/hNXgstJV/+iO+P+518lEmAW3ef++41G1oNoxttH+xpf6oXO+PBrOOODy+WP3he+M//av6E 3BvFd75NeHVF7djV2BPSrj23fPx9Hu/UzuVZrvtyisxrRSWW4oxEQy3mouJEAB1153SPAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/vMBypLxokVaUkbEyI6lHNcGzVr0>
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 17:30:08 -0000
Again, absolutely no issues for me if this is understood and already factored! -- Uma C. -----Original Message----- From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Friday, March 27, 2015 12:28 PM To: Les Ginsberg (ginsberg); Hannes Gredler 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 Of course! ..and we know and see how this is being followed/not followed practically in some cases in actual deployments (and the impact may or may not be even noticed if it is really transient and for few prefixes) . Again my only point was this not "any" information! -- Uma C. -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, March 27, 2015 12:15 PM To: Uma Chunduri; Hannes Gredler 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 Uma - The base protocol specification (ISO 10589) stipulates that an implementation should refrain from moving information from one LSP to another whenever possible. This applies to ALL information advertised by IS-IS - it does not need to be repeated for any particular TLV/sub-TLV. Les > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Friday, March 27, 2015 9:57 AM > To: Les Ginsberg (ginsberg); Hannes Gredler > 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 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 _______________________________________________ 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