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
