Hi Eric, sorry, I missed that one and will look into this asap. s.
> On May 9, 2016, at 4:36 PM, Eric C Rosen <[email protected]> wrote: > > A few months back I pointed out a couple of small issues that I think need to > be addressed in draft-ietf-spring-segment-routing. I still think they need to > be addressed. > > > On 2/26/2016 8:44 AM, Eric C Rosen wrote: >> There seems to be some inconsistency in the various documents about the way >> that penultimate hop popping is handled. >> >> When advertising a prefix-SID via OSPF, the OSPF Segment Routing extensions >> associate an NP-Flag with the prefix-SID. From section 5 of >> draft-ietf-ospf-segment-routing-extensions: >> >> If the NP-Flag is not set then any upstream neighbor of the >> Prefix-SID originator MUST pop the Prefix-SID. This is equivalent >> to the penultimate hop popping mechanism used in the MPLS >> dataplane. >> >> When advertising a prefix-SID via ISIS, the ISIS Segment Routing extensions >> associate a P-flag with the prefix-SID. From section 2.1.1.2 of >> draft-ietf-isis-segment-routing-extensions: >> >> If the P-flag is not set then any upstream neighbor of the >> Prefix-SID originator MUST pop the Prefix-SID. This is >> equivalent to the penultimate hop popping mechanism used in >> the MPLS dataplane which improves performance of the >> ultimate hop. >> >> These specs allow a node to REQUIRE its "upstream neighbors" on a given >> prefix segment to perform penultimate hop popping on any packet whose top >> label corresponds to a prefix-SID that has been advertised via ISIS or OSPF. >> >> The architecture document has a weaker requirement. From section 3.2.2 of >> draft-ietf-spring-segment-routing: >> >> The IGP signaling extension for IGP-Prefix segment includes >> the P-Flag. A Node N advertising a Prefix-SID SID-R for >> its attached prefix R resets the P-Flag to allow its >> connected neighbors to perform the NEXT operation while >> processing SID-R. This behavior is equivalent to >> Penultimate Hop Popping in MPLS. When set, the neighbors >> of N must perform the CONTINUE operation while processing >> SID-R. >> >> This could be interpreted as allowing the upstream neighbor to perform the >> CONTINUE operation even if the P-Flag is clear, which would mean that the >> choice of whether to do PHP is left to the neighbor. This seems to >> contradict the statements quoted above from the IGP documents. >> >> Shouldn't the architecture document be modified so that it says the same >> thing as the IGP documents? >> >> A related issue in the architecture document stems from the following >> passage from section 3.2.2 of the architecture document: >> >> o A node N attaching a Prefix-SID SID-R to its attached prefix >> R MUST maintain the following FIB entry: >> >> Incoming Active Segment: SID-R >> Ingress Operation: NEXT >> Egress interface: NULL >> >> If SID-R has been advertised in OSPF with the NP-flag clear, or if it has >> been advertised in ISIS with the P-flag set, there is no need for this FIB >> entry to be maintained. Perhaps the passage should actually read: >> >> o If a node N advertises Prefix-SID SID-R for a prefix R that >> is attached to N, N MUST either clear the P-Flag in the >> advertisement of SID-R, or else maintain the following >> FIB entry: >> >> Incoming Active Segment: SID-R >> Ingress Operation: NEXT >> Egress interface: NULL >> >> >> >> >> >> >> >> >> > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
