Even better ! Thank you, R.
On Fri, Feb 28, 2020 at 5:44 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Hi Robert, > thank you for you consideration. Pablo and I had discussed references to > OAM in the SRv6 network programming draft. Pablo and authors kindly agreed > to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we > are discussing the network programming > draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was > to work with the authors of SRv6 OAM draft on documenting its relationship > with PSP. Would that make sense? > > Regards, > Greg > > > > On Fri, Feb 28, 2020 at 8:37 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> 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
