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

Uma Chunduri <umac.ietf@gmail.com> Tue, 12 June 2018 01:27 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 999CF130EB2; Mon, 11 Jun 2018 18:27:33 -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 8Ae4legYcexP; Mon, 11 Jun 2018 18:27:29 -0700 (PDT)
Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (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 6B3A0130DCC; Mon, 11 Jun 2018 18:27:29 -0700 (PDT)
Received: by mail-ua0-x241.google.com with SMTP id n4-v6so14863827uad.6; Mon, 11 Jun 2018 18:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=zhe5KU74Ecs4cyXOkdjcB1n4YqEL2vMJ29DHEZy89JQ=; b=pHYci98hemBkfpMN4exMioBewATb41t3nKW95d0rpbtmvq1DcIoYzoRrYVQT5l70Dq RjJGpf1f6RLzLYyZYZTcYX4M6Mbn6PvpwpeoySMIzGb5UNg4ohekGqbAX5Euc/mLqr40 DfjEQTtmFt2U7VtBSEtJcBz/nMU7w/kdSEDlK9XbDQw7C1mj83Mmhkkr8svrtHcfGw7k tPBFkY8IUlUCMCBdbxmBbXL+E2YfJYAftK+kDJ9dg3UPdXE1G1fxzmD+LNxO9iirfiMF kx+j7R/lOpsQM+v9T36uH/LzKun3HDN1pHiz7Mb72OPsBw14WKVS4RE6UYFttj7MSQjv +v6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zhe5KU74Ecs4cyXOkdjcB1n4YqEL2vMJ29DHEZy89JQ=; b=F2ZfL7ys7EMTOH6KkpeOsCnRf9Y02UcS18SPz8zqp63DvtH3DbtKZdwrGCsxCHulAl 8w/uZBE5fVqkSJTQ1HkEy72TgXmzv8F3rqfr49Q7AWmueUF/dtBjCPgL/6S+O0+hgwTy yjDGhdLNiw4kNnssKSmh6Km5OyRIhKF+awd4NWWXa3IIzjYgzGnYLqp+9SEUAkBhqp/2 K/r3+g/WE+lcfM2WPXMgZrQk5oDhZkrOlIVFPOoh5kr4e1Ruzl6GCiMJicFEyD5S+U9r utC1APwi5IxaQ801+1H1e44QmjHXZHmNp8FeQfFQCcYstYlTc7pfSH6RFjMN6aJCHGbI 7IGw==
X-Gm-Message-State: APt69E3Lh/KwEg1uOaCFywsu0I9h072ZaBaa8eNnvwGO5a0XivpHBuu5 W61aPOvJETYakrNU63sIrTX6HHeMvMNHe4SB5zD/Wg==
X-Google-Smtp-Source: ADUXVKIXY9UiQ44agtuADGkuWsQP7flU0IuVP0rKlG/jdEmTPFAAvWybCd1Ho8mXhYCsmk2TkRwC+OVEc8syGpshNxc=
X-Received: by 2002:ab0:136c:: with SMTP id h41-v6mr1076449uae.193.1528766848223; Mon, 11 Jun 2018 18:27:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a67:207:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 18:27:27 -0700 (PDT)
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Mon, 11 Jun 2018 18:27:27 -0700
Message-ID: <CAF18ct4Lx4iBMnQYPEEkF7s7MyHybJkHQBiXzc2RqYk1mvQYrw@mail.gmail.com>
To: lsr@ietf.org
Cc: draft-ietf-isis-segment-routing-extensions@ietf.org, lsr-chairs@ietf.org, lsr-ads@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eecead056e67c4af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/V3NPrikPeOH1yHCUaXD43Q6R5As>
Subject: [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 01:27:34 -0000

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.


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.



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.



 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?



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?



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.



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.



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

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?
--
Uma C.