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
> >>> spring@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/spring
> >>
> >> _______________________________________________
> >> 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
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
