Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Ahmed Bashandy <abashandy.ietf@gmail.com> Wed, 30 May 2018 18:31 UTC

Return-Path: <abashandy.ietf@gmail.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 9B24712EA9D; Wed, 30 May 2018 11:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 TScF_IvmxZTa; Wed, 30 May 2018 11:31:19 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 9E27A12E86A; Wed, 30 May 2018 11:31:19 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id p8-v6so8510028pgq.10; Wed, 30 May 2018 11:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=UjNJZZzJxIxOrnTjHpPkoak5cNKPO9lNnG6WaolWYlw=; b=L9FP2btyO4wfahDqUYDv1ixKgNYYcAprd4rCEYoIydFi/uK5KuB4aDqvNGK36ga4rs ua/xUBLqCqAV5c3pFBL1BvTUfCO03cTn5jwWcKo8eTaqNhuoFx0N9kEy3/r9kZFyEPli gKSvVmUWA4q+T4nUa0thTLvhgwQqMpXKUogm1wWkufKOWy8x5L3SCt02NxTmHPhpODL0 HowNVTe3S1qzqNCbzf9fJs2rBS0cZgF3pzGiffM1r4WROmC1XQBCDm/2aLaOnVfBqVb5 WvEXiy31VdxkGYmGFplIUjdorfUYHMdIJ+b1WoyznPpgwyYOPiiKv/qbReWbgMMnxyfT 1NqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=UjNJZZzJxIxOrnTjHpPkoak5cNKPO9lNnG6WaolWYlw=; b=cnXzpWUcCDoj/4cMCuCEp243grbChg22/Gpi3/fNDyg7OhFNXfOPOb+FdiM6htW4Ek PUbsGQ/oir57L5DR2kJWwQgLTCDsLhk6yD9N3CY0RDmQhRd6akDjMIQoQJG+uFL8Hnwh G42Hfg8ef2cHeLtW4JbCy2QoBCpxfUCl+HkXRZbcyAizPZ+JFTJgot1i0EG0Hn4vRK4g u+fEycT1ijUpu2x90vsBWxyjFz7VPPI1JxIWsf86DSOJqqJ2Cn+zGRiA2Ynd7mHN4S4d WxEsg9ofayQMQgGozoSNlFtTqD9rLJOT7A4t0vXyXrRRqojzhMYdOTIq0zRGsoKDQizV QL4g==
X-Gm-Message-State: ALKqPwdiz2Z5qfdoNYROa+VCZ95XrZIk403xpqe8Gp76WNOu4wpEDn46 RVQBIF0AjUCbYYDdZvwnMEc=
X-Google-Smtp-Source: ADUXVKJ9cDwR1r2Y8xHjCX1tQksPvWjD+TVPby5/Jz6EiMI5TTcgKVNnp0CweOZ5Gyt4eYgpMtampQ==
X-Received: by 2002:a62:4cca:: with SMTP id e71-v6mr3730782pfj.171.1527705079068; Wed, 30 May 2018 11:31:19 -0700 (PDT)
Received: from Arrcus-Ahmeds-MacBook-Pro.local ([75.8.210.205]) by smtp.gmail.com with ESMTPSA id u90-v6sm23202662pfa.101.2018.05.30.11.31.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 11:31:18 -0700 (PDT)
To: adrian@olddog.co.uk, bruno.decraene@orange.com, 'SPRING WG List' <spring@ietf.org>
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup> <00e601d3f409$f3b5b050$db2110f0$@olddog.co.uk>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <e3f7ed17-c9f2-658b-14b4-f03c41fac1ff@gmail.com>
Date: Wed, 30 May 2018 11:31:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <00e601d3f409$f3b5b050$db2110f0$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------FDCF18DC3C4F5AEC086C6A92"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4UK2CTZsyf35d1mUSj8zxheDp2M>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 30 May 2018 18:31:23 -0000

Thanks a lot for the thorough review

I will take care of the comments in next version and I reply to this 
email explaining how they were addressed


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
>
> ---
>
> You'll need to move the "Requirements Language" to be Section 1.1.
>
> ---
>
> Section 2
>
> s/link State IGPs/link state IGPs/
>
> s/Segment ID (SIDs)/Segment IDs (SIDs)/
>
> ---
>
> You use SRGB in 2.2 before you expand it in 2.3
>
> ---
>
> 2.2
>
> oThe 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
>
> oThe 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.
>
> ---
>
> 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.
>
> You might also fix the language and terminology, thus...
>
> OLD
>
> oThe label value MUST NOT be identical to or within the range of
>
> any reserved label value or range [reserved-MPLS], respectively.
>
> NEW
>
> oThe label value MUST NOT come from the range of special purpose
>
> labels [RFC7274].
>
> ---
>
> 2.3 ditto
>
> OLD
>
> oEvery 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
>
> oEvery range in the list of ranges specifying the SRGB MUST NOT
>
> cover or overlap with the range of special purpose labels
>
> [RFC7274].
>
> ---
>
> 2.3
>
> oIf 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.
>
> ---
>
> 2.3 (bottom of page 5)
>
> s/reserved label/special purpose label/
>
> ---
>
> 2.3
>
> s/contiguous range of label/contiguous range of labels/
>
> ---
>
> 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/
>
> ---
>
> 2.5.1
>
> The plural of FEC is FECs not FEC's
>
> ---
>
> 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
>
> ---
>
> 2.5.1
>
> An implementation may choose to implement additional
>
> s/may/MAY/
>
> ---
>
> 2.5.2
>
> s/THEN/then/
>
> ---
>
> 2.7
>
> s/plan./plane./
>
> ---
>
> 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)
>
> ---
>
> 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
>
> ---
>
> 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].
>
> ---
>
> 2.10.1
>
> s/{RFC3031]/[RFC3031]/
>
> ---
>
> 2.10.2 has
>
> oApply 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...
>
> oApply the instruction associated with the incoming label that has
>
> been popped
>
> ---
>
> 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.
>
> ---
>
> 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].
>
> ---
>
> 8.
>
> Possibly Himanshu would prefer to be named as "Himanshu Shah".
>
> *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.