On 1/17/22 09:57, Brandon Butterworth wrote:
Isn't the argument here that if it's in most chip sets already it might
reasonably be expected to be a standard low end feature by now, along
with IPv6?
That it isn't may be why people are open to SRv6 (I'm assuming some are
based on this
> Isn't the argument here that if it's in most chip sets already it might
> reasonably be expected to be a standard low end feature by now, along
> with IPv6?
>
> That it isn't may be why people are open to SRv6 (I'm assuming some are
> based on this discussion) - if they have to pay extra they
On Mon Jan 17, 2022 at 09:25:47AM +0200, Mark Tinka wrote:
> High-end IP routing features (which includes MPLS) have always attracted
> additional costs on what are meant to be Layer 2/3 switches.
Isn't the argument here that if it's in most chip sets already it might
reasonably be expected to
On 1/17/22 03:52, Colton Conor wrote:
I agree that pretty much all the chipsets and asics out there today
support MPLS, but it's the vendor and NOS that decides whether to
enable it or not, or charge more for it.
That has been the case since MPLS debuted.
Example, Junipers EX4600,
I agree that pretty much all the chipsets and asics out there today
support MPLS, but it's the vendor and NOS that decides whether to
enable it or not, or charge more for it.
Example, Junipers EX4600, QFX5100 and ACX5048 all have the same
Broadcom Trident II+ ASIC inside. One supports full MPLS
Hey Sabri,
Eventually they have implemented everything ;-)
Arista was a really special case, routing stack they acquired (NextHop) had no
mpls (quite some time ago), 90% of their revenue was coming from IP only
networks.
Life is good, MS is treating me well :).
Kids are growing, Marina’
Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC
(outside of niche HPC/IB cases).
SR in DC - with overlay starting on the host SR-MPLSoUDP(RFC8663) is a perfect
representation of a working technology that works in IP environment as well as
allows end2end programming
On Sat, 15 Jan 2022 at 19:22, Colton Conor wrote:
> True, but in general MPLS is more costly. It's available on limited
> devices, from limited vendors. Infact, many of these vendors, like
> Extreme, charge you if you want to enable MPLS features on a box
Marketing, not fundamentals. DC people
+1 Mark
There’s no modern silicon that doesn’t support MPLS (and is capable of imposing
at least 3 labels). There’s 0 additional price for vendors to enable MPLS on
their devices. The rest is subject to vendors’ licensing and is completely
artificial.
SR-MPLS uses MPLS data-plane and requires
On 1/15/2022 9:16 AM, Raymond Burkholder wrote:
On 1/15/22 10:22 AM, Colton Conor wrote:
True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.
And
On 1/15/22 21:16, Raymond Burkholder wrote:
And in this discussion group, when MPLS is mentioned, does that
include VPLS? Or do operators simply use MPLS and manually bang up
the various required point-to-point links? Or is there a better way
to do this?
For example, Free Range
On 1/15/22 19:22, Colton Conor wrote:
True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.
Well, I don't entirely agree.
Pretty much all
On 1/15/22 10:22 AM, Colton Conor wrote:
True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.
And in this discussion group, when MPLS is mentioned,
True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.
On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti wrote:
>
> On Thu, 13 Jan 2022 at 00:31, Colton Conor
On Thu, 13 Jan 2022 at 00:31, Colton Conor wrote:
> I agree it seems like MPLS is still the gold standard, but ideally I
> would only want to have costly, MPLS devices on the edge, only where
> needed. The core and transport devices I would love to be able to use
> generic IPv6 enabled switches,
On 1/13/22 00:28, Colton Conor wrote:
I agree it seems like MPLS is still the gold standard, but ideally I
would only want to have costly, MPLS devices on the edge, only where
needed. The core and transport devices I would love to be able to use
generic IPv6 enabled switches, that don't need
Hi Randy,
> this is quite true, and a serious issue. but it has a good side. if
> you run an ipv6 enebled network, you can deploy srv6 without enabling
> srv6 everywhere, only at the marking encaps or embed) points. nice for
> partial and/or incremental deployment.
Yep, that's what I like
I agree it seems like MPLS is still the gold standard, but ideally I
would only want to have costly, MPLS devices on the edge, only where
needed. The core and transport devices I would love to be able to use
generic IPv6 enabled switches, that don't need to support LDP. Low end
switches from
> What worries me more is the opportunity for adversaries to inject SRv6
> packets. MPLS is not enabled by default on most router interfaces, so
> an adversary would have to have access to an interface where MPLS
> processing is explicitly enabled. IPv6 packet processing on the other
> hand…
Thus spake Sander Steffann (san...@steffann.nl) on Wed, Jan 12, 2022 at
06:21:25PM +0100:
> Hi,
>
> > No SRv6 is MPLS labeling where label is carried inside IP instead
> > before the IP header. Layering violation which increases complexity
> > and cost for no other purpose except dishonest
Hi,
> No SRv6 is MPLS labeling where label is carried inside IP instead
> before the IP header. Layering violation which increases complexity
> and cost for no other purpose except dishonest marketing about 'it is
> IP, you already understand it, MPLS is hard'.
What worries me more is the
On Wed, 12 Jan 2022 at 18:20, wrote:
> Like ytti (saku) mentioned, with SR/SPRING the IGP is finally carrying the
> Label/Sid, so we no longer need a label distribution mechanism running
> alongside the IGP (don't need LDP or RSVP). And for SRv6 vice SR-MPLS, the
> SID is now the IPv6
: Wednesday, January 12, 2022 2:35 AM
To: Adam Thompson
Cc: NANOG
Subject: Re: SRv6 Capable NOS and Devices
On Wed, 12 Jan 2022 at 00:00, Adam Thompson wrote:
> My question is, why do you think you need Segment Routing at all? Is your
> network so enormously large and/or c
On Wed, 12 Jan 2022 at 00:00, Adam Thompson wrote:
> My question is, why do you think you need Segment Routing at all? Is your
> network so enormously large and/or complex that IS-IS (and/or MPLS-TE) isn't
> capable of handling it?
> So far, SR looks like a solution in search of a problem, at
On 1/11/22 23:57, Adam Thompson wrote:
My question is, why do you think you need Segment Routing at all? Is your
network so enormously large and/or complex that IS-IS (and/or MPLS-TE) isn't
capable of handling it?
So far, SR looks like a solution in search of a problem, at least to me.
On 1/11/22 19:20, Saku Ytti wrote:
And you have this use-case? And you can't use MPLSoUDP?
SRv6 is pure snake oil, an easy marketing story to people with limited
knowledge. 'It is just IP bro, you already know it'. I'd like to to
continue 'like already widely used X', but I don't dare,
On 1/11/22 17:16, Colton Conor wrote:
Has
anyone deployed this new technology?
I have heard of a network in Uganda that is running it.
The rest I've heard of are either in the lab, or some portions of their
network under testing.
If building a greenfield regional ISP network, would
My question is, why do you think you need Segment Routing at all? Is your
network so enormously large and/or complex that IS-IS (and/or MPLS-TE) isn't
capable of handling it?
So far, SR looks like a solution in search of a problem, at least to me.
I'm not saying you don't have a need for it,
On Tue, 11 Jan 2022 at 17:20, Colton Conor wrote:
> My understanding is that because it's using IPv6 in the dataplane, not
> all devices have to have SRv6 enabled. The in-between core devices
> just have to support IPv6, but not necessarily support SRv6. This is
> much different than traditional
❦ 11 January 2022 09:16 -06, Colton Conor:
> I know the SRv6 is a fairly new technology. I am wondering which
> vendors and network operating systems fully support SRv6 today? Has
> anyone deployed this new technology?
Cisco on NCS devices have full support of SRv6 F1 (End, End.X, End.T,
On 9/21/20 6:16 PM, Randy Bush wrote:
yes, privacy is one aspect of security. and, as mpls vns are not
private sans encryption, they are not secure.
randy
As my backyard is not surrounded by a cement enclosure with acoustic
baffling and white noise generators inside, it's not really
Lol
I was thinking that if I ever need to know about *anything*, I can now just
google "srv6 nanog"
- Aaron
On 22/Sep/20 00:06, Greg Shepherd wrote:
Call me old, but I miss the days when this thread was still on the SRv6 rails.
Can we get back the proper bashing to match this thread title?
Probably not off-topic, since vendors may push SRv6 as a(n) (MPLS) VPN
replacement and new money-maker
On Monday, 21 September, 2020 16:16, Randy Bush wrote:
>> I'm not sure what you're saying here, I never said MPLS VPNs are
>> secure, only private. I hope others recognise that they are
>> different concepts.
>yes, privacy is one aspect of security. and, as mpls vns are not
>private sans
james,
> I'm not sure what you're saying here, I never said MPLS VPNs are
> secure, only private. I hope others recognise that they are
> different concepts.
yes, privacy is one aspect of security. and, as mpls vns are not
private sans encryption, they are not secure.
randy
Call me old, but I miss the days when this thread was still on the SRv6 rails.
Can we get back the proper bashing to match this thread title?
-Shep
> On Sep 21, 2020, at 13:54, James Bensley wrote:
>
>
>
> On 19 September 2020 03:23:15 BST, Randy Bush wrote:
>>> Information can be in
On 19 September 2020 03:23:15 BST, Randy Bush wrote:
>> Information can be in plaintext and private
>
>Three can keep a secret, if two of them are dead. -- franklin
>
>i know you truely believe the tunnel k00laid. the security
>community does not.
Hi Randy,
I'm not sure what you're saying
On 21/09/2020 19:38, Randy Bush wrote:
> newspeak -- 1984
colloquialism
/kəˈləʊkwɪəlɪz(ə)m/
noun: a word or phrase that is not formal or literary and is used in
ordinary or familiar conversation.
--
Tom
> One thing that is true: not all present or historical definitions
> (or acceptable uses) of the word "private" strictly imply or infer
> privacy.
newspeak -- 1984
On 19/09/2020 03:23, Randy Bush wrote:
> i know you truely believe the tunnel k00laid. the security
> community does not.
At this point, I'm beginning to think that you're trolling us with the
assertion(s) that the 'P' in "Virtual Private Network" has obviously
meant "Privacy" all along, and/or
Mark,
> On 20 Sep 2020, at 13:02, Mark Tinka wrote:
>
>
>
> On 19/Sep/20 22:53, Valdis Kl ē tnieks wrote:
>
>> Are there any actual countries heading that way? Seems like most of them
>> insist
>> they have the ability to snoop unencrypted traffic (where "crypto that has a
>> baked-in
>>
On 19/Sep/20 22:53, Valdis Kl ē tnieks wrote:
Are there any actual countries heading that way? Seems like most of them insist
they have the ability to snoop unencrypted traffic (where "crypto that has a
baked-in
back door" counts as unencrypted).
Let's not give them a reason.
The most
On Thu, 17 Sep 2020 18:24:36 +0200, Mark Tinka said:
> On 17/Sep/20 17:56, mark seery wrote:
> > Perhaps all the more reason why end-to-end encryption should be part of the
> > buyer beware conversation (not arguing against operator encryption in saying
> > that - privacy is something everyone in
On 19/Sep/20 05:56, mark seery wrote:
While I get your point, and it is a good one, no. Once lawyers, finance, and
other functions get involved, it goes from being just another technology, to a
pain for suppliers and customers alike. Export laws complicate implementation,
and vendors can
>
> Sounds like you're making a/the case for MACSec :-).
>
While I get your point, and it is a good one, no. Once lawyers, finance, and
other functions get involved, it goes from being just another technology, to a
pain for suppliers and customers alike. Export laws complicate
> Information can be in plaintext and private
Three can keep a secret, if two of them are dead. -- franklin
i know you truely believe the tunnel k00laid. the security
community does not.
randy
On 18/09/2020 12:07, Mark Tinka wrote:
>
> There was a time when the use-case for MACSec was to move banks away
> from running their own DWDM/FC networks, and letting operators do it.
>
Well, the other use case is access networks with 802.1x. With 802.1x as
long as the port stays up the
aar...@gvtc.com писал 2020-09-15 20:31:
Hi Aaron,
Also, with VPN's over SRv6
would this enable automatic vpn capability over the internet? I mean
if I can do VPN's over an IPv6 network, seems that I could do that
across the Internet as well.
I think you already can do it over any kind of
On 16 September 2020 22:38:38 CEST, Randy Bush wrote:
>> Privacy != encryption.
>
>cleartext == privacy * 0
>
>cleartext * complexity == privacy * 0
False. Cleartext and privacy are two different things which are not mutually
exclusive. Information can be in plaintext and private, it can
On 18/Sep/20 11:40, t...@pelican.org wrote:
I've got MACSec deployed for exactly one customer as a point solution. It
works once it's in, but the documentation, vendor or otherwise, and choice of
suitable equipment were fairly sparse. I certainly wouldn't want to offer it
at scale.
> For me, MACSec is kind of like SyncE... great on paper and in the sales
> pitch, but anyone that truly wants to use those features is probably
> going to be architecting, deploying and managing them themselves, and
> not paying a 3rd party network operator for the priviledge.
I've got MACSec
On 17/Sep/20 19:36, mark seery wrote:
Private line was a common term for leased lines. Leased lines were not
encrypted by the operator, AFAIK. This terminology morphed to virtual
private line, Ethernet Private Line, virtual private LAN service
(VPLS), etc.
"In telecommunication, a
> On Sep 17, 2020, at 9:24 AM, Mark Tinka wrote:
>
>> For operators already offering FR/ATM services, it was a replacement, using
>> the same principles of traffic separation over a common infrastructure,
>> without encryption as part of the service. So from that perspective only, it
>> was
> On Sep 17, 2020, at 8:28 AM, Mark Tinka wrote:
>
>
>
> On 16/Sep/20 23:22, Anoop Ghanwani wrote:
>
>> It depends on the definition of VPN. In terms of services like
>> MPLS-based VPNs, it refers to the extension of a Private network
>> over a shared infrastructure, allowing entities
On 17/Sep/20 17:56, mark seery wrote:
For operators already offering FR/ATM services, it was a replacement, using the
same principles of traffic separation over a common infrastructure, without
encryption as part of the service. So from that perspective only, it was not
much of a change
On 17/Sep/20 01:30, Łukasz Bromirski wrote:
And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started,
On 16/Sep/20 23:22, Anoop Ghanwani wrote:
It depends on the definition of VPN. In terms of services like
MPLS-based VPNs, it refers to the extension of a Private network
over a shared infrastructure, allowing entities using the shared
infrastructure to have their own private address space
Mark,
> On 16 Sep 2020, at 10:32, Mark Tinka wrote:
>
> On 15/Sep/20 19:00, aar...@gvtc.com wrote:
>
>> Sorry guys, I'm not aware of much of what you mention as far as agenda,
>> vendor motive, and hardware support, etc
>
> I'm not shy... this would be Cisco.
And that’s fine. The fact
My backyard is private. It offers no privacy with its chain link fence
against a major street.
On 9/16/20 4:38 PM, Randy Bush wrote:
Privacy != encryption.
cleartext == privacy * 0
cleartext * complexity == privacy * 0
randy
> It depends on the definition of VPN.
in my definition, the P stands for privacy not plaintext
> In terms of services like MPLS-based VPNs, it refers to the extension
> of a Private network over a shared infrastructure, allowing entities
> using the shared infrastructure to have their own
On Tue, Sep 15, 2020 at 5:08 PM Randy Bush wrote:
> > You might be on to something, but I'm unsure... are you suggesting that
> it's
> > any less private over SRv6 than it was over MPLS ?
>
> neither srv6, srmpls, mpls, gre, ... provide privacy. they all
> transport the payload in nekkid
> Privacy != encryption.
cleartext == privacy * 0
cleartext * complexity == privacy * 0
randy
On Tue, 15 Sep 2020 at 19:14, Randy Bush wrote:
>
> > I'm still learning, but, It does seem interesting that the IP layer
> > (v6) can now support vpn's without mpls.
>
> as the packet payload is nekkid cleartext, where is the P in vpn?
Define "privacy". In the kind of VPN I think you're
On 16/09/2020 01:31, aar...@gvtc.com wrote:
> then, yes, I may have and didn't know it. Hey, was it you? LOL
Very unlikely. You may do well to peruse some of the objections to the
network-programming draft in the SPRING WG. There are many. :)
--
Tom
On 16/Sep/20 02:05, Randy Bush wrote:
> neither srv6, srmpls, mpls, gre, ... provide privacy. they all
> transport the payload in nekkid cleartext.
C'mon, Randy. Don't tell the kids Santa isn't real. Where's your
humanity :-)...
Mark.
On 15/Sep/20 21:07, Nick Hilliard wrote:
> This gets complicated quickly, and that complication can only be
> solved by adding complication to silicon, which is what you want not
> to do when the speed of your underlying forwarding plane is increasing
> by leaps and bounds. Good, cheap, fast.
On 15/Sep/20 20:57, James W. Laferriere wrote:
>
>
> So then here we are back at the older days of hard wired devices
> configured on site by vendor 'X' to do what buyer 'Y' was told it
> would do .
> And Buyer 'Y' is still wondering WHEN it will be that kitchen sink
> it ordered .
On 15/Sep/20 20:12, Randy Bush wrote:
>
> as the packet payload is nekkid cleartext, where is the P in vpn?
On a piece of paper filed under "It feels good to know it sort of does
the same thing" :-).
Mark.
On 15/Sep/20 19:05, Saku Ytti wrote:
> Ultimately it is very simple, we need tunneling, then the question is
> how much does it cost to look up those tunnel headers and how much
> space they take on the wire (relevant for overspeed), everything else
> is noise.
As we've said many times
On 15/Sep/20 19:00, aar...@gvtc.com wrote:
> Sorry guys, I'm not aware of much of what you mention as far as agenda,
> vendor motive, and hardware support, etc
I'm not shy... this would be Cisco.
And somehow, they've managed to "convince" other vendors to go down this
rabbit hole,
Nick, does CRH-16/32 and uSID change the overhead concern? I could be wrong,
but I thought that's what SRm6 was for, was to shrink the overhead, perhaps
amongst other things. Also, with VPN's over SRv6 would this enable automatic
vpn capability over the internet? I mean if I can do VPN's
> You might be on to something, but I'm unsure... are you suggesting that it's
> any less private over SRv6 than it was over MPLS ?
neither srv6, srmpls, mpls, gre, ... provide privacy. they all
transport the payload in nekkid cleartext.
Dance like no one's watching. Encrypt like everyone is.
You might be on to something, but I'm unsure... are you suggesting that it's
any less private over SRv6 than it was over MPLS ?
-Original Message-
From: Randy Bush
Sent: Tuesday, September 15, 2020 1:12 PM
To: aar...@gvtc.com
Cc: North American Network Operators' Group
Subject: Re
On 15/09/2020 18:00, aar...@gvtc.com wrote:
> And with this v6 SID being smartly divided into
> Locator:Function(Argument), I'm reading that this will carry with it
> much more functionality as well, like network programmability,
> application-to-network interaction or something like that.
Randy,
Was meant as the reply to Aaron’s comment about VPN’s over non MPLS underlay,
not the encryption of it (which is orthogonal).
Cheers,
Jeff
On Sep 15, 2020, 12:59 PM -0700, Randy Bush , wrote:
> > GRE, VXLAN or any other tunneling encap of the day.
> > As long as next-hop could be
Hello All ,
On Tue, 15 Sep 2020, Mark Tinka wrote:
On 15/Sep/20 11:53, Saku Ytti wrote:
I think SRv6 is an
abomination, it is complex SW, and very complex HW, because it exists.
We pay the premium to add HW support for it.
And that is what the vendor(s) pushing this hope operators
> GRE, VXLAN or any other tunneling encap of the day.
> As long as next-hop could be resolved behind remote end
i was not aware that GRE, VXLAN (without CN103618596A), and other tunnel
encaps encrypted the payload. learn something new every day. thanks!
>>> I'm still learning, but, It does
GRE, VXLAN or any other tunneling encap of the day.
As long as next-hop could be resolved behind remote end
Regards,
Jeff
> On Sep 15, 2020, at 11:14, Randy Bush wrote:
>
>
>>
>> I'm still learning, but, It does seem interesting that the IP layer
>> (v6) can now support vpn's without mpls.
Saku Ytti wrote on 15/09/2020 18:05:
You just move the encapsulation from in-order to inside-ip making
everything harder for SW and much harder for HW, the simplicity is a
lie.
to quantify this, the tunneling header increased in size from a minimum
of 4 octets to a minimum of 40 octets. If
> I'm still learning, but, It does seem interesting that the IP layer
> (v6) can now support vpn's without mpls.
as the packet payload is nekkid cleartext, where is the P in vpn?
On Tue, 15 Sep 2020 at 20:00, wrote:
> I'm still learning, but, It does seem interesting that the IP layer (v6) can
> now support vpn's without mpls. So one less layer of encapsulation seems
> cool. Don't get me wrong, I love all that mpls has done for us and offers,
> but, seems that SRx6
Sorry guys, I'm not aware of much of what you mention as far as agenda, vendor
motive, and hardware support, etc
I'm still learning, but, It does seem interesting that the IP layer (v6) can
now support vpn's without mpls. So one less layer of encapsulation seems cool.
Don't get me
On 15/Sep/20 11:53, Saku Ytti wrote:
> I think SRv6 is an
> abomination, it is complex SW, and very complex HW, because it exists.
> We pay the premium to add HW support for it.
And that is what the vendor(s) pushing this hope operators "realize"...
that SRv6 is a complex mess that needs some
On Tue, 15 Sep 2020 at 12:15, Nick Hilliard wrote:
> yep, and you're not alone - the complexity level is pretty high, right
> from the control plane to the hardware.
>
> It's not clear that the modest net gain in functionality is worth it.
Many people are buying hook, line and sinker on the
On 15/Sep/20 11:11, Nick Hilliard wrote:
>
> yep, and you're not alone - the complexity level is pretty high, right
> from the control plane to the hardware.
>
> It's not clear that the modest net gain in functionality is worth it.
Well, we know who's pushing this agenda, and why...
Here's
Mark Tinka wrote on 15/09/2020 07:04:
My head hurts:-)...
yep, and you're not alone - the complexity level is pretty high, right
from the control plane to the hardware.
It's not clear that the modest net gain in functionality is worth it.
Nick
On 14/Sep/20 22:42, aar...@gvtc.com wrote:
> Oh snap! Hey hey, that's good, thanks Nick. I had to go into the locator
> service of the remote pe and find a sid that would respond to ping.
>
> This is apparently an OAM Endpoint with Punt (End.OP)
>
>
Oh snap! Hey hey, that's good, thanks Nick. I had to go into the locator
service of the remote pe and find a sid that would respond to ping.
This is apparently an OAM Endpoint with Punt (End.OP)
aar...@gvtc.com wrote on 14/09/2020 20:03:
Thanks Nick, I only see the following layers... I see no extension headers
behind the ipv6 header. I sent you the wireshark sniff directly so you can
see what I'm seeing.
you should see extension headers if you're doing more complex stuff?
E.g. if
Thanks Nick, I only see the following layers... I see no extension headers
behind the ipv6 header. I sent you the wireshark sniff directly so you can
see what I'm seeing.
Ethernet - Type 0x86dd
Ipv6 - Next Header IPIP (4)
Ipv4
Icmp
-Aaron
aar...@gvtc.com wrote on 14/09/2020 18:57:
But rather, shows my L3VPN v4 traffic riding v6 and that’s it.
that is how SRv6 works. IPv6 + extension headers (+ a bit extra which
is incompatible with ipv6).
Let me know if I’m seeing an SRH and just don’t know it, LOL.
Check out the IPv6
91 matches
Mail list logo
