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

Jeff Tantsura <jefftant@gmail.com> Tue, 12 June 2018 17:15 UTC

Return-Path: <jefftant@gmail.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 9A5A7130F69; Tue, 12 Jun 2018 10:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S_9ic9sXk6p8; Tue, 12 Jun 2018 10:14:59 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DB0130E82; Tue, 12 Jun 2018 10:14:59 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id l2-v6so11753952pgc.7; Tue, 12 Jun 2018 10:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KJvIbDHrTn8Lcr0ftKh6xudwiR4OwTEvP0YTOf8EAe4=; b=mU0FD+TgQ782wClWkgSbJazpljPIczy3o9SaEtw9PmXJJIUCVhH30K6VOgAIOKoA0X kIw7eofSJCk0nWSUvZ1E7edVfE4qEOhecanBxpiqGKCala0VX04wDdM+GqlrHKPXNY4O hxgiG1z8OGZh0k3vXg70J14+69vJ9Qe0KAeiKZ3g24Bo0fvEV3dndmQpQD5eUa7tM+aV gmxCpIl9yBkBzUM6vB13ads78Wpny2WI10xfnxNg+2ze7AXSnvMPdbW+q72jMXK7g+2b +ZvZkgQQB4acA/0GdOBeOt/Vh69VsYs2I7Dq0kHF7uKvjTrKsnuV4JvrK+h2HoHTQhfM C+iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KJvIbDHrTn8Lcr0ftKh6xudwiR4OwTEvP0YTOf8EAe4=; b=V/LL6oK2zPfEPipu+fKPa/S1m3zmlb7BRvCmWlrsLoBI63U2Lm69KpTNQJT4Vlm3D7 C1cyUqUEKwYgOsrPJ5XZHX2tJcBhDU1NV8LDSIsBj8yTyLp0kfolki7rZ/v86LgxTluj IR2tItaqTb0HLMVoDM9IEu2NYwO47KTuRJzzAcEUidrj6HH1q69IFqv5zVXulSi9reVA zos2skELLDh/+NeYgJRLi3y0rkDGUn+VrxAgs4oyEBsrx5WI4eEQDJCTgFUZ+KxfCLcQ bn+Boko3USERyfN+dCSVHKwc/PazZ8AEzDaB+y398mC97NG2Gggp7H30EvPqoTmTqu5W ZaDg==
X-Gm-Message-State: APt69E2Ov6ke9tV4ho4yDFctSNsmg80lGf4y06gCgW6QVMerLqXPnI86 VScMIvM0H8jBV3pbXLMPLc4=
X-Google-Smtp-Source: ADUXVKI25IE64QahkQ/ZWqBlcW1vYTAAQigICt5iB2rL8/fBXrzB8oAcbsKy3Os6gFAgBup9WGte6g==
X-Received: by 2002:a62:119d:: with SMTP id 29-v6mr1319896pfr.102.1528823699198; Tue, 12 Jun 2018 10:14:59 -0700 (PDT)
Received: from [10.11.13.172] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id z19-v6sm658490pgv.12.2018.06.12.10.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 10:14:58 -0700 (PDT)
From: Jeff Tantsura <jefftant@gmail.com>
Message-Id: <5C496FCF-5E82-47E4-848A-CEA99E6A0C62@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_07490A6F-177E-4ACF-914B-655D3665D354"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 12 Jun 2018 10:14:57 -0700
In-Reply-To: <33b6d676e25741eeb83b9330a32854cb@XCH-ALN-001.cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-isis-segment-routing-extensions@ietf.org" <draft-ietf-isis-segment-routing-extensions@ietf.org>, Les Ginsberg <ginsberg@cisco.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
To: Uma Chunduri <umac.ietf@gmail.com>
References: <CAF18ct4Lx4iBMnQYPEEkF7s7MyHybJkHQBiXzc2RqYk1mvQYrw@mail.gmail.com> <e727722e7481444f8b523c2dbd2420e8@XCH-ALN-001.cisco.com> <33b6d676e25741eeb83b9330a32854cb@XCH-ALN-001.cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/4gc6WDfrgXo7MIDFVRXNXVLum10>
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: Tue, 12 Jun 2018 17:15:06 -0000

Uma,

Wrt number of authors, if I recall correctly (I don’t have pointers to the discussion anymore), given the lengths and involvement of the authors currently on the front page, as an exception - both ospf and isis sr drafts would keep the initial number of authors.

Thanks,
Jeff

> On Jun 11, 2018, at 22:05, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> Uma –
>  
> One item I forgot…there are no meaningful nits.
> Idnits reports:
>  
> -- Looks like a reference, but probably isn't: '100' on line 1009
>      'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '199' on line 1009
>      'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '1000' on line 1010
>      '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '1099' on line 1010
>      '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '500' on line 1011
>      '[500, 599]...'
>  
>   -- Looks like a reference, but probably isn't: '599' on line 1011
>      '[500, 599]...'
>  
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'
>  
> The fact that idnits looks at everything enclosed in [] as a reference does not mean the text requires revision.
> Idnits also does not allow that a non-RFC document can be a normative reference – but clearly ISO 10589 is a normative reference.

[jeff] indeed, we have used variety of non-RFC documents as normative references in the past, this should be acceptable in this case.
>  
> Thanx.
>  
>    Les
>  
>  
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, June 11, 2018 10:00 PM
> To: Uma Chunduri <umac.ietf@gmail.com <mailto:umac.ietf@gmail.com>>; lsr@ietf.org <mailto:lsr@ietf.org>
> Cc: 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
>  
> Uma –
>  
> Thanx for the prompt review.
>  
> I have attached proposed diffs to address some of your comments.
>  
> Additional responses inline.
>  
>  
> From: Uma Chunduri <umac.ietf@gmail.com <mailto:umac.ietf@gmail.com>> 
> Sent: Monday, June 11, 2018 6:27 PM
> To: lsr@ietf.org <mailto:lsr@ietf.org>
> Cc: 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: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments
>  
> Dear Authors,
>  
> I have done shepherd  review of  draft-ietf-isis-segment-routing-extensions-16 document as requested by LSR chairs. First, I would like to thank all the the authors and contributors on this document.
> I have few minor comments below  and would be great if authors take a look at these.
>  
>  
> =====
>  
> A. I see few ID nits (comments and warnings). Please fix  those.
> B. For the record: (as this would come up soon) : Currently there are 8  front page authors and please indicate why this document should be given exception w.r.t 5 co-authors norm, that is being followed in general.
>  
> [Les:] This will be addressed after discussion among the authors – thanx for the reminder. J
>  
> 1. Abstract & Section 1
>  
> a.
>    "These segments are   advertised by the link-state routing protocols (IS-IS and OSPF)."
>  
>    I see more than LSR protocols e.g. https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07 <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07>
>    Also not sure if this statement is necessary. Please either correct or remove this.
>  
> [Les:] The abstract and introduction state “within IGP topologies”.  In that context I believe limiting the protocols mentioned to IGPs is appropriate.
>  
> b.
>    "Two    types of segments are defined, Prefix segments and Adjacency   segments."
>  
>    This document defines more than these two if you include Section 2.4 (SID/Label Binding TLV). Section 2 is much better
>    where all types in this document are described as well as   [I-D.ietf-spring-segment-routing] is referred for other types.
>    In that sense the above statement looks incomplete/repetitive.
>  
> [Les:] I have revised the text in this section – see attached diffs.
>  
>  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 <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.
>  
>  
> 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 <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 <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.”
>  
> c. "A Prefix-SID sub-TLV is associated to a prefix advertised by a node    and MAY be present in any of the following TLVs:"
>  
>      Nit: Perhaps the list should include Section 2.5 too.
> [Les:] Added a reference to 2.5 as well. See attached diffs. Thanx.
>  
> 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.
>   
> 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.”
>  
> ???
>  
>  
> 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.
>  
>      Les
>  
> --
> Uma C.