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

[Alia Atlas <[e-mail]>]

Hi Peter,

Excellent  - thanks.
I'll get this into IETF Last Call.

Regards,
Alia

On Fri, Sep 29, 2017 at 10:19 AM, Peter Psenak <[e-mail]> wrote:

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