Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16
Alia Atlas <akatlas@gmail.com> Wed, 14 June 2017 14:22 UTC
Return-Path: <akatlas@gmail.com>
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 1EABD12EABD; Wed, 14 Jun 2017 07:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 Hg7gMfAAwCiC; Wed, 14 Jun 2017 07:22:35 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 BDDDD12EA81; Wed, 14 Jun 2017 07:22:34 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id 77so2867557wrb.1; Wed, 14 Jun 2017 07:22:34 -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=BTwkvD49pNUr27qcUlJCkcsM8s87oQBqHOidtV60JI8=; b=WA5X4N+sWaMMrlvswQ9XvHNQbeAt5H+wHCisCj+Mrhdsv1xTbvLZzOnZ++DtZ3FGUA P45I3/zL93oZQ35j901xrr/1O0XRUS5cn9joUyL/rGravmvJYkrO92pYr5SICRIgR0pg dZrD1fMbTrAm27wyRUxj49LijZPbT9SdIfcP72robawiEKBV2OG0DBtnGEL8W8ZSJd6j zz2H2RWVI4M/DJpM2V+ELltzBFdG6wY1Isg5CBJNlgUBoAUcxdVBWM1+maWKuf9OJXZa db5KP39lq9fv/+c4UjwIvz0ZkZhMDf5P98U0xwLzX3cb+N82uLwEEly6785XKaVjQl2P tZLA==
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=BTwkvD49pNUr27qcUlJCkcsM8s87oQBqHOidtV60JI8=; b=iVkRPwOGDzAe2WHu1QjVjT6T3T8EFRd1G90DOacrH4XJbE/ZkGlxw869cBA6HehHRQ yWu7oJE15G1TgQPWu4ujKGHlWuBW7zqTRsaA+dhzj2BoN2WsJV12r3x98ePFJ5mbpSEK FPEfrZUwmvZLaa1BayVWExhh3fAuyfh121x4DjqiGogyFjw0b177FGVytcrclDKuKdPG M1CNa3soPFvb44AfkPp0qDHw3/py3oMaK/AAJBTBLME2DnEaPfKP8RSnzS9PIHTs55kd 4eor98gN20ToR/sL0bFcKeL1SShGe3z32+mvqRsaQ3uY2XlXUaX5zum3G5KJbfXpFV8J 3fYA==
X-Gm-Message-State: AKS2vOyLdJJyGUJPkRkfnln3yS3XxB69T5GgcBIpTvClUuK3CUdsrLi/ Ti0pQwcH0VeOKQvyCyLuRedjRACxVw==
X-Received: by 10.28.208.207 with SMTP id h198mr248583wmg.40.1497450153135; Wed, 14 Jun 2017 07:22:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.131.66 with HTTP; Wed, 14 Jun 2017 07:22:32 -0700 (PDT)
In-Reply-To: <A0AC0C8F-BBBE-4F9E-AED6-865235BCDC84@cisco.com>
References: <CAG4d1rc63W09vsg5psyUFYdF-1ygX3oD+J+4Rbjd0CoXTi08vA@mail.gmail.com> <CAG4d1rfCJzbUM8rhehd1t3ibm9jMGDz=AR=QWkCWmM5Jh38vVA@mail.gmail.com> <D554439A.B1BAA%acee@cisco.com> <CAG4d1rdmVJht4SrAwh8Kq2_n-6+dfuuOAWsyqLJ2NCfeoE5eaw@mail.gmail.com> <A0AC0C8F-BBBE-4F9E-AED6-865235BCDC84@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 14 Jun 2017 10:22:32 -0400
Message-ID: <CAG4d1rdfaChceRDszb1wssnR_XAz8oBeHAvSbYM1uCnEK2r6HQ@mail.gmail.com>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, OSPF List <ospf@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@ietf.org" <draft-ietf-ospf-segment-routing-extensions@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "BRUNGARD, DEBORAH A (ATTSI)" <db3546@att.com>, "spring-chairs@tools.ietf.org" <spring-chairs@tools.ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19319872717f0551ec48f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/WV3T0RXRatdZRMUF8UCISb9gmHg>
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 <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 14:22:40 -0000
On Wed, Jun 14, 2017 at 9:13 AM, Stefano Previdi (sprevidi) < sprevidi@cisco.com> wrote: > > > On May 31, 2017, at 4:34 PM, Alia Atlas <akatlas@gmail.com> wrote: > > > > Hi Acee, > > > > On Wed, May 31, 2017 at 10:11 AM, Acee Lindem (acee) <acee@cisco.com> > wrote: > > Hi Alia, > > Thank you for your comments. I certainly don’t 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. > > > draft-ietf-spring-segment-routing-ldp-interop is the document where the > srms is briefly introduced. I agree with you, more details are needed and > then the sr-igp drafts (ospf,ospfv3,isis) should point to the ldp-interop > draft. > > I will submit a new version of draft-ietf-spring-segment-routing-ldp-interop > not later than this week. > Thank you. Alia s. > > > > 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’s Write-Up. I’ve 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’ll be on vacation the remainder of this week but will touch base with > the authors on Monday. > > > > Have a good vacation! > > > > Regards, > > Alia > > > > > > Thanks, > > Acee > > From: OSPF <ospf-bounces@ietf.org> on behalf of Alia Atlas < > akatlas@gmail.com> > > Date: Tuesday, May 30, 2017 at 10:35 PM > > To: OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-segment- > routing-extensions@ietf.org" <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" <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 <akatlas@gmail.com> wrote: > > As is customary, I have done my AD review of draft-ietf-ospf-segment-routing-extensions-16 > once publication has been requested. First, 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. 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 documents > from SPRING that this draft depends on do not adequately describe the use > 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 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 > disappointed and concerned about the document. I would strongly recommend > 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 > 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. 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-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 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-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? What is the expected behavior and assumptions by the > receiver? > > > > 5) Sec 3.4: What happens if an SRMS Preference TLV is advertised > without an SR-Algorithm TLV in the same scope? I see that it says "For the > purpose 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 part > 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 > advertising is needed. Obviously, this mechanism does allow the potential > shortening of the MPLS label stack at the cost of advertising multi-hop > explicit path 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-routing-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 refers > to the ldp-interop draft for further details - but obviously not about an > 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/Label > Range TLV, as defined in Section 3.2, is advertised, then the SR-Algorithm > 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 this > is in the same RI LSA as the SID/Label Range TLV was advertised & with the > 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 getting > 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 hurt > to remind readers that the length is just that of the value field - though > 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." and > "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. Again > "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). 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. 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 => 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. This > 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 indicate > 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-routing-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 rapid > 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 > if this is to reuse the same TLV for OSPFv3 so IPv6 can 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. > Similarly, please define "Prefix length: Length of the prefix" clearly. I > really don't understand what the benefit of having a TLV that pretends to > 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 > meaning 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 normative > 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, > the 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 set, > 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 > OSPF 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 be > distributed between areas and even redistributed between protocols, please > 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? Does > the SID/Label sub-sub-TLV indicate a single SID Index or Label that is used > 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 > Extended 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 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 the > 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 the > 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 > source 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 network > operator should be clear as well as the consequences of not conforming. > > > > 24) Sec 10: The Implementation Status section should indicate that it > is to be removed before publication as an RFC. Also, the complete > 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" > > > > 2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV > as 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])." Please > 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 > > > > > > > > > >
- [OSPF] AD review of draft-ietf-ospf-segment-routi… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Acee Lindem (acee)
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Stefano Previdi (sprevidi)
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Alia Atlas
- Re: [OSPF] AD review of draft-ietf-ospf-segment-r… Peter Psenak