Subject: Re: [spring] Is srv6 PSP a good idea

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 13 Dec 2019 22:14:08 +0000

I agree 100% with Jingrong,

PSP allows us to bring SRv6 to legacy PE devices that are not capable of processing the SRH in the dataplane, but are capable of supporting SRv6 in the control plane.
 
See this example:
I am streaming traffic from a server to a customer;
The ingress PE (near the server) encapsulates the packet and adds an SRH with a low-latency list of segments;
The penultimate node in the SRH executes PSP;
The egress PE (near the customer) decapsulates the IPv6 header and forwards the inner packet to the customer.
 
We can include SLA unidirectionally from the server to the customer even though that the egress PE has a legacy ASIC. Legacy equipment are a reality and are not easy to replace, hence interoperability with brownfield is key for any innovative approach.

dan 

On 2019-12-10, 11:15 PM, "spring on behalf of Xiejingrong (Jingrong)" <[email-masked] on behalf of [email-masked]> wrote:

    I think it's a good idea.
    Nothing new, but benefits that people have already said seems notable to me.
    
    (1) reduce the load of final destination. This benefit can be notable for the following sub reasons.
    (1.1) final destination tends to have heavy load. It need to handle all the EHs and do the delivery/demultiplex the packet to the right overlay service.
    (1.2) example 1, the final destination may need to handle the DOH after the RH.
    (1.3) example 2, the final destination may need to do the assembly of fragmented packets.
    (1.4) example 3, the final destination may need to do AH/ESP after the Fragmentation Header.
    (1.5) example 4, the final destination may need to deliver the packet to the right overlay service.
    
    (2) support the incremental deployment when final destination(s) do not process/recognize SRH. This benefit can be notable for the following sub reasons.
    (2.1) A core router may (fan-out) connected with a big number of low-end routers that do not support SRH but support tunnel-end/service-demultiplex function of SRv6.
    
    Thanks
    Jingrong
    
    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Wednesday, December 11, 2019 10:55 AM
    To: [email-masked]
    Subject: [spring] Is srv6 PSP a good idea
    
    For purposes of this thread, even if you think PSP violates RFC 8200, let us assume that it is legal.
    
    As I understand it, the PSP situation is:
    o the packet arrives at the place (let's not argue about whether SIDs are locators) identified by the SID in the destination address field o that SID is the next to last SID in the SID list o that sid is marked as / known to be PSP o at the intended place in the processing pseudocode, the last (first) entry in the SRH is copied into the destination IPv6 address field of the packet
    -> The SRH being used is then removed from the packet.
    
    In order to evaluate whether this is a good idea, we have to have some idea of the benefit.  It may be that I am missing some of the benefit, and I would appreciate clarification.
    As far as I can tell, the benefit of this removal is that in exchange for this node doing the work of removing the SRH, the final node in the SRH does not have to process the SRH at all, as it has been removed.
    
    I have trouble seeing how that work tradeoff can be beneficial. 
    Removing bytes from the middle of a packet is a complex operation. 
    Doing so in Silicon (we expect this to be done in the fast path of significant forwarders as I understand it) requires very special provision.  Even in software, removing bytes from the middle of a packet requires somewhere between some and a lot of extra work.  It is distinctly NOT free.
    
    In contrast, we have assumed that the work of processing SRH itself is tractable, since otherwise all of SRv6 would be problematic.  So why is this necessary.
    
    Yours,
    Joel
    
    PS: Note that both the MPLS case and the encapsulation case are very different in that the material being removed is at the front of the IP packet.  Pop or prepend are MUCH easier than middle-removal (or middle-insertion).
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Dec 2019 17:25:33 -0500

That is an udnerstandable argument, ... except:

It does not acknowledge that there is a cost for this capability, or 
discuss the tradeoff.  PSP clearly has a cost.

Also, that does not match my reading of the definition of the SR domain. 
  In fact, it becomes very confusing as to whether the PE is or is not 
part of the SR domain, since there is nothing in that scenario that 
requires any control participation from the egress PE.   Many of the 
SRv6 arguments rely heavily on the notion of domain.   Blurring that 
boundary makes things quite confusing.  For example, if the egress PE 
does not understand SRv6 data plane behavior, can it enforce teh 
requisite boundary properties?

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Dec 2019 12:10:16 -0500

Dan

The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
historical meaning as well as real consequences as far as a packet walk
through an mpls network.

>From a historical perspective which is really the correct way to look at
PHP in the MPLS world was designed by the developers of MPLS 25+ years ago
for the following reason.  Back then,  asic chipsets used by the MPLS
forwarding plane did not have the horsepower to pop the topmost ldp label
along with all services bottom of stack labels.

For that reason alone the MPLS developers back then came up with the PHP
concept.

In essence what that did was allow the ldp topmost label to be popped one
hop prior to the egress LSR PE node on the egress P node.

What that did was offload the entire burden of popping the entire label
stack done on the PE ultimate hop router to now be offset by one less label
to pop.  Back then that was a big deal and important for processing label
switched packets at high rates.

PSP became the default standard across all vendors and platforms “implicit
null label reserved value 3”

There was a double edged sword that came about from the PSP process.

As mpls became mainstream so did customer SLA and so end to end QOS became
the forefront importance to all service providers.

The major problem in the MPLS world that came about with PSP is that when
you pop that label at the egress PE 1 hop before the ultimate hop.  What
that did is the PE-P link the packet is forwarded without the ldp topmost
label intact preserved which contained the EXP bits for end to end QOS
scheduling.

A workaround fix to this issue was to institute a new feature called
“explicit null reserved label value 0”.  This was implemented using a QOS
policy called “pipe mode” that allowed the topmost label to now be
preserved and “ultimate” hopped which we today call UHP “Ultimate Hop POP”.

Another industry development that came about to get around the complexity
of pipe mode QOS policy to UHP was a enlightening concept but unfortunately
did not work for all use cases.

So the new feature that came about was the ability to schedule outbound on
each node in the operator MPLS core on both  on the topmost label EXP bits
of the topmost was present as well as on the preserved  inner header dscp
this dual PHB scheduling capability based on which outer header existed or
didn’t exist.   This worked for enterprises where you have trust
relationship with your customer or are a customer of yourself.

In the service provide area UHP ultimate hopping to preserve the ldp
topmost label became the general rule of thumb golden standard to meet
customer SLAs of end to end QOS.

Coming back full circle to SRV6.

The concept of PSP was added to SRv6 I believe to provide parity for
operators learning curve as well as similarities as SRV6 would be the
replacement to mpls.

Based on what I have stated above providing history of PHP and how it came
about ; and now adding this truly legacy function to a NG protocol such as
SRv6 to me does not make sense.

I don’t see the necessity to add just for the sake of adding or providing
parity to a soon to be legacy protocol.

I would like to see some technical justification as to why PSP is necessary
with our modern day routers to this in the PR spec.

Warm regards,

Gyan

On Fri, Dec 13, 2019 at 5:25 PM Joel M. Halpern <[email-masked]> wrote:

> > PSP allows us to bring SRv6 to legacy PE devices that are not capable of
> processing the SRH in the dataplane, but are capable of supporting SRv6 in
> the control plane.
> >
> > See this example:
> > The egress PE (near the customer) decapsulates the IPv6 header and
> forwards the inner packet to the customer.
> >
> > We can include SLA unidirectionally from the server to the customer even
> though that the egress PE has a legacy ASIC. Legacy equipment are a reality
> and are not easy to replace, hence interoperability with brownfield is key
> for any innovative approach.
> >
> > dan
> >
> > On 2019-12-10, 11:15 PM, "spring on behalf of Xiejingrong (Jingrong)" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >      (1.1) final destination tends to have heavy load. It need to handle
> all the EHs and do the delivery/demultiplex the packet to the right overlay
> service.
> >      (2) support the incremental deployment when final destination(s) do
> not process/recognize SRH. This benefit can be notable for the following
> sub reasons.
> >      (2.1) A core router may (fan-out) connected with a big number of
> low-end routers that do not support SRH but support
> tunnel-end/service-demultiplex function of SRv6.
> >
> >      Thanks
> >      Jingrong
> >
> >      o the packet arrives at the place (let's not argue about whether
> SIDs are locators) identified by the SID in the destination address field o
> that SID is the next to last SID in the SID list o that sid is marked as /
> known to be PSP o at the intended place in the processing pseudocode, the
> last (first) entry in the SRH is copied into the destination IPv6 address
> field of the packet
> >      In order to evaluate whether this is a good idea, we have to have
> some idea of the benefit.  It may be that I am missing some of the benefit,
> and I would appreciate clarification.
> >      As far as I can tell, the benefit of this removal is that in
> exchange for this node doing the work of removing the SRH, the final node
> in the SRH does not have to process the SRH at all, as it has been removed.
> >
> >      Doing so in Silicon (we expect this to be done in the fast path of
> significant forwarders as I understand it) requires very special
> provision.  Even in software, removing bytes from the middle of a packet
> requires somewhere between some and a lot of extra work.  It is distinctly
> NOT free.
> >
> >      In contrast, we have assumed that the work of processing SRH itself
> is tractable, since otherwise all of SRv6 would be problematic.  So why is
> this necessary.
> >
> >      Yours,
> >      Joel
> >
> >      PS: Note that both the MPLS case and the encapsulation case are
> very different in that the material being removed is at the front of the IP
> packet.  Pop or prepend are MUCH easier than middle-removal (or
> middle-insertion).
> >
> >      External Email: Please use caution when opening links and
> attachments / Courriel externe: Soyez prudent avec les liens et documents
> joints
> >
> >
> >
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 Dec 2019 21:00:08 +0100

Gyan,

Do you think that sending the exact same email twice by copy and paste
makes it any more valid ?

All,

To all opponents of PHP - let me refresh you with a bit of SR history. SR
assumed that most of the operational behaviour will be SID type agnostic.
Regardless if I use MPLS SID or IPv6 SID there should be no difference in
the operational model.

SR PHP is not being defined in NP draft. It has been there since day one
and I suppose it suddenly become the target of attacks perhaps due to no
better one available :). That's actually pretty good prove in itself that
document is really solid and ready to progress.

Where were you all when IGP extensions were defined ? Take RFC8667 - it
passed all IETF standards process - it defines Prefix-SID TLV and P-flag
there. It defines how to use PHP with mapping server in place.

NP draft does actually a courtesy to the implementors to clearly define
expected behaviours when using SR-v6. The PHP can be removed from it making
it less complete, but that will in no way change anything to the rest of
the SR specs in terms of PHP with both MPLS and IPv6.

Last - think of using SRv6 path steering for IoT devices. Every operation
you save there is a huge gain. Segment endpoints may not always be routers
and switches and may not even have slow path processing option.

Best,
Robert.

On Sun, Dec 15, 2019 at 6:10 PM Gyan Mishra <[email-masked]> wrote:

> you pop that label at the egress PE 1 hop before the ultimate hop..  What
> I would like to see some technical justification as to why PSP is
> necessary with our modern day routers to this in the PR spec.
>
> Warm regards,
>
> Gyan
>
>> > PSP allows us to bring SRv6 to legacy PE devices that are not capable
>> of processing the SRH in the dataplane, but are capable of supporting SRv6
>> in the control plane.
>> >
>> > See this example:
>> > We can include SLA unidirectionally from the server to the customer
>> even though that the egress PE has a legacy ASIC. Legacy equipment are a
>> reality and are not easy to replace, hence interoperability with brownfield
>> is key for any innovative approach.
>> >
>> > dan
>> >
>> >      (1.1) final destination tends to have heavy load. It need to
>> handle all the EHs and do the delivery/demultiplex the packet to the right
>> overlay service.
>> >      (2) support the incremental deployment when final destination(s)
>> do not process/recognize SRH. This benefit can be notable for the following
>> sub reasons.
>> >      In contrast, we have assumed that the work of processing SRH
>> itself is tractable, since otherwise all of SRv6 would be problematic.  So
>> why is this necessary.
>> >
>> >      Yours,
>> >      Joel
>> >

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Dec 2019 16:06:41 -0500

Robert

Thank you for your candid and concise response.

Your response is exactly what I was looking for from Spring.

There has been a lot of development across almost every IETF WG related to
the SR specification for years now and I was not there Day 2 and even for
many of the former years during the initial SR development.

I believe consistency is important to any specification so as you stated
PHP has been there day 1.

I don’t see a necessity  to remove from PR draft as it would break I
believe is critical parity across all SR related protocols and WGs.

Kind regards,

Gyan

On Sun, Dec 15, 2019 at 3:00 PM Robert Raszuk <[email-masked]> wrote:

>> PSP became the default standard across all vendors and platforms
>> “implicit null label reserved value 3”
>>
>> As mpls became mainstream so did customer SLA and so end to end QOS
>> became the forefront importance to all service providers.
>>
>> So the new feature that came about was the ability to schedule outbound
>> on each node in the operator MPLS core on both  on the topmost label EXP
>> bits of the topmost was present as well as on the preserved  inner header
>> dscp this dual PHB scheduling capability based on which outer header
>> existed or didn’t exist.   This worked for enterprises where you have trust
>> Based on what I have stated above providing history of PHP and how it
>> came about ; and now adding this truly legacy function to a NG protocol
>> such as SRv6 to me does not make sense.
>>
>>> > On 2019-12-10, 11:15 PM, "spring on behalf of Xiejingrong (Jingrong)"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>> >
>>> >      Doing so in Silicon (we expect this to be done in the fast path
>>> of significant forwarders as I understand it) requires very special
>> 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
>> FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Dec 2019 14:53:21 +0000

Daniel,

This use-case is interesting and may justify PHP. Allow me to ask a few questions about it:

1) When the payload arrives at the final segment endpoint, it is encapsulated in IPv6. There are no extension headers between the IPv6 header and the payload, as the SRH has been removed. Do I have that much right?

2) Does the IPv6 Destination Address represent an interface on the final segment endpoint? Or does it represent an instruction instantiated on the final segment endpoint? If the later, what kind of instructions can it represent?

3) Is the final segment always an adjacency segment? Or can it be an node segment?

                                                                                                                                  Happy holidays,
                                                                                                                                        Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Voyer, Daniel
Sent: Friday, December 13, 2019 5:14 PM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: [spring] Is srv6 PSP a good idea

 
See this example:
I am streaming traffic from a server to a customer; The ingress PE (near the server) encapsulates the packet and adds an SRH with a low-latency list of segments; The penultimate node in the SRH executes PSP; The egress PE (near the customer) decapsulates the IPv6 header and forwards the inner packet to the customer.

dan 

    

    Thanks
    Jingrong
    
    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Wednesday, December 11, 2019 10:55 AM
    To: [email-masked]
    Subject: [spring] Is srv6 PSP a good idea

    

    
    Yours,
    Joel

    _______________________________________________
    spring mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XgiVQSDxI6sGR3TIAfdOZqcIaUfnd08IJjdwQTSxfNVI3DFpiBWIb4eGReqszq9W$ 
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XgiVQSDxI6sGR3TIAfdOZqcIaUfnd08IJjdwQTSxfNVI3DFpiBWIb4eGReqszq9W$ 
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XgiVQSDxI6sGR3TIAfdOZqcIaUfnd08IJjdwQTSxfNVI3DFpiBWIb4eGReqszq9W$