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 <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
