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

Uma Chunduri <uma.chunduri@ericsson.com> Fri, 27 March 2015 17:28 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 147321A8897 for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 10:28:35 -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 7XhoywRopLu6 for <isis-wg@ietfa.amsl.com>; Fri, 27 Mar 2015 10:28:32 -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 747451A8889 for <isis-wg@ietf.org>; Fri, 27 Mar 2015 10:28:32 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-5d-55153131e6ac
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FE.4F.17241.13135155; Fri, 27 Mar 2015 11:30:10 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Fri, 27 Mar 2015 13:28:30 -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/cAgAD2v6CAAEtwAP//v2Xg
Date: Fri, 27 Mar 2015 17:28:29 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61A9CB@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>
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F57402D7C@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+NgFvrDLMWRmVeSWpSXmKPExsUyuXSPt66RoWiowdrT/BaLF7xit9jwZyO7 Rf+9J2wWRw+9Z7VYv/sRkwOrx5TfG1k9liz5yeRxvekqu8eXy5/ZAliiuGxSUnMyy1KL9O0S uDKWPetjKjjkUfFy6iT2BsZJll2MnBwSAiYScyc3MUPYYhIX7q1n62Lk4hASOMIocf3hP1YI ZzmjxKPWL2BVbAJ6Eh+n/mQHsUUEIiU+vt7GDlLELPCAUWLZ/n1sIAlhgXCJrp/rGCGKIiRW nz3NBGG7SUzd2QjWzCKgKvHt/R+wobwCvhJzlh9jh9j2jUliybqJYEWcQIlTb9eC2YxA930/ tQZsELOAuMStJ/OZIO4WkFiy5zzUD6ISLx+DnA1iK0nMeX2NGaJeR2LB7k9sELa2xLKFr6EW C0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAqPrmASb4w7GBZ8sDzEK cDAq8fAW9IuECrEmlhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o+Jq1k3JZf/OOmrMmZqZ89H+6BOFRR/3vv+qtexWm9GduWvzs9rXzDVX8yz1z2s8ky2tV1Dj K7HS+f3UvBeBy1acUmZTiZlYJzbHZgezRuF2s0V7323m4Vt/46zf/cm799al673V5doQf++d YMEGpimm++e8TMj1kVROyb6SXub769D1kFyWbUosxRmJhlrMRcWJAEe4gVuPAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/1kJ_nFj-wHUhPxnsdOwpKW4mJUA>
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:28:35 -0000

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