Robert, the SRv6 SRH specification (and b derivation all the SRv6
related specifications) is explicit that it is for use in a limited
domain. It is not intended to allow or enable SRv6 to be sent over
arbitrary portions of the Internet without suitable encapsulation (and
probably at least authentication of that encapsulation.) While the use
of the Ethernet encaps strengthens taht and simplifies deployments, it
does not introduce the requirement. And I would be rather surprised
(but pleased) if we as a community were to deprecate the existing
structure for those operators who want to use it.
Yours,
Joel
On 3/29/2023 7:45 AM, Robert Raszuk 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.
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
_______________________________________________
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
