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
