Re: [spring] Is srv6 PSP a good idea

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>>
>> 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 <[e-mail]>
>> wrote:
>>
>>> 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
>>>
>>> On 12/13/2019 5:14 PM, Voyer, Daniel wrote:
>>> > 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)"
>>> <[e-mail] on behalf of [e-mail]> 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:[e-mail]] On Behalf Of Joel
>>> M. Halpern
>>> >      Sent: Wednesday, December 11, 2019 10:55 AM
>>> >      To: [e-mail]
>>> >      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
>>> >      [e-mail]
>>> >      https://www.ietf.org/mailman/listinfo/spring
>>> >
>>> >      _______________________________________________
>>> >      spring mailing list
>>> >      [e-mail]
>>> >      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
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > spring mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/spring
>>> >
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>> --
>>
>> Gyan S. Mishra
>>
>> IT Network Engineering & Technology
>>
>> Verizon Communications Inc. (VZ)
>>
>> 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: [phone]
>>
>> Email: [e-mail]
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

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