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

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 May 2016 10:36:39 -0400

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
>
>
>
>
>
>
>
>
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 9 May 2016 16:06:05 +0000

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 May 2016 09:37:14 +0000

Eric,

> On Feb 26, 2016, at 2:44 PM, Eric C Rosen <[email-masked]> wrote:
> 
> 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.
> 

Yes.

>     Incoming Active Segment: SID-R

ok. 

I will update the doc.

Thanks.
s.