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
