[spring] AD Review of draft-ietf-spring-segment-routing-msdc-05

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 31 August 2017 20:40 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 588ED13292C; Thu, 31 Aug 2017 13:40:09 -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 E1dTAgqZy1md; Thu, 31 Aug 2017 13:40:07 -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 ED2B7132941; Thu, 31 Aug 2017 13:40:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21870; q=dns/txt; s=iport; t=1504212006; x=1505421606; h=from:to:cc:subject:date:message-id:mime-version; bh=n4CtsbX5igv72vM5WgFePclnTFh9h5DcETM+ANJew7Q=; b=JBBWwEVIDVz0KQHor3mqTqAoKyBEmn3o3tw4E7kn97bhrleAUpYYoIxS OL2F9tID0lbMdG4V6wMaQvnVx8QUQYxBmoI9dTgT95OmHwf5by/ftv/+J wwESGHFSsG9Vy0N3h2GfWvhJPHFk/Bb2yGQji7MWtZo+hQq2s1ZQI46qB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CgAAC2c6hZ/4MNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgm9rZIEcjhCQHpJahT4OggSFRxyDdT8YAQIBAQEBAQEBax0LhUJWEgEGFDACBDAXEAQOiVJkkiSdZoInJ4s2AQEBAQEBAQEBAQEBAQEBAQEBAR+DKoICgU6BYyuHOoNLMIIxBZgxiD4ClE+CE4VninSWRAEfOIENdxVbAYUFHIFnikGBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,455,1498521600"; d="scan'208,217";a="288038575"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 20:40:02 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VKe2DY029470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 20:40:02 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 15:40:02 -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.1263.000; Thu, 31 Aug 2017 15:40:02 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-spring-segment-routing-msdc@ietf.org" <draft-ietf-spring-segment-routing-msdc@ietf.org>
CC: "bruno.decraene@orange.com" <bruno.decraene@orange.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-msdc-05
Thread-Index: AQHTIplRaR1S1gVL90eoIjw7WKwTtQ==
Date: Thu, 31 Aug 2017 20:40:01 +0000
Message-ID: <3822F955-321A-4B53-AAB6-1628811E32B8@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.82.225.239]
Content-Type: multipart/alternative; boundary="_000_3822F955321A4B53AAB61628811E32B8ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/PnzueRoyev9wQ3_0c_rRCBu0zjk>
Subject: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05
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, 31 Aug 2017 20:40:09 -0000

Dear authors:

I just finished reading this document.  Thanks for a clear and straight forward draft!

I have some comments (see below).  The main one is about the inclusion of hosts as defining the source routed path, without them being explicitly called out in the draft-ietf-spring-segment-routing.  Knowing that some of the authors overlap, please make sure there are no holes in the Architecture.  I will start the IETF LC once this item is addressed, and a revised ID is produced do address the other comments, as needed.

Thanks!

Alvaro.


Major:

M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me that hosts are called out as being able to define the source routed path.  Please make sure that the Architecture document has some text about the use of hosts – maybe constrained to the case where the hosts can be programmed.  Section 6 provides some good text for that.


Minor:

P1. “service chain”: please remove to avoid confusion with SFC (same comment as for all the SR documents).

P2. References:
- s/rfc3107/draft-ietf-mpls-rfc3107bis
- The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938 should be Normative.

P3. There are 2 instances of using rfc2119 language, I don’t think that either is needed because you’re really paraphrasing other documents.  IOW, I recommend you take the Normative language off.

P3.1. Section 4.2.1. (Control Plane): “The implicit-null label in the NLRI tells Node10 that it is the penultimate hop and MUST pop the top label…”  This is normal MPLS operation, so the MUST is really not introducing anything new, just paraphrasing the MPLS architecture.  Instead of the MUST, a reference to MPLS would be more than enough.  s/MUST/must

P3.2. Section 11. (Manageability Considerations): “As recommended in [I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all nodes…”   The Architecture document doesn’t (yet) make that recommendation explicitly, but a pointer to it should be enough.  s/SHOULD/should

P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): “…a packet with top label 16011 received by any node in the fabric…and the label 16011 is penultimate-popped at Node10”, or at Node9, right?

P5. Section 4.3: “…and with the BGP-Prefix-SID attribute extension defined in this document”; that was not defined in this document.

P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: “AIGP metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a large-scale multi-domain design such as Seamless MPLS [I-D.ietf-mpls-seamless-mpls].“  This paragraph sounds random to me as there is no further explanation of the use, impact, advantages, etc.  Neither AIGP/Seamless MPLS is mentioned again in the document, nor in draft-ietf-idr-bgp-prefix-sid or rfc7938.  Please either expand the concepts/use or delete this paragraph.

P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane): “Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the support of the Segment Routing extension header (SRH, [I-D.ietf-6man-segment-routing-header])…”   draft-ietf-idr-bgp-prefix-sid says nothing explicitly about the BGP-Prefix-SID Attribute advertising support for the SRH – maybe it should, but it doesn’t.

NEW>
   Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID
  for IPv6 packets destined to
   segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]).

Instead, put the reference later in the same section where it says “…sending IPv6 packets with a SRH extension header…”.


Nits:

N1. s/BGP4/BGP-4

N2. Section 3: “Further in this document…”  A reference to Section 7 would be nice.

N3. s/index11)/index11

N4. It would have been nice to illustrate the operation in 4.2.x using IPv6 addresses.

N5. Throughout most of the document the nodes are referred to as Nodex, but there are a couple of places where Torx is used.  Even though these nodes have been identified as ToRs, it would be nice to be consistent to avoid confusion.

N6. Section 7: s/problems describe above/problems described above   Also, putting a reference back to Section 3 would be nice.

N7. The content in Section 7 is good, and the DC example helps in the illustration – but the applicability is not just constrained to it.  It might be a good idea to add at note at the start mentioning the broader applicability.

N8. Please avoid using “we”.