Eric,
> On Feb 26, 2016, at 2:44 PM, Eric C Rosen <ero...@juniper.net> 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, well, that’s not the intention. I’ll fix the text to make this 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? Yes. > 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 ok. I will update the doc. Thanks. s. > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
