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
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… bruno.decraene
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- [RTG-DIR] RtgDir Early review: draft-ietf-spring-… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… stephane.litkowski
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Shraddha Hegde
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… stephane.litkowski
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Shraddha Hegde
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Przemyslaw Krol
- Re: [RTG-DIR] [mpls] [spring] RtgDir Early review… Alex Bogdanov
- Re: [RTG-DIR] [mpls] [spring] RtgDir Early review… Rob Shakir
- Re: [RTG-DIR] [mpls] RtgDir Early review: draft-i… Jeff Tantsura
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Loa Andersson
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Loa Andersson