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
