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 <rob...@raszuk.net> 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 <hayabusa...@gmail.com> 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 <j...@joelhalpern.com> >> 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)" >>> <spring-boun...@ietf.org on behalf of xiejingr...@huawei.com> 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:spring-boun...@ietf.org] On Behalf Of Joel >>> M. Halpern >>> > Sent: Wednesday, December 11, 2019 10:55 AM >>> > To: spring@ietf.org >>> > 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 >>> > spring@ietf.org >>> > https://www.ietf.org/mailman/listinfo/spring >>> > >>> > _______________________________________________ >>> > spring mailing list >>> > spring@ietf.org >>> > 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 >>> > spring@ietf.org >>> > https://www.ietf.org/mailman/listinfo/spring >>> > >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> 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: 301 502-1347 >> >> Email: gyan.s.mis...@verizon.com >> >> www.linkedin.com/in/networking-technologies-consultant >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> 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: 301 502-1347 Email: gyan.s.mis...@verizon.com www.linkedin.com/in/networking-technologies-consultant
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
