Re: [Lsr] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 15 June 2018 17:11 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3F3130DFB; Fri, 15 Jun 2018 10:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 9_t8vtXARh53; Fri, 15 Jun 2018 10:11:19 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8F612F18C; Fri, 15 Jun 2018 10:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60576; q=dns/txt; s=iport; t=1529082679; x=1530292279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jajYy9hSu6UaoxjMud5dj09Ov/TWrN8lHKPw5lPiUOE=; b=kMiUS2nvG1z6fiGEml5ODdHThrKFDqZd60ZV6MC1Y6awJRvjvKTVXWMZ fVgb5v+VqycoR/iMXexNADgdRvazvO7O74gylg2fCUOqxWJD3hxYg8/Vo H/4ikBYXyPTn00IcKm4pUzT1Gaqy1oAWUuAyl7LXvcfWKh7mogXA9YJSv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAACd8iNb/51dJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTSypifygKg2+IBIxSgX+CbYUxjFGBeAslhEcCFyiCEyE?= =?us-ascii?q?0GAECAQEBAQEBAm0cDIUoAQEBBCMKHgEtEAIBCBECAgEBIQEGAwICAh8EDRQ?= =?us-ascii?q?JCAIEDgUIgxyBG0wDFQ+pWoIcg3QBgxoNgSyBaIhMgVQ/gQ4BgwyCUUIBAQI?= =?us-ascii?q?BgVkbDxCCS4JVApE8hyYsCQKFd4JdgySCf4FHhACHeYdugh9MUoVvAhETAYE?= =?us-ascii?q?kDRA4gVJwFYJ+CYIYF3oBCIdWhT5vAY8+gRoBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,227,1526342400"; d="scan'208,217";a="407705612"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2018 17:11:17 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5FHBHqn011319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jun 2018 17:11:17 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Jun 2018 12:11:17 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Fri, 15 Jun 2018 12:11:17 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Uma Chunduri <umac.ietf@gmail.com>
CC: "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-isis-segment-routing-extensions@ietf.org" <draft-ietf-isis-segment-routing-extensions@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
Thread-Topic: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments
Thread-Index: AQHUAeyMjcBb59d9r06sj+ia3wesOqRcCx+AgAE1rQCAAH8zgIAEGbaA//+6B5A=
Date: Fri, 15 Jun 2018 17:11:17 +0000
Message-ID: <ededa30c0bd7438ead4381a2c6b40903@XCH-ALN-001.cisco.com>
References: <CAF18ct4Lx4iBMnQYPEEkF7s7MyHybJkHQBiXzc2RqYk1mvQYrw@mail.gmail.com> <e727722e7481444f8b523c2dbd2420e8@XCH-ALN-001.cisco.com> <CAF18ct62iCH7VpjmA9FyrPiA8CYbxhk1S--TJCrZQOcDX7Aftg@mail.gmail.com> <a46f43cdb8384a60a48f7d5619faa473@XCH-ALN-001.cisco.com> <CAF18ct4h0VUmzAmNGDh9G8oZoes0EQzRtF-QC85tdz7FrRJWLA@mail.gmail.com>
In-Reply-To: <CAF18ct4h0VUmzAmNGDh9G8oZoes0EQzRtF-QC85tdz7FrRJWLA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.88.43]
Content-Type: multipart/alternative; boundary="_000_ededa30c0bd7438ead4381a2c6b40903XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uof3NeMiES17HMKPF1rjV-uUk5A>
Subject: Re: [Lsr] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2018 17:11:23 -0000

Uma –

Thank you.

I have posted a new version (17) with the previously provided changes.

   Les


From: Uma Chunduri <umac.ietf@gmail.com>
Sent: Friday, June 15, 2018 9:21 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: lsr@ietf.org; draft-ietf-isis-segment-routing-extensions@ietf.org; lsr-chairs@ietf.org; lsr-ads@ietf.org
Subject: Re: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Les, Co-authors and WG,

Though there is a scope for minor improvements in the text, I am fine  if you choose not to update further -  based on the responses below.

I have no further comments and initial version of the write-up has been updated.


BR,

--
Uma C.

On Wed, Jun 13, 2018 at 12:03 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Uma –

Responses inline.

From: Uma Chunduri <umac.ietf@gmail.com<mailto:umac.ietf@gmail.com>>
Sent: Tuesday, June 12, 2018 11:09 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; draft-ietf-isis-segment-routing-extensions@ietf.org<mailto:draft-ietf-isis-segment-routing-extensions@ietf.org>; lsr-chairs@ietf.org<mailto:lsr-chairs@ietf.org>; lsr-ads@ietf.org<mailto:lsr-ads@ietf.org>
Subject: Re: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Les,

Thanks for your quick response and changes in the document. Please find my further response below [Uma]:

--
Uma C.

On Mon, Jun 11, 2018 at 10:00 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Uma –

Thanx for the prompt review.

 2. Section 2.1

a. "The 'Prefix SID' MUST   be unique within a given IGP domain (when the L-flag is not set)."

   I see this is conflicting with what's been defined in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14,
section 3.3 -
   "Within an anycast group, all routers in an SR domain MUST advertise  the same prefix with the same SID value."

   If you see otherwise please explain why?

[Les:] This is a misunderstanding on your part.
An anycast prefix may be advertised by multiple nodes, but the Prefix SID associated with the prefix is the same regardless of which node advertises it. So there is no contradiction/conflict here.


[Uma]:  I understood the intention.

This doc says - "The 'Prefix SID' MUST   be unique within a given IGP domain (when the L-flag is not set)."
And it won't give any exception for "anycast group" either in the text or through reference to  draft-ietf-spring-segment-routing-14<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14>14>.


[Les:] If both Node A and Node B advertise (1.1.1.1/32<http://1.1.1.1/32>, SID 100) this is NOT a conflict. This is expected behavior for an anycast address.

Examples of conflicts:

Node A (1.1.1.1/32<http://1.1.1.1/32>, SID 100)
Node B (1.1.1.1/32<http://1.1.1.1/32>, SID 200)
(Different SIDs for the same prefix)

Node A (1.1.1.1/32<http://1.1.1.1/32>, SID 100)
Node B (2.2.2.2/32<http://2.2.2.2/32>, SID 100)
(Same SID for different prefixes)


b. "A 4 octet index defining.."
What happens  to the computed label value if the index is of 4 octets value? I am asking this as index can have 4 octets but the eventual label (SRGB offset + index) would be only 20 bits.
Can you point (if any)  references to https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls appropriate sections -  is this is addressed there?

[Les:] See https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4 (emphasis added):

“ 0 =< I < size. If the index "I" does not satisfy the previous
      inequality, then the label cannot be calculated.”

[Uma]: Thanks for the pointer. I am fine with keeping this at a common place but this document  needs a generic reference specifically for some of the conflict/error conditions to that.

[Les:] WE have deliberately kept any discussion of handling of conflicts (now identified as “collisions”)  out of the IGP drafts. Please see https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.5 for discussion of this topic – which is not protocol specific.


3. Section 2.2.1

a. "F-Flag: Address-Family flag..."

     Not sure why this has to do with encapsulation? What happens if native IPv4/IPv6 data packet is using this SID with out any encapsulation? Could you please clarify.

[Les:] When the packet is forwarded over the specified outgoing interface it will either have an IPv4 encapsulation or an IPv6 encapsulation i.e., the payload is encapsulated in the afi specific L3 protocol.
This does not mean that a new AFI specific header is imposed.


[Uma]: Thanks.  I didn't expect payload encapsulation with L3 in IS-IS document. I see this is derived from the base TLV where this sub-TLV belongs to (22/222/223 etc.). This sounded like additional encap and hence my comment.

But one of my larger point here is why a sub-TLV has to specify/define AF. This is the property of the associated TLV/MT-aware TLV.
I understand this could be too late to change here but this additional information should not conflict with base while usage.
One incorrect usage *example* of this sub-TLV with AF unset (IPv4) in TLV 222 with MT-ID=2 (IPv6).

As it stands this combinations valid/allowed. Perhaps some text around this would be helpful.

[Les:] Consider the case of single topology IPv6 support. Here, a single IS Neighbor advertisement is used in support of IPv4 and IPv6. The indication of which SID is used for which address-family is therefore required.
Although it is a common practice to have a 1-1 mapping between topologies and address-families, this is not required. 1-1 mapping  is commonly assumed because of the reserved MTIDs defined in RFC 5120, but a single topology may be used to support multiple address families. MTID 0 support for IPv6 is the most common example.


4. Section 2.2.2

a. Nit: V and L flags: Content is duplicated and perhaps it can instead refer to section 2.2.1


[Les:] The text says:
“ where F, B, V, L, S and P flags are defined in Section 2.2.1.”

???

[Uma]: Sorry - I should have been more specific. Was referring to duplicated text in Section 2.2.1 and 2.2.2

 "

      *  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.



      *  A 4 octet index defining the offset in the SID/Label space

         advertised by this router using the encodings defined in

         Section 3.1<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16#section-3.1>.1>.  In this case V and L flags MUST be unset."



[Les:] What you suggest could be done. IMO it does not improve the readability of the document.

If there is some consensus for your suggestion I am willing to make such a change – but at this point I prefer to leave the text as is.


5. Section 3.2 and Section 2.1

    Could you please clarify what is preferred if multiple prefix-sids with different algorithm values are advertised for the same SID value?

[Les:] There is no “preference” here. In order to have algorithm specific forwarding entries we MUST have different SIDs for each algorithm. A router will use the SID which matches the algorithm associated with the forwarding entry.

[Uma]: ..and IMO, this should be specified.

[Les:] I am not clear on what you think needs to specified. As the notion of “preference” is not relevant why would we introduce it?

   Les