Re: [RTG-DIR] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18

Ahmed Bashandy <> Sat, 30 March 2019 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C71E21201BE; Sat, 30 Mar 2019 15:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-Qx-iJwmdS6; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9300E1201A3; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
Received: by with SMTP id t16so778242plo.0; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lN5dDrAIUweSX8EpSCePmZH9oLlOwUg9I+jFB1ABbUg=; b=S1oFXJOP8oRu+iudRiFxqC3FaKwmCptl6tPPVEev54nn4hfB86ShmsOVb/2awXzmAK KM0Fmvt7ILz7GyiVGifE2jrqaHOrvT2CXBqVA7ruS0eT8uLU6x49D/15xVCoP1XNwDcb VFwBrCyuVaT2/9l5DKMkV51Rcg2pGP5CxSAkuSPZhygjig4V/yJErZKwlFF1zteluttZ FdEJFmh8meYoqfdlaPYJCw/rOklmJoSS/NL6xARFh5if8kAH5ONu32WQ2JoeZrS4Oqxn raeN3j3LriIC/Lv9U2WGXp+FGjI6fP7AeSUzqveLUX6Z3Exr3B3r984s2uucOKyuNxli G8+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=lN5dDrAIUweSX8EpSCePmZH9oLlOwUg9I+jFB1ABbUg=; b=fve2Jj28F8IG/fjIT6axI7+LRIWSWOu8ejyquQE3i44VgxrpBtqeSPLB5ahn0hXYMI eJd7dz836UCCTKaCkM+TRgBzwfwNmzz0ZwWewFvv0NZLUl0XMT1vupLST83ltuFd8QPa eCaOr1+le98aB782KUk0O+x/irFCHbxKtBTJknshdH2wZ20PN1X458C6AnqmmvMnb4fg aUhh3UZ62VVp3z1G6wH54all/leN2zaSyFJFTx5IrIVNQblk2yoxuUzEyb1U4sEkJaPH 83WpYrjOvStUCJyjH8KkmOcpqsPApTTBdhadVzXsz4kasw61jvm4H9zffshqaff8JgZe ViKA==
X-Gm-Message-State: APjAAAX9xT8Tlw+/58G3+LJ0qKxg/N0rxOchAm+F910dogGyCtCCuYAY bsd7URukLzzBR0kTrokELSs=
X-Google-Smtp-Source: APXvYqwENcFaW1HwUPv24EKVcoRtwPWA7MfnswBFC1bEnujFcBywxkwkjDFErRti9apNQzzqfym4Wg==
X-Received: by 2002:a17:902:a5c9:: with SMTP id t9mr54855173plq.196.1553985024072; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
Received: from Arrcus-Ahmeds-MacBook-Pro.local ( []) by with ESMTPSA id a80sm19101979pfj.61.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 15:30:23 -0700 (PDT)
To: Przemyslaw Krol <>
Cc: Alexander Vainshtein <>, "" <>, "" <>, "" <>, "" <>, Min Ye <>, "" <>
References: <> <> <>
From: Ahmed Bashandy <>
Message-ID: <>
Date: Sat, 30 Mar 2019 15:30:21 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------DFD87B35EB70336E4F03A005"
Content-Language: en-US
Archived-At: <>
Subject: Re: [RTG-DIR] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Mar 2019 22:30:30 -0000

thanks for the comment

Mirrored SID  in Section 2.5 refers to RFC8402 section 5.1, which AFAIK 
is correct. What link needs to be updated?


On 3/29/19 9:13 PM, Przemyslaw Krol wrote:
> Hi Ahmed,
> Cosmetic minor nit:
> 2.5. Incoming Label Collision
> [...]
> both links in the '(Mirrored SID)' section need a cleanup / update
> thanks,
> pk
> On Fri, Mar 29, 2019 at 2:14 AM Ahmed Bashandy 
> < <>> wrote:
>     Thanks a lot for the review
>     I uploaded version 19 of the draft, which, IMO, addresses all your
>     comments
>     See the reply "#Ahmed"
>     On 3/10/19 9:55 AM, Alexander Vainshtein wrote:
>>     Hello,
>>     I have been selected as the Routing Directorate reviewer for this
>>     draft. The Routing Directorate seeks to review all routing or
>>     routing-related drafts as they pass through IETF last call and
>>     IESG review, and sometimes on special request. The purpose of the
>>     review is to provide assistance to the Routing ADs. For more
>>     information about the Routing Directorate, please see
>>     ​
>>     Although these comments are primarily for the use of the Routing
>>     ADs, it would be helpful if you could consider them along with
>>     any other IETF Last Call comments that you receive, and strive to
>>     resolve them through discussion or by updating the draft.
>>     Document: review of draft-ietf-spring-segment-routing-mpls-18
>>     Reviewer: Alexander (“Sasha”) Vainshtein
>>     Review Date: 10-Mar-19
>>     IETF LC End Date: 07-Mar-2019
>>     Intended Status: Proposed Standard
>>     *Summary:*I have some minor concerns about this document that I
>>     think should be resolved before publication.
>>     *Comments*:
>>     I have done an early RTG-DIR review of the -14 version of the
>>     draft half a year ago, and the issues I’ve raised then have been
>>     resolved in the subsequent versions one way or another).
>>     Therefore this review has been intentionally focused on the
>>     changes done to the draft in the few recent versions.
>>     In my previous review I have noticed that the draft was not easy
>>     reading for me. Since then readability of the draft has been
>>     improved. However, there are still several places in the new text
>>     that are still difficult to parse.
>>     I did not run the nits checker on the draft, so my list of nits
>>     is probably incomplete.
>>     Just as with my earlier review, I send this one also to the MPLS
>>     WG list – and for the same reasons.
>>     I tried to discuss my review privately with the authors, but they
>>     did not respond.
>>     *Major Issues*: No major issues found.
>>     *Minor Issues*:
>>     1.The text in Section 1 states that  “*a network operator SHOULD configure at least one node segment
>>     per routing instance, topology, algorithm*”and continues that  “*An implementation MAY check that an IGP node-SID is not
>>     associated with a prefix that is owned by more than one router
>>     within the same routing domain, If so, it SHOULD NOT use this
>>     Node-SID, MAY use another one if available, and SHOULD log an error*”. This looks somewhat controversial to me because:
>>     a.The check of the Node SID not being owned by more than one
>>     router in the routing domain is defined as purely optional.
>>     According to RFC 2119, implementations that choose to implement
>>     such a check must be able to interoperate with implementations
>>     that do not implement it
>>     b.The recommended handling of the results of this check (fully
>>     aligned with the text in Section 3.2 pf RFC 8402 that prohibits
>>     using prefixes owned by more than one router in the domain as
>>     Node-SODs) strongly suggests that the prefix that is owned by
>>     more than one router in the domain is unusable as the Node SID
>>     I see two possibilities to resolve this controversy: either make
>>     the check in question a “real requirement” (i.e., replace *MAY*with *SHOULD*or even *MUST*), or explain why it is safe enough not to implement such a check
>>     (i.e., how implementations that support this check and
>>     implementations that do not support it can interoperate within a
>>     given routing domain).The first of these options seems to me aligned with Section 3.2
>>     in RFC 8402 that says that “*An IGP Node-SID MUST NOT be
>>     associated with a prefix that is owned by more than one router
>>     within the same routing domain*”.     
>     #Ahmed: I replaced the MAY with SHOULD
>>     2.I have  a problem with the highlighted part of the following
>>     text in Section 2.5:
>>     *An implementation MUST NOT allow the MCCs belonging to the same*
>>     *router to assign the same incoming label to more than one SR
>>     FEC. An*
>>     *implementation that allows such behavior is considered as faulty.***
>>     *Procedures defined in this document equally applies to this case,*
>>     *both for incoming label collision (Section 2.5
>>     <>)
>>     and the effect on*
>>     *outgoing label programming (Section 2.6
>>     <>).***
>>     a.The Section in question deals with incoming label collision (in
>>     fact, the text that immediately follows the problematic fragment
>>     states that “*The objective of the following steps is to
>>     deterministically install in the MPLS Incoming Label Map, also
>>     known as label FIB, a single FEC with the incoming label "L1"*”
>>     b.As a consequence, any mention of *outgoing label programming*, looks out of context (even accompanied by a forward reference
>>     to Section 2.6)
>>     c.Section 2.6 covers the impact of incoming label collision on
>>     programming of outgoing labels in quite a generic way. Therefore
>>     I think that the highlighted part of the quoted fragment can be
>>     safely removed (complete with the grammar mistake).
>>     d.I also do not see any value in stating that an implementations
>>     that violates a mandatory requirement of the spec is faulty –
>>     isn’t that self-evident?
>     #Ahmed: I removed the highlighted text because I agree with what
>     you said in item (d) that it has no value
>>     3.The highlighted text in Section 2.8 is not accurate:
>>     *   For Local SIDs, the MCC is responsible for downloading the
>>     correct*
>>     *   label value to FIB. For example, an IGP with SR extensions
>>     [I-D.ietf-*
>>     *   isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-*
>>     *   extensions] allocates and downloads the MPLS label
>>     corresponding to*
>>     *   an Adj-SID [RFC8402 <>].*
>>     *a.*IGP with SR extensions**may indeed dynamically allocate and download MPLS labels acting
>>     as local Adj-SIDs **
>>     *b.*However, these labels can be allocated by configuration (e.g. as
>>     mentioned in the tie-breaking rules in Section 2.5.1 and in the
>>     example in Section A.2.3 in the draft), in which case IGP with SR
>>     extensions would only responsible for its advertisement and
>>     installation. **
>     #Ahmed: I removed the highlighted word "allocated"
>>     *NITS*:
>>     :**
>>     1.In section 2.5:
>>     a.In the sentence “*Procedures defined in this document equally
>>     applies to this case*” the noun is in plural but the verb is in singular. (If this
>>     sentence is removed as suggested above, this nit disappears)
>>     b.The same problem exists in the sentence “*An incoming label
>>     collision occurs if the SIDs of the set of FECs {FEC1, FEC2,...,
>>     FECk} maps to the same incoming SR MPLS label "L1"*”
>     #Ahmed: The sentence is removed as you suggested
>>     2.In section 2.10.1 the preposition “*to*” between the words
>>     “*according*” and “*MPLS*” is missing in the fragment “*Push the
>>     calculated label according the MPLS label pushing rules specified
>>     in [RFC3032]*”.
>     #Ahmed added the missing "to"
>>     3.Problems with references:
>>     a.As reported by Sergey
>>     <>,
>>     there are two occurrences of references to RFC 8042 “OSPF
>>     Two-Part Metric” instead of RFC 8402. Lots of thanks to Sergey
>>     for catching this
>     #Ahmed: Corrected, thanks again
>>     b.Reference to RFC 8174 mistakenly contains a link to  RFC 7274.
>     #Ahmed: Corrected
>>     Hopefully these notes will be useful.
>     #Ahmed: VERY useful
>>     Regards,
>>     Sasha
>>     Office: +972-39266302
>>     Cell:      +972-549266302
>>     Email:
>>     <>
>>     ___________________________________________________________________________
>>     This e-mail message is intended for the recipient only and
>>     contains information which is
>>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>>     have received this
>>     transmission in error, please inform us by e-mail, phone or fax,
>>     and then delete the original
>>     and all copies thereof.
>>     ___________________________________________________________________________
>     _______________________________________________
>     spring mailing list
> <>
> -- 
> Przemyslaw "PK" Krol | 	 Strategic Network Engineer 	ing 
> | <>