Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

[Mark Smith <[e-mail]>]

On Wed, 11 Dec 2019, 08:08 Robert Raszuk, <[e-mail]> wrote:

>
> Well I take it as a joke ...
>


It's as serious as performing major updates on a packet and not updating
its source address.


as I am sure you are aware that SRH already contains those verbatim.
>
> PS.
>
> Note that SRm6 would require a local mapping database to decipher those in
> CRH.
>
> On Tue, Dec 10, 2019 at 10:02 PM Mark Smith <[e-mail]>
> wrote:
>
>> Perhaps we need to update RFC8200 and eliminate the source address field,
>> or at least update it so that it can hold a multicast address, indicating
>> the packet has multiple source devices.
>>
>> On Wed, 11 Dec 2019, 07:54 Erik Kline, <[e-mail]> wrote:
>>
>>> Ah right.
>>>
>>> Still, in terms of the things that could be relaxed in 8200, allowing
>>> the SRH to be treated more like a Hop-by-Hop header might be more palatable
>>> than things that change the effective MTU.
>>>
>>> On Tue, Dec 10, 2019 at 12:42 PM Robert Raszuk <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> The issue is that RFC8200 forbids even modification to any EH unless
>>>> the node is a destination node in top most IPv6 header.
>>>>
>>>>
>>>> If there were no resolution to the insertion question vis a vis RFC
>>>>> 8200, then would it then suffice to recommend that ingress nodes should
>>>>> include some padding for these non-SR midpoints to play with (iff. the
>>>>> network has such midpoints), and otherwise abide by RFC 8200?
>>>>>
>>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>