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

[Alexandre Petrescu <[e-mail]>]

Le 10/12/2019 à 22:02, Mark Smith a écrit :
> 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.

I think this is a joke :-)

I would like to remark though that the concept of using src multicast 
addresses might have some application which might not be able to be 
dealt with otherwise.

Alex

> 
> On Wed, 11 Dec 2019, 07:54 Erik Kline, <[e-mail] 
> <mailto:[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]
>     <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>