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
> 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
pected 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 only want to
do so where they are generating revenue from it, the end points.
Complexity and archite
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
, 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
&
enable MPLS features on a box
>
> Marketing, not fundamentals. DC people are driving demand for VXLAN
> and SRv6, because they assume MPLS is something scary and complex. So
> vendors implement something scary and complex to appease DC people.
> I'm sure in some years to the future
DC people are driving demand for VXLAN
and SRv6, because they assume MPLS is something scary and complex. So
vendors implement something scary and complex to appease DC people.
I'm sure in some years to the future, DC people will re-invent MPLS to
simplify their stack.
--
++ytti
+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
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 SRv6 be a requirement?
>
> 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
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
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 wor
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
I'm still growing in my understanding of SR-MPLS and SRv6 but I can say
that about everything... seems like the one constant in life, and particularly
network technology... is change.
Like ytti (saku) mentioned, with SR/SPRING the IGP is finally carrying the
Label/Sid, so we no longer need
of a problem, at least to me.
SR is terrific, SRv6 is snake-oil.
Everyone needs some type of tunnelling in most modern applications of
the network. maybe for pseudowires, repair, l3 vpns, traffic
engineering or just removing state and signalling from backbone.
Signalling labels via IGP is obviously
.
I'm not saying you don't have a need for it, but I am questioning whether you do,
or whether you're just being sucked in by all the latest sizzle (i.e. sales &
marketing materials). (After all, that's what the sizzle is *designed* to do!)
So SR-MPLS is different from SRv6.
I have refused to
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
SRv6 be a requirement?
Nope! It's a problem looking for a problem.
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
, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca
> -Original Message-
> From: NANOG On
> Behalf Of Colton Conor
> Sent: Tuesday, January 11, 2022 9:17 AM
> To: NANOG
> Subject: SRv6 Capable NOS and Devices
>
> I k
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
❦ 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
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?
If building a greenfield regional ISP network, would SRv6 be a requirement?
My understanding is that because it's using IPv6
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:
>
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
ot;Privacy" all along, and/or that - as of 2020 - the only suitable
definition of "Private", must now equal "suitably secure".
If you aren't just winding everyone up, then I would say that you're
skirting rather close to the reimagining of SD-WAN. That, or you are
haphazardly musi
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
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
years" finish line.
As you can tell, I always find the dark lining in the vendor sales
pitches :-).
IPv6 seems to be good plan forward (and would potentially unify
architecture of normal routing and overlay routing with SRv6), even
if things like MPLSoUDP or GRE would really solve everyth
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
least good portion of that heavily filtered one by the way.
IPv6 seems to be good plan forward (and would potentially unify
architecture of normal routing and overlay routing with SRv6), even
if things like MPLSoUDP or GRE would really solve everything if pushed
with enough force[3]
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
> transpo
> 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
sensing another death of a labeling protocol
?! this would be interesting if like MPLS killed ATM SR kills MPLS !)
(namely SRv6/SRm6)
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
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 m
e and sinker on the narrative 'it is
just IP, nothing scary and complex like MPLS'. 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.
For use cases it has, MPLSoUDP would do the same, fast, and it would
actually pass unmanage
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
om/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-0/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-70x/b-segment-routing-cg-asr9000-70x_chapter_011.html
>
> Here I'm executing ping/trace from the SRv6 ingress pe...to the egress PE
>
> RP/0/RP0/CPU0:r1#ping fc00:0:4:4
/configuration/guide/b-segment-routing-cg-asr9000-70x/b-segment-routing-cg-asr9000-70x_chapter_011.html
Here I'm executing ping/trace from the SRv6 ingress pe...to the egress PE
RP/0/RP0/CPU0:r1#ping fc00:0:4:4::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
Mon Sep 14 20:27:09.727 UTC
Type escape sequence
. if you run a ping / traceroute with the "use-srv6-op-sid"
parameter, or create a segment list under "segment-routing srv6 traffic
engineering", that should throw in some EHs.
Nick
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
I have what seems to be a good SRv6 test in my lab running XRv9k 7.0.2
But I'm wondering why the sniffer doesn't show the much-spoken-of SRH
(Segment Routing Header).. But rather, shows my L3VPN v4 traffic riding v6
and that's it. Let me know if I'm seeing an SRH and just don't know it,
LOL
93 matches
Mail list logo
