Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is equal to
0. So, when the SRH is removed, O-flag functionality isn't available at the
ultimate segment endpoint.
Ron
From: spring <spring-boun...@ietf.org> On Behalf Of Greg Mirsky
Sent: Friday, February 28, 2020 11:22 AM
To: Robert Raszuk <rob...@raszuk.net>
Cc: John Scudder <jgs=40juniper....@dmarc.ietf.org>; SPRING WG
<spring@ietf.org>; 6man WG <i...@ietf.org>
Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-10.txt
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<mailto: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<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<mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>
--------------------------------------------------------------------
Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
