Not quite, but close.
Routers which are not upgraded, and receive packets with the new
ethertype, will drop them. Which theoretically is fine for routers
which are not intended to be on SRv6 paths. Practically, since you want
to be able to run the paths where you need them, you probably do need to
upgrade all routers to accept and propagate the new ethertype if you
want to use this solution. For some operators, that is a show stopper
and they will not use this capabilities. For others, it is quite
deployable, and even helpful in keeping control of what servicces are
offered where.
Yours,
Joel
On 3/29/2023 12:00 PM, Muthu Arul Mozhi Perumal wrote:
So, using the new ethertype inside a (closed/open) domain would
require all IPv6 routers inside the domain to support SRv6 or at least
support the new ethertype to check if any IPv6 packet containing an
SRH was received with this ethertype? If an IPv6 router
supports neither, then one cannot enable this feature on any of its
neighbor's interface, right?
Regards,
Muthu
On Wed, Mar 29, 2023 at 5:40 PM Robert Raszuk <rob...@raszuk.net> 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 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
_______________________________________________
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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
