Hi Brian, Yes I am quite aware of lack of assurance from transit nodes for EHs.
But one could construct useful SRv6 packets without using SRH too. On new ethertype I fully second your "good luck" wishes. Cheers, R. On Thu, Mar 30, 2023, 10:26 Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > Robert, > > On 30-Mar-23 01:10, Robert Raszuk wrote: > > 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 > > Only if the SRv6-carrying IPv6 packet is encapsulated inside a normal IPv6 > packet. Otherwise, as we know from RFC 7872 and ongoing work, the Internet > is not transparent to IPv6 packets carrying "unknown" extension headers. > > Since that situation has been blocked for many years (and the equivalent > operational situation for unknown IPv4 options has been blocked for many > more years), I think the fact that SRv6 semantics are local within a trust > boundary is unlikely to change. > > (As for deploying a new Ethertype on every switch and router in the world, > well, good luck with that, since it will be as hard as deploying IPv6, > which we have still only achieved to 42.95% according to Google's graph for > March 25.) > > Regards > Brian > > > 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 > <mailto:markzzzsm...@gmail.com>> wrote: > > > > On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <rob...@raszuk.net > <mailto: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 <mailto: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 <mailto:kireeti.i...@gmail.com>> wrote: > > >>> > > >>> On Mar 28, 2023, at 11:24, Adrian Farrel <adr...@olddog.co.uk > <mailto: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 > > >>> spring@ietf.org <mailto:spring@ietf.org> > > >>> https://www.ietf.org/mailman/listinfo/spring < > https://www.ietf.org/mailman/listinfo/spring> > > >> > > >> _______________________________________________ > > >> spring mailing list > > >> spring@ietf.org <mailto:spring@ietf.org> > > >> https://www.ietf.org/mailman/listinfo/spring < > https://www.ietf.org/mailman/listinfo/spring> > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org <mailto:spring@ietf.org> > > > https://www.ietf.org/mailman/listinfo/spring < > https://www.ietf.org/mailman/listinfo/spring> > > > > > > _______________________________________________ > > Int-area mailing list > > int-a...@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
