Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

<bruno.decraene@orange.com> Wed, 22 February 2017 13:00 UTC

Return-Path: <bruno.decraene@orange.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 DACE31297F3 for <spring@ietfa.amsl.com>; Wed, 22 Feb 2017 05:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 H-u9HqqSgb9b for <spring@ietfa.amsl.com>; Wed, 22 Feb 2017 05:00:20 -0800 (PST)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D601A1297CE for <spring@ietf.org>; Wed, 22 Feb 2017 05:00:19 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 092631607C6 for <spring@ietf.org>; Wed, 22 Feb 2017 14:00:18 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id DE23AC0060 for <spring@ietf.org>; Wed, 22 Feb 2017 14:00:17 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 14:00:17 +0100
From: <bruno.decraene@orange.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02
Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPgAMEbFwAAEo+2A=
Date: Wed, 22 Feb 2017 13:00:17 +0000
Message-ID: <15606_1487768417_58AD8B61_15606_5807_1_53C29892C857584299CBF5D05346208A1ED74B4A@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED74B4AOPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/uhg7t7WuDt0D9LiSGYD1BbVDMwo>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 22 Feb 2017 13:00:23 -0000

Please find below some additional points


1)      "Abstract

   This document describes the motivation and benefits for applying
   segment routing in the data-center.  It describes the design to
   deploy segment routing in the data-center, for both the MPLS and IPv6
   dataplanes. »

It looks to me that this document is limited to BGP-based large-scale data-center  (DC) design described in [RFC7938].
So may be
:s/ the data-center./ BGP-based large-scale data-center.
:s/ in the data-center,/ in those data-center,


2)      For the document write up, are there any known deployment of draft-ietf-spring-segment-routing-msdc?



3)      § 2.1.  Reference design

"   o  Each node is its own AS (Node X has AS X)

      *  For simple and efficient route propagation filtering, Nodes 5,
         6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS,
         Nodes 9 and 10 share the same AS.

      *  For efficient usage of the scarce 2-byte Private Use AS pool,
         different Tier-3 nodes might share the same AS.

      *  Without loss of generality, we will simplify these details in
         this document and assume that each node has its own AS."


First 2 bullets are contradicting each other's.
Please update/rephrase as needed.


4)         [I-D.ietf-idr-bgp-prefix-sid] could be seen as a normative document. IDR WG is also initiating the WG last call, hence both document could progress together.

Thanks,
Regards,
Bruno



From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, February 21, 2017 4:37 PM
To: spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

Hi authors,

As the document shepherd, I have reviewed the document and have the following comments.

Thanks,
Regards,
Bruno

======================================
Major comment:
======================================
- Section 12 (Manageability) is empty ("TBD")
- Section 13 (Security) is empty ("TBD")

======================================
Minor Comment:
======================================
- Section 11 (IANA) is empty ("TBD")
- I-D.ietf-spring-segment-routing should probably be a normative reference

---
§1
Term "middle stage" is used twice but is not defined. May be replacing it with the terms Tier-x which are defined.

---
§4.1

---
"all the nodes are allocated the same SRGB"
Please expand SRGB on first use, and provides a reference ([I-D.ietf-spring-segment-routing])

---
§4.2.1
"BGP-Prefix Attribute"
The name of the BGP attribute is "BGP Prefix-SID" and the TLV hosting the index is "Label-Index"

---
§4.2.1

"Then, Node10 sends the following eBGP3107 update to Node7:

   . NLRI:  192.0.2.11/32
   . Label: 16011"

As per RFC 3107, the NLRI is both the IP prefix and the label. Hence, proposed
:s/NLRI/Prefix
or :s/NLRI/IP Prefix

(RFC 3107 uses the term "Prefix" but IMHO it implies "IP Prefix")

---
§4.2.1

OLD: it should allocate the label LOCAL-SRGB (16000) + "index" 11 (hence 16011)
"LOCAL-SRGB" is undefined. I would suggest
NEW: it should allocate the label from its own SRGB block, offset by the index received in the BGP Prefix-SID attribute. (16000+11 hence 16011)

---
§7.3 seems very similar to me than §7.2. e.g.

§7.2:
"  One particularly interesting instance of performance-aware routing is
   dynamic fault-avoidance.  If some links or devices in the network
   start discarding packets due to a fault, the end-hosts could detect
   the path(s) being affected and steer their flows away from the
   problem spot.  Similar logic applies to failure cases where packets
   get completely black-holed, e.g. when a link goes down."

§7.3
"if in the topology depicted on
   Figure 1 a link between spine switch Node5 and leaf node Node9 fails,
   HostA may exclude the segment corresponding to Node5 from the prefix
   matching the servers under Tier-2 devices Node9."

May be §7.3 should be removed or rephrased to better differentiate its content compared to §7.2

---
§8.1
"The Prefix Segment is a lightweight extension to BGP Labelled Unicast"
"Prefix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-04 uses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribute"

Please make a consistent use of the right term in the whole document.

---
"Common SRGB"
The call for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Please remove the duplicated text. (e.g. moving all related text to 8.1)

---
"§8 Additional Benefits
[...]
§8.4 Incremental Deployments
As explained in Section 4.2.5, this design can be deployed incrementally."

As the incremental benefit is already discussed at length in §4.2.5 there is no need to create a one line section 8.4 as this is not an _additional_ benefit.

So either removing §8.4 or moving §4.2.5 to 8.4.

---
§10
:/BGP Prefix SID attribute/BGP Prefix-SID attribute

Plus may be adding the reference to the IDR document.

:/ORIGINATOR_SRGB TLV/Originator SRGB TLV

---
§10
"   Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID signals
   the SRGB of the switch that originated the BGP Prefix Segment.

   This allows to determine the local label allocated by any switch for
   any BGP Prefix Segment, despite the lack of a consistent unique SRGB
   in the domain."

The above text is not clear enough for me to understand why and how the ORIGINATOR_SRGB is used.
I find the text in the IDR draft a little more clear. "It is used to build SRTE policies when different
   SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc])." Which is a pity given that the IDR draft refers to the SPRING draft for the reason and the use.

So please rephrase/elaborate.

On a side note, I would not call this node a "switch" which for me is a layer 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or (egress) LER)

And I fail see the relation with the title "Alternative options"


======================================
Nits:
======================================
In figure 1 and 2, Node10 diagram outrun the box. :s/ 10  |/10  |

---
"In other words, per-flow ECMP that does not perform efficiently when flow life-time distribution is heavy-tailed."

may be :s/that does/does

---
"Referring to Figure 1Referring to Figure 1"

duplicated.

---
"In the MPLS case, we do not recommend to use different SRGBs at each node."
May be avoiding (double) negation when positive statement is meant . e.g. NEW: In the MPLS case, we do recommend to use same SRGBs at each node



From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Tuesday, February 21, 2017 10:51 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02


Hello Working Group,



This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].



Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *7th of March*.

Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as an Informational RFC.



We have already polled for IPR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2].



Thank you



M&B


[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02
[2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-msdc






_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.