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 07EBF127332; Mon, 19 Nov 2018 21:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuDaDQwoi0EV; Mon, 19 Nov 2018 21:19:06 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 EEA1A12D4EB; Mon, 19 Nov 2018 21:19:05 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id v1-v6so408984plo.2; Mon, 19 Nov 2018 21:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TmhL4/l9hAcZ+Z8NlKXoDWKBydPbJvlUFJwXdC0Z6c4=; b=I0fJyZLN/fH3r74fL7nVSVMrufFP2xjC8NA4iO/VZavU7WR3PmXos9CQr8jkRkDXvu W/pm4toYdEClNk5hKcbbm2OAZlXk4zCL5sO3G9ZMDCJ9A5kLAgaYK5GBR0zhxfDpzN1F PCIbIkG4w9HmaE7kVcNEODx69OE4wobO94tEETay6rANJfSV6toIv71MIzPgqPm8OcZ6 WIW4wTdi0SQTvuqULZC3MXAOAafyNCrt4lUuD0HEU0RGvcZ9E0Hh4WCJ+GRJfDGFT/h/ UsxpmCi/TjGe0E8cvBrOkH+9DcJ7VRmWZGW4g4yhzA/rYliuMI/0L4aNz5WPm+gZsN41 mNGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TmhL4/l9hAcZ+Z8NlKXoDWKBydPbJvlUFJwXdC0Z6c4=; b=Zf8zuQhKWLwi5vW14c6JpxmTwY87ZCNcgINg8OHuDhEH6pf2+D77BXFxLNepEUr6NC PrHu1P78Boe68FHSk+HwEorgpHwSaH+WHy0kq2/Ex991i37C14BmJ+Ivy0W0yp/Ia2oE Fesfygeawf00/GNTt4ekq9+Sk20iV7L1Jybv6VlPULhEI1wEy/Va6zAjcMWImkP6sxmd 8sduFYBezy+Im+QyEdsFsWxFgPM9nqPCN1yhYTwdAR2gXl6HKsReViNgwcWNPHnvRIJ7 2uGv+UdyVOg+leLhnl+VDpx30Y4Wmll1QxktX1hJaDDb+4zjiSrVSA3eRzoK+6S5nPtP KOSw== X-Gm-Message-State: AA+aEWY1g4ss5/MwLOrh9ymf/Elp3uENw9ixUocdAMWnIXEm+L77yA0i zNkEEiNItllZYlcDeCjDI1xD4SaZ X-Google-Smtp-Source: AFSGD/U37YLpIy7hS0Zgx8ipmNQSMBtHijjiHaEXo5OEu9WFnwIET7K8oJ0faHSDjcFlCS9jb3JXzw== X-Received: by 2002:a17:902:7107:: with SMTP id a7mr735958pll.290.1542691144759; Mon, 19 Nov 2018 21:19:04 -0800 (PST) Received: from [192.168.1.9] (c-73-189-13-44.hsd1.ca.comcast.net. [73.189.13.44]) by smtp.gmail.com with ESMTPSA id u6sm43288446pgr.79.2018.11.19.21.19.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 21:19:03 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-4969499B-3E82-4EDD-B8BC-F3CD36C54030 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Mon, 19 Nov 2018 21:19:02 -0800 Cc: Alexander Vainshtein , Ahmed Bashandy , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" Content-Transfer-Encoding: 7bit Message-Id: <71D2FC23-63CD-45A9-8996-2DAF4A27204E@gmail.com> References: <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> To: Shraddha Hegde Archived-At: Subject: Re: [mpls] 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: Tue, 20 Nov 2018 05:19:12 -0000 --Apple-Mail-4969499B-3E82-4EDD-B8BC-F3CD36C54030 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sraddha, Please do so. Thanks=20 Regards, Jeff > On Nov 18, 2018, at 20:37, Shraddha Hegde wrote: >=20 > Hi all, >=20 > =20 >=20 > I am preparing the shepherd write-up and noticed that the topic in below e= -mail thread is an >=20 > Open item. My personal opinion is to add a new section to this draft to ad= dress below cases >=20 > > more than one node advertising the same IPv4/6 PREFIX and both have the s= ame prefix-SID value with "N" flag >=20 > > where an anycast prefix is advertised with a prefix-SID sub-TLV by some (= but not all) of the nodes that advertise that prefix. >=20 > =20 >=20 > This draft is addressing incoming label collision and resulting behavior a= nd also describes other aspects like different SIDs for same prefix so it se= ems reasonable to add above two cases to this draft. >=20 > WG members, if you have an opinion, pls respond on the list. >=20 > =20 >=20 > Rgds >=20 > Shraddha >=20 > From: Alexander Vainshtein =20 > Sent: Sunday, November 4, 2018 9:37 PM > To: Ahmed Bashandy > Cc: rtg-dir@ietf.org; 'mpls@ietf.org' ; 'adrian@olddog.co.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; spring@ietf.org; spring-chairs@ietf.o= rg; draft-ietf-spring-segment-routing-mpls.authors@ietf.org; Shraddha Hegde <= shraddha@juniper.net> > Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 > =20 >=20 > Ahmed, >=20 > Apologies for a delayed response. >=20 > I fully agree that advertising the same prefix SID as the Node SID by two d= ifferent nodes in the SR domain is =E2=80=9Ca clear violation of the SR arch= itecture RFC (8402)=E2=80=9D. >=20 > But I do not think that the SR-MPLS draft can silently ignore this violati= on just because it =E2=80=9Cis not an incoming label collision=E2=80=9D. >=20 > The same applies to the controversy in advertising at the same prefix as A= nycast by some nodes but not as Anycast (or even as a Node SID) by some othe= r nodes. >=20 > Your reference to these being just control plane issues and therefore not r= elated to SR-MPLS is not valid - because the drafts dealing with the SR cont= rol plane to which you refer in this draft are strictly MPLS-oriented: they d= efine how to advertise SID labels or indices that are translated into SID la= bels, and neither of these mechanisms is relevant fore SRV6 IMHO. (I do not h= ave to remind you that a draft that defines SRV6 extensions for ISIS exists,= and deals with other issues). >=20 > My 2c, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 >=20 > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]=20 > Sent: Sunday, October 28, 2018 1:01 AM > To: Shraddha Hegde ; Alexander Vainshtein > Cc: rtg-dir@ietf.org; 'mpls@ietf.org' ; 'adrian@olddog.co.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; spring@ietf.org; spring-chairs@ietf.o= rg; draft-ietf-spring-segment-routing-mpls.authors@ietf.org > Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 > =20 >=20 > Thanks for the comments >=20 > 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-S= ID value with "N" flag is not an incoming label collision because the label i= s associated with the same FEC, which is the prefix.=20 >=20 > Hence handling such violation is not an SR-MPLS problem because there is n= o incoming label collision and hence it it is outside the scope of this draf= t >=20 > =20 >=20 > The second issue is which SID to choose for an SR-policy (be it a policy f= or TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a contr= ol layer functionality and is not specific to SR-MPLS. Hence it is outside t= he scope of this draft >=20 > =20 >=20 > The third issue is the case where an anycast prefix is advertised with a p= refix-SID sub-TLV by some (but not all) of the nodes that advertise that pre= fix. Again this is not an incoming label collision because the label is asso= ciated with a single FEC, which is the anycast prefix. >=20 > =20 >=20 > On 7/19/18 8:30 PM, Shraddha Hegde wrote: >=20 > Hi Ahmed, >=20 > =20 >=20 > The Node-SIDs are expected to be unique to a node. >=20 > =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 > =20 >=20 > If two different nodes advertise same Node-SID, >=20 > For Example Node A and B both advertise prefix 1.1.1.1 and associ= ate a SID 1000 with N bit set. >=20 > There is an anomaly here and IMO, this draft should address how to handle t= his anomaly and whether TI-LFA and other >=20 > Applications can use this SID as a Node-SID. >=20 > Another slight variation of this case is a scenario where A and B both adv= ertise a prefix 1.1.1.1 and A assigns a Node-Sid >=20 > Of 1000 and B does not assign any SID. >=20 > =20 >=20 > Rgds >=20 > Shraddha >=20 > =20 >=20 > From: Alexander Vainshtein =20 > Sent: Thursday, July 19, 2018 10:05 PM > To: Ahmed Bashandy > Cc: rtg-dir@ietf.org; 'mpls@ietf.org' ; 'adrian@olddog.co.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; 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-1= 3 > =20 >=20 > Ahmed hi! >=20 > Lots of thanks for your response. >=20 > Of course Node SIDs are not different from any other Prefix SIDs when it c= omes to the MPLS forwarding plane. >=20 > But, IMHO, strictly speaking, this is correct for any other SID as well. >=20 > You seem to ignore the difference between SR-MPLS and SRv6 with regard to t= he life span of prefix SIDs in general and Node SIDs in particular. =46rom m= y POV this difference should be discussed in the draft. >=20 > So it seems that we can only =E2=80=9Cagree to disagree=E2=80=9D on the ne= ed to say something specific about Node SIDs in the draft, and let the WG to= decide what to do about it. >=20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 >=20 > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]=20 > Sent: Thursday, July 19, 2018 7:13 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; 'mpls@ietf.org' ; 'adrian@olddog.co.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; shraddha@juniper.net; spring@ietf.org= ; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@iet= f.org > Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 > =20 >=20 > Thanks for the reply >=20 > See inline >=20 > Ahmed >=20 > =20 >=20 > On 7/12/18 12:22 AM, Alexander Vainshtein wrote: >=20 > Ahmed and all, >=20 > I would like to expand on my comments (and your responses) about the role o= f Node SIDs in SR-MPLS. >=20 > I would like to bring your attention two points: >=20 > 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 co= nfigure the node to use such a prefix as Node SID and to assign to it a spe= cific index that is unique in the SR domain. =46rom my POV, this difference a= lone would qualify Node SIDs as a topic to be discussed in the MPLS-SR Archi= tecture draft. > #Ahmed: I disagree with your POV. =46rom the forwarding plane perspective i= t does not make any difference whether a the label at the top of an MPLS pac= ket (representing the prefix-SID) identifies a node or not. So from the SR-m= pls 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 nee= d to handle a node-SID different from a prefix SID, it would be great to poi= nt it out >=20 >=20 > 2. In addition, quite a few constructs associated with SR-MPLS implic= itly assume that each node in the SR-MPLS domain is assigned with at least o= ne Node SID. One example can be found in the TI-LFA draft. This draft says i= n Section 4.2: > =20 >=20 > 4.2. The repair node is a PQ node > =20 > =20 > 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, a= nd therefore, to the best of my understanding, =E2=80=9Ca single node segme= nt to the repair node=E2=80=9D can be only the Node SID of the repair node. S= ince repair nodes are computed dynamically, this entire scheme depends on al= l 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) i= n an SR-policy is a control plane behavior, irrespective of reason such poli= cy 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 a= re handled in separate drafts. So just like the response to your previous co= mment, from forwarding plane perspective it does not make any difference whe= ther the label at the top of an MPLS packet identifies a single or multiple n= odes.=20 >=20 >=20 > . > =20 > Hopefully these notes clarify my position on the subject. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 >=20 > From: Alexander Vainshtein=20 > Sent: Wednesday, July 11, 2018 12:02 PM > To: Ahmed Bashandy > Cc: rtg-dir@ietf.org; 'mpls@ietf.org' ; 'adrian@olddog.co.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; shraddha@juniper.net; spring@ietf.org= ; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@iet= f.org > Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 > =20 >=20 > Ahmed, and all, >=20 > Lots of thanks for a detailed response to my comments. >=20 > Please see inline below my position on each of them. >=20 > =20 >=20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 >=20 > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]=20 > 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.u= k' ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.co= m) ; shraddha@juniper.net; spring@ietf.org= > Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-mpls-1= 3 > =20 >=20 > Thanks for thorough (and VERY clear) the review >=20 > See inline #Ahmed >=20 > =20 >=20 > Ahmed >=20 > =20 >=20 > =20 >=20 > On 6/15/18 11:08 PM, Alexander Vainshtein wrote: >=20 > Re-sending to correct SPRING WG list. >=20 > Sincere apologies for the delay caused by a typo. >=20 > Thumb typed by Sasha Vainshtein >=20 > =20 >=20 > 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-1= 3 >=20 > =20 >=20 > Explicitly adding Shraddha who is the shepherd of this draft. >=20 > =20 >=20 > Regards, >=20 > Sasha >=20 > =20 >=20 > Office: +972-39266302 >=20 > Cell: +972-549266302 >=20 > Email: Alexander.Vainshtein@ecitele.com >=20 > =20 >=20 > From: Alexander Vainshtein=20 > 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-13 >=20 > =20 >=20 > =20 >=20 > Hello, >=20 > I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D r= eview of this draft: https://datatracker.ietf.org/doc/draft-ietf-spring-segm= ent-routing-mpls/ >=20 > =20 >=20 > The routing directorate will, on request from the working group chair, per= form an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for= publication to the IESG. The early review can be performed at any time duri= ng the draft=E2=80=99s lifetime as a working group document. The purpose of t= he early review depends on the stage that the document has reached. As this d= ocument is currently in the WG Last call, my focus for the review was to det= ermine whether the document is ready to be published. Please consider my com= ments along with the other working group last call comments. >=20 > =20 >=20 > For more information about the Routing Directorate, please see =E2=80=8Bht= tp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > =20 >=20 > Document: draft-ietf-spring-segment-routing-mpls-13 >=20 > Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein (alexander.vainsh= tein@ecitele.com) >=20 > Review Date: 08-Jun-18 >=20 > Intended Status: Proposed Standard. >=20 > =20 >=20 > Summary: >=20 > =20 >=20 > I have some minor concerns about this document that I think should be reso= lved before it is submitted to the IESG. >=20 > =20 >=20 > Comments: >=20 > =20 >=20 > I consider this draft as an important companion document to the Segment R= outing Architecture draft that, ideally, should augment definitions of the S= egment Routing (SR) notions and constructs given there with details specific= for the SR instantiation that uses the MPLS data plane (SR-MPLS). Many is= sues raised in my review reflect either gaps that should be, but have not be= en, closed, or inconsistencies between the two drafts. >=20 > =20 >=20 > =20 >=20 > Since RFC 8287 is already published as a Standards Track RFC, I expect suc= h augmentation to be backward compatible with this document (or to provide c= lear indications of required updates to this document). And I include the MP= LS WG into distribution list. >=20 > =20 >=20 > This draft was not easy reading for me. In particular, the style of Sectio= n 2.5 that discusses at length and in some detail multiple =E2=80=9Ccorner c= ases=E2=80=9D resulting, presumably, from misconfiguration, before it explai= ns the basic (and relatively simple) =E2=80=9Cnormal=E2=80=9D behavior, look= s problematic to me. >=20 > =20 >=20 > The WG Last Call has been extended by one week. Nevertheless, I am sending= out my comments >=20 > =20 >=20 > Major Issues: None found >=20 > #Ahmed: thanks a lot >=20 > =20 >=20 > Minor Issues: Quite a few but, hopefully, easy to resolve. >=20 > =20 >=20 > 1. Encapsulation of SR-MPLS packets: > a. RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in th= e draft) depend two encapsulations of labeled packets - one for Downstream-a= llocated 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 R= FC was not referred to in the SR-MPLS draft >=20 > [[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: >=20 > 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. > =20 >=20 > This looks to me as being very much multicast in SR, and, unless you want t= o say that it is limited to SRv6, makes my question relevant IMHO. >=20 > b. =46rom 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 maj= or 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-s= tream allocated as you mentioned >=20 > [[Sasha]] This is quite unambiguous and, once added, would resolve my comm= ent in full =E2=80=93 the previous comment notwithstanding. In particular, i= t would imply that even labels representing BSIDs of a SR Replication polici= es will be downstream-allocated. >=20 > =20 >=20 > 2. Label spaces in SR-MPLS: > a. RFC 3031 (referenced by the draft) defines per-platform and per-inte= rface label spaces, and RFC 5331 (not mentioned in the draft) adds context-s= pecific label spaces and context labels. > b. The draft does not say which of these are or are not relevant for SR= -MPLS > c. =46rom my POV: > i. Labels representing all kin= ds of SIDs mentioned in the draft MUST be allocated from the per-platform la= bel space only > ii. At the same time, instantia= tion of Mirror Segment IDs defined in Section 5.1 of the Segment Routing Arc= hitecture draft using MPLS data plane clearly calls for context labels and c= ontext-specific label spaces > d. I expect the draft to provide a clear-cut position on these aspects o= f SR-MPLS. > #Ahmed: I will add a statement to section 2.2 to say that the it is per-pl= atform. 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 tryi= ng to be as specific as possible to the MPLS forwarding plane. General funct= ions attached to SID are described in the segment routing architecture docum= ent or future documents. Furture documents proposing new SR function must be= as specific and clear as possible >=20 > [[Sasha]] Looks OK to me. >=20 > =20 >=20 > 3. SR-MPLS and hierarchical LSPs: > a. SR LSPs that include more than one segment are hierarchical LSPs fro= m the POV of the MPLS data plane. Therefore some (possibly, all) of the mode= ls for handling TTL and TC bits that have been defined in RFC 3443 (not ment= ioned in the draft) should apply to SR-MPLS > b. RFC 8287 (not referenced in the draft) specifically discussed operat= ion of the LSP Traceroute function for SR LSPs in the case when Pipe/Short P= ipe model for TTL handling is used > c. I expect the draft to provide at least some guidelines regarding app= licability of each specific model defined in RFC 3443 (separately for TTL an= d 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 i= t is mentioned in the first sentence in Section 1. So the TTL behavior speci= fied in rfc3443 is already implied and there is no need to re-mention it her= e 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 >=20 > [[Sasha]] Unfortunately I do not think this is good enough. Let me ask a s= pecific question reflecting my concerns: >=20 > The head-end node sends SR-MPLS packets across a path defined by an ordere= d 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 e= ach 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 fie= lds in each of the LSEs following the top one? This clearly depends on the m= odel (Uniform vs. Pipe/Short Pipe) implemented in each node that that perfor= ms Next operation on the packet along the path =E2=80=93 but the head-end no= de usually is not aware of that. >=20 > RFC 8287 is relevant as an example here IMHO because it recommends the fol= lowing setting of TTL in Traceroute packets: >=20 > - Set the TTL of all the labels above one that represents the seg= ment you are currently tracing to maximum > - Set the TTL of the label one that represents the segment you ar= e currently tracing to the desired value (to be incremented until end of seg= ment is reached > - Set the TTL of all the labels below one that represents the seg= ment you are currently tracing to 0. > I expect the draft to provide some recommendations for traffic (non-OAM) p= ackets as well. >=20 > =20 >=20 > 4. Inferring network layer protocol in SR-MPLS: > a. I wonder if the draft could provide any details on the situation whe= n a label that represents some kind of SID is the bottom-of-stack label to b= e popped by the egress LER > #ahmed: This is part of the "Next" function. It is described in detail in t= his document. >=20 > [[Sasha]] NEXT function is mentioned in several places in the document. Ca= n you please point to the specific text that is relevant for my question? >=20 > =20 >=20 > b. For the reference, RFC 3032 says that =E2=80=9Cthe identity of the n= etwork layer protocol must be inferable from the value of the label which i= s popped from the bottom of the stack, possibly along with the contents of= the network layer header itself=E2=80=9D > c. =46rom my POV the following scenario indicates relevance of this exp= ectation for SR-MPLS: > i. IS-IS is used for distribut= ing both IPv4 and IPv6 reachability in a given domain > ii. An IS-IS adjacency over som= e dual-stack link is established, and a single Adj-SID for this adjacency is= advertised > iii. The node that has assigned a= nd advertised this Adj-SID receives a labeled packet with the label represen= ting this Adj-SID being both the top and bottom-of-stack label > iv. The implementers must be giv= en 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 a= nd IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draf= t-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 th= e prefix advertisement and hence implies the identity of the protocol undern= eath the bottom most label. For any other "function" attached to a SID, it i= s part of the specification of this function to describe what happens when t= he SID is represented by a label in the MPLS forwarding plane and this label= is the bottom most label >=20 > [[Sasha]] OK, got it. This issue is resolved. >=20 > =20 >=20 > 5. Resolution of Conflicts: Are the > a. Are the conflict resolution procedures listed in section 2.5 mandato= ry to implement? > b. If they are mandatory to implement, are they also mandatory to deplo= y, or can the operators simply treat any detected conflict as requiring huma= n 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. =20 >=20 > [[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 conf= lict resolution rules (if they are implemented). >=20 > c. For the reference, the IETF capitalized MUST appears just in a few p= laces in Section 2.5, and each appearance has very narrow context: > i. For MCCs where the "Topolog= y" and/or "Algorithm" fields are not defined, the numerical value of zero MU= ST 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 se= lect 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 deterministi= c. > iii. An implementation of explic= it SID assignment MUST guarantee collision freeness on the same router > =46rom my POV, it is not possible to infer the answer to my question from t= hese statements. Some explicit statement is required. >=20 > #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 yo= u questions in items (a) and (b) >=20 > 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 values are n= ot supposed to appear in any IANA registries (because the draft does not req= uest any IANA actions). Can you please clarify what is so special about thes= e 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 >=20 > [[Sasha]] OK. >=20 > =20 >=20 > e. I also doubt that comparison of FECs that represent IPv4 and IPv6 pr= efix 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 a= n IPv4 prefix is different from the IPv4 prefix. The specifications of SR ex= tensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes separ= ately, including the IPV6 prefixes with embedded IPv4 ones. Besides not all I= Pv6 prefixes embed IPv4 prefix in them. Hence the distinction between IPv4 a= nd IPv6 prefixes is quite clear >=20 > [[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. Quoting f= rom RFC 4291: >=20 > 2.5.5.2. IPv4-Mapped IPv6 Address > =20 > =20 > 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. > =20 >=20 > =46rom 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 map= ped 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 ad= dresses defined in RFC 4798. However, the comparison rules you have defined w= ill treat them as two different prefixes. I wonder if these rules, in the c= ase 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 servic= e to its egress PE? >=20 > =20 >=20 > f. Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure al= l SID types defined in the Segment Routing Architecture draft can be unambig= uously mapped to one of these types. Problematic examples include at least t= he following: > i. Parallel Adjacency SID > ii. Mirror SID > Explicit mapping of SID types to SR-MPLS FEC types would be most useful IM= O. If some SID types cannot be mapped to SR-MPLS FECs, this must be explicit= ly stated in the draft. >=20 > #Ahmed:=20 > Parallel adjacency SID are handled in the type "(next-hop, outgoing interf= ace)" > [[Sasha]] OK >=20 > Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR a= rchitecture draft (draft-ietf-spring-segment-routing-15). Also as described i= n Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the eq= uivalent in the OSPFv2 and OSPFv3 draft), a binding SID is identified by a p= refix. Hence it is covered by the type "(Prefix, Routing Instance, Topology,= Algorithm)" > [[Sasha]] I respectfully disagree. There is definitely no mention of Algor= ithm in the definition of the Mirror SID. > =20 >=20 > 6. Node SIDs in SR-MPLS: > a. Node SIDs are explicitly defined and discussed in the Segment Routin= g Architecture draft but are not mentioned even once in this draft > b. AFAIK, the common implementation practice today includes assignment o= f 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 i= nstance, topology, algorithm} in SR-MPLS? If not, can the authors explain ex= pected 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 speci= fic about it from the MPLS forwarding plane point of view. Similarly from a s= tandard tracks draft point of view, there is no requirement to assign a SID t= o every prefix just like there is no requirement to bind every prefix to an L= DP label. Common and/or recommended practices or description of deployment s= cenarios are more befitting to BCP or informational drafts. This draft is a s= tandards track draft > [[Sasha]] Well, you=E2=80=99ve just said that conflict resolution rules ar= e RECOMMENDED, and this is quite common in the Standards Track RFCs. >=20 > If a {routing instance, topology, algorithm} is not assigned a SID, then t= his FEC is totally irrelavant to this draft and hence describing how a node t= reats it is totally outside the scope of this draft > [[Sasha]] AFAIK, neither of the SR extension drafts for IGPs mention routi= ng instances that can be associated with the prefix, so I think that your re= ference to it is incorrect. > What=E2=80=99s more I suspect that Node SIDs represent the most used speci= al 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 p= lace IMHO. > =20 >=20 > 7. SRGB Size in SR-MPLS: > a. The draft correctly treats the situation when an index assigned to s= ome 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) t= hat MUST be implemented by all SR-capable nodes > c. I suspect that lack of such a definition could be detrimental to int= eroperability of SR-MPLS solutions. AFAIK, the IETF has been following, for q= uite some time, a policy that some reasonable MUST-to-implement defaults sho= uld be assigned for all configurable parameters exactly in order to prevent t= his. > #Ahmed: This document specifies how the SRGB is used and the behavior of r= outers when a prefix-SID index maps to a label inside and/or outside the SRG= B. The actual size of the SRGB is a task in partitioning the label space, wh= ich is very specific to a particular deployment scenario. So IMO it is outsi= de the scope of a standards track document. Now that SR-MPLS is deployed in m= any places, I expect the community to gain sufficient experience to recommen= d (or not recommend) a particular minimum/maximum size for the SRGB is some f= uture informational or BCP draft/RFC > [[Sasha]] My reading of your response is that minimum size of SRGB is an i= ssue for future study. Can you please just add this to the draft? > =20 >=20 > 8. Algorithms and Prefix SIDs: > a. The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, bu= t 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] ri= ght beside the first time "Algorithm" is mentioned > [[Sasha]] OK > =20 >=20 > b. =46rom my POV, the draft should explicitly state that the default Pr= efix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers. > #Ahmed: The specification of what path calculation method should or must b= e supported is a routing protocol property not a forwarding plane property. I= n fact, the choice of a path calculation method or algorithm is completely o= rthogonal to the routed protocol. Hence mandating the support of a particula= r routing algorithm is beyond the scope of this document. > [[Sasha]] OK > =20 >=20 > c. The Segment Routing Architecture draft states (in section 3.1.3) tha= t =E2=80=9CSupport of multiple algorithms applies to SRv6=E2=80=9D. But neit= her draft states whether multiple algorithms apply to SR-MPLS. Can you pleas= e clarify this point? > #Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-s= pring-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 recei= ved by a node that does not support this algorithm, this packet will be disc= arded. If this is the only type of support for multiple algorithms SR provid= es, it is not very useful IMHO. > =20 >=20 > 9. Routing instances and the context for Prefix-SIDs: > a. The Segment Routing Architecture draft states in Section 3.1 that th= e =E2=80=9Ccontext for an IGP-Prefix segment includes the prefix, topology, a= nd algorithm=E2=80=9D > b. This draft seems to define (in section 2.5) the context for the Pref= ix SID as =E2=80=9CPrefix, Routing Instance, Topology, Algorithm=E2=80=9D wh= ere =E2=80=9Da routing instance is identified by a single incoming label dow= nloader to FIB=E2=80=9D (but the notion of the label downloader to FIB is no= t defined). > c. These two definitions look different to me. > d. At the very least I would expect alignment between the definitions o= f context for the Prefix-SID between the two drafts. Preferably, the definit= ion given in the Segment Routing Architecture draft should be used in both d= rafts. > #Ahmed: The context of the section 2.5 is limited to the resolution of loc= al label collision. The use of "routing instance" in section 2.5 is just the= re for tie-breaking if there is local label collision. > [[Sasha]] I have already mentioned that =E2=80=9Crouting instances=E2=80=9D= 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 t= his. And in any case the difference between two definitions of the context o= f Prefix-SID requires some explanation. >=20 >=20 >=20 > 10. Example of PUSH operation in Section 2.10.1: > a. The first para of this section begins with the sentence =E2=80=9CSup= pose 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"= =E2=80=9D. In the context of SR-MPLS this means (to me) that the incoming pa= cket is a labeled packet and its top label matches the global SID =E2=80=9CS= i=E2=80=9D. > b. However, the example for PUSH operation in the next para of this sec= tion is the case of an (unlabeled) IP packet with the destination address co= vered by the IP prefix for which =E2=80=9CSi=E2=80=9D has been assigned. > c. =46rom my POV: > i. Mapping unlabeled packets t= o SIDs is indeed out of scope of the draft. Therefore an example of a PUSH o= peration that is applied to a labeled packet (with the active SID inferred f= rom the top label in the stack) is preferable. > ii. Valid examples of PUSH ope= ration applied to a labeled incoming packet can be found in Sections 4.2 or 4= .3 of the TI-LFA draft > =20 >=20 > #Ahmed: I do not understand your concern here:) >=20 > [[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? > =20 > Nits: >=20 > 1. I concur with Adrian regarding numerous nits he has reported in his W= G LC Comment. 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 addr= essed all his comments in the latest version. >=20 > 2. In addition, I=E2=80=99d like to report the following nits: > a. Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft) > #Ahmed: Already done in the latest version[[Sasha]] OK >=20 > b. TI-LFA draft is referenced in the text of Section 2.11.1, but there i= s no matching reference in the =E2=80=9CReferences=E2=80=9D section (probabl= y, Informational) > #Ahmed: Already done in the latest version[[Sasha]] OK >=20 > c. =E2=80=9Czero Algorithm=E2=80=9D in Section 2.5 (immediately above S= ection 2.5.1) must be replaced with =E2=80=9Cdefault algorithm=E2=80=9D. Sim= ilarly, =E2=80=9Cnon-zero Algorithm=E2=80=9D should be replaced with =E2=80=9C= non-default algorithm=E2=80=9D > #Ahmed: Will be done in the next version[[Sasha]] OK >=20 > 3. I think that RFC 3443 and RFC 5332 should be listed as Normative ref= erences in this draft while RFC 5331 and RFC 8277 should be listed as Inform= ative references. This would improve the readability of the draft without an= y impact on its advancement. > =20 >=20 > #Ahmed RFC5331 describes upstream label assignment. As you mentioned above= (and I will modify the draft to indicate that) SR-MPLS behavior is similar t= o downstream label assignment. RFC 3443 describes TTL behavior. This is an M= PLS forwarding behavior. As mentioned in the draft, SR-MPLS does not modify a= t the MPLS forwarding behavior > [[Sasha]] Regarding RFC 5331 =E2=80=93 you may skip this reference if you s= tate (as discussed below) that SR-MPLS only allocates labels from the per-pl= atform label space. Regarding RFC 3443 =E2=80=93 I do not think that you can= fully avoid discussion of Uniform and Pipe/Short Pipe models, and therefore= you will need this reference. >=20 >=20 >=20 > Hopefully, these comments will be useful. >=20 > #Ahmed: They are certainly quite useful. Thanks a lot >=20 > =20 >=20 > Regards, >=20 > Sasha >=20 > =20 >=20 > Office: +972-39266302 >=20 > Cell: +972-549266302 >=20 > Email: Alexander.Vainshtein@ecitele.com >=20 > =20 >=20 >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ > =20 >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ > =20 >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ > =20 >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-4969499B-3E82-4EDD-B8BC-F3CD36C54030 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sraddha,

Please do so.
Thanks 


Regards,
Jeff

On Nov 18, 2018, at 2= 0:37, Shraddha Hegde <shraddha@ju= niper.net> wrote:

Hi all,

 

I am preparing the shepherd write-up an= d noticed that the topic in below e-mail thread is an

Open item. My personal opinion is to ad= d a new section to this draft to address below cases

> more than one node advertis= ing the same IPv4/6 PREFIX and both have the same prefix-SID value with "N" f= lag

> where an anycast prefix is a= dvertised with a prefix-SID sub-TLV by some (but not all) of the nodes that a= dvertise that prefix.

 

This draft is= addressing incoming label collision and resulting behavior and also describ= es other aspects like different SIDs for same prefix so it seems reasonable to add above two cases to this draft.

WG members, i= f you have an opinion, pls respond on the list.

 

Rgds

Shraddha=

From: Alexander Vainshtein &= lt;Alexander.Vainshtein@= ecitele.com>
Sent: Sunday, November 4, 2018 9:37 PM
To: Ahmed Bashandy <ab= ashandy.ietf@gmail.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; 'adrian= @olddog.co.uk' <adrian@olddog.= co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; spring@ietf.org; spring-chairs@ietf.org; draft-ietf-spring-segment-routing= -mpls.authors@ietf.org; Shraddha Hegde <shraddha@juniper= .net>
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-m= pls-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 =E2=80=9Ca clear violation of the SR architecture RFC (8402)=E2=80=9D.=

But I do not t= hink that the SR-MPLS draft can silently ignore this violation just because i= t =E2=80=9Cis not an incoming label collision=E2=80=9D.=

The same appl= ies to the controversy in advertising at the same prefix as Anycast by some n= odes but not as Anycast (or even as a Node SID) by some other nodes.

Your referenc= e to these being just control plane issues and therefore not related to SR-M= PLS is not valid - because the drafts dealing with the SR control plane to which you refer in this draft are strictly MPL= S-oriented: they define how to advertise SID labels or indices that are translated into <= b>SID labels, and neither of these mechanisms is relevant fore SR= V6 IMHO. (I do not have to remind you that a draft that defines SRV6 extensions for ISIS exists, and deals with other i= ssues).

My 2c,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302<= /span>

Email:   Alexander.Vainsht= ein@ecitele.com

 

 

Thanks for the comments

While it is a clear violation of the SR architecture RFC (8402), more tha= n 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 n= o incoming label collision and hence it it is outside the scope of this draf= t

 

The second issue is which SID to choose for an SR-policy (be it a policy f= or TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a contr= ol layer functionality and is not specific to SR-MPLS. Hence it is outside t= he scope of this draft

 

The third issue is the case where an anycast prefix is advertised with a p= refix-SID sub-TLV by some (but not all) of the nodes that advertise that pre= fix. Again this is not an incoming label collision because the label is asso= ciated with a single FEC, which is the anycast prefix.

 

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

Hi Ahmed,

 

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

=E2=80=9C

   An IGP Node-S= ID 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 N= ode-SID,

  &= nbsp;      For Example Node A and B both advertise p= refix 1.1.1.1 and associate a  SID 1000 with N bit set.

There is an a= nomaly here and IMO, this draft should address how to handle this anomaly an= d whether TI-LFA and other

Applications c= an use this SID as a Node-SID.

Another sligh= t 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.Vai= nshtein@ecitele.com>
Sent: Thursday, July 19, 2018 10:05 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.o= rg' <mpls@ietf.org>; 'adrian@olddog.= co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hard= wick@metaswitch.com>; Shraddha Hegde <shraddha@juniper.n= et>; 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-m= pls-13

 

Ahmed hi!

Lots of thank= s for your response.

Of course Nod= e SIDs are not different from any other Prefix SIDs when it comes to the MPL= S forwarding plane.

But, IMHO, st= rictly speaking, this is correct for any other SID as well.

You seem to i= gnore the difference between SR-MPLS and SRv6 with regard to the life span o= f prefix SIDs in general and Node SIDs in particular. =46rom my POV this difference should be discussed in the draft.

So it seems t= hat we can only =E2=80=9Cagree to disagree=E2=80=9D on the need to say somet= hing 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.Vainsht= ein@ecitele.com

 

 

Thanks for the reply

See inline

Ahmed

 

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

Ahmed and all= ,

I would like t= o expand on my comments (and your responses) about the role of Node SIDs in S= R-MPLS.

I would like t= o bring your attention two points:

1.     &= nbsp; Node SIDs (and, in= general, Prefix SIDs) in MPLS-SR are different from the same in SRv6 becaus= e 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 ex= plicitly configure the node to use such a prefix as  Node SID and to as= sign to it a specific index that is unique in the SR domain. =46rom my POV, t= his difference alone would qualify Node SIDs as a topic to be discussed in the MPLS-SR Architecture draft.

=

#Ahmed: I disagree wit= h your POV. =46rom the forwarding plane perspective it does not make any dif= ference whether a the label at the top of an MPLS packet (representing the prefix-SID) identifies a node or not. So from the S= R-mpls forwarding point of view there is no difference between a prefix-SID a= nd a node-SID. If there is any place in the SR-mpls draft where there is a n= eed 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 w= ith SR-MPLS implicitly assume that each node in the SR-MPLS domain is assign= ed 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

 
 
   Whe=
n the repair node is in P(S,X), the repair list is made of a
   sin=
gle node segment to the repair node.

In the scope of this section, the repair node is not adjacent t= o the PLR, and therefore, to the best of my understanding,  =E2=80=9Ca s= ingle node segment t= o the repair node=E2=80=9D can be only the Node SID of the repair node. Sinc= e repair nodes are computed dynamically, this entire scheme depends on all n= odes in the MPLS=3DSR domain  having at least one Node SID each

#Ahmed: The choice of t= he SID to identify an intermediate or exit node(s) in an SR-policy is a cont= rol plane behavior, irrespective of reason such policy is created (be it ti-lfa explicit path, uloop avoidance explicit pat= h, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop avoid= ance are handled in separate drafts. So just like the response to your previ= ous comment, from forwarding plane perspective it does not make any difference whether the label at the t= op 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.Vainsht= ein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, July 11, 2018 12:02 PM
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
Cc: rtg-dir@ietf.org; 'mpls@ietf.o= rg' <mpls@ietf.org>; 'adrian@olddog.= co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hard= wick@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-m= pls-13

 

Ahmed, and al= l,

Lots of thank= s for a detailed response to my comments.

Please see inline below my posi= tion on each of them.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302=

Email:   Alexander.Vainsht= ein@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>; spring-chairs@ietf.org; draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Cc: rtg-dir@ietf.org; 'mpls@ietf.o= rg' <mpls@ietf.org>; 'adrian@olddog.= co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) <jonathan.hardw= ick@metaswitch.com>; shraddha@juniper.net; spring@ietf.org
Subject: Re: RtgDir Early review: draft-ietf-spring-segment-routing-m= pls-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 Va= inshtein

 

From: Alexander Vainshtein
Sent: Sunday, June 10, 2018 10:43:52 AM
To: spring-chairs@ietf.org<= /a>; 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 Ha= rdwick (Jonathan.Hardwic= k@metaswitch.com); shraddha@juniper.net
Subject: RE: RtgDir Early review: draft-ietf-spring-segment-routing-m= pls-13

 

Explicitly adding Shrad= dha  who is the shepherd of this draft.

 

Regards,

Sasha=

 

Office: +972-39266302

Cell:   =    +972-549266302

Email:   Alexander.Vainshtein@= ecitele.com

 

 

 

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 wor= king group chair, perform an =E2=80=9Cearly=E2=80=9D review of a draft befor= e 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 worki= ng 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 a= long with the other working group last call comments.

 

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

 

Document: draft-ietf-spring-segment-rou= ting-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 definit= ions of the Segment Routing (SR) notions and constructs given there with det= ails specific for the SR instantiation that uses  the MPLS data plane (SR-MPLS).  Many issues raised in my re= view reflect either gaps that should be, but have not been, closed, or incon= sistencies between the two drafts.

 

 

Since RFC 8287 is already published as a Standards Track RFC, I expect suc= h augmentation to be backward compatible with this document (or to provide c= lear 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 multi= ple =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.

 

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

 

Major Issues: None found

#Ahmed: thanks a lot

 

Minor Issues: Quite a few but, hopefull= y, easy to resolve.

 

1.&nbs= p;   Encapsulation of SR-MPLS packets:

a.    RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned i= n the draft) depend two encapsulations of labeled packets - one for D= ownstream-allocated labels and another for Upstream-allocated ones.

#Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of dr= aft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. He= nce the RFC was not referred to in the SR-MPLS draft

[[Sasha]] I would be satisfied wi= th 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 b= e used for packet replication.  A

   candidate path could comprise m= ultiple SID-Lists; one for each

   replication path.  In suc= h a scenario, packets are actually

   replicated through each SID Li= st of the SR Policy to realize a point-

   to-multipoint service delivery= .

 

This looks to me as being very mu= ch multicast in SR, and, unless you want to say that it is limited to SRv6, m= akes my question relevant IMHO.

b.    =46rom 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 i= s down-stream allocated as you mentioned

[[Sasha]] This is quite unambiguo= us and, once added, would resolve my comment in full =E2=80=93 the previous c= omment notwithstanding. In particular, it would imply that even labels representing BSIDs of a SR Replication policies will be do= wnstream-allocated.

 

2.&nbs= p;   Label spaces in SR-MPLS:

a.    RFC 3031 (referenced by the draft) defines per-platform and per-inter= face label spaces, and RFC 5331 (not mentioned in the draft) a= dds 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.    =46rom my POV:

            = ;            &nb= sp;            &= nbsp;   i.    Labels representing all kinds of SIDs mentioned in the draft MUST be a= llocated from the per-platform label space only

            = ;            &nb= sp;            &= nbsp;  ii.    At the same time, instantiation of Mirror Segment IDs defined in Sect= ion 5.1 of the Segment Routing Architecture draft using MPLS data plane clea= rly calls for context labels and context-specific label spaces

d.    I expect the draft to provide a clear-cut position on these aspects o= f SR-MPLS.

#Ahmed: I will add a statement to section 2.2 to say that the it i= s 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 i= s not specific to the MPLS forwarding plane. Hence there is no need to re-me= ntion it here because this document is trying to be as specific as possible t= o the MPLS forwarding plane. General functions attached to SID are described in the segment routing arch= itecture document or future documents. Furture documents proposing new SR fu= nction must be as specific and clear as possible

[[Sasha]] Looks OK to me.<= /i>

 

3.&nbs= p;   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 model= s for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned in the draft) should a= pply to SR-MPLS

b.    RFC 8287 (not referenced in the draft) specifically dis= cussed 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 appl= icability 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 forwardi= ng plane (and hence this draft) does not modify the MPLS forwarding plan beh= avior as it is mentioned in the first sentence in Section 1. So the TTL behavior specified in rfc3443 is already implied a= nd there is no need to re-mention it here just like all aspects of MPLS forw= arding. RFC8287 is OAM-specific.  SR-OAM is handled in a separate docum= ent so is outside the scope of this draft

[[Sasha]] Unfortunately I do not t= hink this is good enough. Let me ask a specific question reflecting my conce= rns:

The head-end node sends SR-MPLS p= ackets across a path defined by an ordered set of SIDs with more than one SI= D in the list. Each SID is represented by a label stack entry (LSE) in the MPLS label stack, and the label field in eac= h LSE is the label that matches the corresponding SID. However, each LSE als= o includes the TTL and TC fields. How does the head-end node set these field= s 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 a= long the path =E2=80=93 but the head-end node usually is not aware of that.

RFC 8287 is relevant as an exampl= e here IMHO because it recommends the following setting of TTL in Traceroute= packets:

-      &nb= sp;   Set the TTL o= f all the labels above one that represents the segment you are currently tra= cing to maximum

-      &nb= sp;   Set the TTL o= f the label one that represents the segment you are currently tracing to the= desired value (to be incremented until end of segment is reached=

-      &nb= sp;   Set the TTL o= f all the labels below one that represents the segment you are currently tra= cing to 0.

I expect the draft to provide some recommendations= for traffic (non-OAM) packets as well.

 

4.&nbs= p;   Inferring network layer protocol in SR-MPLS:<= /o:p>

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 d= etail in this document.

[[Sasha]] NEXT function is mentio= ned in several places in the document. Can you please point to the specific t= ext that is relevant for my question?

 

b.    For the reference, RFC 3032 says that =E2=80=9Cthe identity of the ne= twork layer protocol  must be inferable from the value of the label whi= ch is popped from  the bottom of the stack, possibly along with the contents  of the network layer header itself=E2=80=9D<= o:p>

c.    =46rom my POV the following scenario indicates relevance of this expe= ctation for SR-MPLS:

            = ;            &nb= sp;            &= nbsp;   i.    IS-IS is used for distributing both IPv4 and IPv6 reachability in a g= iven domain

            = ;            &nb= sp;            &= nbsp;  ii.    An IS-IS adjacency over some dual-stack link is established, and a si= ngle Adj-SID for this adjacency is advertised

            = ;            &nb= sp;            &= nbsp; iii.    The node that has assigned and advertised this Adj-SID receives a lab= eled packet with the label representing this Adj-SID being both the top and b= ottom-of-stack label

            = ;            &nb= sp;            &= nbsp; iv.    The implementers must be given unambiguous instructions for forwardin= g 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-OSFv= 3 drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 n= ext-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section 2.2.1 in draft-ietf-isis-segment-routing-extensi= ons-18) to specify whether the adj-SID is for IPv4 and IPv6. Similarly, the S= R-ISIS draft attaches a prefix-SID to the prefix advertisement and hence imp= lies the identity of the protocol underneath the bottom most label. For any other "function" attached to a SI= D, 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 thi= s label is the bottom most label

[[Sasha]] OK, got it. This issue i= s resolved.

 

5.&nbs= p;   Resolution of Conflicts: Are the

a.    Are the conflict resolution procedures listed in section 2.5 mandator= y 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 t= he first 3 bullets in Section 2.5 to say that it is recommeded.  

[[Sasha]] OK. However, it would b= e 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 probabl= y requires a configuration knob for enabling conflict resolution rules (if they are im= plemented).

c.    For the reference, the IETF capitalized MUST appears just in a few pl= aces in Section 2.5, and each appearance has very narrow context:

            = ;            &nb= sp;            &= nbsp;   i.    For MCCs where the "Topology" and/or "Algorithm" fields are not defin= ed, the numerical value of zero MUST be used for these two fields

            = ;            &nb= sp;            &= nbsp;  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 orde= r in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic.

            = ;            &nb= sp;            &= nbsp; iii.    An implementation of explicit SID assignment MUST guarantee collision= freeness on the same router

=46rom my POV, it is not p= ossible to infer the answer to my question from these statements. Some expli= cit statement is required.

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

d.    The tie-breaking rules in section 2.5.1 include some specific values f= or encoding FEC types and address families =E2=80=93 but these values are no= t supposed to appear in any IANA registries (because the draft does not request any IANA actions). Can you please clarify what i= s so special about these values?

#Ahmed: There is no significance to the values but there is a sig= nificance 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 pre= fix SIDs makes much sense (for conflict resolution or else), because, among o= ther 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 prefixe= s with embedded IPv4 ones. Besides not all IPv6 prefixes embed IPv4 prefix i= n them. Hence the distinction between IPv4 and IPv6 prefixes is quite clear

[[Sasha]] My concern was mainly a= bout IPv4-mapped IPv6 addresses. Quoting from RFC 4291:<= /o:p>

2.5.5.2.  IPv4-Mapped IPv6 Address

 

 

   A second type of IPv6 address t= hat holds an embedded IPv4 address is

   defined.  This address type is used to represent the addresses of

&nbs= p;  IPv4 nodes as IPv6 addresses.

 <= /p>

=46rom my POV this means that a /= 128 prefix associated with an IPv4-mapped IPv6 address and a /32 prefix asso= ciated with the IPv4 address that was mapped to this IPv6 address represent the same entity. This understanding fully ma= tches usage of IPv4-mapped IPv6 addresses as BGP Next Hops of VPN-IPv6 addre= sses defined in RFC 4798. However, the comparison rules you have defined wil= l treat them as two different prefixes.  I wonder if these rules, in the case of a conflict, could r= esult in preferring the IPv6 prefix to an IPv4 one and therefore loosing MPL= S 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 S= ID types defined in the Segment Routing Architecture draft can be unambiguou= sly mapped to one of these types. Problematic examples include at least the following:

            = ;            &nb= sp;            &= nbsp;   i.    Parallel Adjacency SID

            = ;            &nb= sp;            &= nbsp;  ii.    Mirror SID

Explicit mapping of SID t= ypes 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 interfac= e)"

[[Sasha]] OK


Mirror SID is a type of binding-SID as mentioned in Section 5.1 in the SR ar= chitecture draft (draft-ietf-spring-segment-routing-15). Also as described i= n Section 2.4 draft-ietf-isis-segment-routing-extensions-18 (also see the eq= uivalent 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 n= o mention of Algorithm in the definition of the Mirror SID.

 

6.&nbs= p;   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 o= f 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 i= nstance, topology, algorithm} in SR-MPLS? If not, can the authors explain ex= pected 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 fro= m the MPLS forwarding plane point of view. Similarly from a standard tracks d= raft point of view, there is no requirement to assign a SID to every prefix just like there is no requirement to bind e= very prefix to an LDP label. Common and/or recommended practices or descript= ion of deployment scenarios are more befitting to BCP or informational draft= s. This draft is a standards track draft

[[Sasha]] Well, you=E2=80=99ve just said that conflict r= esolution rules are RECOMMENDED, and this is quite common in the Standards T= rack RFCs.


If a {routing instance, topology, algorithm} is not assigned a SID, then thi= s FEC is totally irrelavant to this draft and hence describing how a node tr= eats it is totally outside the scope of this draft

[[Sasha]] AFAIK, neither of the SR extension drafts for I= GPs mention routing instances that can be associated with the prefix, so I t= hink that your reference to it is incorrect.

What=E2=80=99s more I suspect that Node SIDs represent t= he most used special case of Prefix SIDs with Anycast SIDs being quite behin= d.  Therefore some recommendation pertaining to the usage of Node SIDs would be very much in place IMHO.

 

7.&nbs= p;   SRGB Size in SR-MPLS:

a.    The draft correctly treats the situation when an index assigned to so= me 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) t= hat MUST be implemented by all SR-capable nodes

c.    I suspect that lack of such a definition could be detrimental to inte= roperability of SR-MPLS solutions. AFAIK, the IETF has been following, for q= uite some time, a policy that some reasonable MUST-to-implement defaults should be assigned for all configurable paramete= rs exactly in order to prevent this.

#Ahmed: This d= ocument specifies how the SRGB is used and the behavior of routers when a pr= efix-SID index maps to a label inside and/or outside the SRGB. The actual si= ze 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 e= xperience to recommend (or not recommend) a particular minimum/maximum size for the SRGB is some future in= formational or BCP draft/RFC

[[Sasha]] My reading of your response is that minimum si= ze of SRGB is an issue for future study. Can you please just add this to the= draft?

 

8.&nbs= p;   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 s= ection 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 f= irst time "Algorithm" is mentioned

[[Sasha]] OK

 

b.    =46rom my POV, the draft should explicitly state that the default Pre= fix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.

#Ahmed: The sp= ecification of what path calculation method should or must be supported is a= routing protocol property not a forwarding plane property. In fact, the cho= ice of a path calculation method or algorithm is completely orthogonal to the routed protocol. Hence mandating the suppor= t 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= =E2=80=9CSupport of multiple algorithms applies to SRv6=E2=80=9D. But neith= er draft states whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?

#Ahmed: The la= st paragraph of Section 3.1.2 titled SR-MPLS in draft-ietf-spring-segment-ro= uting-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 tha= t if a packet with the active Prefix-SID that is associated with a specific a= lgorithm is received by a node that does not support this algorithm, this packet will be discarded. If this is the o= nly type of support for multiple algorithms SR provides, it is not very usef= ul IMHO.

 

9.&nbs= p;   Routing instances and the context for Prefix-SIDs:

a.    The Segment Routing Architecture draft states in Section 3.1 that the= =E2=80=9Ccontext for an IGP-Prefix segment includes the prefix, topology, a= nd algorithm=E2=80=9D

b.    This draft seems to define (in section 2.5) the context for the Prefi= x SID as =E2=80=9CPrefix, Routing Instance, Topology, Algorithm=E2=80=9D whe= re =E2=80=9Da routing instance is identified by a single incoming label downloader to FIB=E2=80=9D (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 definiti= on given in the Segment Routing Architecture draft should be used in both drafts.

#Ahmed: The co= ntext of the section 2.5 is limited to the resolution of local label collisi= on. The use of "routing instance" in section 2.5 is just there for tie-break= ing if there is local label collision.

[[Sasha]] I have already mentioned that =E2=80=9Crouting= instances=E2=80=9D are not defined in any the drafts dealing with SR Extens= ions for IGPs. So I do not understand how the conflict resolution procedure is supposed to use this. And in any case the difference between t= wo definitions of the context of Prefix-SID requires some explanation.



10. Example of PUSH operation in Section 2.10.1:<= /o:p>

a.    The first para of this section begins with the sentence =E2=80=9CSupp= ose an MCC on a router "R0" determines that PUSH or CONTINUE   ope= ration is to be applied to an incoming packet whose active SID is the global SID "Si"=E2=80=9D. In the context of SR-MPLS this means (= to me) that the incoming packet is a labeled packet and its top label matche= s the global SID =E2=80=9CSi=E2=80=9D.

b.    However, the example for PUSH operation in the next para of this sect= ion is the case of an (unlabeled) IP packet with the destination address cov= ered by the IP prefix for which =E2=80=9CSi=E2=80=9D has been assigned.

c.    =46rom my POV:

            = ;            &nb= sp;            &= nbsp;   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 pack= et (with the active SID inferred from the top label in the stack) is preferable.

            = ;            &nb= sp;            &= nbsp;  ii.    Valid examples of  PUSH operation applied to a labeled incoming p= acket can be found in Sections 4.2 or 4.3 of the TI-LFA draft

 

#Ahmed: I do not under= stand 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 cur= rent example?

 <= o:p>

Nits:

1.&nbs= p;   I concur with Adrian regarding numerous nits he has reported in his WG LC Comment. I would like to thank Adrian for an excellent review= that have saved me lots of hard work.

#Ahmed: I also agree t= hat Adrian's review is exceptional. I believe I addressed all his comments i= n the latest version.

2.&nbs= p;   In addition, I=E2=80=99d like to report the following nits:

a.    Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA draft)

#Ahmed: Already done i= n the latest version[[Sasha]] OK

b.    TI-LFA draft is referenced in the text of Section 2.11.1, but there i= s no matching reference in the =E2=80=9CReferences=E2=80=9D section (probabl= y, Informational)

#Ahmed: Already done i= n the latest version[[Sasha]] OK

c.    =E2=80=9Czero Algorithm=E2=80=9D in Section 2.5 (immediately above Se= ction 2.5.1) must be replaced with =E2=80=9Cdefault algorithm=E2=80=9D. Simi= larly, =E2=80=9Cnon-zero Algorithm=E2=80=9D should be replaced with =E2=80=9C= non-default algorithm=E2=80=9D

#Ahmed: Will be done i= n the next version[[Sasha]]  OK

3.&nbs= p;   I think that RFC 3443 and RFC 5332 should be listed as Normative refe= rences in this draft while RFC 5331 and RFC 8277 should be listed as Informa= tive 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 mod= ify the draft to indicate that) SR-MPLS behavior is similar to downstream la= bel assignment. RFC 3443 describes TTL behavior. This is an MPLS forwarding behavior. As mentioned in the draft, SR-MPLS doe= s not modify at the MPLS forwarding behavior

[[Sasha]] Regarding RFC 5331 =E2=80=93 you may skip this= reference if you state (as discussed below) that SR-MPLS only allocates lab= els from the per-platform label space. Regarding RFC 3443 =E2=80=93 I do not think that you can fully avoid discussion of Un= iform and Pipe/Short Pipe models, and therefore you will need this reference= .



Hopefully, these comments will be useful.<= /p>

#Ahmed: They are certa= inly quite useful. Thanks a lot

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 


___________________________________________________________________________<= br>
This e-mail message is intended for the recipient only and contains informat= ion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have receiv= ed this
transmission in error, please inform us by e-mail, phone or fax, and then de= lete the original
and all copies thereof.
___________________________________________________________________________<= /span>

 <= o:p>


___________________________________________________________________________<= br>
This e-mail message is intended for the recipient only and contains informat= ion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have receiv= ed this
transmission in error, please inform us by e-mail, phone or fax, and then de= lete the original
and all copies thereof.
___________________________________________________________________________<= /span>

 <= o:p>


___________________________________________________________________________<= br>
This e-mail message is intended for the recipient only and contains informat= ion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have receiv= ed this
transmission in error, please inform us by e-mail, phone or fax, and then de= lete the original
and all copies thereof.
___________________________________________________________________________<= o:p>

 


___________________________________________________________________________<= br>
This e-mail message is intended for the recipient only and contains informat= ion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have receiv= ed this
transmission in error, please inform us by e-mail, phone or fax, and then de= lete the original
and all copies thereof.
___________________________________________________________________________<= o:p>

________= _______________________________________
mpls mailing list
mpls@ietf.org
<= span>https://www.ietf= .org/mailman/listinfo/mpls
= --Apple-Mail-4969499B-3E82-4EDD-B8BC-F3CD36C54030--