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

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Wed, 15 April 2015 09:09 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 D0D531B3399 for <isis-wg@ietfa.amsl.com>; Wed, 15 Apr 2015 02:09:31 -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 Tc-VzSSoSWIB for <isis-wg@ietfa.amsl.com>; Wed, 15 Apr 2015 02:09:29 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7FA1B3384 for <isis-wg@ietf.org>; Wed, 15 Apr 2015 02:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7011; q=dns/txt; s=iport; t=1429088969; x=1430298569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2AG71y/PUqcASrHymvWO9dnbZWtpeMlN8vtAMvTRMtM=; b=bNhyHP5i1RYLSHmvXUw9LfwlTuiyMdY3U/kHFA+Qu+OmpPdZxXA/g2Bh 2O5y1KTVzwjcP/LypxFBTWQ2a7kyAlzEuOOoxlAEm4FrxISWcy2ldhXba UBj8hPjxS6SnHHy32UVbxoRlgFPOXlgvhR+qHSbx8bAVT29mDvoWGhWj7 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVBQBuKi5V/4wNJK1cgwxSXAXEboI0CoYDAoE8TAEBAQEBAX6EIAEBAQMBAQEBNzQLBQcEAgEIEQQBARYJCQcnCxQJCAIEAQ0FiCIIDcULAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKLH+EGREBHjMHBgSDDYEWAQSRDoVmP4NsAYEcgzeJEIcLIoNvb4ECBwIXIn8BAQE
X-IronPort-AV: E=Sophos;i="5.11,581,1422921600"; d="scan'208";a="411965530"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP; 15 Apr 2015 09:09:28 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3F99SLM019134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Apr 2015 09:09:28 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 04:09:28 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>, "Wim (Wim) Henderickx" <wim.henderickx@alcatel-lucent.com>
Thread-Topic: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions
Thread-Index: AQHQdvRkXJcnhrT7/0CqjBnWZJ1kmJ1OHaeA
Date: Wed, 15 Apr 2015 09:09:27 +0000
Message-ID: <EC0327EA-562E-4A70-B293-909C45132DAF@cisco.com>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com> <13738_1429015784_552D0CE8_13738_6154_1_53C29892C857584299CBF5D05346208A0EBA0D52@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F626FCC@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F626FCC@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.147.74.79]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F28F4C437BDF4948A0012A005E486F90@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/gcH9L_XvtG9lir5Sub7M3TkMLis>
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: Wed, 15 Apr 2015 09:09:32 -0000

thanks for the support and yes, I agree on the "Non-backward compatible changes" section.

If we're ok with this I'll update the draft accordingly and re-submit asap.

Thanks.
s.


On Apr 14, 2015, at 10:48 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:

> 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