On Wed, 11 Dec 2019, 08:08 Robert Raszuk, <rob...@raszuk.net> 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 <markzzzsm...@gmail.com> > 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, <ek.i...@gmail.com> 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 <rob...@raszuk.net> >>> 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 >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
