[spring] AD Review of draft-ietf-spring-segment-routing-mpls-10

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 24 August 2017 02:39 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7BF12008A; Wed, 23 Aug 2017 19:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 u4b4klHODWRT; Wed, 23 Aug 2017 19:38:58 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8C31323A2; Wed, 23 Aug 2017 19:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28424; q=dns/txt; s=iport; t=1503542337; x=1504751937; h=from:to:cc:subject:date:message-id:mime-version; bh=fJ8oVpdiwGY63Gs7GH3Rm2d5zU6Xe4wn5NwVglHFhy8=; b=er2qOjTnynDZBijfBVLgIjpajshBRG6g6DdPZKV+5+c+wRTvP4uGLFpn VcxkKFJUjU0lkLj8XyZ1ZAoayZNGfYoRsNI5YW0sLuM/GMZmXB3TRyx7Z EOGZvSpqpmfl49InflNZV0KUkM3tLQ0UpjNDzwOdavzRoBDUajacs87e5 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DMAgCFO55Z/4kNJK1dGgEBAQECAQEBAQgBAQEBgm9rZIEcg3CaNJgUDoIECYU+HIQtQRYBAgEBAQEBAQFrHQuFQgpMEgEGFBsVAgQwFxAEDolSZI8AnWaCJieLOQEBAQEBAQEBAQEBAQEBAQEBAQEBHoMqggKBTIFiASuHLA11glQwgjEFmCKINgKUQoIShWOKb4lvjD4BJgwlgQp3FUkSAYUEBReBZ4ZngQ8BAQE
X-IronPort-AV: E=Sophos;i="5.41,419,1498521600"; d="scan'208,217";a="471047794"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2017 02:38:56 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7O2cu81004739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2017 02:38:56 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Aug 2017 21:38:55 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 23 Aug 2017 21:38:55 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-spring-segment-routing-mpls@ietf.org" <draft-ietf-spring-segment-routing-mpls@ietf.org>
CC: Martin Vigoureux <martin.vigoureux@nokia.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: AD Review of draft-ietf-spring-segment-routing-mpls-10
Thread-Index: AQHTHIIh4KJmZ7gcR0CZ8hGMO0nB2Q==
Date: Thu, 24 Aug 2017 02:38:55 +0000
Message-ID: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.25.69]
Content-Type: multipart/alternative; boundary="_000_74FB72FCAD694EA3ACA2739168EE0A44ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8>
Subject: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Aug 2017 02:39:01 -0000

Dear authors:

I just finished reading this document.  Please take a look at my comments below.

The main questions/concerns that I have related to this document is not just for the authors, but for the Shepherd and the Chairs too.

Q1. Why is this document on the Standards Track? From the Introduction: “This drafts describes how Segment Routing operates on top of the MPLS data plane.”  Describes, yes.  On the other hand, the Shepherd’s write-up says that it “specifies the generic functions of the architecture” – I don’t see a specification, just a description.  As such, I think this document should be Informational.

Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one with any real content…but there are only a couple of things in it that are not in the Architecture document: the introduction of the SRLB, and some words about the index – both of which should be really explained in the Architecture document, and not here.  I wonder what the value of publishing this document really is.  What long-term archival value does it provide?

Q3. I also have to wonder about the IPR declared for this document.  If most of the information here is already defined, described or specified in draft-ietf-spring-segment-routing, should the IPR declaration apply to that document as well (or maybe instead of this one)?  It is not the IETF’s role (including the WG) to discuss whether a piece of IPR is valid or not – I just want to make sure the disclosures apply to the right document.


I didn’t find a discussion on the list about any of these points.

Thanks!

Alvaro.


Major

M1. Section 2. (MPLS Instantiation of Segment Routing) explains how “in the MPLS instantiation, the SID values are allocated within a reduced 20-bit space out of the 32-bit SID space.”  However, I couldn’t find where draft-ietf-spring-segment-routing defines the SID space as using 32 bits (or any other length).  In fact, the closest that document comes is when it defines an SID and mentions “Examples of SIDs are: an MPLS label, an index value in an MPLS label space, an IPv6 address.”   I’m assuming the “32-bit SID space” comes from the fact that the extensions define an SID of that length.  All this is to say that as you describe how SR operates in the MPLS dataplane, do so not explicitly depending on the implementation of the extensions (which in fact seem to already account for different lengths).


M2. [I mentioned these issues in the review of draft-ietf-spring-segment-routing as well.]

M2.1. “The notion of indexed global segment, defined in [I-D.ietf-spring-segment-routing]…”  That document doesn’t properly define the concept/use of the index.  There are several mentions in this document that I think rely on a proper definition/discussion of the concept.

M2.2. The concept of an SRLB is not defined in the Architecture document either.


M3. Still in Section 2, from this text:

      *  When different SRGBs are used, the outgoing label value is set
         as: [SRGB(next_hop)+index].  If the index can't be applied to
         the SRGB (i.e.: if the index points outside the SRGB of the
         next-hop or the next-hop has not advertised a valid SRGB), then
         no outgoing label value can be computed and the next-hop MUST
         be considered as not supporting the MPLS operations for that
         particular SID.

…several questions/comments…

M3.1. [minor] I hope to see an explanation of the “[SRGB(next_hop)+index]” notation.

M3.2. What is a “valid SRGB”?  I don’t think the validity of the SRGB is described in the Architecture document.

M3.3. I’m assuming that once the “next-hop MUST be considered as not supporting” then the packets are dropped, right?

M3.4. [Maybe I’m missing something obvious here.]  Going back to the validity of the SRGB advertised by a specific node, shouldn’t the ingress node verify that before imposing a path that will fail?  But I couldn’t find anything in the Architecture document that talks about the ingress node verifying that the path is valid (including the validity of the SRGB).


M4. Still in Section 2: “As described in [I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within the SR domain eases operations and troubleshooting and is expected to be a deployment guideline.”  As I mentioned in my review of the Architecture document, that document doesn’t contain deployment guidelines related to the SRGB, and it doesn’t describe how “using the same SRGB…eases operations and troubleshooting”.



Minor

P1. The term “service chain” is used in the Abstract.  Given that the concept is not vital to the architecture and that there might be unnecessary confusion with SFC, I would suggest taking it out.

P2. Informative References to VPN, VPLS, VPWS, LDP, RSVP-TE…would be nice.

P3. Section 2. (MPLS Instantiation of Segment Routing) says that “a controller-driven network…MAY use the control plane to discover the available set of local SIDs”.  The “MAY” implies that there is a choice (i.e. it is optional) and that other discovery mechanisms exist.  What are those other choices?  Note that earlier in this section you already wrote that IGPs are used for flooding the information.  s/MAY/may

P4. Section 2: “…the use of the binding segment as specified in [I-D.ietf-spring-segment-routing], also allows to substantially reduce the length of the segment list…”  Nice, but there is no description of the binding segment in draft-ietf-spring-segment-routing.

P5. References.  Please take a look at rfc8174 and update the “Requirements Language” and associated references.



Nits

N1. I think that the references to *-segment-routing-extensions are superfluous.  BTW, the fourth paragraph of the Introduction uses a reference to *-segment-routing-extensions to point at ISIS/OSPF (the protocols!).

N2. It would be very nice if the examples used IPv6 addresses.