Really ? If in an implementation SID would be just a logical interface on a box doesn't it deserve to be both routable as well as have an arbitrary opaque ID assigned to it ?
On Fri, Dec 20, 2019 at 5:18 PM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > In my view – there is a fundamental difference. > > > > The stated rfc refers to a derived interface identifier – with an > interface identifier being a well defined concept in RFC4291 – it specifies > the actions taken on said interface identifier – it does not alter the > specification. > > > > Here – you have gone way beyond that. > > > > This actually eliminates the interface identifier from the address and > replaces the interface identifier with something that has no bearing on an > interface – that is a redefinition of the specification. > > > > Andrew > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, 20 December 2019 18:58 > *To:* Andrew Alston <andrew.als...@liquidtelecom.com> > *Cc:* Alexandre Petrescu <alexandre.petre...@gmail.com>; Gyan Mishra < > hayabusa...@gmail.com>; SPRING WG <spring@ietf.org>; Mark Smith < > markzzzsm...@gmail.com>; Pablo Camarillo (pcamaril) <pcama...@cisco.com> > *Subject:* Re: [spring] 64-bit locators > > > > > > Therefore – this redefines the address semantics – and that – should be > accompanied by an update to said drafts to avoid confusion and to avoid > potential future complications > > > > Please observe that we have a lot of IETF documents putting various stuff > into IPv6 128 bits. Take rfc7599 as an easy example. Where do you see > anyone in IETF requested to update IPv6 base specs when any of such > documents were going via standards track ? > > > > Cheers, > R. >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
