[Isis-wg] Comments on - draft-ietf-isis-segment-routing-extensions-03

Uma Chunduri <uma.chunduri@ericsson.com> Mon, 09 March 2015 13:58 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 6DC641A87C3 for <isis-wg@ietfa.amsl.com>; Mon, 9 Mar 2015 06:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id whR4gGMonVx4 for <isis-wg@ietfa.amsl.com>; Mon, 9 Mar 2015 06:58:50 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1EA1A1EEE for <isis-wg@ietf.org>; Mon, 9 Mar 2015 06:57:51 -0700 (PDT)
X-AuditID: c618062d-f79876d000003ebd-44-54fd51e8b24a
Received: from EUSAAHC006.ericsson.se (Unknown_Domain []) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.79.16061.8E15DF45; Mon, 9 Mar 2015 08:55:21 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([]) by EUSAAHC006.ericsson.se ([]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 09:57:49 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "isis-wg@ietf.org list (isis-wg@ietf.org)" <isis-wg@ietf.org>
Thread-Topic: Comments on - draft-ietf-isis-segment-routing-extensions-03
Thread-Index: AdBabatEjrsngtWIQnygXHDHXdsFmw==
Date: Mon, 9 Mar 2015 13:57:48 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F5D2C5F@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F5D2C5Feusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPlO7LwL8hBmf62CyOHnrP6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHnf5zAVHHvIWLF9z1K2BsbHBxm7GDk4JARMJI4s1+1i5AQy xSQu3FvP1sXIxSEkcIRRomfPfFYIZxmjxLcH39hAqtgE9CQ+Tv3JDmKLCDhKrDrWDWYLC7hI rLmygQUi7inxcOMlZghbT+Lnth5WEJtFQEWiec0jsHpeAV+JA/uXgtUzAm3+fmoNE4jNLCAu cevJfCaIiwQkluw5zwxhi0q8fPyPFcJWkvj4ez47RH2+RMvmO2wQMwUlTs58wjKBUWgWklGz kJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxlsYgQG/zEJNt0d jHteWh5iFOBgVOLhNZjzJ0SINbGsuDL3EKM0B4uSOO+iBwdDhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAu5NWeIhb+ha00dMPSxC7XqSs/aVdadGflPBN53p+S8i/PLsHob6bIvTNpHpn7 Jxms5pZpWLVkTdCEuptCnI8mzbmx+KNy56P/iW+Pdgq+ylstw/72o7Lxwr6ZfBwuUqJexlPu nAg6+kpGbM+FU9t8uB7XHHlTO/30Nj0B3cyQL8573P+s7t2mxFKckWioxVxUnAgAQWHrxV8C AAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/VMTaMPvTxGBurGBSOeKozQ2ua0A>
Subject: [Isis-wg] Comments on - draft-ietf-isis-segment-routing-extensions-03
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: Mon, 09 Mar 2015 13:58:56 -0000

Dear Authors,

Though it's bit delayed from side to get these out because of unavoidable reasons thought to
post my comments any ways on "03" version for future reference.


1. Section 2
   "The 'Prefix SID'
   MUST be unique within a given IGP domain (when the L-flag is not
   set).  The 'Prefix SID' MUST carry an index (when the V-flag is not
   set) that determines the actual SID/label value inside the set of all
   advertised SID/label ranges of a given router."

   With the above its possible to advertise a "globally unique and absolute" prefix SID.
   But this is negated below and there is nothing called globally unique and absolute prefix SID.
   Perhaps L flag is not required and V flag is sufficient to represent the local nature of the SID.
   It's better to correct the same.

2. Section 2

   " P-Flag: no-PHP flag.  If set, then the penultimate hop MUST NOT
         pop the Prefix-SID before delivering the packet to the node
         that advertised the Prefix-SID."

   Inconsistent with OSPF definition, which could be ok but I would agree with Acee's original comment which led OSPF draft
   to say that as NP flag.

3. Section 2

      *  A 4 octet index defining the offset in the SID/Label space
         advertised by this router using the encodings defined in
         Section 3.1.  In this case the V and L flags MUST be unset.

      *  A 3 octet local label where the 20 rightmost bits are used for
         encoding the label value.  In this case the V and L flags MUST
         be set."

    This is a big change and has some impact on how we configure things today.
    Is this because it's clear that globally agreeable ranges can't be configured in a multi-vendor deployment?
    It's good to write some explanation on why?

4. Section 2.2.1

         "F-Flag: Address-Family flag.  If unset, then the Adj-SID refers
         to an adjacency with outgoing IPv4 encapsulation.  If set then
         the Adj-SID refers to an adjacency with outgoing IPv6

   As base IS-IS TLVs would have MT-ID as and when needed to represent the topology/AF, I don't see the need for this.

   Also I see towards the end of section 2.2.1 -
      The F-flag is used in order for the router to advertise the
      outgoing encapsulation of the adjacency the Adj-SID is attached
      to.  Use cases of the use of the F-flag are described in

   Why MTID of the base TLVs (22/222/etc..) won't cover outgoing encapsulation??

5. Section 2.2.1
         "S-Flag.  Set Flag.  When set, the S-Flag indicates that the
         Adj-SID refers to a set of adjacencies (and therefore MAY be
         assigned to other adjacencies as well)."

A forward reference (same document or other document) would be helpful on how to use this.
Ideally "procedures" should explain the advertisement and processing og this in the same document.

6.  Section 2.2.1
    "      *  A 16 octet IPv6 address.  In this case the V flag MUST be set.
         The L flag MUST be unset if the IPv6 address is globally

7. Section 2.2.1 -

   "      *  A 16 octet IPv6 address.  In this case the V flag MUST be set.
         The L flag MUST be unset if the IPv6 address is globally

   All of a sudden this document introduces IPv6 data plane (or non-mpls) semantics here.
   It's good to cover some background in the introduction and rationale on why only for ADJ-SIDs this
   is required should be explained. Currently there is no explanation more than the reference as below
   and 6man-sr-header drafts.

   Section 2.2.2 -

   "An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined
   in [I-D.previdi-6man-segment-routing-header])."

8. Section 2.4
   for the first 2 bullets, it should include the previously agreed upon reference,
    which details the usage scenarios of binding SIDs -

9. Section 2.4.1
   "      F-Flag: Address Family flag.  If unset, then the Prefix FEC
      carries an IPv4 Prefix.  If set then the Prefix FEC carries an
      IPv6 Prefix."

    It's good to put MT-ID, as for ISIS it's more of MT ID (RFC 5120) which represents AF too.

10. Section 2.4
    "   o  The SID/Label Binding TLV may also be used in order to advertise
      prefixes to SID/Label mappings.  This functionality is called the
      'Mapping Server' and it's used when, in a heterogeneous network,
      not all nodes are capable of advertising their own SIDs/Labels.
      When the SID/Label Binding TLV is used by the Mapping Server in
      order to advertise prefix to SID/label mappings, the index/label
      MUST include the Prefix-SID SubTLV (Section 2.1)."

     It should have a forward reference to section 2.4.5, where mapping server prefix-SID is kind of attempted to be addressed.

11. Section 2.4.5

    "The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1
   and contains the SID/index/label value associated with the prefix and
   range. "

Reference should be corrected to Section 2.4.
Advertising node, receiving node in SR domain and the receiving boarder node in SR domain processing should be detailed.

12. Section 3.1
      I see an example of index sid - 0 as valid value
      do we have to make it valid ?? Can this be invalid -
      Just feeling uncomfortable to receive an index "0" for prefix SID (error checks on the received data id difficult).

     Also example can be modified not to have index 0

   " SRGB =  [101, 200]
            [1001, 2000]
            [501, 600]

      The indexes span multiple ranges:

         index=1   means label 101
         index 100  means label 200
         index 101 means label 1001
         index 200 means label 2000
         index 201 means label 501

    If authors strongly feel 0 is a valid index and can be advertised in the LSP, it's fine.

13. As we have https://tools.ietf.org/html/draft-ginsberg-isis-prefix-attributes-01 , which defines some of the flags (N flag for example) defined here it's better to harmonize this and deprecate some of the flags from SR draft (per offline discussion).
Uma C.