Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 12 June 2018 09:53 UTC
Return-Path: <adrian@olddog.co.uk>
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 CD8F5130E1D; Tue, 12 Jun 2018 02:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 lCLmm2I5hl14; Tue, 12 Jun 2018 02:53:13 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99C8130E0D; Tue, 12 Jun 2018 02:53:11 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w5C9r5XS031142; Tue, 12 Jun 2018 10:53:08 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E2FB2203D; Tue, 12 Jun 2018 10:53:08 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 213A022032; Tue, 12 Jun 2018 10:53:08 +0100 (BST)
Received: from 950129200 (243.125.113.87.dyn.plus.net [87.113.125.243]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w5C9r410002502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2018 10:53:05 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Ahmed Bashandy' <abashandy.ietf@gmail.com>
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, bruno.decraene@orange.com, 'SPRING WG List' <spring@ietf.org>
References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <00e601d3f409$f3b5b050$db2110f0$@olddog.co.uk> <578b0d2f-3f7d-34dd-74eb-8a80cfc94fff@gmail.com>
In-Reply-To: <578b0d2f-3f7d-34dd-74eb-8a80cfc94fff@gmail.com>
Date: Tue, 12 Jun 2018 10:53:00 +0100
Message-ID: <02a901d40233$27843370$768c9a50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AA_01D4023B.8954D070"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQKAP//l/nPI4LNxaT86HbB7WmbcnAHy7KP1AmExflOi4UKXAA==
X-Originating-IP: 87.113.125.243
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23902.006
X-TM-AS-Result: No--15.321-10.0-31-10
X-imss-scan-details: No--15.321-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23902.006
X-TMASE-Result: 10--15.321500-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGUTHcBIlpNjX7siEtWY367EtdrY/Wb3fOrzPs85fwUk7IX LC9Ontkqox3eLPiNwxWxJZlbR4Xa9t1ZJprSJcwwJrUxoq6hvw/oFXQb3ZgkUSSqFMz9Rn227rK mSSA0LwB3AukSOTHXs9R7tePP+vqhuJqllQ6sW7QOrlBkQa9qFhokPBiBBj9/E+5bAfeaWuoP65 UmIJNL5MaYX5VNZEadH/8tLCuKdK9FqOm7OcUht3ZoUVaGRPdAlljUGWaZawJXPwnnY5XL5JIId Lez+VHof7y+obb77eLzhH+Ygr1L3dt1WGHYVkBEl1zsjZ1/6azfGWkUxfkwIN9RlPzeVuQQKO87 yxW0MVnNd3ejTGLU+OLymIssOrN/bvdUI+HIJ+NoMLOoNHsM9rBH/AqZyGLZIFBEE5CFomI4BNe SqPakoWzMze6/BySlKN7l2fUCrJWwWT+tU+LPUg2IdVM+s7+jzV4D+5YmeSJmAuQLcdQ1EBYFvk rc4IiTCCjEChDSo1e+tz/CddrFFyOPMOQqmOkm6/xAZojbl7cP/NGt6Npc0koUtcWDAJ8qxUDTx L3vuSAg72GtZPeFmZBAVCwRE3qJ8KoeamrOdHWPR2u912hYRPgv6yQpgxkbftUOKYKOYt/0Cylm bBU3T8wiPFwdmGtzjMBdzXSd1csClT9RFJraeQXysW33GYMpZdKh+/+x0Y4L6gLoFDUZRIDfaUb apuKiJYhudvYhR966zLpt0DR8OrcP6OCfbw/mylAqNTt8FdXj5lyuq8IOQeouc5Rcf1B027SCZT a2t0oU2gELQ2/DBe/rqcgLK+Dfw3inhDZkPRmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vasQd9qPXhnJJVXmq9vM64RV03UYxlH1xrQis6BIjAqs3EwLMh5k3Y1bDa3dV7MlAA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/WsLswmQbs2U48IlozhOweQQR5vA>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <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: Tue, 12 Jun 2018 09:53:21 -0000
Good work, Ahmed. Very many thanks for the changes and for the clear response to my review. Best, Adrian From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] Sent: 11 June 2018 22:55 To: adrian@olddog.co.uk; bruno.decraene@orange.com; 'SPRING WG List' Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Thanks a lot for the through review I posted version 14 few minutes ago to address your comments See my reply as #Ahmed On 5/25/18 2:22 AM, Adrian Farrel wrote: Hi, I think it is well past time that we completed this foundation work and got an RFC published. So I support passing this draft to the AD again. However, we do need to clean it up first. Hopefully this won't be a lot of effort for the editors as nearly all I found were editorial nits. As a side comment, it isn't a success that section 2.5 is so large. Full one quarter of the document is dedicated to the edge case of collision avoidance. That said, I don't have a better solution. Thanks for the work. Adrian ==== idnits isn't as clean as it could be. In particular: - 2.5.2.1 uses IP address 1.1.1.1 and should pick one from RFC 6890. - Missing normative reference for RFC 8174 - [I-D.ietf-idr-segment-routing-te-policy] is not used - [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] have spurious spaces in the filenames #Ahmed: Fixed --- You'll need to move the "Requirements Language" to be Section 1.1. #Ahmed: Moved it to section 1.1 --- Section 2 s/link State IGPs/link state IGPs/ s/Segment ID (SIDs)/Segment IDs (SIDs)/ #Ahmed: Fixed --- You use SRGB in 2.2 before you expand it in 2.3 #Ahmed: I expanded it at the beginning of Section 2.2 --- 2.2 o The label value MUST be unique within the router on which the MCC is running. i.e. the label MUST only be used to represent the SID. I don't think you mean this. You have written that the label value has be unique which means that only one label value can be assigned to a SID. I think what you mean is that o The label value MUST NOT be used for any other purpose on the router on which the MCC is running. I.e. the label MUST NOT be used to represent more than one SID or for any other forwarding purpose on the router. #Ahmed: I used a slightly different wording than what you suggested. Here it is The label value MUST be unique within the router on which the MCC is running. i.e. the label MUST only be used to represent the SID and MUST NOT be used to represent more than one SID or for any other forwarding purpose on the router. --- 2.2 Unusual to have a normative reference to an IANA URL as you have for [reserved-MPLS]. Besides, the URL you give is 404. You would do better to reference RFC 7274. #Ahmed: Agreed and done You might also fix the language and terminology, thus... OLD o The label value MUST NOT be identical to or within the range of any reserved label value or range [reserved-MPLS], respectively. NEW o The label value MUST NOT come from the range of special purpose labels [RFC7274]. #Ahmed: Agreed and done --- 2.3 ditto OLD o Every range in the list of ranges specifying the SRGB MUST NOT cover or overlap with a reserved label value or range [reserved- MPLS], respectively. NEW o Every range in the list of ranges specifying the SRGB MUST NOT cover or overlap with the range of special purpose labels [RFC7274]. #Ahmed: Agreed and Done --- 2.3 o If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules, then this SRGB is completely ignored and the node is treated as if it does not have an SRGB. Can we fix this passive voice? Presume the intention is that the advertisement of this SRGB is ignored by any routing protocol speakers that receive it. Two points of clarification I think we should add: 1. The *whole* SRGB is ignored, not simply the range of labels in a set of ranges that is at fault 2. The term "ignore" in this case means that no SR action is taken, but the SRGB advertisement continues to be propagated within the routing protocol. #Ahmed: the section defines the SRGB as a single entity consisting of a list of label ranges. Hence the SRGB is not divisible. The document clearly specifies what "ignore" means by saying "and the node is treated as if it does not have an SRGB.". How a routing protocol advertises the SRGB (e.g. by flooding, leaking between levels/areas) is beyond the scope of this document. I modified the statement slightly to indicate what does it mean "ignored" --- 2.3 (bottom of page 5) s/reserved label/special purpose label/ #Ahmed: renamed "reserved label" to special purpose label through out the document as you s --- 2.3 s/contiguous range of label/contiguous range of labels/ #Ahmed: Done --- 2.5 s/(e.g.,over/(e.g., over/ s/map to the same incoming/maps to the same incoming/ s/FECk} maps to the same/FECk} map to the same/ s/non-zero algo/non-zero algorithm/ #Ahmed: Corrected or removed the statement containing the typo --- 2.5.1 The plural of FEC is FECs not FEC's #Ahmed: corrected the 3 occurrences --- 2.5.1 2. if more than one competing FEC remains after step 1, sort them and select the smallest numerical FEC value Is sorting required? Can we just have... 2. if more than one competing FEC remains after step 1, select the smallest numerical FEC value #Ahmed: Agreed and modified accordingly --- 2.5.1 An implementation may choose to implement additional s/may/MAY/ #Ahmed: Agreed and modified accordingly --- 2.5.2 s/THEN/then/ #Ahmed: Agreed and modified accordingly --- 2.7 s/plan./plane./ #Ahmed: Agreed and modified accordingly --- Terminology for adjacency SIDs needs to be harmonised. draft-ietf-spring-segment-routing has "IGP-Adjacency Segment" and "Adj-SID" This document has: adjacency SID (2.5.1) Adj-SID (2.7.3) adj-SID (2.7.3) IGP-adjacency-SID (2.8) IGP-Adj-SID (2.11.1) IGP adj-SID (2.11.2) #Ahmed: I changed all of them to adj-SID --- Some of the section names are overly long and can be cut down without risking much. This helps with layout and readability. Just a suggestion, but... OLD 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix 2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global SIDs 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on Local SIDs 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local SIDs NEW 2.1. Multiple Forwarding Behaviors for the Same Prefix 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs 2.10.2. Forwarding for NEXT Operation for Global SIDs 2.11.1. Forwarding for PUSH Operation on Local SIDs 2.11.2. Forwarding for CONTINUE Operation for Local SIDs #Ahmed: Thanks for the advice. Modified as suggested --- For some reason the definite article is missing before a lot of instances of "FIB". For example, in 2.8... The label corresponding to the global SID "Si" represented by the global index "I" downloaded to FIB is used to match packets whose --- 2.10 OLD This section specifies forwarding behavior, including the outgoing label(s) calculations corresponding to a global SID when applying PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. This document covers the calculation of outgoing label for the top label only. The case where outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is covered in other documents such as [I.D.filsfils-spring-segment-routing-policy]. NEW This section specifies forwarding behavior, including the calculation of outgoing labels, that corresponds to a global SID when applying PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. This document covers the calculation of the outgoing label for the top label only. The case where the outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is covered in other documents such as [I.D.filsfils-spring-segment-routing-policy]. #Ahmed: Modified as suggested --- 2.10.1 s/{RFC3031]/[RFC3031]/ --- 2.10.2 has o Apply the instruction associated with the incoming label prior to popping This is a little ambiguous. Might be read that the instruction should be applied prior to popping. The text that follows des clarify, but perhaps rewrite as... o Apply the instruction associated with the incoming label that has been popped #Ahmed: Agreed and modified accordingly --- In order that ECMP descriptions work in the examples, Section 3 just needs a quick comment like. All links in this example have the same IGP metric. #Ahmed: Added a phrase to the end of the second sentence in the section --- While it is largely OK to defer the discussion of manageability in Section 5 to draft-ietf-spring-segment-routing, it would make sense to make explicit reference to RFC 8287 because that is the key document that means no further OAM discussion is needed in this document. Probably just copy in the following paragraph SR OAM use cases for the MPLS data plane are defined in [I-D.ietf-spring-oam-usecase]. SR OAM procedures for the MPLS data plane are defined in [RFC8287]. #Ahmed. Copied --- 8. Possibly Himanshu would prefer to be named as "Himanshu Shah". #Ahmed: Thanks for catching that :) From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: 24 May 2018 18:14 To: SPRING WG List Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd.. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y ________________________________________________________________________________ _________________________________________ 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.
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Adrian Farrel
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… 徐小虎(义先)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Chris Bowers
- Re: [spring] WG Last Call for draft-ietf-spring-s… Przemyslaw Krol
- Re: [spring] WG Last Call for draft-ietf-spring-s… Przemyslaw Krol
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- [spring] WG Last Call for draft-ietf-spring-segme… bruno.decraene
- [spring] FW: WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Adrian Farrel
- Re: [spring] WG Last Call for draft-ietf-spring-s… Zafar Ali (zali)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Acee Lindem (acee)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Chris Bowers