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 <[email protected]> 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 <[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
