Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B755127137; Wed, 31 May 2017 07:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 AzAxEyg4XyvN; Wed, 31 May 2017 07:35:01 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 BF80412778D; Wed, 31 May 2017 07:35:00 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 7so121173688wmo.1; Wed, 31 May 2017 07:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xkBf5JXnP/kwp8h5Fws6zUbObktxQM9RNNm9S4+Rp4w=; b=qhhkSEv4Y21lhd3blWijbmhfjMtQXfC+PcVQwlYhJd3oG6wY9eu4zJzIObxbyyMp/m dNzO8xTdVZBN9G1xXJz47C6Bf0h9aWull5dekjGrUCsCyzwYoxlKtunW/apsxgAnsr2w aqCTQa3GANO9JcaVXhSV5VnMRI4VYEHGvjDOZ/vcSDiKzObA5xF0tC4fvIqcsMkdRbml aKJ1So/DVsFBehVL9N+v2E5ZcHksGz/8SXWGGK380E/i3H2kIXHd56Kg56X6fVEG/83h wqZKUD/bCNc6y0FmaBRiG76Q+Tu7N4T0cgfY1Ln+HrodBHCSFZAhqWuHqVRLmi2ZK/Q0 j2dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xkBf5JXnP/kwp8h5Fws6zUbObktxQM9RNNm9S4+Rp4w=; b=E84fc/2L/bTvHUhYgZHuMafNIZv+vigpjleuhu1wdpCdaYDuxcp+X1fIOJssRVEN02 waVJO0Gcv3FJBEz5AbBwDxBnnYMcWOLKqO6J/p6R3/bx4MPcS/KYcqt22+gjP2erKPwa eCH77UnTw5E0AU9UlfJ6ZHIe/PE8kk8oyZiqvCAoD3vrfL9mB9cUyt3A79AznLejQFhS YNNj/tkizdS+WK7ReAbOzVvD/rQInduPP8bCSAWTpPMlqPs8TkomB77N/x/6lwGQIjpT XPRp1hCHMtd2+zgN+5sN/XK21/myH3dwUTcGLM7aXmAvZ8ZlpBUU8hJEm0aN/zddTwge pg6Q== X-Gm-Message-State: AODbwcA+sWpPOUetceZjl5fXlsle4bQCA7ldGtaifcJXBEx4Ps4jM/6p 5sQpQZdDPceh0G8e9iNsOrdLSu7MgQ== X-Received: by 10.28.32.19 with SMTP id g19mr5346740wmg.123.1496241298853; Wed, 31 May 2017 07:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.86 with HTTP; Wed, 31 May 2017 07:34:58 -0700 (PDT) In-Reply-To: References: From: Alia Atlas Date: Wed, 31 May 2017 10:34:58 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: OSPF List , "draft-ietf-ospf-segment-routing-extensions@ietf.org" , "Alvaro Retana (aretana)" , "BRUNGARD, DEBORAH A (ATTSI)" , "spring-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary="001a113d7b541dd8950550d2d33e" Archived-At: Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:35:05 -0000 --001a113d7b541dd8950550d2d33e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Acee, On Wed, May 31, 2017 at 10:11 AM, Acee Lindem (acee) wrote= : > Hi Alia, > Thank you for your comments. I certainly don=E2=80=99t agree with all of = them but > will allow the authors to respond. For example, I believe the concept of = an > SRMS to be well-undestood and defined in the SPRING WG. Perhaps we just > need the right references. > I found circular references about an SRMS in the SPRING WG documents but nothing that was a clear definition. I didn't read all the SPRING WG drafts, of course, but I did follow the references from this document and from that on - back to the isis-segment-routing-extensions draft. Obviously, on the one hand, it isn't the job of the OSPF WG to define this - but it does need clear references so the technology can be understood in context. > The one comment I will respond to is the one regarding the author limit. > Note that this is covered in the Shepherd=E2=80=99s Write-Up. I=E2=80=99v= e excerpted it > here: > > The document does have seven authors. All the authors have > played in active role in the development of the standard including > periodic segment routing design team meetings. All of the authors > have responded promptly to IPR polls. At least three of the > authors represented independent implementations. There is > absolutely no reason to relegate any of them to contributor status. > Then the solution may be to have one or two be editors and on the front page. I am willing to discuss but I am getting quite tired of this consistent issue on almost every draft I receive for publication. > I=E2=80=99ll be on vacation the remainder of this week but will touch bas= e with > the authors on Monday. > Have a good vacation! Regards, Alia > Thanks, > Acee > From: OSPF on behalf of Alia Atlas < > akatlas@gmail.com> > Date: Tuesday, May 30, 2017 at 10:35 PM > To: OSPF WG List , "draft-ietf-ospf-segment- > routing-extensions@ietf.org" routing-extensions@ietf.org>, "Alvaro Retana (aretana)" , > Deborah Brungard > Cc: "spring-chairs@tools.ietf.org" > Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment- > routing-extensions-16 > > I forgot to point out that the Security Considerations sections is not > close to sufficient. > At a minimum, it needs to refer to the existing security work for OSPF, > indicate what new > information is being advertised, and discuss if there are any privacy or > security concerns > around them. I don't personally see any - except for, perhaps, the > increased ability to fingerprint > the type and version of routers with these advertisements. > > Regards, > Alia > > On Tue, May 30, 2017 at 10:05 PM, Alia Atlas wrote: > >> As is customary, I have done my AD review of draft-ietf-ospf-segment-rou= ting-extensions-16 >> once publication has been requested. First, I would like to thank the >> editors & many authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jef= f, >> for the work that they have put in so far and the remaining work that is >> greatly needed. >> >> While there are a great many issues to be handled, they fall primarily >> into three categories. The first is simply not going through and >> tightening up the details; for example, stating that the length of a TLV= is >> variable provides no meaning. The second is that the technical document= s >> from SPRING that this draft depends on do not adequately describe the us= e >> of the advertised information (SID/Label Binding TLV) or some of the >> concepts (e.g. SR Mapping Server). The third is a more common set of >> handling error cases and adding clarity to the intended behavior. I do = not >> see issues with the encodings but I do see fragility with the unstated >> assumptions and behaviors. The draft describes encodings, but very litt= le >> of the handling, behaviors, or meaning - and the references do not provi= de >> adequate detail. >> >> I have spent all day (and evening) doing this review and I am quite >> disappointed and concerned about the document. I would strongly recomme= nd >> having sharing the next WGLC with the SPRING working group; perhaps more >> eyes will help with the discrepancies. >> >> I have not yet decided what to do about the "early" IANA allocation - >> which has now existed for this draft for 3 years. I do know that there = are >> implementations, >> but I am currently seeing the failure of this work to successfully >> complete as an example of an issue with providing early allocations. >> >> MAJOR ISSUES: >> >> 1) This draft has 7 authors. The limit for authors & editors is 5, as i= s >> clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well over= a >> decade, unless there are extraordinary circumstances. Is there a reason= to >> not simply list the active editor and move the others to contributors? = One >> of the authors is already listed there. I regret that failure to deal >> earlier with this long-standing IETF policy will be delaying progressing >> the draft. >> >> 2) This expired individual draft(draft-minto-rsvp-lsp-egress-fast-protec= tion-03) >> is listed as Informative - but IS ACTUALLY NORMATIVE since it DEFINES th= e >> "M-bit - When the bit is set, the binding represents a mirroring context >> as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]." >> Unfortunately, when I look there for the definition of a mirroring >> context, it doesn't exists. >> >> 3) The following Informative references expired several years ago and - >> being individual drafts - do not appear to convey the SPRING or TEAS WG >> consensus. >> a) draft-filsfils-spring-segment-routing-ldp-interop-03 was replaced >> with draft-ietf-spring-segment-routing-ldp-interop-07 and there are >> considerable differences. >> b) It is unclear what happened to draft-filsfils-spring-segment-routi= ng-use-cases-01, >> but I do not see any successor - or reason for this individual draft to >> explain the OSPFv2 extensions more than work from the SPRING WG. >> >> 4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the >> SR-Algorithm TLV? What is the expected behavior and assumptions by the >> receiver? >> >> 5) Sec 3.4: What happens if an SRMS Preference TLV is advertised withou= t >> an SR-Algorithm TLV in the same scope? I see that it says "For the purp= ose >> of the SRMS Preference Sub-TLV advertisement, AS scope flooding is >> required." but also provides for area scope flooding. Some words >> clarifying the expected behavior would be useful. >> >> 6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not >> preserved for >> the final destination (the Prefix-SID being removed)." I am quite >> startled to see an assumption that MPLS Pipe mode is being forced as par= t >> of specifying PHP mode! This will also break any ECN or 3-color marking >> that has affected the MPLS EXP bits. I would like to see and understand= a >> clear justification for why short-pipe mode is being required instead of >> Uniform (or up to implementation/configuration.). Basically, this >> sentence means that transport considerations are a necessary section - >> which is completely inappropriate in an IGP draft. >> >> 7) Sec 6: This section defines the SID/Label Binding sub-TLV - which >> appears to be a way to advertise an explicit path - and has a SID/Label = by >> which the path can be entered. How and what state is set up by the >> sending router to create the indicated segment is completely unclear. = I >> have hunted through draft-ietf-spring-segment-routing, draft-ietf-spring= -segment-routing-mpls, >> and draft-ietf-spring-segment-routing-ldp-interop, RFC7855, >> and draft-ietf-isis-segment-routing-extensions. As far as I can tell, >> NONE of them clearly describe the details of where and why this advertis= ing >> is needed. Obviously, this mechanism does allow the potential shortenin= g >> of the MPLS label stack at the cost of advertising multi-hop explicit pa= th >> segments across the entire area or AS. There MUST be a normative >> description of what the sending router will do when a packet is received >> with the specified label. >> >> 8) Sec 4: "The Segment Routing Mapping Server, which is described in >> [I-D.filsfils-spring-segment-routing-ldp-interop]" Where precisely is >> an SRMS and its behavior/role actually defined? >> draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP >> interworking requires a SRMS as defined in [I-D.ietf-isis-segment-routin= g-extensions]." >> but that wouldn't be appropriate, of course, and it isn't there either! >> draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't >> define it. draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1 >> that "A Remote-Binding SID S advertised by the mapping server M" and ref= ers >> to the ldp-interop draft for further details - but obviously not about a= n >> SRMS. >> >> Minor Issues: >> >> 1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only >> be advertised once in the Router Information Opaque LSA. If the SID/Lab= el >> Range TLV, as defined in Section 3.2, is advertised, then the SR-Algorit= hm >> TLV MUST >> also be advertised." Please provide a pointer in the text to the >> behavior for a receiving router if one or both of these are violated? = For >> the requirement to advertise the SR-Algorithm TLV, please clarify that t= his >> is in the same RI LSA as the SID/Label Range TLV was advertised & with t= he >> same scope. What does it mean, in terms of the receiving router, to >> determine that the sending router supports SR or not - given the >> possibility of receiving other SR-related TLVS in an RI LSA without gett= ing >> an SR-Algorithm TLV? >> >> 2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable". >> Given that advertising Algorithm 0 is required, I'm fairly sure that the >> Length has to be a minimum of 1 - and, to prevent overrun & weird issues= , >> let's have a reasonable maximum (for instance, 24) too. It wouldn't hur= t >> to remind readers that the length is just that of the value field - thou= gh >> experienced OSPF implementers will know that. >> >> 3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV >> advertisement, area scope flooding is required." and "For the purpose of >> SID/Label Range TLV advertisement, area scope flooding is required." an= d >> "For the purpose of SR Local Block Sub-TLV TLV advertisement, area scope >> flooding is required." Please capitalize REQUIRED as per RFC 2119. >> Otherwise, please explain behavior when area scope isn't used. >> >> 4) Sec 3.2: The SID/Label Range TLV doesn't indicate that include a >> SID/Label sub-TLV is required - but I don't understand how it could be >> interpreted otherwise; nor does it indicate what to do if there are >> multiple SID/Label sub-TLVs included in a single SID/Label Range TLV. Ag= ain >> "Length" is just defined as variable. In this case, it clearly can't be >> less than 11 (probably 12, assuming padding to the 32-bit boundary). I= t >> would be useful to have an upper-bound on length, but at least here I ca= n >> see the argument that meaningful flexibility is provided for. >> >> 5) SID index is used without introduction in Sec 3.2. It isn't defined >> in the terminology of draft-ietf-spring-segment-routing-11 and the other >> uses of it in this document aren't enough to clearly define it. Please = add >> at least a description of its meaning before use - in a terminology >> section, if necessary. >> >> 6) Sec 3.2: "The originating router advertises the following ranges: >> Range 1: [100, 199] >> Range 2: [1000, 1099] >> Range 3: [500, 599]" >> Please turn this into the information actually advertised - i.e. >> Range 1: Range Size: 100 SID/Label sub-TLV: 100 =3D> meaning [100, >> 199] >> etc. >> >> 7) 3.2. SID/Label Range TLV: Please specify that the sender MUST NOT >> advertise overlapping ranges & how to handle the case when it does. Thi= s >> is required by draft-ietf-spring-conflict-resolution. >> >> 8) Sec 3.3 SR Local Block (SRLB) Sub-TLV: The document doesn't specify >> that the SR Local Block TLV MUST include a SID/Label sub-TLV nor indicat= e >> what to do if multiple are included. The Length, again, isn't specified= at >> all and clearly has at least a minimum. I don't see a reference to an = SR >> Local Block or the need to advertise it in draft-ietf-spring-segment-rou= ting-11; >> perhaps I missed where the requirement and usage are defined? >> >> 9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also = be >> reported to all components..." Presumably, this is subjected to the >> normal OSPF dampening - it'd be nice to note that somewhere - since rapi= d >> sequential allocation may not provide the reporting speed anticipated. >> >> 10) Sec 4: "AF: Address family for the prefix. Currently, the only >> supported >> value is 0 for IPv4 unicast. The inclusion of address family in >> this TLV allows for future extension." Could you please clarify i= f >> this is to reuse the same TLV for OSPFv3 so IPv6 can be supported, are y= ou >> thinking of extending OSPFv2 for IPv6 prefixes for some cases or somethi= ng >> else? I think the current phrasing is likely to raise questions. >> Similarly, please define "Prefix length: Length of the prefix" clearly. = I >> really don't understand what the benefit of having a TLV that pretends t= o >> support multiple AFs but can't is versus the clarity of specifying the >> prefix lengths. >> >> 11) Sec 4: Again "Length: Variable" - It should have a minimum and >> preferable describe a function for how it is computed. A maximum is >> probably unlikely with sub-TLVs. >> >> 12) Sec 4: OSPF Extended Prefix Range TLV: Does this TLV has any meanin= g >> or action associated with it without including sub-TLVs? Are there >> mandatory sub-TLVs? What is a receiving router to do with it? >> >> 13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix, >> the >> receiving router MUST use the first encoded SID and MAY use >> subsequent SIDs." What does this even mean? A receiving router when >> making the decision to use a subsequent SID is making a decision to not = use >> the first encoded SID; it's not like the router is going to stick both >> SID/Labels onto the stack. Please describe this in meaningful normativ= e >> terms. >> >> 14) Sec 5:" When calculating the outgoing label for the prefix, the >> router MUST >> take into account the E and P flags advertised by the next-hop router >> if that router advertised the SID for the prefix. This MUST be done >> regardless of whether the next-hop router contributes to the best >> path to the prefix." First, I assume this is "NP flag" because there >> is no P flag. >> Second - please clarify to "take into account, as described below, th= e >> E and NP flags...". Third, the M flag must also be taken into account - >> given the text later in the section. >> >> 15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range >> TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted = as a >> starting SID value." This appears to contradict "SID/Index/Label: >> According to the V and L flags, it contains either: >> >> A 32-bit index defining the offset in the SID/Label space >> advertised by this router. >> >> A 24-bit label where the 20 rightmost bits are used for >> encoding the label value." >> I assume that what is meant by the first quote is "...is interpreted, >> if the V flag is clear, as a starting SID value, and if the V flag is se= t, >> as a starting Label value." Otherwise, it looks like the Prefix-SID >> sub-TLV couldn't be included in the Extended Prefix Range TLV if a label >> value would be used. >> >> It would be helpful for Example 2 to show the label case. >> >> 16) Sec 6.1: "aggregate IGP or TE path cost." Given that this is an OSP= F >> draft, it'd be helpful to indicate whether there are challenges with >> non-comparable OSPF metrics (I'm thinking about AS-external type 2 costs= ) >> or if the path will never include such costs. >> >> 17) Sec 6.2: "a domain and hence need to be disambiguated using a >> domain-unique Router-ID." Given that the Prefix-SIDs and sub-TLVs can b= e >> distributed between areas and even redistributed between protocols, plea= se >> clearly define what is meant by a "domain" or point to the appropriate >> definition. >> >> 18) Sec 4, 5, 6: Is it possible to have an OSPF Extended Prefix Range >> TLV that includes both a Prefix SID Sub-TLV and a SID/Label Binding >> Sub-TLV? What does that mean? >> >> What does it mean if there are multiple prefixes described in the OSPF >> Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV? Do= es >> the SID/Label sub-sub-TLV indicate a single SID Index or Label that is u= sed >> for the single path to all those prefixes? Is it the start of a list of >> SID Indices or Labels? >> I see that the SID/Label Binding sub-TLV can be in both the OSPF Extende= d >> Prefx Range TLV as well as the OSPF Extended Prefix TLV - but there is n= o >> text on differences in interpretation. >> >> 19) Sec 7.1 & 7.2: Another couple "Length: Variable." Please actually >> specify the value. I think that, given the padding to 32-bit alignment, >> there is a single correct value. >> >> 20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same >> meaning - it'd be clearer to have them defined once. >> >> 21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix >> Range TLV when advertising SIDs for prefixes. Prefixes of different >> route-types can be combined in a single OSPF Extended Prefix Range TLV >> advertised by an SR Mapping Server." So - I can't find a normative >> definition of an SRMS to determine why it is always necessary to use an >> OSPF Extended Prefix Range TLV instead of an OSPF Extended Prefix TLV. = I >> don't see how advertising prefixes from different route-types can work >> unless the prefixes are adjacent, which seems likely to be uncommon. >> Perhaps what is meant is "Because the OSPF Extended Prefix Range TLV >> doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV, = it >> is possible to include adjacent prefixes from different Route-Types in t= he >> OSPF Extended Prefix Range TLV." >> >> 22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same >> prefix, then >> the Prefix-SID MUST be the same. This is required in order to allow >> traffic load-balancing when multiple equal cost paths to the destination >> exist in the OSPFv2 routing domain." How is this enforced? What are th= e >> consequences of it not being conformed to? This is NOT a protocol >> implementation requirement. This should really be called out in a >> Manageability Considerations with warnings. >> >> 23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the sourc= e >> area >> by the router that contributes to the best path to the prefix, the >> originating ABR will use the Prefix-SID advertised by any other >> router when propagating the Prefix-SID for the prefix to other >> areas." I believe that this depends on the assumption that if a >> Prefix-SID is advertised by any router, the Prefix-SID will be the same. >> Please be explicit in this assumption, since the requirement on the netw= ork >> operator should be clear as well as the consequences of not conforming. >> >> 24) Sec 10: The Implementation Status section should indicate that it i= s >> to be removed before publication as an RFC. Also, the complete >> implementation part seems a bit dated - given the draft's technical chan= ges >> in the last 2 years. >> >> >> NITS: >> >> 1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV" >> >> 2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV a= s >> defined >> in Section 2.1. The SID/Label advertised in the SID/Label TLV >> represents the first SID/Label in the advertised range." >> replace SID/Label TLV with SID/Label sub-TLV. >> >> 3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top-level >> TLV of the Router Information Opaque LSA (defined in [RFC7770])." Plea= se >> correct the descriptions (many) to SR Local Block (SRLB) Sub-TLV to SR >> Local Block SRLB TLV. The same issue exists for "SRMS Preference >> Sub-TLV". >> >> Regards, >> Alia >> >> >> > --001a113d7b541dd8950550d2d33e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Acee,

On Wed, May 31, 2017 at 10:11 AM, Acee Lindem (acee) <acee@cisco.com<= /a>> wrote:
Hi Alia,=C2=A0
Thank you for your comments. I certainly don=E2=80=99t agree with all of th= em but will allow the authors to respond. For example, I believe the concep= t of an SRMS to be well-undestood and defined in the SPRING WG. Perhaps we = just need the right references.

I found circular references about an SRMS in the SPRING WG documents but = nothing that was a clear definition.=C2=A0 I didn't read all the SPRING= WG drafts, of course, but I did follow the references from this document a= nd from that on - back to the isis-segment-routing-extensions draft. Obviou= sly, on the one hand, it isn't the job of the OSPF WG to define this - = but it does need clear references so the technology can be understood in co= ntext.


Have a good vacation!


=
Thanks,
Acee=C2=A0
From: OSPF <ospf-bounces@ietf.org> on beh= alf of Alia Atlas <akatlas@gmail.com>
Date: Tuesday, May 30, 2017 at 10:3= 5 PM
To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@ietf.org" &= lt;draft-ietf-ospf-segment-routing-extensions@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, Deborah Brungard <db3546@att.com>
Cc: "spring-chairs@tools.ietf.org&q= uot; <= spring-chairs@tools.ietf.org>
Subject: Re: [OSPF] AD review of dr= aft-ietf-ospf-segment-routing-extensions-16

I forgot to point out that the Security Considerations sec= tions is not close to sufficient.
At a minimum, it needs to refer to the existing security work for OSPF= , indicate what new
information is being advertised, and discuss if there are any privacy = or security concerns
around them.=C2=A0 I don't personally see any - except for, perhap= s, the increased ability to fingerprint
the type and version of routers with these advertisements.

Regards,
Alia

On Tue, May 30, 2017 at 10:05 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
As is customary, I have done my AD review of=C2=A0draft-ietf-ospf-segm= ent-routing-extensions-16 once publication has been requested.=C2=A0 F= irst, I would like to thank the editors & many authors, Peter, Stefano,= Clarence, Hannes, Rob, Wim & Jeff, for the work that they have put in so far and the remaining work that is greatly needed= .

While there are a great many issues to be handled, they fall primarily= into three categories.=C2=A0 The first is simply not going through and tig= htening up the details; for example, stating that the length of a TLV is va= riable provides no meaning.=C2=A0 The second is that the technical documents from SPRING that this draft depends on do = not adequately describe the use of the advertised information (SID/Label Bi= nding TLV) or some of the concepts (e.g. SR Mapping Server).=C2=A0 The thir= d is a more common set of handling error cases and adding clarity to the intended behavior.=C2=A0 I do not see issu= es with the encodings but I do see fragility with the unstated assumptions = and behaviors.=C2=A0 The draft describes encodings, but very little of the = handling, behaviors, or meaning - and the references do not provide adequate detail.

I have spent all day (and evening) doing this review and I am quite di= sappointed and concerned about the document.=C2=A0 I would strongly recomme= nd having sharing the next WGLC with the SPRING working group; perhaps more= eyes will help with the discrepancies.

I have not yet decided what to do about the "early" IANA all= ocation - which has now existed for this draft for 3 years.=C2=A0 I do know= that there are implementations,
but I am currently seeing the failure of this work to successfully com= plete as an example of an issue with providing early allocations. =C2=A0

MAJOR ISSUES:

1) This draft has 7 authors.=C2=A0 The limit for authors & editors= is 5, as is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for= well over a decade, unless there are extraordinary circumstances.=C2=A0 Is= there a reason to not simply list the active editor and move the others to contributors?=C2=A0 One of the authors is al= ready listed there.=C2=A0 I regret that failure to deal earlier with this l= ong-standing IETF policy will be delaying progressing the draft.

2) This expired individual draft(draft-minto-rsvp-lsp-egress-fast= -protection-03) is listed as Informative - but IS ACTUALLY NORMATIVE since = it DEFINES the
"M-bit - When the bit is set, the binding represents a mirroring conte= xt as defined in=C2=A0[I-D.minto-rsvp-lsp-egress-fast-protection].&quo= t; =C2=A0Unfortunately, when I look there for the definition of a mirroring= context, it doesn't exists.

3) The following Informative references expired several years ago and = - being individual drafts - do not appear to convey the SPRING or TEAS WG c= onsensus.=C2=A0
=C2=A0 =C2=A0a) =C2=A0draft-filsfils-spring-segment-routing-ldp-intero= p-03 was replaced with=C2=A0draft-ietf-spring-segment-routing-ldp-inte= rop-07 and there are considerable differences.
=C2=A0 =C2=A0b) It is unclear what happened to=C2=A0draft-filsfils-spr= ing-segment-routing-use-cases-01, but I do not see any successor - or = reason for this individual draft to explain the OSPFv2 extensions more than= work from the SPRING WG.

4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the = SR-Algorithm TLV?=C2=A0 What is the expected behavior and assumptions by th= e receiver?

5) Sec 3.4: =C2=A0What happens if an SRMS Preference TLV is advertised= without an SR-Algorithm TLV in the same scope?=C2=A0 I see that it says &q= uot;For the purpose of the SRMS Preference Sub-TLV advertisement, AS scope = flooding is required." but also provides for area scope flooding.=C2=A0 Some words clarifying the expected behavior would be= useful.

6) Sec 5:=C2=A0"In such case, MPLS EXP bits of the Prefix-SID are= not preserved for=C2=A0
the final destination (the Prefix-SID being removed)." =C2=A0 I a= m quite startled to see an assumption that MPLS Pipe mode is being forced a= s part of specifying PHP mode!=C2=A0 This will also break any ECN or 3-colo= r marking that has affected the MPLS EXP bits.=C2=A0 I would like to see and understand a clear justification for why short-pip= e mode is being required instead of Uniform (or up to implementation/config= uration.). =C2=A0 Basically, this sentence means that transport consid= erations are a necessary section - which is completely inappropriate in an IGP draft.

7) Sec 6: This section defines the SID/Label Binding sub-TLV - which a= ppears to be a way to advertise an explicit path - and has a SID/Label by w= hich the path can be entered. =C2=A0 How and what state is set up by the se= nding router to create the indicated segment is completely unclear. =C2=A0 I have hunted through=C2=A0draft-iet= f-spring-segment-routing,=C2=A0draft-ietf-spring-segment-routing-= mpls, and=C2=A0draft-ietf-spring-segment-routing-ldp-interop, RFC7855,= and=C2=A0draft-ietf-isis-segment-routing-extensions. =C2=A0 As far as I can tell, NONE of them clearly describe the details of = where and why this advertising is needed.=C2=A0 Obviously, this mechanism d= oes allow the potential shortening of the MPLS label stack at the cost of a= dvertising multi-hop explicit path segments across the entire area or AS.=C2=A0 There MUST be a normative description = of what the sending router will do when a packet is received with the speci= fied label. =C2=A0

8) Sec 4:=C2=A0"The Segment Routing Mapping Server, which is desc= ribed in [I-D.filsfils-spring-segment-routing-ldp-interop]" =C2= =A0Where precisely is an SRMS and its behavior/role actually defined? =C2= =A0draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP interworking requires a SRMS as defined in [I-D.ietf-isis-segment-r= outing-extensions]." but that wouldn't be appropriate, of cou= rse, and it isn't there either! =C2=A0draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't define it. =C2=A0=C2=A0draft-ietf-spring-segment-routing-11 mentions in Sec = 3.5.1 that "A Remote-Binding SID S advertised by the mapping server M&= quot; and refers to the ldp-interop draft for further details - but obvious= ly not about an SRMS.

Minor Issues:

1) In Sec 3.1, it says:=C2=A0"The SR-Algorithm TLV is optional. I= t MUST only be advertised once in the Router Information Opaque LSA.=C2=A0 = If the SID/Label Range TLV, as=C2=A0defined in Section 3.2, is advertised, = then the SR-Algorithm TLV MUST
also be advertised." =C2=A0Please provide a pointer in the text to the= behavior for a receiving router if one or both of these are violated? =C2= =A0 For the requirement to advertise the SR-Algorithm TLV, please clarify t= hat this is in the same RI LSA as the SID/Label Range TLV was advertised & with the same scope.=C2=A0 What does it mea= n, in terms of the receiving router, to determine that the sending router s= upports SR or not - given the possibility of receiving other SR-related TLV= S in an RI LSA without getting an SR-Algorithm TLV?

2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable= ".=C2=A0 Given that advertising Algorithm 0 is required, I'm fairl= y sure that the Length has to be a minimum of 1 - and, to prevent overrun &= amp; weird issues, let's have a reasonable maximum (for instance, 24) too.=C2=A0 It wouldn't hurt to remind readers that the l= ength is just that of the value field - though experienced OSPF implementer= s will know that.

3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorit= hm TLV advertisement, area scope flooding is required." and "For = the purpose of SID/Label Range TLV advertisement, area scope flooding is re= quired." =C2=A0and "For the purpose of SR Local=C2=A0Block Sub-TL= V TLV advertisement, area scope flooding is required." Please capitaliz= e REQUIRED as per RFC 2119.=C2=A0 Otherwise, please explain behavior when a= rea scope isn't used.

4) Sec 3.2: =C2=A0The SID/Label Range TLV doesn't indicate that in= clude a SID/Label sub-TLV is required - but I don't understand how it c= ould be interpreted otherwise; nor does it indicate what to do if there are= multiple SID/Label sub-TLVs included in a single SID/Label Range TLV. Again "Length" is just defined as variable.= =C2=A0 In this case, it clearly can't be less than 11 (probably 12, ass= uming padding to the 32-bit boundary). =C2=A0 It would be useful to have an= upper-bound on length, but at least here I can see the argument that meaningful flexibility is provided for.

5) SID index is used without introduction in Sec 3.2.=C2=A0 It isn'= ;t defined in the terminology of draft-ietf-spring-segment-routing-11 = and the other uses of it in this document aren't enough to clearly defi= ne it.=C2=A0 Please add at least a description of its meaning before use - in a terminology section, if necessary.

6) Sec 3.2: "The originating router advertises the following rang= es:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Range 1: [100, 199]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Range 2: [1000, 1099]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Range 3: [500, 599]"
Please turn this into the information actually advertised - i.e.
=C2=A0 =C2=A0Range 1: Range Size: 100 =C2=A0 SID/Label sub-TLV: 100 = =C2=A0=3D> meaning [100, 199]
etc. =C2=A0=C2=A0

7)=C2=A03.2. SID/Label Range TLV: =C2=A0Please specify that the sender= =C2=A0MUST NOT advertise overlapping=C2=A0ranges & how to handle the ca= se when it does.=C2=A0 This is required by=C2=A0draft-ietf-spring-conflict-= resolution.

8) Sec 3.3 =C2=A0SR Local Block (SRLB) Sub-TLV: The document doesn'= ;t specify that the SR Local Block TLV MUST include a=C2=A0SID/Label sub-TL= V nor indicate what to do if multiple are included.=C2=A0 The Length, again= , isn't specified at all and clearly has at least a minimum. =C2=A0 I don't see a reference to an SR Local Block or the ne= ed to advertise it in=C2=A0draft-ietf-spring-segment-routing-11; perha= ps I missed where the requirement and usage are defined?

9) Sec 3.3:=C2=A0"Each time a SID from the SRLB is allocated, it = SHOULD also be
=C2=A0 =C2=A0reported to all components..." =C2=A0Presumably, this is = subjected to the normal OSPF dampening - it'd be nice to note that some= where - since rapid sequential allocation may not provide the reporting spe= ed anticipated.

10) Sec 4: "AF: Address family for the prefix. Currently, the onl= y supported
=C2=A0 =C2=A0 =C2=A0 value is 0 for IPv4 unicast.=C2=A0 The inclusion of ad= dress family in
=C2=A0 =C2=A0 =C2=A0 this TLV allows for future extension." =C2=A0Coul= d you please clarify if this is to reuse the same TLV for OSPFv3 so IPv6 ca= n be supported, are you thinking of extending OSPFv2 for IPv6 prefixes for = some cases or something else? I think the current phrasing is likely to raise questions.=C2=A0 Similarly, please define=C2=A0"Pr= efix length: Length of the prefix" clearly.=C2=A0 I really don't u= nderstand what the benefit of having a TLV that pretends to support multipl= e AFs but can't is versus the clarity of specifying the prefix lengths.=C2=A0

11) Sec 4: =C2=A0Again=C2=A0"Length: Variable" - It should h= ave a minimum and preferable describe a function for how it is computed.=C2= =A0 A maximum is probably unlikely =C2=A0with sub-TLVs.

12)=C2=A0Sec 4: OSPF Extended Prefix Range TLV: =C2=A0Does this TLV ha= s any meaning or action associated with it without including sub-TLVs?=C2= =A0 Are there mandatory sub-TLVs?=C2=A0 What is a receiving router to do wi= th it?

13) Sec 5:=C2=A0"If multiple Prefix-SIDs are advertised for the s= ame prefix, the
=C2=A0 receiving router MUST use the first encoded SID and MAY use
=C2=A0 subsequent SIDs." =C2=A0What does this even mean?=C2=A0 A recei= ving router when making the decision to use a subsequent SID is making a de= cision to not use the first encoded SID; it's not like the router is go= ing to stick both SID/Labels onto the stack. =C2=A0 Please describe this in meaningful normative terms.

14) Sec 5:" When calculating the outgoing label for the prefix, t= he router MUST
=C2=A0 =C2=A0take into account the E and P flags advertised by the next-hop= router
=C2=A0 =C2=A0if that router advertised the SID for the prefix.=C2=A0 This M= UST be done
=C2=A0 =C2=A0regardless of whether the next-hop router contributes to the b= est
=C2=A0 =C2=A0path to the prefix." =C2=A0First, I assume this is "= NP flag" because there is no P flag.
=C2=A0 =C2=A0Second - please clarify to "take into account, as de= scribed below, the E and NP flags...".=C2=A0 Third, the M flag must al= so be taken into account - given the text later in the section.

15) Sec 5:=C2=A0"When a Prefix-SID is advertised in an Extended P= refix Range TLV, then=C2=A0the value advertised in the Prefix SID Sub-TLV i= s interpreted as a
=C2=A0 =C2=A0starting SID value." =C2=A0 This appears to contradict=C2= =A0"SID/Index/Label: According to the V and L flags, it contains=C2=A0= either:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A 32-bit index defining the offset in the= SID/Label space
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertised by this router.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A 24-bit label where the 20 rightmost bit= s are used for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encoding the label value."
=C2=A0 I assume that what is meant by the first quote is "...is i= nterpreted, if the V flag is clear, as a starting SID value, and if the V f= lag is set, as a starting Label value." =C2=A0Otherwise, it looks like= the Prefix-SID sub-TLV couldn't be included in the Extended Prefix Range TLV if a label value would be used.
=C2=A0
It would be helpful for Example 2 to show the label case.

16) Sec 6.1: "aggregate IGP or TE path=C2=A0cost." =C2=A0Giv= en that this is an OSPF draft, it'd be helpful to indicate whether ther= e are challenges with non-comparable OSPF metrics (I'm thinking about A= S-external type 2 costs) or if the path will never include such costs. =C2=A0

17) Sec 6.2: "a domain and hence need to be disambiguated using a= domain-unique Router-ID." =C2=A0Given that the Prefix-SIDs and sub-TL= Vs can be distributed between areas and even redistributed between protocol= s, please clearly define what is meant by a "domain" or point to the appropriate definition.

18) Sec 4, 5, 6: =C2=A0Is it possible to have an=C2=A0OSPF Extended Pr= efix Range TLV that includes both a=C2=A0Prefix SID Sub-TLV and=C2=A0a SID/= Label Binding Sub-TLV? =C2=A0 What does that mean?=C2=A0

What does it mean if there are multiple prefixes described in the OSPF= Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV?=C2=A0= Does the SID/Label sub-sub-TLV indicate a single SID Index or Label that i= s used for the single path to all those prefixes?=C2=A0 Is it the start of a list of SID Indices or Labels?
I see that the SID/Label Binding sub-TLV can be in both the OSPF Exten= ded Prefx Range TLV as well as the OSPF Extended Prefix TLV - but there is = no text on differences in interpretation.

19) Sec 7.1 & 7.2: Another =C2=A0couple "Length: Variable.&qu= ot; =C2=A0Please actually specify the value. I think that, given the paddin= g to 32-bit alignment, there is a single correct value.

20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same me= aning - it'd be clearer to have them defined once.

21) Sec 8.1:=C2=A0"An SR Mapping Server MUST use the OSPF Extende= d Prefix Range TLV when advertising SIDs for prefixes.=C2=A0 Prefixes of di= fferent route-types can be combined in a single OSPF Extended Prefix Range = TLV advertised by an SR Mapping Server." =C2=A0 =C2=A0So - I can't find a normative definition of an SRMS to determine why it i= s always necessary to use an OSPF Extended Prefix Range TLV instead of an O= SPF Extended Prefix TLV. =C2=A0 I don't see how advertising prefixes fr= om different route-types can work unless the prefixes are adjacent, which seems likely to be uncommon.=C2=A0 Perhaps wh= at is meant is "Because the OSPF Extended Prefix Range TLV doesn't= include a Route-Type field, as in the OSPF Extended Prefix TLV, it is poss= ible to include adjacent prefixes from different Route-Types in the OSPF Extended Prefix Range TLV."

22) Sec 8.1:=C2=A0"If multiple routers advertise a Prefix-SID for= the same prefix, then
the Prefix-SID MUST be the same.=C2=A0 This is required in order to allow t= raffic load-balancing when multiple equal cost paths to the destination exi= st in the OSPFv2 routing domain." =C2=A0How is this enforced?=C2=A0 Wh= at are the consequences of it not being conformed to?=C2=A0 This is NOT a protocol implementation requirement.=C2=A0 This should reall= y be called out in a Manageability Considerations with warnings.

23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in th= e source area
=C2=A0 =C2=A0 =C2=A0 by the router that contributes to the best path to the= prefix, the
=C2=A0 =C2=A0 =C2=A0 originating ABR will use the Prefix-SID advertised by = any other
=C2=A0 =C2=A0 =C2=A0 router when propagating the Prefix-SID for the prefix = to other
=C2=A0 =C2=A0 =C2=A0 areas." =C2=A0I believe that this depends on the = assumption that if a Prefix-SID is advertised by any router, the Prefix-SID= will be the same.=C2=A0 Please be explicit in this assumption, since the r= equirement on the network operator should be clear as well as the consequences of not conforming.

24) Sec 10: =C2=A0The Implementation Status section should indicate th= at it is to be removed before publication as an RFC. =C2=A0 Also, the compl= ete implementation part seems a bit dated - given the draft's technical= changes in the last 2 years.


NITS:

1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV"<= /div>

2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Labe= l TLV as defined
=C2=A0 =C2=A0in Section 2.1.=C2=A0 The SID/Label advertised in the SID/Labe= l TLV
=C2=A0 =C2=A0represents the first SID/Label in the advertised range."<= br>
=C2=A0 =C2=A0replace SID/Label TLV with SID/Label sub-TLV.

3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top= -level TLV of the Router=C2=A0Information Opaque LSA (defined in [RFC7770])= ." =C2=A0 Please correct the descriptions (many) to SR Local Block (SR= LB) Sub-TLV to SR Local Block SRLB TLV. =C2=A0 The same issue exists for=C2=A0"SRMS Preference Sub-TLV".

Regards,
Alia




--001a113d7b541dd8950550d2d33e--