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

Uma Chunduri <umac.ietf@gmail.com> Tue, 12 June 2018 18:13 UTC

Return-Path: <umac.ietf@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 32B86131029; Tue, 12 Jun 2018 11:13:13 -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 4xN-Pj4OjIM6; Tue, 12 Jun 2018 11:13:06 -0700 (PDT)
Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 517F5130E70; Tue, 12 Jun 2018 11:13:06 -0700 (PDT)
Received: by mail-vk0-x244.google.com with SMTP id q135-v6so14975098vkh.1; Tue, 12 Jun 2018 11:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2i66LddB7rxaWHlZ/lx4FAo+b1wK9mK8w6CRTmKTIaE=; b=Ims07VLPj9tbwaWFCBCY8oY0+03x4/lK3tqwMMT9jHRNEJa0fyHDy7BOhKN0lUxsLm SnSf+g9Uivr/zclUwWAonlWOsg+NENG8r1houDaWXAO+xJhDvbmQPzsp3FvRmTlQ8iMe NM9MBwA/HE94InaSiYOM8E+ziTmw1BG/3atJQtUek57k74cxYDgPsScV+SF7ugnuC2vh iI6lt57TFzkISZcKouCO7NFwzQ4zfBqnm9ug4/VWCw6nkL8GucvZGkLcluvtoOJaaZxy FzMa+viAvVutyOxT+Y1LDJhzQJwP8GKmHRNK1qxtVG2gWU9Gk44ZM8YY5SylfuX8L0tN +zcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2i66LddB7rxaWHlZ/lx4FAo+b1wK9mK8w6CRTmKTIaE=; b=dRM5QOIdvizfdGzoT83Gy0wbM+gWLj7CzZu8wmiXOeozKX3mXOXpFIoc3kO2FEJMby NBtBH4X+n2fkl/KNa6tY4W2jE2+s664qUnOTBLjKC3E5qzOK77ushyVshuvo78zV9iJB VZFy6NHoJmm7mxCmzjU/ZiyreZNamkcUwfHy1MU5MYJ9yqUabn2kPxa04TIPGbf7Ibjp r1kGr/CMqRsgrQ0ncnGXPc73QepRu18BaZb/7EXBCzRU9Xtp8gwDkyLDRSwMmWAvyL9p LmhjZO8JOub4h4Q0rxvpV25Ht8/eAV4BWLpQA6jeTzuRetw6h0Ky96yo8z9f6RKreZE3 I68g==
X-Gm-Message-State: APt69E1pF/LIptGkXLSYi/+ZuaFGxZ/InvyEXdz7e9QA1SWCy5mazjBf 4G/dV9dJnPihtrdgM9ot6yLRE7YZMXw42CIbfYU=
X-Google-Smtp-Source: ADUXVKJWcuMHXRvdnW6wtior92Tw8gBWAqx8xP4gaJwNbiFerSywdrpTmyJd6TL0vWRfDZWy13m8GqyZ475bnXfH90Q=
X-Received: by 2002:a1f:44:: with SMTP id 65-v6mr939287vka.32.1528827184685; Tue, 12 Jun 2018 11:13:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a67:207:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 11:13:04 -0700 (PDT)
In-Reply-To: <5C496FCF-5E82-47E4-848A-CEA99E6A0C62@gmail.com>
References: <CAF18ct4Lx4iBMnQYPEEkF7s7MyHybJkHQBiXzc2RqYk1mvQYrw@mail.gmail.com> <e727722e7481444f8b523c2dbd2420e8@XCH-ALN-001.cisco.com> <33b6d676e25741eeb83b9330a32854cb@XCH-ALN-001.cisco.com> <5C496FCF-5E82-47E4-848A-CEA99E6A0C62@gmail.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Tue, 12 Jun 2018 11:13:04 -0700
Message-ID: <CAF18ct6KSTFbmdErtY7YYktdprUefvRfk0fcv3ekukH+-RAq5A@mail.gmail.com>
To: Jeff Tantsura <jefftant@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>, Les Ginsberg <ginsberg@cisco.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004427de056e75d148"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WuregONcP8JlwDXGUTXvqSwSOvs>
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 18:13:19 -0000

Hi Jeff,

Thanks for your response. I would note the same but this is obviously with
Chairs and responsible AD's discretion.

Hi Les,

Thank you and I am fine here.

--
Uma C.

On Tue, Jun 12, 2018 at 10:14 AM, Jeff Tantsura <jefftant@gmail.com> wrote:

> 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>om>; lsr@ietf.org
> *Cc:* draft-ietf-isis-segment-routing-extensions@ietf.org; l
> sr-chairs@ietf.org; 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>
> *Sent:* Monday, June 11, 2018 6:27 PM
> *To:* lsr@ietf.org
> *Cc:* draft-ietf-isis-segment-routing-extensions@ietf.org; l
> sr-chairs@ietf.org; 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
>    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,
> 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 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.
>
>
>