Joel, Let me observe that as it has been said already such end device may support SR but SRH above say N SIDs is handled only in slow path.
In the same time let me observe that while slow path may be just fine for a lot of time such device also is to receive 5 well engineered high bandwidth streams. So only for those 5 streams it is required to do PSP. IMO this is good enough reason to support it. Thx, R. On Fri, Feb 28, 2020 at 5:03 PM Joel M. Halpern <j...@joelhalpern.com> wrote: > While it is true that some traffic only needs steering in one direction, > I have real trouble figuring out how an operator would dare deploy an SR > edge device that could not steer incoming traffic. Either they do not > need SR, or they can expect that some traffic will need it in both > directions. So I am left supporting John's contention that there seems > to be a gap in how one would used the hypothesized device that needs > another device performing PSP. > > also, and edge device that requires PSP would place constraints on the > SRv6 traffic paths that could be used be used to it. One would have to > ensure that all SRv6 traffic ending there had a penultimate explicit hop > to a device that could perform PSP. Yes, this can be done. It does > seem to complicate life. Thus, yet another way that PSP adds > complications. > > Yours, > Joel > > On 2/28/2020 5:55 AM, Robert Raszuk 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 <mailto: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
