Re: [RTG-DIR] [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Loa Andersson <loa@pi.nu> Tue, 20 November 2018 06:45 UTC

Return-Path: <loa@pi.nu>
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 42B41128D68; Mon, 19 Nov 2018 22:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DmZoZXHr_08K; Mon, 19 Nov 2018 22:45:48 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EDC1277D2; Mon, 19 Nov 2018 22:45:47 -0800 (PST)
Received: from [192.168.1.20] (unknown [119.94.172.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 773BE1802AAA; Tue, 20 Nov 2018 07:45:41 +0100 (CET)
To: Przemyslaw Krol <pkrol=40google.com@dmarc.ietf.org>, Shraddha Hegde <shraddha@juniper.net>
Cc: rtg-dir@ietf.org, spring@ietf.org, Alexander.Vainshtein@ecitele.com, mpls@ietf.org, spring-chairs@ietf.org, jonathan.hardwick@metaswitch.com, draft-ietf-spring-segment-routing-mpls.authors@ietf.org, abashandy.ietf@gmail.com, adrian@olddog.co.uk
References: <DB5PR0301MB19093D3B7D8159B9A341F5F79D790@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB190932C9A74DE438278C337D9D730@DB5PR0301MB1909.eurprd03.prod.outlook.com> <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <DB5PR0301MB1909C7F93AA4DF7CFB5EEEA09D5A0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB19090AA4E888EFF6E634B4239D590@DB5PR0301MB1909.eurprd03.prod.outlook.com> <da7c2afe-ebf8-1827-1134-14f72044c812@gmail.com> <DB5PR0301MB1909542DB5C8F571257304929D520@DB5PR0301MB1909.eurprd03.prod.outlook.com> <BN3PR05MB27060F2C9F0D775C33AD5A65D5510@BN3PR05MB2706.namprd05.prod.outlook.com> <c33105ce-41b2-3beb-f8d7-826999a8f588@gmail.com> <DB5PR0301MB1909D4AB682398BD152E72519DC90@DB5PR0301MB1909.eurprd03.prod.outlook.com> <BYAPR05MB3943FB07ACA7E343152F2BFBD5D80@BYAPR05MB3943.namprd05.prod.outlook.com> <CACH2EkUXjNDJs2rDtAZ5OiMCbAdknvoHcUx3AtMcHatG_jdEjQ@mail.gmail.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <13fea595-f142-4417-1e05-9b305942aef5@pi.nu>
Date: Tue, 20 Nov 2018 14:45:11 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CACH2EkUXjNDJs2rDtAZ5OiMCbAdknvoHcUx3AtMcHatG_jdEjQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/xv-yrzU1HRDfIPHncN4MHY5W6xg>
Subject: Re: [RTG-DIR] [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
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: Tue, 20 Nov 2018 06:45:54 -0000

Shaddra,

Yes I agree.

/Loa

On 2018-11-20 00:01, Przemyslaw Krol wrote:
> Hi Shraddha
> 
> I think this would be very helpful.
> 
> pk
> 
> On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <shraddha@juniper.net 
> <mailto:shraddha@juniper.net>> wrote:
> 
>     Hi all,____
> 
>     __ __
> 
>     I am preparing the shepherd write-up and noticed that the topic in
>     below e-mail thread is an____
> 
>     Open item. My personal opinion is to add a new section to this draft
>     to address below cases____
> 
>     >  more than one node advertising the same IPv4/6 PREFIX and both
>     have the same prefix-SID value with "N" flag____
> 
>     >  where an anycast prefix is advertised with a prefix-SID sub-TLV by
>     some (but not all) of the nodes that advertise that prefix.____
> 
>     __ __
> 
>     This draft is addressing incoming label collision and resulting
>     behavior and also describes other aspects like different SIDs for
>     same prefix so it seems reasonable to add above two cases to this
>     draft.____
> 
>     WG members, if you have an opinion, pls respond on the list.____
> 
>     __ __
> 
>     Rgds____
> 
>     Shraddha____
> 
>     *From:*Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>>
>     *Sent:* Sunday, November 4, 2018 9:37 PM
>     *To:* Ahmed Bashandy <abashandy.ietf@gmail.com
>     <mailto:abashandy.ietf@gmail.com>>
>     *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>; 'mpls@ietf.org
>     <mailto:mpls@ietf.org>' <mpls@ietf.org <mailto:mpls@ietf.org>>;
>     'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>'
>     <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>; Jonathan
>     Hardwick (Jonathan.Hardwick@metaswitch.com
>     <mailto:Jonathan.Hardwick@metaswitch.com>)
>     <jonathan.hardwick@metaswitch.com
>     <mailto:jonathan.hardwick@metaswitch.com>>; spring@ietf.org
>     <mailto:spring@ietf.org>; spring-chairs@ietf.org
>     <mailto:spring-chairs@ietf.org>;
>     draft-ietf-spring-segment-routing-mpls.authors@ietf..org
>     <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf..org>;
>     Shraddha Hegde <shraddha@juniper.net <mailto:shraddha@juniper.net>>
>     *Subject:* RE: RtgDir Early review:
>     draft-ietf-spring-segment-routing-mpls-13____
> 
>     __ __
> 
>     Ahmed,____
> 
>     Apologies for a delayed response.____
> 
>     I fully agree that advertising the same prefix SID as the Node SID
>     by two different nodes in the SR domain is “a clear violation of the
>     SR architecture RFC (8402)”.____
> 
>     But I do not think that the SR-MPLS draft can silently ignore this
>     violation just because it “is not an incoming label collision”. ____
> 
>     The same applies to the controversy in advertising at the same
>     prefix as Anycast by some nodes but not as Anycast (or even as a
>     Node SID) by some other nodes. ____
> 
>     Your reference to these being just control plane issues and
>     therefore not related to SR-MPLS is not valid - because the drafts
>     dealing with the SR control plane to which you refer in this draft
>     are strictly MPLS-oriented: they define how to advertise */SID
>     labels/* or */indices/* that are translated into */SID labels/*, and
>     neither of these mechanisms is relevant fore SRV6 IMHO. (I do not
>     have to remind you that a draft that defines SRV6 extensions for
>     ISIS
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=>exists,
>     and deals with other issues).____
> 
>     My 2c,____
> 
>     Sasha____
> 
>     __ __
> 
>     Office: +972-39266302____
> 
>     Cell:      +972-549266302____
> 
>     Email: Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>     __ __
> 
>     *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
>     *Sent:* Sunday, October 28, 2018 1:01 AM
>     *To:* Shraddha Hegde <shraddha@juniper.net
>     <mailto:shraddha@juniper.net>>; Alexander Vainshtein
>     <Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>>
>     *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>; 'mpls@ietf.org
>     <mailto:mpls@ietf.org>' <mpls@ietf.org <mailto:mpls@ietf.org>>;
>     'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>'
>     <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>; Jonathan
>     Hardwick (Jonathan.Hardwick@metaswitch.com
>     <mailto:Jonathan.Hardwick@metaswitch.com>)
>     <jonathan.hardwick@metaswitch.com
>     <mailto:jonathan.hardwick@metaswitch.com>>; spring@ietf.org
>     <mailto:spring@ietf.org>; spring-chairs@ietf.org
>     <mailto:spring-chairs@ietf.org>;
>     draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>     <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>     *Subject:* Re: RtgDir Early review:
>     draft-ietf-spring-segment-routing-mpls-13____
> 
>     __ __
> 
>     Thanks for the comments____
> 
>     While it is a clear violation of the SR architecture RFC (8402),
>     more than one node advertising the same IPv4/6 PREFIX and both have
>     the same prefix-SID value with "N" flag is not an incoming label
>     collision because the label is associated with the same FEC, which
>     is the prefix. ____
> 
>     Hence handling such violation is not an SR-MPLS problem because
>     there is no incoming label collision and hence it it is outside the
>     scope of this draft____
> 
>     __ __
> 
>     The second issue is which SID to choose for an SR-policy (be it a
>     policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is
>     strictly a control layer functionality and is not specific to
>     SR-MPLS. Hence it is outside the scope of this draft____
> 
>     __ __
> 
>     The third issue is the case where an anycast prefix is advertised
>     with a prefix-SID sub-TLV by some (but not all) of the nodes that
>     advertise that prefix. Again this is not an incoming label collision
>     because the label is associated with a single FEC, which is the
>     anycast prefix.____
> 
>     __ __
> 
>     On 7/19/18 8:30 PM, Shraddha Hegde wrote:____
> 
>         Hi Ahmed,____
> 
>         ____
> 
>         The Node-SIDs are expected to be unique to a node. ____
> 
>         “____
> 
>             An IGP Node-SID MUST NOT be associated with a prefix that is
>         owned by____
> 
>             more than one router within the same routing domain.”____
> 
>         ____
> 
>         If two different nodes advertise same Node-SID,____
> 
>                   For Example Node A and B both advertise prefix 1.1.1.1
>         and associate a  SID 1000 with N bit set.____
> 
>         There is an anomaly here and IMO, this draft should address how
>         to handle this anomaly and whether TI-LFA and other____
> 
>         Applications can use this SID as a Node-SID.____
> 
>         Another slight variation of this case is a scenario where A and
>         B both advertise a prefix 1.1.1.1 and A assigns a Node-Sid____
> 
>         Of 1000 and B does not assign any SID.____
> 
>         ____
> 
>         Rgds____
> 
>         Shraddha____
> 
>         ____
> 
>         *From:*Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>         <mailto:Alexander.Vainshtein@ecitele.com>
>         *Sent:* Thursday, July 19, 2018 10:05 PM
>         *To:* Ahmed Bashandy <abashandy.ietf@gmail.com>
>         <mailto:abashandy.ietf@gmail.com>
>         *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>; 'mpls@ietf.org
>         <mailto:mpls@ietf.org>' <mpls@ietf.org> <mailto:mpls@ietf.org>;
>         'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>'
>         <adrian@olddog.co.uk> <mailto:adrian@olddog.co.uk>; Jonathan
>         Hardwick (Jonathan.Hardwick@metaswitch.com
>         <mailto:Jonathan.Hardwick@metaswitch.com>)
>         <jonathan.hardwick@metaswitch.com>
>         <mailto:jonathan.hardwick@metaswitch.com>; Shraddha Hegde
>         <shraddha@juniper.net> <mailto:shraddha@juniper.net>;
>         spring@ietf.org <mailto:spring@ietf.org>; spring-chairs@ietf.org
>         <mailto:spring-chairs@ietf.org>;
>         draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>         <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>         *Subject:* RE: RtgDir Early review:
>         draft-ietf-spring-segment-routing-mpls-13____
> 
>         ____
> 
>         Ahmed hi!____
> 
>         Lots of thanks for your response.____
> 
>         Of course Node SIDs are not different from any other Prefix SIDs
>         when it comes to the MPLS forwarding plane.____
> 
>         But, IMHO, strictly speaking, this is correct for any other SID
>         as well. ____
> 
>         You seem to ignore the difference between SR-MPLS and SRv6 with
>         regard to the life span of prefix SIDs in general and Node SIDs
>         in particular. From my POV this difference should be discussed
>         in the draft. ____
> 
>         So it seems that we can only “agree to disagree” on the need to
>         say something specific about Node SIDs in the draft, and let the
>         WG to decide what to do about it. ____
> 
>         Regards,____
> 
>         Sasha____
> 
>         ____
> 
>         Office: +972-39266302____
> 
>         Cell:      +972-549266302____
> 
>         Email: Alexander.Vainshtein@ecitele.com
>         <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>         ____
> 
>         *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
>         *Sent:* Thursday, July 19, 2018 7:13 PM
>         *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>         <mailto:Alexander.Vainshtein@ecitele.com>>
>         *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>; 'mpls@ietf.org
>         <mailto:mpls@ietf.org>' <mpls@ietf.org <mailto:mpls@ietf.org>>;
>         'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>'
>         <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>; Jonathan
>         Hardwick (Jonathan.Hardwick@metaswitch.com
>         <mailto:Jonathan.Hardwick@metaswitch.com>)
>         <jonathan.hardwick@metaswitch.com
>         <mailto:jonathan.hardwick@metaswitch.com>>; shraddha@juniper.net
>         <mailto:shraddha@juniper.net>; spring@ietf.org
>         <mailto:spring@ietf.org>; spring-chairs@ietf.org
>         <mailto:spring-chairs@ietf.org>;
>         draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>         <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>         *Subject:* Re: RtgDir Early review:
>         draft-ietf-spring-segment-routing-mpls-13____
> 
>         ____
> 
>         Thanks for the reply____
> 
>         See inline____
> 
>         Ahmed____
> 
>         ____
> 
>         On 7/12/18 12:22 AM, Alexander Vainshtein wrote:____
> 
>             Ahmed and all,____
> 
>             I would like to expand on my comments (and your responses)
>             about the role of Node SIDs in SR-MPLS.____
> 
>             I would like to bring your attention two points:____
> 
>             __1.__Node SIDs (and, in general, Prefix SIDs) in MPLS-SR
>             are different from the same in SRv6 because they require
>             explicit configuration action by the operator of SR domain.
>             I.e., it is not enough for a node to own some /32 or /128
>             prefix that is advertised by IGP. The operator must
>             explicitly configure the node to use such a prefix as  Node
>             SID and to assign to it a specific index that is unique in
>             the SR domain. From my POV, this difference alone would
>             qualify Node SIDs as a topic to be discussed in the MPLS-SR
>             Architecture
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=>draft.____
> 
>         #Ahmed: I disagree with your POV. From the forwarding plane
>         perspective it does not make any difference whether a the label
>         at the top of an MPLS packet (representing the prefix-SID)
>         identifies a node or not. So from the SR-mpls forwarding point
>         of view there is no difference between a prefix-SID and a
>         node-SID. If there is any place in the SR-mpls draft where there
>         is a need to handle a node-SID different from a prefix SID, it
>         would be great to point it out
> 
>         ____
> 
> 
>                   __2.__In addition, quite a few constructs associated
>                   with SR-MPLS implicitly assume that each node in the
>                   SR-MPLS domain is assigned with at least one Node SID.
>                   One example can be found in the TI-LFA
>                   <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>
>                   draft. This draft says in Section 4.2:____
> 
>             ____
> 
> 
>                   4.2
>                   <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>..
>                   The repair node is a PQ node____
> 
>             ____
> 
>             ____
> 
>                 When the repair node is in P(S,X), the repair list is
>             made of a____
> 
>                 single node segment to the repair node.____
> 
>             In the scope of this section, the repair node is not
>             adjacent to the PLR, and therefore, to the best of my
>             understanding,  “a single node segment to the repair node”
>             can be only the Node SID of the repair node. Since repair
>             nodes are computed dynamically, this entire scheme depends
>             on all nodes in the MPLS=SR domain  having at least one Node
>             SID each____
> 
>         #Ahmed: The choice of the SID to identify an intermediate or
>         exit node(s) in an SR-policy is a control plane behavior,
>         irrespective of reason such policy is created (be it ti-lfa
>         explicit path, uloop avoidance explicit path, or some SR-TE
>         explicit path). SR-Policy as well as Ti-LFA and uloop avoidance
>         are handled in separate drafts. So just like the response to
>         your previous comment, from forwarding plane perspective it does
>         not make any difference whether the label at the top of an MPLS
>         packet identifies a single or multiple nodes.
> 
>         ____
> 
>             .____
> 
>             ____
> 
>             Hopefully these notes clarify my position on the subject.____
> 
>             ____
> 
>             Regards,____
> 
>             Sasha____
> 
>             ____
> 
>             Office: +972-39266302____
> 
>             Cell:      +972-549266302____
> 
>             Email: Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>             ____
> 
>             *From:*Alexander Vainshtein
>             *Sent:* Wednesday, July 11, 2018 12:02 PM
>             *To:* Ahmed Bashandy <abashandy.ietf@gmail.com>
>             <mailto:abashandy.ietf@gmail.com>
>             *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>;
>             'mpls@ietf.org <mailto:mpls@ietf.org>' <mpls@ietf.org>
>             <mailto:mpls@ietf.org>; 'adrian@olddog.co.uk
>             <mailto:adrian@olddog.co.uk>' <adrian@olddog.co.uk>
>             <mailto:adrian@olddog.co.uk>; Jonathan Hardwick
>             (Jonathan.Hardwick@metaswitch.com
>             <mailto:Jonathan.Hardwick@metaswitch.com>)
>             <jonathan.hardwick@metaswitch.com>
>             <mailto:jonathan.hardwick@metaswitch.com>;
>             shraddha@juniper.net <mailto:shraddha@juniper.net>;
>             spring@ietf.org <mailto:spring@ietf.org>;
>             spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>;
>             draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>             <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>             *Subject:* RE: RtgDir Early review:
>             draft-ietf-spring-segment-routing-mpls-13____
> 
>             ____
> 
>             Ahmed, and all,____
> 
>             Lots of thanks for a detailed response to my comments. ____
> 
>             Please see */inline below/*my position on each of them.____
> 
>             ____
> 
>             Regards,____
> 
>             Sasha____
> 
>             ____
> 
>             Office: +972-39266302____
> 
>             Cell:      +972-549266302____
> 
>             Email: Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>             ____
> 
>             *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
>             *Sent:* Wednesday, July 11, 2018 4:42 AM
>             *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>>;
>             spring-chairs@ietf.org <mailto:spring-chairs@ietf.org>;
>             draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>             <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>             *Cc:* rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>;
>             'mpls@ietf.org <mailto:mpls@ietf.org>' <mpls@ietf.org
>             <mailto:mpls@ietf.org>>; 'adrian@olddog.co.uk
>             <mailto:adrian@olddog.co.uk>' <adrian@olddog.co.uk
>             <mailto:adrian@olddog.co.uk>>; Jonathan Hardwick
>             (Jonathan.Hardwick@metaswitch.com
>             <mailto:Jonathan.Hardwick@metaswitch.com>)
>             <jonathan.hardwick@metaswitch.com
>             <mailto:jonathan.hardwick@metaswitch.com>>;
>             shraddha@juniper.net <mailto:shraddha@juniper.net>;
>             spring@ietf.org <mailto:spring@ietf.org>
>             *Subject:* Re: RtgDir Early review:
>             draft-ietf-spring-segment-routing-mpls-13____
> 
>             ____
> 
>             Thanks for thorough (and VERY clear) the review____
> 
>             See inline #Ahmed____
> 
>             ____
> 
>             Ahmed____
> 
>             ____
> 
>             ____
> 
>             On 6/15/18 11:08 PM, Alexander Vainshtein wrote:____
> 
>                 Re-sending to  correct SPRING WG list.____
> 
>                 Sincere apologies for the delay caused by a typo.____
> 
>                 Thumb typed by Sasha Vainshtein____
> 
>                 ____
> 
>                 ------------------------------------------------------------------------
> 
>                 *From:* Alexander Vainshtein
>                 *Sent:* Sunday, June 10, 2018 10:43:52 AM
>                 *To:* spring-chairs@ietf.org
>                 <mailto:spring-chairs@ietf.org>;
>                 draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>                 <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>                 *Cc:* spring@ietf..com <mailto:spring@ietf.com>;
>                 rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>;
>                 'mpls@ietf.org <mailto:mpls@ietf.org>';
>                 'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>';
>                 Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com
>                 <mailto:Jonathan.Hardwick@metaswitch.com>);
>                 shraddha@juniper.net <mailto:shraddha@juniper.net>
>                 *Subject:* RE: RtgDir Early review:
>                 draft-ietf-spring-segment-routing-mpls-13____
> 
>                 ____
> 
>                 Explicitly adding Shraddha  who is the shepherd of this
>                 draft. ____
> 
>                 ____
> 
>                 Regards,____
> 
>                 Sasha____
> 
>                 ____
> 
>                 Office: +972-39266302____
> 
>                 Cell:      +972-549266302____
> 
>                 Email: Alexander.Vainshtein@ecitele.com
>                 <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>                 ____
> 
>                 *From:* Alexander Vainshtein
>                 *Sent:* Friday, June 8, 2018 5:43 PM
>                 *To:* 'spring-chairs@ietf.org
>                 <mailto:spring-chairs@ietf.org>'
>                 <spring-chairs@ietf.org>
>                 <mailto:spring-chairs@ietf.org>;
>                 'draft-ietf-spring-segment-routing-mpls.authors@ietf.org
>                 <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>'
>                 <draft-ietf-spring-segment-routing-mpls.authors@ietf.org> <mailto:draft-ietf-spring-segment-routing-mpls.authors@ietf.org>
>                 *Cc:* 'spring@ietf.com <mailto:spring@ietf.com>'
>                 <spring@ietf.com> <mailto:spring@ietf.com>;
>                 rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>;
>                 mpls@ietf.org <mailto:mpls@ietf.org>;
>                 'adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>'
>                 <adrian@olddog.co.uk> <mailto:adrian@olddog.co.uk>
>                 *Subject:* RtgDir Early review:
>                 draft-ietf-spring-segment-routing-mpls-13____
> 
>                 ____
> 
>                 ____
> 
>                 Hello,____
> 
>                 I have been selected to do a routing directorate “early”
>                 review of this draft:
>                 https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=>____
> 
>                 ____
> 
>                 The routing directorate will, on request from the
>                 working group chair, perform an “early” review of a
>                 draft before it is submitted for publication to the
>                 IESG. The early review can be performed at any time
>                 during the draft’s lifetime as a working group document.
>                 The purpose of the early review depends on the stage
>                 that the document has reached. As this document is
>                 currently in the WG Last call, my focus for the review
>                 was to determine whether the document is ready to be
>                 published. Please consider my comments along with the
>                 other working group last call comments.____
> 
>                 ____
> 
>                 For more information about the Routing Directorate,
>                 please see ​
>                 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>                 <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=>____
> 
>                 ____
> 
>                 *Document*: draft-ietf-spring-segment-routing-mpls-13____
> 
>                 *Reviewer*: Alexander (“Sasha”) Vainshtein
>                 (alexander.vainshtein@ecitele.com
>                 <mailto:alexander.vainshtein@ecitele.com>)____
> 
>                 *Review Date*: 08-Jun-18____
> 
>                 *Intended Status*: Proposed Standard.____
> 
>                 ____
> 
>                 *Summary*:____
> 
>                 ____
> 
>                 I have some minor concerns about this document that I
>                 think should be resolved before it is submitted to the
>                 IESG.____
> 
>                 ____
> 
>                 *Comments*:____
> 
>                 ____
> 
>                 I consider this draft as an important  companion
>                 document to the Segment Routing Architecture
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=>draft
>                 that, ideally, should augment definitions of the Segment
>                 Routing (SR) notions and constructs given there with
>                 details specific for the SR instantiation that uses  the
>                 MPLS data plane (SR-MPLS).  Many issues raised in my
>                 review reflect either gaps that should be, but have not
>                 been, closed, or inconsistencies between the two drafts.
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 Since RFC 8287
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=>is
>                 already published as a Standards Track RFC, I expect
>                 such augmentation to be backward compatible with this
>                 document (or to provide clear indications of required
>                 updates to this document). And I include the MPLS WG
>                 into distribution list. ____
> 
>                 ____
> 
>                 This draft was not easy reading for me. In particular,
>                 the style of Section 2.5 that discusses at length and in
>                 some detail multiple “corner cases” resulting,
>                 presumably, from misconfiguration, before it explains
>                 the basic (and relatively simple) “normal” behavior,
>                 looks problematic to me.____
> 
>                 ____
> 
>                 The WG Last Call has been extended by one week.
>                 Nevertheless, I am sending out my comments ____
> 
>                 ____
> 
>                 *Major Issues*: None found____
> 
>             #Ahmed: thanks a lot____
> 
>                 ____
> 
>                 *Minor Issues*: Quite a few but, hopefully, easy to
>                 resolve.____
> 
>                 ____
> 
>                 1.*Encapsulation of SR-MPLS packets*: ____
> 
>                 a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not
>                 mentioned in the draft/*) depend two encapsulations of
>                 labeled packets - one for Downstream-allocated labels
>                 and another for Upstream-allocated ones.____
> 
>             #Ahmed: RFC5332 is for multicast. As mentioned in Section 6
>             of draft-ietf-spring-segment-routing-15, multicast is
>             outside the scope of SR. Hence the RFC was not referred to
>             in the SR-MPLS draft____
> 
>             */[[Sasha]] I would be satisfied with this response, would
>             it not be for the following text I see in Section 2.2 of
>             the/**//**/SR Policy Architecture/*
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=>*//**/draft:/*____
> 
>                 A variation of SR Policy can be used for packet
>             replication.  A____
> 
>                 candidate path could comprise multiple SID-Lists; one
>             for each____
> 
>                 replication path.  In such a scenario, packets are
>             actually____
> 
>                 replicated through each SID List of the SR Policy to
>             realize a point-____
> 
>                 to-multipoint service delivery. ____
> 
>             ____
> 
>             */This looks to me as being very much multicast in SR, and,
>             unless you want to say that it is limited to SRv6, makes my
>             question relevant IMHO./*____
> 
>                 b.From my POV the ST-MPLS only uses Downstream-allocated
>                 labels – but I expect the draft to state that
>                 explicitly, one way or another. (If Upstream-allocated
>                 labels are relevant for SR-MPLS, I would see it as a
>                 major gap, so I hope that this is not the case).____
> 
>             #Ahmed: I will add a statement in section 2.2 to mention
>             that it is down-stream allocated as you mentioned____
> 
>             */[[Sasha]] This is quite unambiguous and, once added, would
>             resolve my comment in full – the previous comment
>             notwithstanding. In particular, it would imply that even
>             labels representing BSIDs of a SR Replication policies will
>             be downstream-allocated. /*____
> 
>             ____
> 
>                 2.*Label spaces in SR-MPLS*:____
> 
>                 a.RFC 3031 (referenced by the draft) defines
>                 per-platform and per-interface label spaces, and RFC
>                 5331 (*/not mentioned in the draft/*) adds
>                 context-specific label spaces and context labels. ____
> 
>                 b.The draft does not say which of these are or are not
>                 relevant for SR-MPLS____
> 
>                 c.From my POV:____
> 
>                 i.Labels representing all kinds of SIDs mentioned in the
>                 draft MUST be allocated from the per-platform label
>                 space only ____
> 
>                 ii.At the same time, instantiation of Mirror Segment IDs
>                 defined in Section 5.1 of the Segment Routing
>                 Architecture draft using MPLS data plane clearly calls
>                 for context labels and context-specific label spaces____
> 
>                 d.I expect the draft to provide a clear-cut position on
>                 these aspects of SR-MPLS.____
> 
>             #Ahmed: I will add a statement to section 2.2 to say that
>             the it is per-platform. Regarding the function "mirroring",
>             SR attaches a *function* to each SID. The "mirroring"
>             function is already described in Section 5.1 of
>             draft-ietf-spring-segment-routing and is not specific to the
>             MPLS forwarding plane. Hence there is no need to re-mention
>             it here because this document is trying to be as specific as
>             possible to the MPLS forwarding plane. General functions
>             attached to SID are described in the segment routing
>             architecture document or future documents. Furture documents
>             proposing new SR function must be as specific and clear as
>             possible____
> 
>             */[[Sasha]] Looks OK to me./*____
> 
>             ____
> 
>                 3.*SR-MPLS and hierarchical LSPs*:____
> 
>                 a.SR LSPs that include more than one segment are
>                 hierarchical LSPs from the POV of the MPLS data plane.
>                 Therefore some (possibly, all) of the models for
>                 handling TTL and TC bits that have been defined in RFC
>                 3443 (*/not mentioned in the draft/*) should apply to
>                 SR-MPLS____
> 
>                 b.RFC 8287 (*/not referenced in the draft/*)
>                 specifically discussed operation of the LSP Traceroute
>                 function for SR LSPs in the case when Pipe/Short Pipe
>                 model for TTL handling is used____
> 
>                 c.I expect the draft to provide at least some guidelines
>                 regarding applicability of each specific model defined
>                 in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.____
> 
>             #Ahmed: BY design, the instantiation of SR over the MPLS
>             forwarding plane (and hence this draft) does not modify the
>             MPLS forwarding plan behavior as it is mentioned in the
>             first sentence in Section 1. So the TTL behavior specified
>             in rfc3443 is already implied and there is no need to
>             re-mention it here just like all aspects of MPLS forwarding.
>             RFC8287 is OAM-specific.  SR-OAM is handled in a separate
>             document so is outside the scope of this draft____
> 
>             */[[Sasha]] Unfortunately I do not think this is good
>             enough. Let me ask a specific question reflecting my
>             concerns:/*____
> 
>             */The head-end node sends SR-MPLS packets across a path
>             defined by an ordered set of SIDs with more than one SID in
>             the list. Each SID is represented by a label stack entry
>             (LSE) in the MPLS label stack, and the label field in each
>             LSE is the label that matches the corresponding SID.
>             However, each LSE also includes the TTL and TC fields. How
>             does the head-end node set these fields in each of the LSEs
>             following the top one? This clearly depends on the model
>             (Uniform vs. Pipe/Short Pipe) implemented in each node that
>             that performs Next operation on the packet along the path –
>             but the head-end node usually is not aware of that. /*____
> 
>             */RFC 8287 is relevant as an example here IMHO because it
>             recommends the following setting of TTL in Traceroute
>             packets:/*____
> 
>             __-__*/Set the TTL of all the labels above one that
>             represents the segment you are currently tracing to
>             maximum/*____
> 
>             __-__*/Set the TTL of the label one that represents the
>             segment you are currently tracing to the desired value (to
>             be incremented until end of segment is reached/*____
> 
>             __-__*/Set the TTL of all the labels below one that
>             represents the segment you are currently tracing to 0./*____
> 
>             */I expect the draft to provide some recommendations for
>             traffic (non-OAM) packets as well./*____
> 
>             ____
> 
>                 4.*Inferring network layer protocol in SR-MPLS*:____
> 
>                 a.I wonder if the draft could provide any details on the
>                 situation when a label that represents some kind of SID
>                 is the bottom-of-stack label to be popped by the egress
>                 LER____
> 
>             #ahmed: This is part of the "Next" function. It is described
>             in detail in this document. ____
> 
>             */[[Sasha]] NEXT function is mentioned in several places in
>             the document. Can you please point to the specific text that
>             is relevant for my question?/*____
> 
>             ____
> 
>                 b.For the reference, RFC 3032 says that “the identity of
>                 the network layer protocol  must be inferable from the
>                 value of the label which is popped from  the bottom of
>                 the stack, possibly along with the contents  of the
>                 network layer header itself”____
> 
>                 c.From my POV the following scenario indicates relevance
>                 of this expectation for SR-MPLS:____
> 
>                 i.IS-IS is used for distributing both IPv4 and IPv6
>                 reachability in a given domain____
> 
>                 ii.An IS-IS adjacency over some dual-stack link is
>                 established, and a single Adj-SID for this adjacency is
>                 advertised____
> 
>                 iii.The node that has assigned and advertised this
>                 Adj-SID receives a labeled packet with the label
>                 representing this Adj-SID being both the top and
>                 bottom-of-stack label____
> 
>                 iv.The implementers must be given unambiguous
>                 instructions for forwarding the unlabeled packet via the
>                 dual-stack link as an Ipv4 or an IPv6 packet.____
> 
>             #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and
>             SR-OSFv3 drafts, you will see all 3 protocol advertise
>             different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For
>             example, ISIS uses the "F-Flag" (section 2.2.1 in
>             draft-ietf-isis-segment-routing-extensions-18) to specify
>             whether the adj-SID is for IPv4 and IPv6. Similarly, the
>             SR-ISIS draft attaches a prefix-SID to the prefix
>             advertisement and hence implies the identity of the protocol
>             underneath the bottom most label. For any other "function"
>             attached to a SID, it is part of the specification of this
>             function to describe what happens when the SID is
>             represented by a label in the MPLS forwarding plane and this
>             label is the bottom most label ____
> 
>             */[[Sasha]] OK, got it. This issue is resolved./*____
> 
>             ____
> 
>                 5.*Resolution**of Conflicts*: Are the____
> 
>                 a.Are the conflict resolution procedures listed in
>                 section 2.5 mandatory to implement? ____
> 
>                 b.If they are mandatory to implement, are they also
>                 mandatory to deploy, or can the operators simply treat
>                 any detected conflict as requiring human intervention
>                 and preventing normal operation of SR-MPLS?____
> 
>             #Ahmed: They are recommended. I will modify the paragraph
>             after the first 3 bullets in Section 2.5 to say that it is
>             recommeded. ____
> 
>             */[[Sasha]] OK. However, it would be nice if you could refer
>             separately for “RECOMMENDED to implement” and “RECOMMENDED
>             to deploy”.  The latter probably requires a configuration
>             knob for enabling conflict resolution rules (if they are
>             implemented). /*____
> 
>                 c.For the reference, the IETF capitalized MUST appears
>                 just in a few places in Section 2.5, and each appearance
>                 has very narrow context:____
> 
>                 i.For MCCs where the "Topology" and/or "Algorithm"
>                 fields are not defined, the numerical value of zero MUST
>                 be used for these two fields____
> 
>                 ii.If the same set of FECs are attached to the same
>                 label "L1", then the tie-breaking rules MUST always
>                 select the same FEC irrespective of the order in which
>                 the FECs and the label "L1" are received. In other
>                 words, the tie-breaking rule MUST be deterministic. ____
> 
>                 iii.An implementation of explicit SID assignment MUST
>                 guarantee collision freeness on the same router____
> 
>                  From my POV, it is not possible to infer the answer to
>                 my question from these statements. Some explicit
>                 statement is required.____
> 
>             #Ahmed: I agree with you POV and as mentioned in my reply to
>             items (a) and (b), I will modify the paragraph to say that
>             it is RECOMMENDED to answer you questions in items (a) and
>             (b)____
> 
>                 d.The tie-breaking rules in section 2.5.1 include some
>                 specific values for encoding FEC types and address
>                 families – but these values are not supposed to appear
>                 in any IANA registries (because the draft does not
>                 request any IANA actions). Can you please clarify what
>                 is so special about these values? ____
> 
>             #Ahmed: There is no significance to the values but there is
>             a significance to the order among them. I will modify the
>             text to clarify that____
> 
>             */[[Sasha]] OK. /*____
> 
>             ____
> 
>                 e.I also doubt that comparison of FECs that represent
>                 IPv4 and IPv6 prefix SIDs makes much sense (for conflict
>                 resolution or else), because, among other things, there
>                 are valid scenarios when an IPv4 /32 prefix is embedded
>                 in an IPv6 /128 one.____
> 
>             #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix
>             that embeds an IPv4 prefix is different from the IPv4
>             prefix. The specifications of SR extensions to ISIS, OSPFv2,
>             OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately,
>             including the IPV6 prefixes with embedded IPv4 ones. Besides
>             not all IPv6 prefixes embed IPv4 prefix in them. Hence the
>             distinction between IPv4 and IPv6 prefixes is quite clear ____
> 
>             */[[Sasha]] My concern was mainly about IPv4-mapped IPv6
>             addresses. Quoting from RFC 4291:/*____
> 
> 
>                       *2.5.5.2*
>                       <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>*.
>                       IPv4-Mapped IPv6 Address*____
> 
>             ____
> 
>             ____
> 
>                 A second type of IPv6 address that holds an embedded
>             IPv4 address is____
> 
>                 defined. This address type is used to represent the
>             addresses of____
> 
>                 IPv4 nodes as IPv6 addresses.____
> 
>             *//*____
> 
>             */From my POV this means that a /128 prefix associated with
>             an IPv4-mapped IPv6 address and a /32 prefix associated with
>             the IPv4 address that was mapped to this IPv6 address
>             represent the same entity. This understanding fully matches
>             usage of IPv4-mapped IPv6 addresses as BGP Next Hops of
>             VPN-IPv6 addresses defined in RFC 4798. However, the
>             comparison rules you have defined will treat them as two
>             different prefixes.  I wonder if these rules, in the case of
>             a conflict, could result in preferring the IPv6 prefix to an
>             IPv4 one and therefore loosing MPLS connectivity for the
>             ingress PE of a 6VPE service to its egress PE?/*____
> 
>             ____
> 
>                 f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I
>                 am not sure all SID types defined in the Segment Routing
>                 Architecture draft can be unambiguously mapped to one of
>                 these types. Problematic examples include at least the
>                 following:____
> 
>                 i.Parallel Adjacency SID____
> 
>                 ii.Mirror SID____
> 
>                 Explicit mapping of SID types to SR-MPLS FEC types would
>                 be most useful IMO. If some SID types cannot be mapped
>                 to SR-MPLS FECs, this must be explicitly stated in the
>                 draft.____
> 
>             #Ahmed:
>             Parallel adjacency SID are handled in the type "(next-hop,
>             outgoing interface)" ____
> 
>             */[[Sasha]] OK/*____
> 
> 
>             Mirror SID is a type of binding-SID as mentioned in Section
>             5.1 in the SR architecture draft
>             (draft-ietf-spring-segment-routing-15). Also as described in
>             Section 2.4 draft-ietf-isis-segment-routing-extensions-18
>             (also see the equivalent in the OSPFv2 and OSPFv3 draft), a
>             binding SID is identified by a prefix. Hence it is covered
>             by the type "(Prefix, Routing Instance, Topology,
>             Algorithm)"____
> 
>             */[[Sasha]] I respectfully disagree. There is definitely no
>             mention of Algorithm in the definition of the Mirror SID. /*____
> 
>             ____
> 
>                 6.*Node SIDs in SR-MPLS*:____
> 
>                 a.Node SIDs are explicitly defined and discussed in the
>                 Segment Routing Architecture draft but are not mentioned
>                 even once in this draft____
> 
>                 b.AFAIK, the common implementation practice today
>                 includes assignment of at least one Node SID to every
>                 node in the SR-MPLS domain____
> 
>                 c.Is there a requirement to assign at least one Node SID
>                 per {routing instance, topology, algorithm} in SR-MPLS?
>                 If not, can the authors explain expected behavior of
>                 such a node? (See also my comment about routing
>                 instances below).____
> 
>             #Ahmed: A Node-SID is a special case of prefix-SID. So there
>             nothing specific about it from the MPLS forwarding plane
>             point of view. Similarly from a standard tracks draft point
>             of view, there is no requirement to assign a SID to every
>             prefix just like there is no requirement to bind every
>             prefix to an LDP label. Common and/or recommended practices
>             or description of deployment scenarios are more befitting to
>             BCP or informational drafts. This draft is a standards track
>             draft____
> 
>             */[[Sasha]] Well, you’ve just said that conflict resolution
>             rules are RECOMMENDED, and this is quite common in the
>             Standards Track RFCs. /*____
> 
> 
>             If a {routing instance, topology, algorithm} is not assigned
>             a SID, then this FEC is totally irrelavant to this draft and
>             hence describing how a node treats it is totally outside the
>             scope of this draft____
> 
>             */[[Sasha]] AFAIK, neither of the SR extension drafts for
>             IGPs mention routing instances that can be associated with
>             the prefix, so I think that your reference to it is
>             incorrect./*____
> 
>             */What’s more I suspect that Node SIDs represent the most
>             used special case of Prefix SIDs with Anycast SIDs being
>             quite behind.  Therefore some recommendation pertaining to
>             the usage of Node SIDs would be very much in place IMHO. /*____
> 
>             ____
> 
>                 7.*SRGB Size in SR-MPLS*: ____
> 
>                 a.The draft correctly treats the situation when an index
>                 assigned to some global SID cannot be mapped to a label
>                 using the procedure in Section 2.4 as a conflict.____
> 
>                 b.At the same time the draft does not define any minimum
>                 size of SRGB (be it defined as a single contiguous block
>                 or as a sequence of such blocks) that MUST be
>                 implemented by all SR-capable nodes____
> 
>                 c.I suspect that lack of such a definition could be
>                 detrimental to interoperability of SR-MPLS solutions.
>                 AFAIK, the IETF has been following, for quite some time,
>                 a policy that some reasonable MUST-to-implement defaults
>                 should be assigned for all configurable parameters
>                 exactly in order to prevent this.____
> 
>             #Ahmed: This document specifies how the SRGB is used and the
>             behavior of routers when a prefix-SID index maps to a label
>             inside and/or outside the SRGB. The actual size of the SRGB
>             is a task in partitioning the label space, which is very
>             specific to a particular deployment scenario. So IMO it is
>             outside the scope of a standards track document. Now that
>             SR-MPLS is deployed in many places, I expect the community
>             to gain sufficient experience to recommend (or not
>             recommend) a particular minimum/maximum size for the SRGB is
>             some future informational or BCP draft/RFC____
> 
>             */[[Sasha]] My reading of your response is that minimum size
>             of SRGB is an issue for future study. Can you please just
>             add this to the draft?/*____
> 
>             ____
> 
>                 8.*Algorithms and Prefix SIDs*:____
> 
>                 a.The draft mentions Algorithms (as part of SR-MPLS
>                 Prefix FEC) in, but it does not explicitly link them
>                 with the Prefix-SID algorithms defined in section 3.1.1
>                 of the Segment Routing Architecture draft____
> 
>             #Ahmed: I will just add the reference
>             [I-D.ietf-spring-segment-routing] right beside the first
>             time "Algorithm" is mentioned____
> 
>             */[[Sasha]] OK/*____
> 
>             ____
> 
>                 b.From my POV, the draft should explicitly state that
>                 the default Prefix-SID algorithm MUST be implemented in
>                 all SR-MPLS-compliant routers.____
> 
>             #Ahmed: The specification of what path calculation method
>             should or must be supported is a routing protocol property
>             not a forwarding plane property. In fact, the choice of a
>             path calculation method or algorithm is completely
>             orthogonal to the routed protocol. Hence mandating the
>             support of a particular routing algorithm is beyond the
>             scope of this document.____
> 
>             */[[Sasha]] OK/*____
> 
>             ____
> 
>                 c.The Segment Routing Architecture draft states (in
>                 section 3.1.3) that “Support of multiple algorithms
>                 applies to SRv6”. But neither draft states whether
>                 multiple algorithms apply to SR-MPLS. Can you please
>                 clarify this point?____
> 
>             #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS
>             in draft-ietf-spring-segment-routing-15 discusses the
>             support of multiple algorithms. So it is implied that the
>             concept of algorithm applies to SR-MPLS. Hence there is no
>             need to re-mention it here____
> 
>             */[[Sasha]] The paragraph to which you refer only says that
>             if a packet with the active Prefix-SID that is associated
>             with a specific algorithm is received by a node that does
>             not support this algorithm, this packet will be discarded.
>             If this is the only type of support for multiple algorithms
>             SR provides, it is not very useful IMHO/**/. /*____
> 
>             ____
> 
>                 9.*Routing instances and the context for Prefix-SIDs*:____
> 
>                 a.The Segment Routing Architecture draft states in
>                 Section 3.1 that the “context for an IGP-Prefix segment
>                 includes the prefix, topology, and algorithm”____
> 
>                 b.This draft seems to define (in section 2.5) the
>                 context for the Prefix SID as “Prefix, Routing Instance,
>                 Topology, Algorithm” where ”a routing instance is
>                 identified by a single incoming label downloader to FIB”
>                 (but the notion of the label downloader to FIB is not
>                 defined).____
> 
>                 c.These two definitions look different to me. ____
> 
>                 d.At the very least I would expect alignment between the
>                 definitions of context for the Prefix-SID between the
>                 two drafts. Preferably, the definition given in the
>                 Segment Routing Architecture draft should be used in
>                 both drafts.____
> 
>             #Ahmed: The context of the section 2.5 is limited to the
>             resolution of local label collision. The use of "routing
>             instance" in section 2.5 is just there for tie-breaking if
>             there is local label collision.____
> 
>             */[[Sasha]] I have already mentioned that “routing
>             instances” are not defined in any the drafts dealing with SR
>             Extensions for IGPs. So I do not understand how the conflict
>             resolution procedure is supposed to use this. And in any
>             case the difference between two definitions of the context
>             of Prefix-SID requires some explanation./*____
> 
> 
> 
>             ____
> 
>                 10.*Example of PUSH operation in Section 2.10.1*:____
> 
>                 a.The first para of this section begins with the
>                 sentence “Suppose an MCC on a router "R0" determines
>                 that PUSH or CONTINUE   operation is to be applied to an
>                 incoming packet whose active SID is the global SID
>                 "Si"”. In the context of SR-MPLS this means (to me) that
>                 the incoming packet is a labeled packet and its top
>                 label matches the global SID “Si”. ____
> 
>                 b.However, the example for PUSH operation in the next
>                 para of this section is the case of an (unlabeled) IP
>                 packet with the destination address covered by the IP
>                 prefix for which “Si” has been assigned. ____
> 
>                 c.From my POV:____
> 
>                 i.Mapping unlabeled packets to SIDs is indeed out of
>                 scope of the draft. Therefore an example of a PUSH
>                 operation that is applied to a labeled packet (with the
>                 active SID inferred from the top label in the stack) is
>                 preferable.____
> 
>                 ii.Valid examples of  PUSH operation applied to a
>                 labeled incoming packet can be found in Sections 4.2 or
>                 4.3 of the TI-LFA
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft____
> 
>                 ____
> 
>             #Ahmed: I do not understand your concern here:)____
> 
>             */[[Sasha]] I think it is pretty clear: can you provide an
>             example of a PUSH operation applied to a labeled packet
>             instead of your current example?/*____
> 
>             ____
> 
>                 *Nits*: ____
> 
>                 1.I concur with Adrian regarding numerous nits he has
>                 reported in his WG LC Comment
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_spring_FRhO2lgR8r4VlKP2ZN2dZwHU5BY&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I_4gDFhcjR_1npqKUQDHThsejUMgJy3WlLzC90poR1w&e=>.
>                 I would like to thank Adrian for an excellent review
>                 that have saved me lots of hard work.____
> 
>             #Ahmed: I also agree that Adrian's review is exceptional. I
>             believe I addressed all his comments in the latest version.____
> 
>                 2.In addition, I’d like to report the following nits:____
> 
>                 a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the
>                 TI-LFA
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft)____
> 
>             #Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
> 
>                 b.TI-LFA draft is referenced in the text of Section
>                 2.11.1, but there is no matching reference in the
>                 “References” section (probably, Informational)____
> 
>             #Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
> 
>                 c.“zero Algorithm” in Section 2.5 (immediately above
>                 Section 2.5.1) must be replaced with “default
>                 algorithm”. Similarly, “non-zero Algorithm” should be
>                 replaced with “non-default algorithm”____
> 
>             #Ahmed: Will be done in the next version*/[[Sasha]] /* OK____
> 
>                 3.I think that RFC 3443 and RFC 5332 should be listed as
>                 Normative references in this draft while RFC 5331 and
>                 RFC 8277 should be listed as Informative references.
>                 This would improve the readability of the draft without
>                 any impact on its advancement. ____
> 
>                 ____
> 
>             #Ahmed RFC5331 describes upstream label assignment. As you
>             mentioned above (and I will modify the draft to indicate
>             that) SR-MPLS behavior is similar to downstream label
>             assignment. RFC 3443 describes TTL behavior. This is an MPLS
>             forwarding behavior. As mentioned in the draft, SR-MPLS does
>             not modify at the MPLS forwarding behavior____
> 
>             */[[Sasha]] Regarding RFC 5331 – you may skip this reference
>             if you state (as discussed below) that SR-MPLS only
>             allocates labels from the per-platform label space.
>             Regarding RFC 3443 – I do not think that you can fully avoid
>             discussion of Uniform and Pipe/Short Pipe models, and
>             therefore you will need this reference./*____
> 
> 
> 
>             ____
> 
>                 Hopefully, these comments will be useful.____
> 
>             #Ahmed: They are certainly quite useful. Thanks a lot____
> 
>                 ____
> 
>                 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.
>                 _______________________________________________________________________________
> 
>             ____
> 
> 
>             ___________________________________________________________________________
> 
>             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.
>             _______________________________________________________________________________
> 
>         ____
> 
> 
>         ___________________________________________________________________________
> 
>         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.
>         _______________________________________________________________________________
> 
>     __ __
> 
> 
>     ___________________________________________________________________________
> 
>     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> 	
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64