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

Ahmed Bashandy <abashandy.ietf@gmail.com> Sat, 30 March 2019 22:30 UTC

Return-Path: <abashandy.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E21201BE; Sat, 30 Mar 2019 15:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
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: 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 N-Qx-iJwmdS6; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 9300E1201A3; Sat, 30 Mar 2019 15:30:24 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id t16so778242plo.0; Sat, 30 Mar 2019 15:30:24 -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=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; 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=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 (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id a80sm19101979pfj.61.2019.03.30.15.30.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 15:30:23 -0700 (PDT)
To: Przemyslaw Krol <pkrol@google.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" <draft-ietf-spring-segment-routing-mpls.authors@ietf.org>, Min Ye <amy.yemin@huawei.com>, "mpls@ietf.org" <mpls@ietf.org>
References: <VI1PR03MB3839B5FA07EADE57084F8E389D4F0@VI1PR03MB3839.eurprd03.prod.outlook.com> <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> <CACH2EkU01XsLPT1ow15q+y6GLzgfeKiFkNPWg7jWX+FF0OPZnw@mail.gmail.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <2a3e1d27-5f26-36ca-7332-462b89c7c5a6@gmail.com>
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: <CACH2EkU01XsLPT1ow15q+y6GLzgfeKiFkNPWg7jWX+FF0OPZnw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------DFD87B35EB70336E4F03A005"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/NqMxIMDt6x_XFqqvFTszXTqkIEQ>
Subject: Re: [RTG-DIR] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=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?

Ahmed


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 
> <abashandy.ietf@gmail.com <mailto:abashandy.ietf@gmail.com>> 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
>>     ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>>     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
>>     <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#section-2.5>)
>>     and the effect on*
>>
>>     *outgoing label programming (Section 2.6
>>     <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#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 <https://tools.ietf.org/html/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
>>     <https://mailarchive.ietf.org/arch/msg/spring/C_W3KBcL2AWxmlB7Sp53_PvqbQA>,
>>     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: Alexander.Vainshtein@ecitele.com
>>     <mailto:Alexander.Vainshtein@ecitele.com>
>>
>>
>>     ___________________________________________________________________________
>>
>>     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
>     spring@ietf.org <mailto:spring@ietf.org>
>     https://www.ietf.org/mailman/listinfo/spring
>
>
>
> -- 
> Przemyslaw "PK" Krol | 	 Strategic Network Engineer 	ing 
> |pkrol@google.com <mailto:pkrol@google.com> 	
>