Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDB6130E6A for ; Mon, 19 Nov 2018 10:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.491 X-Spam-Level: X-Spam-Status: No, score=-17.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txce7-5FqWPn for ; Mon, 19 Nov 2018 10:47:24 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAA0130E41 for ; Mon, 19 Nov 2018 10:47:23 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id t17so18377136vsc.8 for ; Mon, 19 Nov 2018 10:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g2DWToyU9PH43kTSmOE/nRrWSLBi/7M9TGnvNFq+1iw=; b=kfflTTkxatjCczBjog18DKy/hiXJ2j/+bDuXCYXqaSrhSJ4IcJT6EZZIgdQC8ksS93 J6C2jhPOtfEGjCkADya5IotgUtDRjR5Za1erCPLxkTEImlMMwXqN8Q2K/93m1CqnjYZK k300xLJO95NoiywkqwP0Gw1BuRgnIJOSw0BUzLw1bgFQwI0bEANb87ebNdL5lBs0/qqe AjPk2YvLsfALcrGapDc8ZkYGmh6j15WqSYNiv8F7sN67IDRBV3LkNlVZIJVK3F+xkmVZ zXC/HnJBpfGfXDzMIlN55Lcs6/QzQ4JXl+uQeghdddY0a25LVCRLPUw9sus70L6uuLmP Q09A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g2DWToyU9PH43kTSmOE/nRrWSLBi/7M9TGnvNFq+1iw=; b=bh5Y6H1pP60Og1IKASnp09mooOfp5GyxPG7r1s4L6K+wSXBT+Nl3sIrxpOb1nzN7ek wRuZ9tQSwWEknIoh5hgoG5S7dzTAi8UjunoRfjpeSS4AGQTnmNue+oaLo8QsUavoWVRx 155oExSZqTM2Fv/+xddbkRygCiZfeXhmJuXFNWfMrDddKGKmpkGHJeE0L5jRgmah+9vc j6q3EhxPoUJ31wpX+y3yCMoEXYlB/VJ0GDYQsCBuwYFHTWqYKt3WovYEhLWf/sOJKO1A 5P4SxyhbgcvkpTbJssOfkO07zjlh8NQemZI/qgSMX7WJANir+ooIDC+iVY8I0gSWLDV6 YvmA== X-Gm-Message-State: AGRZ1gK+p/ZY0lgLiQvcOjXeS+FtI04hQ0M5PzmnlkZnX7CFbU9JlBrw okicDPu8++uwwQ0zE3ykJLDB5J2z0oNYkLZsKho43Q== X-Google-Smtp-Source: AJdET5fsQzeDPxQjldhqR1fo8eY+XzQxFKNiA5oio4N49iTpWZRLDhRX9+wRGFQqT419BSh1z+l4OSI26N/C+gdq4PE= X-Received: by 2002:a67:2309:: with SMTP id v9mr9737667vsf.115.1542653241991; Mon, 19 Nov 2018 10:47:21 -0800 (PST) MIME-Version: 1.0 References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> In-Reply-To: From: Alex Bogdanov Date: Mon, 19 Nov 2018 10:47:09 -0800 Message-ID: To: Przemyslaw Krol Cc: Shraddha Hegde , rtg-dir@ietf.org, spring@ietf.org, mpls@ietf.org, spring-chairs@ietf.org, jonathan.hardwick@metaswitch.com, draft-ietf-spring-segment-routing-mpls.authors@ietf.org Content-Type: multipart/alternative; boundary="00000000000080b26d057b08f282" Archived-At: Subject: Re: [mpls] [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 18:47:36 -0000 --00000000000080b26d057b08f282 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Shraddha, I think it's an important recommendation to include. In the absence of another obvious draft/RFC, I would lean towards my original proposal of including it as a section in draft-ietf-spring-segment-routing-mpls. Cheers, Alex On Mon, Nov 19, 2018 at 8:02 AM Przemyslaw Krol wrote: > Hi Shraddha > > I think this would be very helpful. > > pk > > On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde > 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 >> > *Sent:* Sunday, November 4, 2018 9:37 PM >> *To:* Ahmed Bashandy >> > *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; ' >> adrian@olddog.co.uk' ; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) ; >> spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf..org; Shraddha Hegde >> >> > >> *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 tw= o >> different nodes in the SR domain is =E2=80=9Ca clear violation of the SR >> architecture RFC (8402)=E2=80=9D. >> >> But I do not think that the SR-MPLS draft can silently ignore this >> violation just because it =E2=80=9Cis not an incoming label collision=E2= =80=9D. >> >> 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 no= t >> 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-oriente= d: >> 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 >> >> exists, and deals with other issues). >> >> My 2c, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> ] >> *Sent:* Sunday, October 28, 2018 1:01 AM >> *To:* Shraddha Hegde ; Alexander Vainshtein < >> Alexander.Vainshtein@ecitele.com> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; ' >> adrian@olddog.co.uk' ; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) ; >> spring@ietf.org; spring-chairs@ietf.org; >> 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 becaus= e >> 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 tha= t >> 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. >> >> =E2=80=9C >> >> An IGP Node-SID MUST NOT be associated with a prefix that is owned by >> >> more than one router within the same routing domain.=E2=80=9D >> >> >> >> 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 handl= e >> 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 >> >> *Sent:* Thursday, July 19, 2018 10:05 PM >> *To:* Ahmed Bashandy >> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; >> 'adrian@olddog.co.uk' ; >> Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) >> ; >> Shraddha Hegde ; >> spring@ietf.org; spring-chairs@ietf.org; >> 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 t= o >> the life span of prefix SIDs in general and Node SIDs in particular. Fro= m >> my POV this difference should be discussed in the draft. >> >> So it seems that we can only =E2=80=9Cagree to disagree=E2=80=9D on the = need to say >> something specific about Node SIDs in the draft, and let the WG to decid= e >> what to do about it. >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> ] >> *Sent:* Thursday, July 19, 2018 7:13 PM >> *To:* Alexander Vainshtein >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; ' >> adrian@olddog.co.uk' ; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) ; >> shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; >> 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 rol= e >> 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 configurat= ion >> action by the operator of SR domain. I.e., it is not enough for a node t= o >> 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 P= OV, >> this difference alone would qualify Node SIDs as a topic to be discussed= in >> the MPLS-SR Architecture >> >> 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 MPL= S >> packet (representing the prefix-SID) identifies a node or not. So from t= he >> 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 wh= ere >> there is a need to handle a node-SID different from a prefix SID, it wou= ld >> 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 >> >> draft. This draft says in Section 4.2: >> >> >> >> 4.2 >> .. >> 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, =E2=80=9Ca single node = segment >> to the repair node=E2=80=9D 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=3DSR 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 uloo= p >> avoidance are handled in separate drafts. So just like the response to y= our >> 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 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Alexander Vainshtein >> *Sent:* Wednesday, July 11, 2018 12:02 PM >> *To:* Ahmed Bashandy >> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; >> 'adrian@olddog.co.uk' ; >> Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) >> ; >> shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; >> 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 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> ] >> *Sent:* Wednesday, July 11, 2018 4:42 AM >> *To:* Alexander Vainshtein ; >> spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' ; ' >> adrian@olddog.co.uk' ; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) ; >> shraddha@juniper.net; 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; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> >> *Cc:* spring@ietf..com ; rtg-dir@ietf.org; ' >> mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com); 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 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Alexander Vainshtein >> *Sent:* Friday, June 8, 2018 5:43 PM >> *To:* 'spring-chairs@ietf.org' >> ; ' >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org' >> >> >> *Cc:* 'spring@ietf.com' ; >> rtg-dir@ietf.org; mpls@ietf.org; 'adrian@olddog.co.uk' >> >> *Subject:* RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 >> >> >> >> >> >> Hello, >> >> I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D= review of this >> draft: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> >> >> >> >> The routing directorate will, on request from the working group chair, >> perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submit= ted for publication >> to the IESG. The early review can be performed at any time during the >> draft=E2=80=99s lifetime as a working group document. The purpose of the= early >> review depends on the stage that the document has reached. As this docum= ent >> is currently in the WG Last call, my focus for the review was to determi= ne >> whether the document is ready to be published. Please consider my commen= ts >> along with the other working group last call comments. >> >> >> >> For more information about the Routing Directorate, please see =E2=80=8B >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> >> >> >> *Document*: draft-ietf-spring-segment-routing-mpls-13 >> >> *Reviewer*: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein ( >> 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 >> >> 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 rai= sed >> in my review reflect either gaps that should be, but have not been, clos= ed, >> or inconsistencies between the two drafts. >> >> >> >> >> >> Since RFC 8287 >> >> is already published as a Standards Track RFC, I expect such augmentatio= n >> to be backward compatible with this document (or to provide clear >> indications of required updates to this document). And I include the MPL= S >> 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 =E2=80= =9Ccorner >> cases=E2=80=9D resulting, presumably, from misconfiguration, before it e= xplains the >> basic (and relatively simple) =E2=80=9Cnormal=E2=80=9D behavior, looks p= roblematic 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* >> >> *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 =E2= =80=93 >> 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 =E2=80=93 the previous comment notwithstanding. In parti= cular, 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 Segmen= t >> Routing Architecture draft using MPLS data plane clearly calls for conte= xt >> 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 *functio= n* >> 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 t= his >> 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 t= he >> 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 plan= e >> (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-menti= on >> it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specifi= c. >> 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 th= e >> 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) implemen= ted >> in each node that that performs Next operation on the packet along the p= ath >> =E2=80=93 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 lab= el >> to be popped by the egress LER >> >> #ahmed: This is part of the "Next" function. It is described in detail i= n >> 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 questi= on?* >> >> >> >> b. For the reference, RFC 3032 says that =E2=80=9Cthe 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=E2=80=9D >> >> 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 l= abel >> >> iv. The implementers must be >> given unambiguous instructions for forwarding the unlabeled packet via t= he >> 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 IPv= 4 >> 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 wheth= er >> 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 firs= t >> 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 =E2=80=9CRECOMMENDED to implement=E2=80=9D and =E2=80=9CRECOMMENDED = to deploy=E2=80=9D. 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 valu= e >> 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 a= nd >> 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 ro= uter >> >> 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 =E2=80=93 but these v= alues are >> not supposed to appear in any IANA registries (because the draft does no= t >> request any IANA actions). Can you please clarify what is so special abo= ut >> 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* >> *. >> IPv4-Mapped IPv6 Address* >> >> >> >>

> >> -- -- Alex Alex Bogdanov | Strategic NetEng | bogdanov@ | Cell: 650-314-8196 --00000000000080b26d057b08f282 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Shraddha, I think it's an important recommendati= on to include.=C2=A0

In the absence of another obvious d= raft/RFC, I would lean towards my original proposal of including it as a se= ction in draft-ietf-spring-segment-routing-mpls.=C2=A0

C= heers,

Alex



On Mon, Nov 19, 2018 at 8:02 AM Przemyslaw Krol <pkro= l=3D40goog= le.com@dmarc.ietf.org> wrote:
Hi Shraddha

I think this would be very=C2=A0helpful.

p= k

On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <shraddha@juniper.net> wrote:

Sent: Sunday, November 4, 2018 9:37 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>


Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-= mpls-13

=

=C2=A0

Ahmed,

Apologies f= or a delayed response.

I fully agr= ee that advertising the same prefix SID as the Node SID by two different no= des in the SR domain is =E2=80=9Ca clear violation of the SR architecture RFC (8402)=E2=80=9D.

But I do no= t think that the SR-MPLS draft can silently ignore this violation just beca= use it =E2=80=9Cis not an incoming label collision=E2= =80=9D.

The same ap= plies to the controversy in advertising at the same prefix as Anycast by so= me nodes but not as Anycast (or even as a Node SID) by some other nodes.

Your refere= nce to these being just control plane issues and therefore not related to S= R-MPLS is not valid - because the drafts dealing with the SR control plane to which you refer in this draft are strictly MP= LS-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 exists, and deals with other= issues).

My 2c,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302<= /u>

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com=

=C2=A0

From: Ahmed Bashandy [mailto:a= bashandy.ietf@gmail.com]
Sent: Sunday, October 28, 2018 1:01 AM
To: Shraddha Hegde <shraddha@juniper.net>;= Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: rt= g-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian@olddo= g.co.uk' <adrian@olddog.co.uk>; Jonathan= Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.h= ardwick@metaswitch.com>; spring@ietf.or= g; spring-= chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ie= tf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-= mpls-13

=C2=A0

Thanks for the comments

While it is a clear violation of the SR architecture RFC (8402), more th= an one node advertising the same IPv4/6 PREFIX and both have the same prefi= x-SID value with "N" flag is not an incoming label collision beca= use the label is associated with the same FEC, which is the prefix.=C2=A0

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 d= raft

=C2=A0

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 co= ntrol layer functionality and is not specific to SR-MPLS. Hence it is outsi= de the scope of this draft

=C2=A0

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.

=C2=A0

On 7/19/18 8:30 PM, Shraddha Hegde wrote:<= /u>

Hi Ahmed,

=C2=A0

The Node-SIDs are expected to be uniq= ue to a node. 

=E2=80=9C

=C2=A0=C2=A0 An IGP Node-= SID MUST NOT be associated with a prefix that is owned by<= /u>

=C2=A0=C2=A0 more than on= e router within the same routing domain.=E2=80=9D

=C2=A0

If two different nodes advertise same= Node-SID,

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For Example Node A and B both adver= tise prefix 1.1.1.1 and associate a =C2=A0SID 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

Application= s can use this SID as a Node-SID.

Another sli= ght variation of this case is a scenario where A and B both advertise a pre= fix 1.1.1.1 and A assigns a Node-Sid

Of 1000 and= B does not assign any SID.

=C2=A0

Rgds=

Shraddha

=C2=A0

From: Alexander Vainshtei= n <Alexander.Vainshtein@ecitele.com>
Sent: Thursday, July 19, 2018 10:05 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rt= g-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.or= g>; 'adrian@olddog.co.uk' <adrian= @olddog.co.uk>; Jonathan Hardwick (<= a href=3D"mailto:Jonathan.Hardwick@metaswitch.com" target=3D"_blank">Jonat= han.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; S= hraddha Hegde &l= t;shraddha@juniper.net>; spring@ietf.or= g; spring-= chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ie= tf.org
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-= mpls-13

=C2=A0

Ahmed hi!

Lots of tha= nks for your response.

Of course N= ode 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 spa= n 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 =E2=80=9Cagree to disagree=E2=80=9D on the need to say so= mething specific about Node SIDs in the draft, and let the WG to decide what to do about it.

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0

=C2=A0

Thanks for the reply

See inline

Ahmed

=C2=A0

On 7/12/18 12:22 AM, Alexander Vainshtein wrote:<= /u>

Ahmed and a= ll,

I would lik= e to expand on my comments (and your responses) about the role of Node SIDs= in SR-MPLS.

I would lik= e to bring your attention two points:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Node SIDs (and, in gener= al, Prefix SIDs) in MPLS-SR are different from the same in SRv6 because the= y 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 e= xplicitly configure the node to use such a prefix as=C2=A0 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 draft.=

#Ahmed: I disagree w= ith your POV. From the forwarding plane perspective it does not make any di= fference 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-S= ID and a node-SID. If there is any place in the SR-mpls draft where there i= s a need to handle a node-SID different from a prefix SID, it would be great to point it out

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition, quite a few constructs associated with SR= -MPLS implicitly assume that each node in the SR-MPLS domain is assigned wi= th at least one Node SID. One example can be found in the TI-LFA draft. This draft says in Section 4.2:

=C2=A0

4.2.. The repair node is a PQ node

=C2=A0
=C2=A0
=C2=A0=C2=A0 Wh=
en the repair node is in P(S,X), the repair list is made of a=

=C2=A0=C2=A0 si=
ngle node segment to the repair node.

In the scope of this section, the repair node is not adjacen= t to the PLR, and therefore, to the best of my understanding, =C2=A0=E2=80= =9Ca single node segment to the repair node=E2= =80=9D 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= =3DSR domain =C2=A0having at least one Node SID each

#Ahmed: The choice o= f 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 pa= th, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop avo= idance are handled in separate drafts. So just like the response to your pr= evious 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.

.

=C2=A0

Hopefully these notes clarify my position on the subject.

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0

From: Alexander Vainshtei= n
Sent: Wednesday, July 11, 2018 12:02 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rt= g-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.or= g>; 'adrian@olddog.co.uk' <adrian= @olddog.co.uk>; Jonathan Hardwick (<= a href=3D"mailto:Jonathan.Hardwick@metaswitch.com" target=3D"_blank">Jonat= han.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; shraddha@= juniper.net; spring@ietf.or= g; spring-= chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ie= tf.org
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-= mpls-13

=C2=A0

Ahmed, and = all,

Lots of tha= nks for a detailed response to my comments.

Please see inline below my p= osition on each of them.

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0

=C2=A0

Thanks for thorough (and VERY clear) the review

See inline #Ahmed

=C2=A0

Ahmed

=C2=A0

=C2=A0

On 6/15/18 11:08 PM, Alexander Vainshtein wrote:<= /u>

Re-sending to=C2=A0 correct SPRING WG list.

Sincere apologies for the delay caused by a typo.=

Thumb typed by Sasha Vainshtein

=C2=A0

From: Al= exander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spri= ng-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org

<= /div>


Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-= mpls-13

Explicitly adding Shra= ddha =C2=A0who is the shepherd of this draft.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Hello,

I have been selected to do a routing directorate = =E2=80=9Cearly=E2=80=9D review of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring= -segment-routing-mpls/

=C2=A0

The routing directorate will, on request from the w= orking group chair, perform an =E2=80=9Cearly=E2=80=9D review of a draft be= fore it is submitted for publication to the IESG. The early review can be performed at any time during the draft=E2=80=99s lifetime as a work= ing group document. The purpose of the early review depends on the stage th= at the document has reached. As this document is currently in the WG Last c= all, 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.

=C2=A0

For more information about the Routing Directorate,= please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

=C2=A0

Document: draft-ietf-spring-segment-= routing-mpls-13

Reviewer: Alexander (=E2=80=9CSasha= =E2=80=9D) Vainshtein (alexander.vainshtein@ecitele.com)

Review Date: 08-Jun-18=

Intended Status: Proposed Standard.<= /span>

=C2=A0

Summary:

=C2=A0

I have some minor concerns about this document that= I think should be resolved before it is submitted to the IESG.

=C2=A0

Comments:

=C2=A0

I consider this draft as an important =C2=A0compani= on document to the Segment Routing Architecture draft that, ideally, should augment defin= itions of the Segment Routing (SR) notions and constructs given there with = details specific for the SR instantiation that uses=C2=A0 the MPLS data plane (SR-MPLS).=C2=A0 Many issues raised in my r= eview reflect either gaps that should be, but have not been, closed, or inc= onsistencies between the two drafts.

=C2=A0

=C2=A0

Since RFC 8287 is already published as a Standards Track RFC, I expect s= uch augmentation to be backward compatible with this document (or to provid= e clear indications of required updates to this document). And I include the MPLS WG into distribution list.

=C2=A0

This draft was not easy reading for me. In particul= ar, the style of Section 2.5 that discusses at length and in some detail mu= ltiple =E2=80=9Ccorner cases=E2=80=9D resulting, presumably, from misconfiguration, before it explains the basic (and relatively simple) =E2= =80=9Cnormal=E2=80=9D behavior, looks problematic to me.

=C2=A0

The WG Last Call has been extended by one week. Nev= ertheless, I am sending out my comments

=C2=A0

Major Issues: None found

#Ahmed: thanks a lot

=C2=A0

Minor Issues: Quite a few but, hopef= ully, easy to resolve.

=C2=A0

1.=C2=A0=C2=A0=C2=A0 Encapsulation of SR-MPLS packets:

a.=C2=A0=C2=A0= =C2=A0 RFC 3032 (referenced by the draft) and RFC 5332 (not mentione= d 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 d= raft-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 draft:

=C2=A0=C2=A0 A variation of SR Policy can = be used for packet replication.=C2=A0 A

=C2=A0=C2=A0 candidate path could comprise= multiple SID-Lists; one for each

=C2=A0=C2=A0 replication path.=C2=A0 In su= ch a scenario, packets are actually

=C2=A0=C2=A0 replicated through each SID L= ist of the SR Policy to realize a point-

=C2=A0=C2=A0 to-multipoint service deliver= y.

=C2=A0

This looks to me as being very = much multicast in SR, and, unless you want to say that it is limited to SRv= 6, makes my question relevant IMHO.

b.=C2=A0=C2=A0= =C2=A0 From my POV the ST-MPLS only uses Downstream-allocated labels =E2= =80=93 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 unambig= uous and, once added, would resolve my comment in full =E2=80=93 the previo= us comment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be d= ownstream-allocated.

=C2=A0

2.=C2=A0=C2=A0=C2=A0 Label spaces in SR-MPLS:

a.=C2=A0=C2=A0= =C2=A0 RFC 3031 (referenced by the draft) defines per-platform and per-int= erface label spaces, and RFC 5331 (not mentioned in the draft= ) adds context-specific label spaces and context labels.

b.=C2=A0=C2=A0= =C2=A0 The draft does not say which of these are or are not relevant for S= R-MPLS

c.=C2=A0=C2=A0= =C2=A0 From my POV:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0=C2=A0 Labels representing all kinds of SIDs mentioned in the draft MUST b= e allocated from the per-platform label space only

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0=C2=A0 At the same time, instantiation of Mirror Segment IDs defined in Se= ction 5.1 of the Segment Routing Architecture draft using MPLS data plane c= learly calls for context labels and context-specific label spaces

d.=C2=A0=C2=A0= =C2=A0 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 possib= le to the MPLS forwarding plane. General functions attached to SID are described in the segment routing arc= hitecture document or future documents. Furture documents proposing new SR = function must be as specific and clear as possible

[[Sasha]] Looks OK to me.

=C2=A0

3.=C2=A0=C2=A0=C2=A0 SR-MPLS and hierarchical LSPs:<= /p>

a.=C2=A0=C2=A0= =C2=A0 SR LSPs that include more than one segment are hierarchical LSPs fr= om the POV of the MPLS data plane. Therefore some (possibly, all) of the mo= dels for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should= apply to SR-MPLS

b.=C2=A0=C2=A0= =C2=A0 RFC 8287 (not referenced in the draft) specifically d= iscussed operation of the LSP Traceroute function for SR LSPs in the case w= hen Pipe/Short Pipe model for TTL handling is used

c.=C2=A0=C2=A0= =C2=A0 I expect the draft to provide at least some guidelines regarding ap= plicability 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 forward= ing plane (and hence this draft) does not modify the MPLS forwarding plan b= ehavior 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 fo= rwarding. RFC8287 is OAM-specific.=C2=A0 SR-OAM is handled in a separate do= cument so is outside the scope of this draft

[[Sasha]] Unfortunately I do no= t think this is good enough. Let me ask a specific question reflecting my c= oncerns:

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 ea= ch LSE is the label that matches the corresponding SID. However, each LSE a= lso includes the TTL and TC fields. How does the head-end node set these fi= elds in each of the LSEs following the top one? This clearly depends on the model (Uniform vs. Pipe/Short Pip= e) implemented in each node that that performs Next operation on the packet= along the path =E2=80=93 but the head-end node usually is not aware of tha= t.

RFC 8287 is relevant as an exam= ple here IMHO because it recommends the following setting of TTL in Tracero= ute packets:

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set the TTL of all= the labels above one that represents the segment you are currently tracing= to maximum

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set the TTL of the= label one that represents the segment you are currently tracing to the des= ired value (to be incremented until end of segment is reached

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 recommendatio= ns for traffic (non-OAM) packets as well.

=C2=A0

4.=C2=A0=C2=A0=C2=A0 Inferring network layer protocol in SR-MPLS:<= u>

a.=C2=A0=C2=A0= =C2=A0 I wonder if the draft could provide any details on the situation wh= en 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 des= cribed in detail in this document.

[[Sasha]] NEXT function is ment= ioned in several places in the document. Can you please point to the specif= ic text that is relevant for my question?

=C2=A0

b.=C2=A0=C2=A0= =C2=A0 For the reference, RFC 3032 says that =E2=80=9Cthe identity of the = network layer protocol=C2=A0 must be inferable from the value of the label = which is popped from=C2=A0 the bottom of the stack, possibly along with the contents=C2=A0 of the network layer header itself=E2=80=9D=

c.=C2=A0=C2=A0= =C2=A0 From my POV the following scenario indicates relevance of this expe= ctation for SR-MPLS:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0=C2=A0 IS-IS is used for distributing both IPv4 and IPv6 reachability in a= given domain

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0=C2=A0 An IS-IS adjacency over some dual-stack link is established, and a = single Adj-SID for this adjacency is advertised

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iii.=C2=A0=C2=A0=C2=A0 The node that has assigned and advertised this Adj-SID receives a l= abeled packet with the label representing this Adj-SID being both the top a= nd bottom-of-stack label

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iv.=C2=A0=C2=A0=C2=A0 The implementers must be given unambiguous instructions for forward= ing the unlabeled packet via the dual-stack link as an Ipv4 or an IPv6 pack= et.

#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSF= v3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv= 4 next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-rout= ing-extensions-18) to specify whether the adj-SID is for IPv4 and IPv6. Sim= ilarly, 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" attac= hed 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 issu= e is resolved.

=C2=A0

5.=C2=A0=C2=A0=C2=A0 Resolution of Conflicts: Are the

a.=C2=A0=C2=A0= =C2=A0 Are the conflict resolution procedures listed in section 2.5 mandat= ory to implement?

b.=C2=A0=C2=A0= =C2=A0 If they are mandatory to implement, are they also mandatory to depl= oy, or can the operators simply treat any detected conflict as requiring hu= man 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. =C2=A0

[[Sasha]] OK. However, it would= be nice if you could refer separately for =E2=80=9CRECOMMENDED to implemen= t=E2=80=9D and =E2=80=9CRECOMMENDED to deploy=E2=80=9D.=C2=A0 The latter pr= obably requires a configuration knob for enabling conflict resolution rules (if they are i= mplemented).

c.=C2=A0=C2=A0= =C2=A0 For the reference, the IETF capitalized MUST appears just in a few = places in Section 2.5, and each appearance has very narrow context:<= u>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0=C2=A0 For MCCs where the "Topology" and/or "Algorithm"= ; fields are not defined, the numerical value of zero MUST be used for thes= e two fields

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0=C2=A0 If the same set of FECs are attached to the same label "L1&quo= t;, then the tie-breaking rules MUST always select the same FEC irrespectiv= e of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iii.=C2=A0=C2=A0=C2=A0 An implementation of explicit SID assignment MUST guarantee collisi= on freeness on the same router

From my POV, it is not = possible to infer the answer to my question from these statements. Some exp= licit statement is required.

#Ahmed: I agree with you POV and as mentioned in my reply to ite= ms (a) and (b), I will modify the paragraph to say that it is RECOMMENDED t= o answer you questions in items (a) and (b)

d.=C2=A0=C2=A0= =C2=A0 The tie-breaking rules in section 2.5.1 include some specific value= s for encoding FEC types and address families =E2=80=93 but these values ar= e 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 th= e values but there is a significance to the order among them. I will modify= the text to clarify that

[[Sasha]] OK.

=C2=A0

e.=C2=A0=C2=A0= =C2=A0 I also doubt that comparison of FECs that represent IPv4 and IPv6 p= refix SIDs makes much sense (for conflict resolution or else), because, amo= ng 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 tha= t embeds an IPv4 prefix is different from the IPv4 prefix. The specificatio= ns of SR extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately, including the IPV6 prefix= es with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix= in them. Hence the distinction between IPv4 and IPv6 prefixes is quite cle= ar

[[Sasha]] My concern was mainly= about IPv4-mapped IPv6 addresses. Quoting from RFC 4291:=

2.5.5.2.=C2=A0 IPv4-Mapped IPv6 Address

=C2=A0

=
<p class=3D"MsoNormal" style=3D"margin:0in;margin-bottom:= .0001pt;line-heigh
=
--
=
-- Alex

Alex Bogdanov |= =C2=A0Strategic NetEng |=C2=A0bogdanov@=C2=A0| Cell: 650-314-8196
--00000000000080b26d057b08f282--