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

[Peter Psenak <[e-mail]>]

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.


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