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