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.
- 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