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

Uma Chunduri <uma.chunduri@ericsson.com> Thu, 26 March 2015 19:34 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 925151B2B11 for <isis-wg@ietfa.amsl.com>; Thu, 26 Mar 2015 12:34:57 -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 apaSy3h6SKom for <isis-wg@ietfa.amsl.com>; Thu, 26 Mar 2015 12:34:55 -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 6BA311B2B09 for <isis-wg@ietf.org>; Thu, 26 Mar 2015 12:34:55 -0700 (PDT)
X-AuditID: c618062d-f79686d0000030a8-ab-551409853be6
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5A.F9.12456.58904155; Thu, 26 Mar 2015 14:28:37 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Thu, 26 Mar 2015 15:34:51 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "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: AQHQZvC7hrT9qKDDQUuVCHLnjTqMo50vJrOQ
Date: Thu, 26 Mar 2015 19:34:51 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F61A11D@eusaamb105.ericsson.se>
References: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com>
In-Reply-To: <61FC3466-5350-46DF-829F-889B45F8EB92@cisco.com>
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+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPlG4rp0iowavlGhaLF7xitzh66D2r xfrdj5gcmD2m/N7I6rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZVxasYm9oFGx4tXqJ+wN jKukuhg5OSQETCSuTb3FCmGLSVy4t56ti5GLQ0jgCKPE66kH2CGc5YwSc/rPsoBUsQnoSXyc +pMdxBYRSJZ4vH8HE4jNLFArsePLdLC4sEC4xOq2JawQNRES+7fMZ4KwjSS27PvCDGKzCKhK nH71CSzOK+ArMXniUbBeIQEbicsL1oHt4hSwlTjRvIYNxGYEuu77qTVQu8Qlbj2BmCkhICCx ZM95ZghbVOLl439Q3yhK7OuHuIdZQEdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsYOUqLU8ty040MNjECY+eYBJvuDsY9Ly0PMQpwMCrx8H6wFQ4VYk0sK67M PcQozcGiJM676MHBECGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mk2NLPAUdb713/6d6s+gX /wn7tIyvS1pPHVlRs1zgB3fGLNX7M0tPldeZHHau1Ar2ZF4S9+NGxvdpR/bvXi38c753UNRm i8mcDA9fPF5m67L4Thg7D+eeC44p51gc1xh9rSqcNvO/5Y99m/KqeXbdTb8ZHsoqc+6H/eMg Jo5ItudcnXP/bioWV2Ipzkg01GIuKk4EAGIt0C1+AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/F8CUAA-htSm8i3-9vNWucHjMjnw>
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: Thu, 26 Mar 2015 19:34:57 -0000

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