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

[Alia Atlas <[e-mail]>]

Hi Acee,

On Wed, May 31, 2017 at 10:11 AM, Acee Lindem (acee) <[e-mail]> 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.  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 <[e-mail]> on behalf of Alia Atlas <
> [e-mail]>
> Date: Tuesday, May 30, 2017 at 10:35 PM
> To: OSPF WG List <[e-mail]>, "draft-ietf-ospf-segment-
> [e-mail]" <draft-ietf-ospf-segment-
> [e-mail]>, "Alvaro Retana (aretana)" <[e-mail]>,
> Deborah Brungard <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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 <[e-mail]> 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
>>
>>
>>
>