Greg, I agree. Moreover I would suggest to add such text that PSP endpoint behaviours should or must not be set for any OEM packets. Would that help ?
Thx, R. On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Robert, > you've asked about a possible operational drawback of PSP. I think that > for OAM PSP has decremental effect on the usefulness of performance > measurements as there's no obvious information to identify the path a > packet traversed. > > Regards, > Greg > > On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> Hi John, >> >> > I have an additional observation, or question, about Dan’s scenario. >> Almost all communication is bidirectional. >> > Presumably this means a router that’s the tail end of an SRv6 path in >> one direction is the head end in the other. >> >> While your observation is correct that most TCP connections are bidir SR >> in a lot of cases can operate only in one direction. Needless to say it can >> also be used with UDP streaming. >> >> To extend Ketan's OTT video example let me observe that in a lot of >> transactions queries from clients are tiny and do not TE capabilities while >> responses are huge and bursty and may indeed benefit from special handling. >> >> Sure if you think of applications like VPNs than you are right .. >> regardless of the size of the packets proper tagging must occur in either >> direction - but this is just one use of SRv6 perhaps not even the major >> one. >> >> - - - >> >> Now as one friend just asked me offline - putting all IPv6 dogmas aside - >> what is the technical issue with removing previously applied extension >> header from the packet within a given operator's network ? What breaks when >> you do that ? >> >> Thx, >> R. >> >> >> On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs= >> 40juniper....@dmarc.ietf.org> wrote: >> >>> I have an additional observation, or question, about Dan’s scenario.. >>> Almost all communication is bidirectional. Presumably this means a router >>> that’s the tail end of an SRv6 path in one direction is the head end in the >>> other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, >>> then we can extend Ron’s list with one more item. That is, apparently the >>> ultimate segment endpoint: >>> >>> • Can process a SID, received as an IPv6 DA, on the fast path >>> • Cannot process an SRH on receipt, even if Segments Left equal 0, on >>> the fast path. >>> • Can add an SRH on transmission, on the fast path >>> >>> Even though strictly speaking the second and third bullet points aren’t >>> mutually exclusive, it’s a little difficult to imagine a real router that >>> would have both these properties simultaneously. Perhaps I’m not being >>> creative enough in imagining deployment scenarios? Since this scenario is >>> claimed as an important reason this problematic feature is needed, it would >>> be great if someone who understands it would elucidate, thanks. >>> >>> One further point, Ron says “I wonder whether it is a good idea to >>> stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also >>> wonder this, especially because these devices will have a relatively >>> limited lifetime in the network.[*] I don’t find the cost/benefit >>> attractive of making a permanent detrimental change to the IPv6 >>> architecture to accommodate a temporary deployment issue. >>> >>> Regards, >>> >>> —John >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
