Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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=
>> [e-mail]> 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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>