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

[Robert Raszuk <[e-mail]>]

Even better !

Thank you,
R.

On Fri, Feb 28, 2020 at 5:44 PM Greg Mirsky <[e-mail]> 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 <[e-mail]> 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 <[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
>>>> --------------------------------------------------------------------
>>>>
>>>