Nope, that is completely not what I have in mind, Please remember that transit nodes are not SRv6 aware in closed or open domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink to my MEC or private DC where services are being properly demuxed based on the SID/uSID.
If you close this date plane option by new ethertype my car is disconnected, So I am not sure who is "incredibly naive" here or perhaps to put it a bit more politely who does not understand the power of new technology. Regards, R. On Wed, Mar 29, 2023 at 5:02 AM Mark Smith <markzzzsm...@gmail.com> wrote: > On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <rob...@raszuk.net> wrote: > > > > Guys, > > > > What you are really saying here is that the concept of using network > programmability should be killed and we should get stuck for decades to > come with closed domains only innovation. > > > > I find it quite disturbing especially as we are talking about Internet > Engineering Task Force produced standards here. > > > > Yes it has been derailed {not to say hijacked} into standardization of > private extensions for various protocols which are limited to closed > domains as the technology of new forwarding paradigm called MPLS simply by > design was not applicable to be deployed in the open Internet. But that > should not mean we should get stuck with this till new generation > understands mistakes made and moves forward, > > > > It is obvious that those who invested heavily in MPLS will fight to > protect it no matter what. But new technologies and services are being > deployed over SRv6 using native IPv6 dataplane. Examples are mobile nodes > which move from network to network. > > > > Is this closed domain - no by any means. Is it working today - yes > pretty well. > > > > So proposing a new ethertype for SRv6 today seems to be comparable to > putting a stick into the wheels of a cool bicycle starting to gain speed. > > > > If you believe one network operator is going to let another network > operator program the first network operator's network, then I think > you're incredibly naive about how the multi-party Internet is operated > and the security and availability concerns network operators have. > > > > > Respectfully to all td-srv6 authors and cheerleaders, > > Robert > > > > > > On Wed, Mar 29, 2023 at 1:58 AM Tony Przygienda <tonysi...@gmail.com> > wrote: > >> > >> Though I would like to cheer for Kireeti's 2. as well I think the point > of SHOULD is more realistic (for now) as Joel points out ... > >> > >> As to ethertype, I think grown-ups in the room were since long time > drily observing that a new IP version would have been appropriate after > enough > contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4 > were performed with drafts whose authors' list length sometimes rivaled > pages of content ;-) I think this ship has sailed and that's why after > some discussions with Andrew we went the ether type route as more > realistic. Additionally, yes, lots encaps (not encodings) carrying SRv6 > should get new codepoints if we are really serious about trusted domains > here. > >> > >> And folks who went the MPLS curve know that none of this is new, same > curve was walked roughly (though smoother, no'one was tempted to "hide > label stack in extension headers" ;-) and it would go a long way if > deploying secure SRv6 becomes as simple as *not* switching on "address > family srv6" on an interface until needed and then relying on BGP-LU (oops > ;-) to build according lookup FIBs for SRv6 instead of going in direction > of routers becoming massive wildcard matching and routing header processing > firewalls ... > >> > >> --- tony > >> > >> > >> > >> On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella < > kireeti.i...@gmail.com> wrote: > >>> > >>> On Mar 28, 2023, at 11:24, Adrian Farrel <adr...@olddog.co.uk> wrote: > >>> > >>> [Spring cc’ed because, well, you know, SR. I wonder whether 6man and > 6ops should care as well.] > >>> > >>> > >>> SPRING cc’ed because, you know, replying to Adrian’s email. Agree > that 6man and 6ops [sh|w]ould be interested. > >>> > >>> tl;dr > >>> > >>> I think this is a good initiative and worth discussion. Thanks > >>> > >>> for the draft. > >>> > >>> > >>> Agree. In particular: > >>> 1. There is an acknowledged security problem. Might be worth > summarizing, as it is central to this draft, but an example is in rfc > 8402/section 8. Section 3 of this draft (“The SRv6 Security Problem”) > doesn’t actually describe the security problem; Section 5 does, briefly. > >>> > >>> 2. The solution (using a new EtherType, SRv6-ET) is a good one. It’s > sad that this wasn’t done from the get-go, as the solution is a bit “evil > bit”-ish. I’d prefer to see ALL SRv6 packets (i.e., those containing SRH) > use SRv6-ET. Boundary routers SHOULD drop packets with SRv6-ET that cross > the boundary in either direction; all routers MUST drop packets with SRH > that don’t have SRv6-ET. Yeah, difficult, but the added security is worth > it. > >>> > >>> 3. Ease of secure deployment is a major consideration; this draft is a > big step in that direction. > >>> > >>> 4. As Adrian said, several nits. Will send separately to authors. > >>> > >>> Kireeti > >>> > >>> > >>> _______________________________________________ > >>> spring mailing list > >>> spr...@ietf.org > >>> https://www.ietf.org/mailman/listinfo/spring > >> > >> _______________________________________________ > >> spring mailing list > >> spr...@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spr...@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area