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

[Peter Psenak <[e-mail]>]

Hi Alia,

a new version of th draft-ietf-spring-segment-routing-ldp-interop has 
been posted, where the PHP behavior for SIDs adverised by SRMS has been 
clarified.

thanks,
Peter


On 18/09/17 17:47 , Alia Atlas wrote:
> Hi Peter,
>
> On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Alia,
>
>     thanks for comments, please see inline:
>
>     On 12/08/17 04:09 , Alia Atlas wrote:
>
>         As is customary, I have done another AD review
>         of draft-ietf-ospf-segment-routing-extensions-18. I do
>         appreciate the
>         improvements in the draft.
>
>         I do still see a few minor issues.  I would like to see a
>         revised draft
>         before IETF Last Call. I expect to progress this at an IESG telechat
>         with the primary spring documents, when Alvaro feels they are ready.
>
>
>         1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
>              Information LSAs that have different flooding scopes, the SR-
>              Algorithm TLV in the Router Information LSA with the narrowest
>              flooding scope SHOULD be used.  "
>              Given that the area-scope is REQUIRED - shouldn't this also
>         prefer
>              the area-scope?  Is there future-proofing being done?
>
>
>     link-local scope here does not really make much sense, so the
>     assumption was that it's either area or AS-scope, in which case
>     area-scope has narrower flooding scope. I'll clarify that in the text.
>
>
>
>         2) In Sec 3.4: "For the purpose of the SRMS Preference TLV
>         advertisement, AS-scoped flooding is REQUIRED.  This
>              is because SRMS servers can be located in a different area then
>              consumers of the SRMS advertisements.  If the SRMS
>         advertisements
>              from the SRMS server are only used inside the SRMS server's
>         area,
>              area-scoped flooding may be used."
>
>         REQUIRED is like MUST - I think you mean "AS-scoped flooded
>         SHOULD be
>         used.... area-scoped flooding MAY be used."
>
>
>     will change to SHOULD.
>
>
>
>         3) In Sec 4. "The Segment Routing Mapping Server, which is
>         described in
>              [I-D.ietf-spring-segment-routing-ldp-interop], is an
>         example where we
>              need a single advertisement to advertise SIDs for multiple
>         prefixes
>              from a contiguous address range."
>
>         I've read through the vastly improved section (thank you)
>         in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't
>         see any
>         explanation for why a contiguous address range is needed.
>
>         I can speculate that a primary purpose is to advertise SIDs for the
>         loopback addresses of routers that don't support SR - and those
>         loopback
>         addresses are likely to be allocated from a contiguous range
>         (though why
>         some wouldn't be supporting SR and cause gaps isn't clear).
>
>
>     range is an optimization similar to summarization. Instead of
>     advertising each individual prefix to SID mappings, we can advertise
>     single range with the starting SID. I referenced the
>     I-D.ietf-spring-segment-routing-ldp-interop, because SRMS is an
>     example where the range advertisements is clearly useful, although
>     it's not limited to to that case. One can use SRMS as a SID
>     provisioning tool.
>
>
>
>         4) Sec 5: In the end of Sec 4.2 in
>         draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR
>         mappings advertisements cannot set Penultimate Hop Popping.
>              In the previous example, P6 requires the presence of the
>         segment 103
>              such as to map it to the LDP label 1037.  For that reason,
>         the P flag
>              available in the Prefix-SID is not available in the
>         Remote-Binding
>              SID."
>         However, in this draft Sec 5 gives the following rules:
>
>         "As the Mapping Server does not specify the originator of a prefix
>         advertisement, it is not possible to determine PHP behavior
>         solely based
>         on the Mapping Server advertisement. However, PHP behavior SHOULD be
>         done in following cases: The Prefix is intra-area type and the
>         downstream neighbor is the originator of the prefix. The Prefix is
>         inter-area type and downstream neighbor is an ABR, which is
>         advertising
>         prefix reachability and is also generating the Extended Prefix
>         TLV with
>         the A-flag set for this prefix as described in section 2.1 of
>         [RFC7684].
>         The Prefix is external type and downstream neighbor is an ASBR,
>         which is
>         advertising prefix reachability and is also generating the Extended
>         Prefix TLV with the A-flag set for this prefix as described in
>         section
>         2.1 of [RFC7684].
>
>         These seem to be contradictory.
>
>
>     The text in draft-ietf-spring-segment-routing-ldp-interop-08 refers
>     to the fact that SRMS advertisements itself can not include PHP
>     signaling in the advertisement itself, like the regular SID
>     advertisement does, because SRMS is not the "owner" of the prefix.
>
>     The text in the draft-ietf-ospf-segment-routing-extensions-18
>     describes how the PHP can still be done for SIDs that come from the
>     SRMS adverisements, using additional information available to the
>     protocol - e.g. prefix owner.
>
>     I don't believe these contradict each other.
>
>
> I think this is the final issue to be resolved before I can put this
> into IETF Last Call.
>
> First, the OSPF document has to follow the architecture and behavior
> defined in the SPRING documents.
> This paragraph looks like a potential optimization that is not clearly
> articulated and directly contradicts the
> text in draft-ietf-spring-segment-routing-ldp-interop-08.
>
> The logic in the ldp-interop draft is so that the boundary router
> between segment-routing and LDP can do the mapping from segment-routing
> to LDP.
>
> In the paragraph above from the ospf draft, it is handling the edge case
> where the downstream neighbor originates the prefix, basically.  So -
> the signaling has no indication that PHP is desired but OSPF infers that
> it is based on topology and advertisements.
>
> The explanation for why this is correct behavior does need to exist -
> preferably in the ldp-interop draft - but simply having the unexplained
> rules in here will not make for good interoperability or
> comprehensibility of the segment-routing architecture.
>
> To be clear, I am fine with having the rules here - if the WG believes
> that they are desirable - but there must be an actual explanation as to
> why this works and doesn't need the top-level label mapping that
> ldp-interop refers to. I'd prefer to see that discussed in the
> ldp-interop, but if you think that the issue is IGP-specific, then I
> could see having it in this draft.
>
> While this may seem obvious to you as to why it is ok, this document and
> associated architecture needs to make sense and ensure interoperability
> for many other implementations where those developing are basing it on
> the standard.  For me, that means that if it isn't obvious to me after
> reading through all the related documents (as I have), then it is likely
> to not be obvious to others.
>
> Regards,
> Alia
>
>         5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
>              Prefix-SIDs for the same prefix, in which case the same
>         Prefix-SID
>              MUST be advertised by all of them."
>
>         What is forcing this constraint?  Does it work if the Prefix-SID
>         is an
>         index into an
>         SRGB or SRLB that is not the same value globally?
>
>
>     yes, it does. The SID value for the single prefix MUST be unique
>     though, otherwise we get into the conflict resolution area, that is
>     covered by the draft-ietf-spring-conflict-resolution.
>
>         I don't see it
>         specified in Sec 7.2 of
>         draft-ietf-spring-segment-routing-ldp-interop-08?
>
>
>     SR architecture assumes unique mapping of a SID to a prefix. If that
>     is not followed, draft-ietf-spring-conflict-resolution comes into
>     picture.
>
>     thanks,
>     Peter
>
>
>
>
>         Regards,
>         Alia
>
>
>