Hi Eric, Why don't we go a bit further on that and consider section 3.2.3 of arch draft:
3.2.3 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-06#section-3.2.3>. IPv6 Dataplane When SR is used over the IPv6 dataplane: o The Prefix-SID is the prefix itself. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ How do you define PHP when SR is used over v6 ? Is this removal of entire new v6 header if the new header was imposed by SR ingress node? Is it cleaning path list in the extension header ? Or is PHP you are referring to really PHP-for_SR_MPLS only and all text currently referring to PHP is only applicable to PHP-for_SR_MPLS ? Many thx, R. On Fri, Feb 26, 2016 at 2:44 PM, Eric C Rosen <[email protected]> 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
