Subject: [spring] Issue re PHP specification in SPRING drafts

From: Eric C Rosen <[email-masked]>
Date: Fri, 26 Feb 2016 08:44:04 -0500

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Feb 2016 16:09:27 +0100

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-masked]> wrote:

> extensions associate a P-flag with the prefix-SID.  From section 2.1.1.2 of
> draft-ietf-isis-segment-routing-extensions:
>
> 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:
>
> 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.
>
> 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:
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>