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

[Alia Atlas <[e-mail]>]

Hi Peter,

On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak <[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
>>
>
>