Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 14 Jun 2017 13:13:45 +0000

> On May 31, 2017, at 4:34 PM, Alia Atlas <[email-masked]> wrote:
> 
> Hi Acee,
> 
> On Wed, May 31, 2017 at 10:11 AM, Acee Lindem (acee) <[email-masked]> 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.

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 <[email-masked]> on behalf of Alia Atlas <[email-masked]>
> Date: Tuesday, May 30, 2017 at 10:35 PM
> To: OSPF WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "Alvaro Retana (aretana)" <[email-masked]>, Deborah Brungard <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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 <[email-masked]> 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
> 
> 
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Jun 2017 10:22:32 -0400

On Wed, Jun 14, 2017 at 9:13 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

> > 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.
> >
> 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.
>

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:
> >
> > To: OSPF WG List <[email-masked]>, "draft-ietf-ospf-segment-
> [email-masked]" <draft-ietf-ospf-segment-
> [email-masked]>, "Alvaro Retana (aretana)" <[email-masked]>,
> Deborah Brungard <[email-masked]>
> > 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.
> >
> > 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.
> >
> > 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?
> >
> >    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.
> >
> >       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?
> >
> >   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.
> >
> >    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:
> >
> >   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.
> >
> > 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."
> >
> > 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.
> >
> >       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:
> >
> > 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
> >
> >
> >
> >
>
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 23 Jun 2017 12:14:34 +0200

Hi Alia,

thanks for comments, please see inline:

On 31/05/17 04:05 , Alia Atlas 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.
>
> 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.
>
> 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.
>
> which has now existed for this draft for 3 years.  I do know that there
> are implementations,
> 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.

I don't know how to resolve this. I can not tell any of the coauthors 
that I'm going to drop him from the list after his contribution to this 
for several years. Two of us are marked as editors already.

>
> 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
>   Unfortunately, when I look there for the definition of a mirroring
> context, it doesn't exists.

Section 6 was removed.

> are considerable differences.

fixed

>     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.

I replaced it with RFC7855.

> SR-Algorithm TLV?  What is the expected behavior and assumptions by the

These are independent TLVs. Both are optional and there is no dependency 
between them.

> without an SR-Algorithm TLV in the same scope?

SRMS Preference TLV is independent of the SR-Algorithm TLV.

The fact that SRMS provides mapping between addresses and SIDs, does not 
require SRMS to support SR at all. SRMS functionality can be run on a 
node that is never in the data path and as such does not need to support SR.

> 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.

   "For the purpose of the SRMS
    Preference Sub-TLV advertisement, AS scope flooding is required."

above refers to a generic case, where the SRMS can be located anywhere 
in the network, which means it can be in a different area.

    "If
    the SRMS advertisements from the SRMS server are only used inside the
    area to which the SRMS server is attached, area scope flooding may be
    used."

Above says that if the usage of the SRMS advertisements is bound to an 
area, area flooding is sufficient.

I added some more text to the first part above to make it clear that the 
is referring to the multi-area case.

> 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.

sentence has been removed.

> 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.

section 6 has been removed.

> [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
> 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.

A new text has been added to filsfils-spring-segment-routing-ldp-interop 
to explain the SRMS better.

> 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

I removed the above sentence, it is not required. Following sentence in 
the draft clearly says:

"If the SR-Algorithm TLV is not advertised by the node, such node is 
considered as not being segment routing capable."

> 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?

please see above.

> 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.

I added "dependent on number of Algorithms advertised".

But I'm not sure why would we want to limit ourselves to 24 or any 
specific length.

> 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.

I change to REQUIRED.

I'm not sure why do we need to explain what happens if other scope is 
used, when we say what is REQUIRED. If someone uses link scope, 
information would not be propagated where it needs to be present. If 
someone uses AS scope the information would go to places where it is not 
needed. Do we need to say that explicitly in the draft? We used teh same 
wording in other RFCs, without describing what happens if the REQUIRED 
is not followed.

> multiple SID/Label sub-TLVs included in a single SID/Label Range TLV.

added text that the SID/Label sub-TLV MUST be included

I also added some text about handling of multiple SID/Label TLVs.

> 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.

I added "dependent on sub-TLVs.", which we used in rfc7684

> 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.

Added some text at the beginning of section 3.2.

>     Range 1: Range Size: 100   SID/Label sub-TLV: 100  => meaning [100, 199]

fixed.

> advertise overlapping ranges & how to handle the case when it does.
> This is required by draft-ietf-spring-conflict-resolution.

done.

> that the SR Local Block TLV MUST include a SID/Label sub-TLV nor
> indicate what to do if multiple are included.

added text that the SID/Label sub-TLV MUST be included

I also added some text about multiple SID/Label TLVs being present.

> The Length, again, isn't
> specified at all and clearly has at least a minimum.

I added "dependent on sub-TLVs.", which we used in rfc7684

> 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?

The need for advertisement is described in latest version of 
draft-ietf-spring-segment-routing-mpls.

I also modified the text in OSPF draft to better describe the need for 
advertisemement.

> normal OSPF dampening - it'd be nice to note that somewhere - since
> rapid sequential allocation may not provide the reporting speed anticipated.

SRLB is something that is either configured or eventually tight to a 
platform. In neither case, this is not expected to change frequently.

> 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.

This mirrors what we have done for OSPFv2 Extended Prefix TLV in RFC768. 
We defined these top level containers in a way that they are extendible 
for other AFs.

> Similarly, please define "Prefix length: Length of the
> prefix" clearly.

changed to "Length of prefix in bits." to mirror RFC768.

> 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.

I fixed the Address Prefix encoding text to mirror RFC7684.

> probably unlikely  with sub-TLVs.

I added "dependent on sub-TLVs.", which we used in rfc7684

> meaning or action associated with it without including sub-TLVs?

no.

> Are
> there mandatory sub-TLVs?  What is a receiving router to do with it?

no. If it's empty, router just stores it in LSDB and do not use it for 
anything.

> 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.

replaced that text with a new one.

>     path to the prefix."  First, I assume this is "NP flag" because

corrected

> the E and NP flags...".

done

 >Third, the M flag must also be taken into
> account - given the text later in the section.

corrected

>           encoding the label value."

I added changed the text to:

"Prefix SID Sub-TLV is interpreted as a starting SID/Label value", which 
I believe should be sufficient.

> 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.
> 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.

section 6 was removed

> 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.

section 6 was removed

> Sub-TLV?   What does that mean?

SID/Label Binding TLV was removed.

> 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?

SID/Label Binding Sub-TLV was removed

> there is a single correct value.

fixed.

> meaning - it'd be clearer to have them defined once.

done

> OSPF Extended Prefix Range TLV instead of an OSPF Extended Prefix TLV.

for simplicity we only want to use OSPF Extended Prefix Range TLV when 
advertising SRMS mapping entries. It's the encoding we enforced for SRMS 
advertisement.

> I don't see how advertising prefixes from different route-types can work
> 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."

yes, that is correct. I added the above text to the draft.

> 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

I removed the above text.

> 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.

above text says that the prefix SID may come from different router then 
the one which is contributing to the best path, if the router that 
contributes to the best path is not advertising the SID. No assumption 
about multiple SIDs being the same is made.

> implementation part seems a bit dated - given the draft's technical
> changes in the last 2 years.

I added a sentence about this section being removed before publication.

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

fixed all of them
>     replace SID/Label TLV with SID/Label sub-TLV.

done.

> 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".

I updated the text to use the expanded name first time and use 
abbreviated name in other places.

thanks,
Peter

>
> Regards,
> Alia
>
>
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>