Archive

Darren, could you please comment on the behavioral / deployment 
implications I believe I identified in my recent email about the use 
case?  It does seem to me that something needs to be said about the 
implications of the use case.  Yes, we do sometimes make allowances in 
protocol design for deficient but complaint implementations.  But we do 
not pretend that there are not issues when doing so.  And we try to 
identify the needs clearly.

Yours,
Joel

On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
> Hi Ron
> 
> I don’t think you are really asking equipment vendors to provide that 
> information on this list.  That will not happen.
> 
> I’ll simply repeat what has been stated by others on this list.
> Products with limited ability to receive and process a packet containing 
> a RH when SL==0 exist.
> PSP provides a means of allowing those products to be used as a PE.
> 
> Thanks
>    Darren
> 
>> On Mar 4, 2020, at 3:01 PM, Ron Bonica 
>> <rbonica=40juniper.net@dmarc.ietf.org 
>> <mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote:
>>
>> Andy,
>> AFAIKS, the only use case PSP is to accommodate SRv6 egress nodes that:
>>
>>   * Can process an SRv6  SID that appears in the IPv6 Destination Address
>>   * Can process the SRH with Segments Left equal to 0
>>   * But cannot process the SRH with Segments Left equal to 0 at high speed
>>
>> I am not aware that any such device exists. Does anybody know of one?
>>                                                    Ron
>> *From:*Andrew G. Malis <agmalis@gmail.com <mailto:agmalis@gmail.com>>
>> *Sent:*Tuesday, March 3, 2020 6:28 PM
>> *To:*Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>> *Cc:*Ron Bonica <rbonica@juniper.net 
>> <mailto:rbonica@juniper.net>>;bruno.decraene@orange.com 
>> <mailto:bruno.decraene@orange.com>;spring@ietf.org 
>> <mailto:spring@ietf.org>; Joel M. Halpern <jmh@joelhalpern.com 
>> <mailto:jmh@joelhalpern.com>>; Martin Vigoureux 
>> <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>>
>> *Subject:*Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>> MPLS PHP was invented to solve a particular issue with some forwarding 
>> engines at the time - they couldn't do a final pop followed by an IP 
>> lookup and forward operation in a single forwarding cycle (it would 
>> impact forwarding speed by 50% best case). 20 years later, is this 
>> still an issue at the hardware/firmware level? If so, affected 
>> implementers should speak up, otherwise there's really no need for PSP.
>> Cheers,
>> Andy (who was there at the time)
>> On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <robert@raszuk.net 
>> <mailto:robert@raszuk.net>> wrote:
>>
>>     Hi Ron,
>>     >   MPLS PHP is a clear case of de-encapsulation.
>>     Purely looking at technical aspect that is not true at all.
>>     MPLS PHP does not remove label stack. MPLS PHP is just used to pop
>>     last label. After MPLS PHP packets continue with remaining label
>>     stack to the egress LSR (example L3VPN PE).
>>     >  I don't think that you can compare MPLS PHP with SRv6 PSP
>>     But I agree with that. Both operations have very little in common
>>     from packet's standpoint or forwarding apect. Well maybe except
>>     "penultimate" word :)
>>     Kind regards,
>>     R.
>>     On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica
>>     <rbonica=40juniper.net@dmarc.ietf.org
>>     <mailto:40juniper.net@dmarc.ietf.org>> wrote:
>>
>>         Folks,
>>
>>         I don't think that you can compare MPLS PHP with SRv6 PSP.
>>         MPLS PHP is a clear case of de-encapsulation. We do that all
>>         the time. In SRv6 PSP, we are removing something from the
>>         middle of a packet. That is quite a different story.
>>
>>                                                                      
>>                                                                      
>>                   Ron
>>
>>     _______________________________________________
>>     spring mailing list
>>     spring@ietf.org <mailto:spring@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/spring
>>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$>
>>     Juniper Business Use Only
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org <mailto:spring@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spring
> 