Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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 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 architectural cleanliness are not a consideration, if a
vendor makes a box that does the job at the right price there is a high
risk people will buy it.


There are other things that are required to support MPLS services than 
just chip and software capability. Control plane, buffer memory, queue 
depth, e.t.c.


That is why you would not find a lack of MPLS support in Ethernet 
switches... you would find "broken" support, because the rest of the 
hardware is not designed to deliver the same level of MPLS service scale 
that a high-end router would; and the vendors make that very clear. An 
Ethernet switch running MPLS can probably be an excellent P router, but 
won't be an awesome PE router.


There are still some IP routing features we consider "basic" in bigger 
routers that attract extra costs in Ethernet switches. Never mind MPLS.


Let's not confuse "MPLS no longer being expensive" with "MPLS being a 
low-end feature".


I find it hard to believe that SRv6 support will be enabled on low-end 
devices like Ethernet switches by the traditional vendors. But hey, I 
have been wrong before.


Mark.

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

> 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 only want to
> do so where they are generating revenue from it, the end points.

HW doing IPv6 does not imply HW being able to do SRv6. SRv6 is not
IPV6, SRv6 is MPLS embedded in (HW) complex way in EH.

Heck, EH is specified in such a way that no HW device is technically
IPv6 capable. What happens when you stack EH headers is question mark,
some devices revert to crawl (Nokia FP), some devices drop packet in
HW after it sees more than N ER (Juniper Trio). And how does that
imply devices capability to find L4 headers and honour ECMP, ACL, QOS
is a question mark.

-- 
  ++ytti

Re: SRv6 Capable NOS and Devices

[Brandon Butterworth]

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 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 architectural cleanliness are not a consideration, if a
vendor makes a box that does the job at the right price there is a high
risk people will buy it.

brandon

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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, QFX5100 and ACX5048 all have the same
Broadcom Trident II+ ASIC inside. One supports full MPLS features
(ACX), while the other is limited (QFX), and then the EX is even more
limited. . Only difference is what Juniper has enabled or disabled in
software to my knowledge. All 3 run JUNOS, just different flavors.


I don't see anything wrong with that. As with any business, different 
products provide different functionality, and as such, come with a 
different price. You can't expect Cessna's turboprops to fly you 16hrs 
between two points, non-stop, just because it is an aeroplane.


Juniper are targeting different markets and use-cases with their 
switches vs. their routers. To expect them to provide the same degree of 
MPLS capability at both ends of the spectrum is unreasonable.


I'm certain that in your business, you have different products, as well, 
that satisfy different types of customers at different price points, 
with differing value delivery.




Mikrotik's MPLS stack is quite limited, but I hope that will change
soon in version 7 that was just released. Honestly hoping that
Mikrotik kicks half these vendors in the nuts with everything they are
implementing in v7 with the new linux kernel and a development team
that is 3x as large. 100G switches are coming soon from them with
Marvell ASICs


I actually think Mikrotik should maintain their model. It works for 
them, and their customer base. It's terrible for support, but you also 
aren't paying through the nose, and the boxes do what they generally 
claim to do.


I'd rather they did not try to take on the traditional vendors. That 
pond is already murky as it is.




VyOS doesn't run on any ASIC based systems to my knowledge, so its
just a software router.


My point was MPLS is available, even on x86 platforms with open source 
code. You don't have to pay tons of money for it to get it anymore. Of 
course, if you want to run it at scale, there are other considerations 
beyond just the MPLS code itself, as you know.




Extreme charges extra to enable MPLS in their SLX lineup.


High-end IP routing features (which includes MPLS) have always attracted 
additional costs on what are meant to be Layer 2/3 switches.




  Ciena,
Ribbon, and others do the same.


Also Tejas, Infinera, Xtera, e.t.c., all "claim" MPLS support, but 
that's not their bread & butter. So yes, along with the priviledge of it 
being terribly implemented, you get the pleasure of paying extra for it 
too, with the optical vendors.


Mark.

Re: SRv6 Capable NOS and Devices

[Colton Conor]

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 features
(ACX), while the other is limited (QFX), and then the EX is even more
limited. . Only difference is what Juniper has enabled or disabled in
software to my knowledge. All 3 run JUNOS, just different flavors.

Mikrotik's MPLS stack is quite limited, but I hope that will change
soon in version 7 that was just released. Honestly hoping that
Mikrotik kicks half these vendors in the nuts with everything they are
implementing in v7 with the new linux kernel and a development team
that is 3x as large. 100G switches are coming soon from them with
Marvell ASICs

VyOS doesn't run on any ASIC based systems to my knowledge, so its
just a software router.

Extreme charges extra to enable MPLS in their SLX lineup. Ciena,
Ribbon, and others do the same.






On Sat, Jan 15, 2022 at 1:47 PM Mark Tinka  wrote:
>
>
>
> 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 chips shipping now, either custom or merchant silicon,
> will support MPLS. Whether the vendor chooses to implement it in code or
> not is a whole other matter.
>
> If you need MPLS, chances are you can afford it. If you don't, then you
> don't have to worry about it.
>
> For Extreme, are you referring to before or after they picked up Brocade?
>
> There is MPLS available in a number of cheap software suites. Even
> Mikrotik provides MPLS support. Whether it works or not, I can't tell you.
>
> VyOS supports is too. Whether it works or not, I can't tell you.
>
> But I think we are long past the days of "MPLS is expensive".
>
> Mark.

Re: SRv6 Capable NOS and Devices

[Jeff Tantsura]

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’ business doing ok.
How’s life on your side?

Would love to meet, lunch or so?

Cheers,
Jeff

> On Jan 16, 2022, at 13:19, Jeff Tantsura  wrote:
> 
> 
> 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 for MPLS WAN/DCI.
> Here’s an example of end2end architecture that works really well - 
> https://datatracker.ietf.org/doc/draft-bookham-rtgwg-nfix-arch/
> 
> Geneve (there are some quirks as you get into implementing it) is another 
> example of a well designed overlay encap.
> 
> 
> Cheers,
> Jeff
> 
>>> On Jan 15, 2022, at 23:54, Saku Ytti  wrote:
>>> 
>> 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 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

Re: SRv6 Capable NOS and Devices

[Jeff Tantsura]

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 for MPLS WAN/DCI.
Here’s an example of end2end architecture that works really well - 
https://datatracker.ietf.org/doc/draft-bookham-rtgwg-nfix-arch/

Geneve (there are some quirks as you get into implementing it) is another 
example of a well designed overlay encap.


Cheers,
Jeff

> On Jan 15, 2022, at 23:54, Saku Ytti  wrote:
> 
> 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 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

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

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 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

Re: SRv6 Capable NOS and Devices

[Jeff Tantsura]

+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 no changes to silicon, since head-end 
might be required to push more labels (TE, BSIDs, services)one needs to pay 
attention -  (RFC8491/8476) allow signaling of MSD (maximum SID depth) if 
centralized controller/PCE is used for path computation.
LDP after all the years of bug fixing is still a crappy protocol, moving to 
SR-MPLS makes all the sense.


Cheers,
Jeff

> On Jan 15, 2022, at 11:50, Mark Tinka  wrote:
> 
> 
> 
>> 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 chips shipping now, either custom or merchant silicon, will 
> support MPLS. Whether the vendor chooses to implement it in code or not is a 
> whole other matter.
> 
> If you need MPLS, chances are you can afford it. If you don't, then you don't 
> have to worry about it.
> 
> For Extreme, are you referring to before or after they picked up Brocade?
> 
> There is MPLS available in a number of cheap software suites. Even Mikrotik 
> provides MPLS support. Whether it works or not, I can't tell you.
> 
> VyOS supports is too. Whether it works or not, I can't tell you.
> 
> But I think we are long past the days of "MPLS is expensive".
> 
> Mark.

Re: SRv6 Capable NOS and Devices -> MPLS instead?

[scott]

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 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 Routing can do do MPLS, but I don't think it 
has a construct for VPLS (joining more than two sites together).


---


MPLS has services that run on the top of it.  VPLS is one of those 
services.  The other two main services are VPRN and pseudowires.  First 
the MPLS is configured (LSPs between nodes) and then the services are 
configured that run on top of MPLS.


scott








On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti  wrote:
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, that don't need to support LDP. Low end
switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
support LDP for example.

It is utter fallacy that MPLS is costly, MPLS is systematically and
fundamentally cheaper than IPv4 (and of course IPv6 costs more than
IPv4).

However if this doesn't reflect your day-to-day reality, then you can
always do MPLSoGRE, so that core does not need more than IP. So in no
scenario is this narrative justification for hiding MPLS headers
inside IP headers, which is expensive and complex, systematically and
fundamentally.

--
   ++ytti

Re: SRv6 Capable NOS and Devices -> MPLS instead?

[Mark Tinka]

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 Routing can do do MPLS, but I don't think it 
has a construct for VPLS (joining more than two sites together).


Hasn't the world moved on to EVPN?

Mark.

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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 chips shipping now, either custom or merchant silicon, 
will support MPLS. Whether the vendor chooses to implement it in code or 
not is a whole other matter.


If you need MPLS, chances are you can afford it. If you don't, then you 
don't have to worry about it.


For Extreme, are you referring to before or after they picked up Brocade?

There is MPLS available in a number of cheap software suites. Even 
Mikrotik provides MPLS support. Whether it works or not, I can't tell you.


VyOS supports is too. Whether it works or not, I can't tell you.

But I think we are long past the days of "MPLS is expensive".

Mark.

Re: SRv6 Capable NOS and Devices -> MPLS instead?

[Raymond Burkholder]

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, 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 Routing can do do MPLS, but I don't think it has 
a construct for VPLS (joining more than two sites together).





On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti  wrote:

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, that don't need to support LDP. Low end
switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
support LDP for example.

It is utter fallacy that MPLS is costly, MPLS is systematically and
fundamentally cheaper than IPv4 (and of course IPv6 costs more than
IPv4).

However if this doesn't reflect your day-to-day reality, then you can
always do MPLSoGRE, so that core does not need more than IP. So in no
scenario is this narrative justification for hiding MPLS headers
inside IP headers, which is expensive and complex, systematically and
fundamentally.

--
   ++ytti

Re: SRv6 Capable NOS and Devices

[Colton Conor]

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  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 to support LDP. Low end
> > switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
> > support LDP for example.
>
> It is utter fallacy that MPLS is costly, MPLS is systematically and
> fundamentally cheaper than IPv4 (and of course IPv6 costs more than
> IPv4).
>
> However if this doesn't reflect your day-to-day reality, then you can
> always do MPLSoGRE, so that core does not need more than IP. So in no
> scenario is this narrative justification for hiding MPLS headers
> inside IP headers, which is expensive and complex, systematically and
> fundamentally.
>
> --
>   ++ytti

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

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, that don't need to support LDP. Low end
> switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
> support LDP for example.

It is utter fallacy that MPLS is costly, MPLS is systematically and
fundamentally cheaper than IPv4 (and of course IPv6 costs more than
IPv4).

However if this doesn't reflect your day-to-day reality, then you can
always do MPLSoGRE, so that core does not need more than IP. So in no
scenario is this narrative justification for hiding MPLS headers
inside IP headers, which is expensive and complex, systematically and
fundamentally.

-- 
  ++ytti

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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 to support LDP. Low end
switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
support LDP for example.

MPLS switches are very expensive compared to enterprise switches.


I would be surprised to find devices that support SR, and not MPLS/LDP.

Mark.

Re: SRv6 Capable NOS and Devices

[Sander Steffann]

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 about it! But I haven't figured out a way to mitigate 
the risks. Easy deployment == easy abuse it seems :(

Cheers,
Sander

Re: SRv6 Capable NOS and Devices

[Colton Conor]

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 premium vendors, like Juniper's  EX2200 - EX3400 don't
support LDP for example.

MPLS switches are very expensive compared to enterprise switches.

On Wed, Jan 12, 2022 at 1:09 AM Mark Tinka  wrote:
>
>
>
> 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 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 traditional MPLS networks today where all devices
> > have to support MPLS/LDP correct?
>
> You'd be hard-pressed to find anything that will help you generate
> revenue that does not come with MPLS baked into the chip and code.
>
> Do you want to take the chance of where and when SRv6 may or may not be
> needed?
>
> SRv6 is Cisco trying to create a market for a problem that does not
> exist. In the process, all other vendors are forced to waste tons of
> money and time to stay in the game, when they could be fixing real
> problems and adding real value.
>
> Don't fall for the trap. Vote with your wallet, and feet. We did.
>
> Mark.

Re: SRv6 Capable NOS and Devices

[Randy Bush]

> 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… Unless an operator has airtight protection on every interface to
> block unwanted SRv6 headers I see some interesting opportunities to
> cause havoc :)

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.

randy, with no dog in this fight

Re: SRv6 Capable NOS and Devices

[Dale W. Carder]

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 marketing about 'it is
> > IP, you already understand it, MPLS is hard'.
> 
> 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… Unless an 
> operator has airtight protection on every interface to block unwanted SRv6 
> headers I see some interesting opportunities to cause havoc :)

You are not alone, see for example the thread at
https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JKB1PlDh_fPdc/ 
this is more pronounced with respect to the various SRv6 compression scheme 
proposals.

Dale

Re: SRv6 Capable NOS and Devices

[Sander Steffann]

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 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… Unless an operator has 
airtight protection on every interface to block unwanted SRv6 headers I see 
some interesting opportunities to cause havoc :)

Cheers,
Sander

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

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 address, and not the MPLS Label.  So we don't even need 
> MPLS, but can accomplish network virtualization using a pure IPv6 core.  
> Reminds me of Cell Mode MPLS vs Frame Mode MPLS... whereas the ATM Cell 
> header VPI/VCI was repurposed as the MPLS label, until we went with straight 
> MPLS shim headers.

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'.

-- 
  ++ytti

RE: SRv6 Capable NOS and Devices

[aaron1]

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 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 address, and not the MPLS Label.  So we don't even need MPLS, 
but can accomplish network virtualization using a pure IPv6 core.  Reminds me 
of Cell Mode MPLS vs Frame Mode MPLS... whereas the ATM Cell header VPI/VCI was 
repurposed as the MPLS label, until we went with straight MPLS shim headers.

In case you are interested, I put a video on my channel showing a quick look at 
SRv6.  Using Cisco CML, IOS-XR 7.2.2, IS-IS, only using FE80 link local 
addressing.  L3VPN to prove end to end Customer connectivity over SRv6.
https://www.youtube.com/watch?v=SrryHbjpnAc

The P node is quite interesting in it's ability to handle this with little to 
no additional protocols.

-Aaron





-Original Message-
From: NANOG  On Behalf Of Saku Ytti
Sent: 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 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.

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 better than via LDP.

--
  ++ytti

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

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 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 better than via LDP.

-- 
  ++ytti

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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.
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 jump on the SR-MPLS train, but I AFAIK, it is not the 
monstrosity that SRv6 is. And while you still have to consider your 
hardware and software options for SR-MPLS, it is out there in the wild, 
working.


So if you had to choose, SR-MPLS is likely a better option than SRv6.

For me, MPLS + LDP works, and is mature. The vendors I am willing to 
invest in support LDPv6. The hardware we run is not going to fall over 
because of LDP state.


Leaves me time to focus on other, real problems.

Mark.

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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, considering
it's so established despite its obvious benefits only existing in
marketability.


100%.

In a market where Cisco can no longer guarantee that operators will be 
spending US$50 million a year, minimum, they have to find a way to make 
it difficult for you to live without them.


Mark.

Re: SRv6 Capable NOS and Devices

[Mark Tinka]

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 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 traditional MPLS networks today where all devices
have to support MPLS/LDP correct?


You'd be hard-pressed to find anything that will help you generate 
revenue that does not come with MPLS baked into the chip and code.


Do you want to take the chance of where and when SRv6 may or may not be 
needed?


SRv6 is Cisco trying to create a market for a problem that does not 
exist. In the process, all other vendors are forced to waste tons of 
money and time to stay in the game, when they could be fixing real 
problems and adding real value.


Don't fall for the trap. Vote with your wallet, and feet. We did.

Mark.

RE: SRv6 Capable NOS and Devices

[Adam Thompson]

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, 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!)
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, 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 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 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 MPLS networks today where all devices
> have to support MPLS/LDP correct?

Re: SRv6 Capable NOS and Devices

[Saku Ytti]

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 MPLS networks today where all devices
> have to support MPLS/LDP correct?

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, considering
it's so established despite its obvious benefits only existing in
marketability.

-- 
  ++ytti

Re: SRv6 Capable NOS and Devices

[Vincent Bernat]

 ❦ 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,
End.DX4, End.DT4, End.DX6, End.DT6, End.DX2, with PSP/USD or USP,
H.Encaps.*), without any EVPN (so not End.DT2U AFAIK), from 7.2,
depending on hardware (Jericho 2-based platforms need 7.5). There may be
hardware restriction on the smaller NCS (NCS540). However, Cisco is
switching to SRv6 F3216, aka microsegments. The same behaviours are
supported. Beware there is a gap between being on the datasheet and not
running into various bugs. Staying close to what Cisco promotes will
help avoiding some bugs. With ISIS as an IGP, there is also support for
TI-LFA and FlexAlgo.

Juniper supports SRv6 F1 on MX, with the same feature set. Nokia
supports it too on the 7750 SR. No support from Arista yet.

Iliad deployed SRv6 in Italy (and partly in France), with Cisco.

> If building a greenfield regional ISP network, would SRv6 be a
> requirement?

Dunno. This is still super young and you restrict the number of vendors
you can select and interoperate with. Also note that SRv6 F3216 RFC is
not out yet and Cisco is already asking customers to move away from SRv6
F1. AFAIK, other vendors are still on F1. Starting with SRv6 now may be
a bit of a gamble because of that. Latest draft is here:

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-12

> 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 MPLS networks today where all devices
> have to support MPLS/LDP correct?

That's correct.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

Re: SRv6

[Paul Timmins]

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 private 
property.

RE: SRv6

[aaron1]

Lol

I was thinking that if I ever need to know about *anything*, I can now just 
google "srv6 nanog"

- Aaron

Re: SRv6

[Mark Tinka]

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 for operators, all being done in IPv6 
and what-not...


Mark.

RE: SRv6

[Keith Medcalf]

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 encryption, they are not secure.

That is blatantly untrue.  I have an MPLS VPN running from my Living
Room to my Bathroom.  It is not encrypted.  It is protected with 3G
security (Guards, Guns, Gates).  You do not need "encryption" in order
to be "secure".

--
Be decisive.  Make a decision, right or wrong.  The road of life is
paved with flat squirrels who could not make a decision.

Re: SRv6

[Randy Bush]

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

Re: SRv6

[Greg Shepherd]

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 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 here, I never said MPLS VPNs are secure, only 
> private. I hope others recognise that they are different concepts.
> 
> Cheers,
> James.

Re: SRv6

[James Bensley]

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 here, I never said MPLS VPNs are secure, only 
private. I hope others recognise that they are different concepts.

Cheers,
James.

Re: SRv6

[Tom Hill]

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

Re: SRv6

[Randy Bush]

> 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

Re: SRv6

[Tom Hill]

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 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 musing in a direction that ensures "Encrypted SRv6" will
become the next gigantic pain^Wdraft for the SPRING WG to endur^Wdebate.

One thing that is true: not all present or historical definitions (or
acceptable uses) of the word "private" strictly imply or infer privacy.
One may prefer an alternate history, but you may find more success in
expelling that energy in pursuit of creating a better future.

See/also:

"broadband"
"software defined networks"
"the cloud"

-- 
Tom

Re: SRv6

[Łukasz Bromirski]

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
>> back door" counts as unencrypted).
> 
> Let's not give them a reason.
> 
> The most I've heard (from Africa) is countries making requirements for 
> nominated information to not be stored outside of the country, especially in 
> the U.S, and parts of Europe. To some extent, this has pushed many of the 
> cloud bags to become present in Africa so they can comply, although I'm not 
> sure even sleeping with one eye open counts as being safe in that respect.

I believe right now the only country in the world with enforcing of crypto 
backdoors is Australia[1], which is kind-of crazy. OTOH, they had their own set 
of problems with massive Chinese intelligence penetration.

And we have couple of countries like Russia, obviously China, Turkey(?) that 
insist or either having your data locally, dear content provider, or forbid 
your service to operate at all in given country. Apple, Amazon, Microsoft and 
Google of this world are on a different level of compliance here. As far as I 
know, in most of EU countries, inspecting payload of customer traffic is 
explicitly forbidden by telco laws.

Ah, and there’s cooperation between US and EU about exchanging citizen data, 
which recently was stopped by EU once it become obvious, US was abusing that 
cooperation[2]. That can help potential malicious SP to cross-check and 
correlate user to content across continents.

We’re living in interesting times.

[1]. https://www.cyberscoop.com/australia-encryption-backdoors-law-passes/

[2]. 
https://www.wsj.com/articles/eus-top-court-restricts-personal-data-transfers-to-u-s-citing-surveillance-concerns-11594888385

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: SRv6

[Mark Tinka]

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 I've heard (from Africa) is countries making requirements for 
nominated information to not be stored outside of the country, 
especially in the U.S, and parts of Europe. To some extent, this has 
pushed many of the cloud bags to become present in Africa so they can 
comply, although I'm not sure even sleeping with one eye open counts as 
being safe in that respect.


Mark.

Re: SRv6

[Valdis Klētnieks]

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 I[C]T has to think about today).
>
> If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud
> bags will simply take over (not that they haven't, already).

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).




pgpwzdXuegf5e.pgp
Description: PGP signature

Re: SRv6

[Mark Tinka]

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 only afford and/or have the operational agility, to do an 
implementation once. Any security tech that is sufficiently interesting, is 
going to be a pain for router vendors to implement and operationalize given the 
government’s attitude to such tech. The lower in the stack it is, the bigger 
the pain.

That said, vendors are being asked to put MACSec in and I suspect more 
platforms supporting it will become available over tim


Totally share your view.

End-points already have plenty of methods to provide security, as do 
tons of "appliances" one can deploy as CPE.


We don't need to complicate the backbone further by having it do 
wholesale encryption. But alas, watch this space...


The best thing we can do, as operators, is not make this a reality. If 
gubbermints want us to, then they are welcome to fund the project.


Mark.

Re: SRv6

[mark seery]

> 
> 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 implementation, 
and vendors can only afford and/or have the operational agility, to do an 
implementation once. Any security tech that is sufficiently interesting, is 
going to be a pain for router vendors to implement and operationalize given the 
government’s attitude to such tech. The lower in the stack it is, the bigger 
the pain. 

That said, vendors are being asked to put MACSec in and I suspect more 
platforms supporting it will become available over time.

Re: SRv6

[Randy Bush]

> 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

Re: SRv6

[Wilco Baan Hofman]

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 session cookie (whatever is set as
authenticated) is the MAC address. So once a port is authenticated, it's
really easy to spoof a MAC and still be on the network.

With WPA2 enterprise on WiFi, this problem does not exist, because then
there is a cryptographic session. MACsec fixes that gap on wired.

Not all that relevant for long-distance links though :)

-- Wilco

Re: SRv6

[Andrey Kostin]

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 tunnel, and there are a 
lot of SDWAN solutions are available. Or do you expect from a transit 
provider a capability to respect and process SID stack programmed by 
another provider? I wouldn't bet on this ;) From administrative PoV it's 
similar to Inter-AS or CsC, based on trusted relations between parties, 
but seems not very popular in real life.
Otherwise, it will be the same best path routing as for any general 
tunnel. Doesn't look as a distinctive advantage of SRv6 at least.




- Aaron


--
Kind regards,
Andrey

Re: SRv6

[James Bensley]

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 also be 
encrypted and not private.

Consider multiple devices connected to a single customer instance (A) on an 
MPLS L2 VPN provider's network, consisting of a single VLAN/broadcast domain, 
all the connected devices are able to send information to each other, and they 
can receive the information sent to other devices not intended for itself. Any 
device, for example, can send a gratuitous ARP, update the control plane of the 
switch and pull traffic towards itself and have visibility of all the 
conversation on the VLAN/broadcast domain. Even if the conversations are 
encrypted, meaning no plaintext, which you seem to suggest means privacy, this 
receiving device sees all the conversations which take place, when they are 
taking place, between whom, for how long, how often, and so on. Encryption 
hasn't provided privacy if someone can see all that information.

Now consider a second customer (B) connected to a separate customer instance on 
the same L2 VPN provider network. Customer A can send any traffic they like and 
they can listen all day until the cows come home; they will never be able to 
send traffic to a customer B device in a separate L2 VPN instance, and they 
will never receive any traffic from a customer B device, they can't even see 
that customer B exists, if they are having any conversations, when, for how 
long etc, nothing.

That is privacy, which is completely different to plaintext and ciphertext.

Cheers,
James

Re: SRv6

[Mark Tinka]

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.

Encrypted network conversations with customers, I always try to be very clear 
about what they're trying to protect against, and make them think properly 
about trust boundaries.  Sure, I can slap a managed CPE on site if I don't 
already have one and provide overlay encryption - but that doesn't stop a rogue 
engineer on my side from capturing data before it's encrypted.  If what you're 
concerned about is fibre taps, or security flaws in the MPLS 
traffic-segregation model or implementation, that helps.  If you don't want to 
trust me as a service provider not to sniff your traffic in the middle, having 
me encrypt it at the edge really doesn't help - you need to encrypt it 
yourself, or have a different third-party that you do trust do the encryption.

Some people get it, some people are just trying to fill auditor check-boxes ;)


Agreed.

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.


I'm yet to find a bank willing to do this.

Maybe I'm not paying enough attention.

Mark.

Re: SRv6

[t...@pelican.org]

> 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 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.

Encrypted network conversations with customers, I always try to be very clear 
about what they're trying to protect against, and make them think properly 
about trust boundaries.  Sure, I can slap a managed CPE on site if I don't 
already have one and provide overlay encryption - but that doesn't stop a rogue 
engineer on my side from capturing data before it's encrypted.  If what you're 
concerned about is fibre taps, or security flaws in the MPLS 
traffic-segregation model or implementation, that helps.  If you don't want to 
trust me as a service provider not to sniff your traffic in the middle, having 
me encrypt it at the edge really doesn't help - you need to encrypt it 
yourself, or have a different third-party that you do trust do the encryption.

Some people get it, some people are just trying to fill auditor check-boxes ;)

Regards,
Tim.

Re: SRv6

[Mark Tinka]

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 private line is typically a telephone company 
service that uses a dedicated, usually unswitched 
point-to-point circuit, but it may involve 
private switchingarrangements, or predefined transmission physical or 
virtual paths.”


https://en.wikipedia.org/wiki/Private_line 



https://www.business.att.com/products/dedicated-internet/#/ 



http://etler.com/docs/AT%20Pub/TR54077.pdf 



https://business.comcast.com/enterprise/products-services/data-networking/ethernet-virtual-private-line 



VPN is a terminology consistent with past practices. It is P in all 
the ways discussed on this thread, and historically consistent (at 
least from a marketing perspective). Whether it is P enough is a 
reasonable discussion, everyone in I(C)T is going to be facing a wave 
of voter concern about privacy, IMO.


It's six and half-a-dozen.

"Private Line" isn't the same thing as "Private Network". A small, but 
crucial distinction, particularly for folk on a list like this. Probably 
interchangeable to the ordinary wi-fi user. But then again, operators 
always choose words carefully, and if the contract said "Private Line" 
in lieu of "Private Network", or vice versa, that wasn't by mistake.



Torn between two lovers: Growing voter concern about privacy & 
longheld, and arguably increasing, desire to intercept criminal / 
terrorist communication. I’d actually be curious if any operators have 
received public sector pushback when they tried to implement encryption.


Sounds like you're making a/the case for MACSec :-).

Anyone know how widely MACSec has been adopted? Or for that matter, 
large-scale encryption on the backbone side?


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.


As always, I could be wrong...

Mark.

Re: SRv6

[mark seery]

> 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 not much of a change for *existing* enterprise customers.
> 
> Indeed. But the difference with Frame Relay and ATM was that telco's never 
> called it a (V)PN. At worst, it was a leased line.

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 private line is typically a telephone company service 
that uses a dedicated, usually unswitched point-to-point circuit, but it may 
involve private switchingarrangements, or predefined transmission physical or 
virtual paths.”

https://en.wikipedia.org/wiki/Private_line 


https://www.business.att.com/products/dedicated-internet/#/ 


http://etler.com/docs/AT%20Pub/TR54077.pdf 


https://business.comcast.com/enterprise/products-services/data-networking/ethernet-virtual-private-line
 


VPN is a terminology consistent with past practices. It is P in all the ways 
discussed on this thread, and historically consistent (at least from a 
marketing perspective). Whether it is P enough is a reasonable discussion, 
everyone in I(C)T is going to be facing a wave of voter concern about privacy, 
IMO.

> Or someone else who might "capture" the operator, and thus, be able to 
> intercept it.

Good point.

> If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud bags 
> will simply take over (not that they haven't, already).

Torn between two lovers: Growing voter concern about privacy & longheld, and 
arguably increasing, desire to intercept criminal / terrorist communication. 
I’d actually be curious if any operators have received public sector pushback 
when they tried to implement encryption.

> 
> Mark.

Re: SRv6

[mark seery]

> 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 using the shared
>> infrastructure to have their own private address space and routing
>> tables.
> 
> Really, it was just a way to leverage IP networks to make more money.

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 for *existing* enterprise customers. 

This community is aware of the responsibility of a network is to ensure that 
traffic is forwarded to the (originally?) intended destination to prevent 
confidential information being exposed to a third-party. It is in this respect 
that the term “privacy” is often used. So seems like there is a taxonomy issue 
here. Perhaps traffic separation is a better term than privacy, because while 
traffic is probablistically private with respect to other VPN customers 
(separated with some high level of probability), it is not private with respect 
to the operator (who could intercept it).

> Nothing against that, as long as "buyer be aware" applies.

Sure, transparency is good.

I remember 20 years ago at a London IETF where the issue arose, and a food 
fight arose over who would own and manage encryption keys if traffic was 
encrypted. I don’t recall what the resolution of that debate was.

That said, we live in an era where there is increasing sensitivity to 
protecting consumer (at least) information. This sensitivity exists at multiple 
layers of the “stack”. So it is an interesting question / issue, and certainly 
would not be of any surprise if governments mandated it in the future, as long 
as they could intercept it for law enforcement purposes of course, and until 
they could, they probably would not be encouraging operators to encrypt data in 
any difficult to crack way (a speculation on my part).

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 I[C]T has to think about today).

> 
> Mark.

Re: SRv6

[Mark Tinka]

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 for *existing* enterprise customers.


Indeed. But the difference with Frame Relay and ATM was that telco's 
never called it a (V)PN. At worst, it was a leased line.




This community is aware of the responsibility of a network is to ensure that 
traffic is forwarded to the (originally?) intended destination to prevent 
confidential information being exposed to a third-party. It is in this respect 
that the term “privacy” is often used. So seems like there is a taxonomy issue 
here. Perhaps traffic separation is a better term than privacy, because while 
traffic is probablistically private with respect to other VPN customers 
(separated with some high level of probability), it is not private with respect 
to the operator (who could intercept it).


Or someone else who might "capture" the operator, and thus, be able to 
intercept it.





Sure, transparency is good.

I remember 20 years ago at a London IETF where the issue arose, and a food 
fight arose over who would own and manage encryption keys if traffic was 
encrypted. I don’t recall what the resolution of that debate was.

That said, we live in an era where there is increasing sensitivity to 
protecting consumer (at least) information. This sensitivity exists at multiple 
layers of the “stack”. So it is an interesting question / issue, and certainly 
would not be of any surprise if governments mandated it in the future, as long 
as they could intercept it for law enforcement purposes of course, and until 
they could, they probably would not be encouraging operators to encrypt data in 
any difficult to crack way (a speculation on my part).

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 I[C]T has to think about today).


If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud 
bags will simply take over (not that they haven't, already).


Mark.

Re: SRv6

[Mark Tinka]

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, it was close feedback loop with at least
some of the ISPs wanting to have “easier” and SDN-ish control over the
network so the blame should be shared :) Having support from other
vendors was de facto requirement to even think about deploying it widely
and that's better approach IMHO than “lets patent everything out and
force everyone into our black-box-architecture that’s best in the world”.

I’m observing the discussions over the last couple of months and
generally they boil down to “leave us alone, everything sucks, we’ll
stay with what we have”. And sure, as you indisputably proven during last
30 years, running modern ISP network can be done over IP, MPLS, and the
network can even survive introduction of IPv6. And I get it - vendors
have generally failed to address your ideas and problems in timely manner,
and when we did, quality was simply not there. But really, is that all
what’s interesting in life? I doubt it. Unless the whole point of
discussing here would be to start from technical topics
(because of ‘rules’) and end up with everybodys favorite part - beating
virtual Pinata made to look like representation of most hated
salesman/vendor. Then sorry, I somehow missed that :)

While I personally find the idea of stacking IPv6 labels gruesome for
any non-trivial label depth[2] (and I'm really worried about software guys
coming in from the “mobile app” world soon, and finding out that they can
create those IPv6 EH stacks easily), going forward we have to think
about what will keep networks running in for the next 5, 10 or 20 years.
IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS,
but IPv6 is gaining adoption and need to multiplex/demultiplex more and
more services and users will only grow. And BTW, MPLS forwarding between
ASes in the internet is still something that works mainly on slides,
highly paid consulting “proposals” and of course on the CCIE exam.


I have no problem at all with dreaming up nice fancy features that 
either move the industry forward or just eliminate a great deal of 
personal idleness.


My problem is now using that tech. to force a business model that is no 
longer relevant in these times we live in. And somehow, making that 
tech. complicated enough to justify those business models.


I'm sure the genius engineers that thought up the idea aren't likely the 
suits who decide to monetize said idea in an unreasonable manner. I'm 
even more sure that if you had both sitting in the same room, they'd 
never converge on a "go to market" strategy.


So no, nothing against technology. Totally against it being commercially 
weaponized.




On the other side, there’s Elon Musk moving us to Mars, wretched IoT
world with “build, sell and forget" mentality w/r to firmware and good
network stacks. And yet only 59% people around the world today have internet
access. At least good portion of that heavily filtered one by the way.


That Tesla Powerwall does look awfully sexy. But no way I'm dishing out 
all that dosh for a measly 13kWh of storage just so it can shutdown 
after 48hrs of no Internet. For that price, there are many places that I 
can get 35kWh from, and not have to be concerned about being spied on 
for years just so the Powerwall can make it to the "Guaranteed for 8 
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 everything if pushed
with enough force[3] ;) It’s worth observing, that from this perspective
IPinIP would be as good as SRv6 if everyone would agree 20 years ago that
source routing is acceptable. LDP or RSVP-TE would never gain any usage
and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get
back to this simplification with LISP[4], and in the long run it seems
overloading address semantics is not something that is happily accepted
everywhere, and it doesn’t matter if that's IPv4 or IPv6.

So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS
data plane after those 20 years on firewalls, load balancers and what-you
looks kind of dissapointingly. And if we are talking about network
functions - I believe it’s more important right now to agree on one way
of doing service chaining, than discussing SR or SRv6 as evil seed created
to conquer the world.

SR takes out state out, and SRv6 has the same address format on the
outside as well as inside. You can happily run it with both data planes,
and while today maybe you can’t provide migration of ALL services,
SR+IGP quite nicely 

Re: SRv6

[Mark Tinka]

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 and routing
tables.


Really, it was just a way to leverage IP networks to make more money.

Nothing against that, as long as "buyer be aware" applies.

Mark.

Re: SRv6

[Łukasz Bromirski]

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 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, it was close feedback loop with at least
some of the ISPs wanting to have “easier” and SDN-ish control over the
network so the blame should be shared :) Having support from other
vendors was de facto requirement to even think about deploying it widely
and that's better approach IMHO than “lets patent everything out and
force everyone into our black-box-architecture that’s best in the world”.

I’m observing the discussions over the last couple of months and
generally they boil down to “leave us alone, everything sucks, we’ll 
stay with what we have”. And sure, as you indisputably proven during last
30 years, running modern ISP network can be done over IP, MPLS, and the
network can even survive introduction of IPv6. And I get it - vendors
have generally failed to address your ideas and problems in timely manner,
and when we did, quality was simply not there. But really, is that all
what’s interesting in life? I doubt it. Unless the whole point of
discussing here would be to start from technical topics
(because of ‘rules’) and end up with everybodys favorite part - beating
virtual Pinata made to look like representation of most hated
salesman/vendor. Then sorry, I somehow missed that :)

While I personally find the idea of stacking IPv6 labels gruesome for
any non-trivial label depth[2] (and I'm really worried about software guys
coming in from the “mobile app” world soon, and finding out that they can
create those IPv6 EH stacks easily), going forward we have to think
about what will keep networks running in for the next 5, 10 or 20 years.
IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS,
but IPv6 is gaining adoption and need to multiplex/demultiplex more and
more services and users will only grow. And BTW, MPLS forwarding between
ASes in the internet is still something that works mainly on slides,
highly paid consulting “proposals” and of course on the CCIE exam.

On the other side, there’s Elon Musk moving us to Mars, wretched IoT
world with “build, sell and forget" mentality w/r to firmware and good
network stacks. And yet only 59% people around the world today have internet
access. At 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] ;) It’s worth observing, that from this perspective
IPinIP would be as good as SRv6 if everyone would agree 20 years ago that
source routing is acceptable. LDP or RSVP-TE would never gain any usage
and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get
back to this simplification with LISP[4], and in the long run it seems
overloading address semantics is not something that is happily accepted
everywhere, and it doesn’t matter if that's IPv4 or IPv6.

So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS
data plane after those 20 years on firewalls, load balancers and what-you
looks kind of dissapointingly. And if we are talking about network
functions - I believe it’s more important right now to agree on one way
of doing service chaining, than discussing SR or SRv6 as evil seed created
to conquer the world. 

SR takes out state out, and SRv6 has the same address format on the
outside as well as inside. You can happily run it with both data planes,
and while today maybe you can’t provide migration of ALL services,
SR+IGP quite nicely interworks with MPLS+LDP.

Will HW evolve? It has to anyway, no previous change was done day one
and 128 bits times 5 or 8 or 12 seems horrible only today. Over the
years, people got used to bigger horrors ;)

— 
./

[1]. https://patents.google.com/patent/US20140169370
[2]. Yeah, Binding SIDs of course, but that’s a solution to self-made
 problem as Ivan Pepelnjak would say.
[3]. https://tools.ietf.org/html/rfc1925 point 2.3.
[4]. https://tools.ietf.org/html/rfc6830

Re: SRv6

[Paul Timmins]

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

Re: SRv6

[Randy Bush]

> 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 private address
> space and routing tables.

i think we wrote the paper on that :)

http://www.ieee-infocom.org/2003/papers/36_02.PDF

randy

Re: SRv6

[Anoop Ghanwani]

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 cleartext.
>
> Dance like no one's watching. Encrypt like everyone is.
>

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 and routing
tables.

Re: SRv6

[Randy Bush]

> Privacy != encryption.

cleartext == privacy * 0

cleartext * complexity == privacy * 0

randy

Re: SRv6

[James Bensley]

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 suggesting (e.g.
an IPSEC based VPN) they implement the classic CIA acronym
(Confidentiality, Integrity and Authentication, with the "C"
essentially meaning "encrypted" in practice however, privacy requires
all three of "CIA", encryption alone isn't privacy). "VPN" is not
mutually dependent on "CIA", the two things can and do exist
separately.

WIth MPLS L3 VPNs for example, the traffic isn't encrypted, but by
creating a layer of abstraction (at the control plane, by signalling
via MP-BGP using RDs and RTs, and at the forwarding plane by using
MPLS tunneling) a customer's routing data and forwarding data is kept
private (not encrypted!) from my physical infa forwarding- and
control-planes, and from each other L3 VPN customer on my infra [1].

In fact, the point that customer (control- and forwarding-plane) data
is kept private from MY INFRA, is *the* fundamental aspect of MPLS L3
VPNs; they wouldn't scale at all without it. Privacy != encryption.

Cheers,
James.

[1] This doesn't mean there aren't security flaws in MPLS (there are,
but there are in things like IPSEC too), and "how secure" it is, is a
separate subject.

Re: SRv6

[Tom Hill]

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

Re: SRv6

[Mark Tinka]

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.

Re: SRv6

[Mark Tinka]

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. Choose two - or maybe one.

More complex silicon means tons of R, which means big prices to
recover that from operators who "want want want" that R in their networks.

>
> As Mark points out, many companies have made their fortunes with a
> full stack product offering, from hardware and software to design,
> engineering and operations.  It's not a bad business model as long as
> you realise that it's time-limited to the technology of the day. When
> it draws to a close, it's hard to turn companies around that have been
> used to a single-product or single-vertical cash trough which no
> longer exists.  Some have done this successfully; others have floundered.

The one thing you have to give Cisco is they know how to market... in
slides. That boring RFC document looks colorful, bright and full of
promi$e when Cisco have turned into a marketing slide.

It takes a lot of find the "boring" slides of some other vendors more
appealing, as a solution.

Mark.

Re: SRv6

[Mark Tinka]

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 .

Don't you just love Project Manager from vendor and Project Manager from
operator occupying a board room for all 365 days of the year, pointing
fingers at each other :-).

All the while, they are still mailing you their monthly Managed Services
invoice...

Mark.

Re: SRv6

[Mark Tinka]

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.

Re: SRv6

[Mark Tinka]

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 before, MPLS is not a bad tunneling service.
And while things can always be better, it's a bit hard to find anything
else, today, that is reasonably well baked-in and efficient (as it can be).

Mark.

Re: SRv6

[Mark Tinka]

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, because it is seemingly clear that network operators
(especially mobile providers) may actually buy this cockamamie.

Mark.

RE: SRv6

[aaron1]

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 over an IPv6 
network, seems that I could do that across the Internet as well.  

Thanks Tom, man, I have read so much the last week or so regarding sr/spring... 
so if you mean that I borrowed someone else's description of the anatomy of an 
SRv6 SID then, yes, I may have and didn't know it.  Hey, was it you? LOL

- Aaron

Re: SRv6

[Randy Bush]

> 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.

RE: SRv6

[aaron1]

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: SRv6

> 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?

Re: SRv6

[Tom Hill]

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.


"smartly divided"... Did someone else prepare these words for you? ;)

-- 
Tom

Re: SRv6

[Jeff Tantsura]

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 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 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?

Re: SRv6

[James W. Laferriere]

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 "realize"...
that SRv6 is a complex mess that needs some kind of centralized system
to manage. But wait, the centralized system is, itself, quite complex
that no operator would dare spend time installing, commissioning or
maintaining it themselves.

So what ever shall we do, as operators?

Simple, pay the vendor(s) to take care of all of it for you... planning,
design, spec'ing, bill of materials, deployment, operation and refresh
programs... lock that vendor top and bottom line in for them for the
next 10 years, while they find some other RFC to create in order to keep
the cycle going 11 years later.

Mark.


	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 .


Twyl ,  JimL

--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: SRv6

[Randy Bush]

> 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 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?

Re: SRv6

[Jeff Tantsura]

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.
> 
> as the packet payload is nekkid cleartext, where is the P in vpn?

Re: SRv6

[Nick Hilliard]

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 you want explicit path 
routing, you'll need to tack on a SRH which is another 8 octets + 16 
octets per SID, so e.g. an mpls frame with 2-node ERO goes from 12 
octets to 80 octets.


This comes at a cost.  What was previously a simple lookup operation on 
a tightly optimised format is now up to 10x bloated with little extra 
functionality to show for it.  It's true that these devices already do 
ipv6, but can they do ipv6 + complex decapsulation in a single pass?  If 
you're using an NPU, probably yes.  If an ASIC, maybe not.  What if the 
decapsulated packet has a stash of ipv6 extension headers?  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. Choose two - or maybe one.


The control plane is byzantine.  This also has a cost in terms of 
design, build and support / maintenance.  As Mark points out, many 
companies have made their fortunes with a full stack product offering, 
from hardware and software to design, engineering and operations.  It's 
not a bad business model as long as you realise that it's time-limited 
to the technology of the day. When it draws to a close, it's hard to 
turn companies around that have been used to a single-product or 
single-vertical cash trough which no longer exists.  Some have done this 
successfully; others have floundered.


Nick

Re: SRv6

[Randy Bush]

> 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?

Re: SRv6

[Saku Ytti]

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 (x=v or m) is able to do it.  Seems that the end to end 
> label challenges with unified mpls, and all the csc and vpn type a,b,c might 
> be better done with an IPv6 stack of headers and SIDs.

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.

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.

-- 
  ++ytti

RE: SRv6

[aaron1]

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 wrong, I love all that mpls has done for us and offers, but, 
seems that SRx6 (x=v or m) is able to do it.  Seems that the end to end label 
challenges with unified mpls, and all the csc and vpn type a,b,c might be 
better done with an IPv6 stack of headers and SIDs.

(wow, I'm not a prophet, but am I 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 
network programmability, application-to-network interaction or something like 
that.

Oh and I do agree that this SRv6 terminology and architecture does make your 
head hurt, lol, there is some very different/new stuff going on there.

-Aaron

Re: SRv6

[Mark Tinka]

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 kind of centralized system
to manage. But wait, the centralized system is, itself, quite complex
that no operator would dare spend time installing, commissioning or
maintaining it themselves.

So what ever shall we do, as operators?

Simple, pay the vendor(s) to take care of all of it for you... planning,
design, spec'ing, bill of materials, deployment, operation and refresh
programs... lock that vendor top and bottom line in for them for the
next 10 years, while they find some other RFC to create in order to keep
the cycle going 11 years later.

Mark.

Re: SRv6

[Saku Ytti]

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 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 unmanaged IP domains, unlike SRv6, since many people
filter EH at edges.

-- 
  ++ytti

Re: SRv6

[Mark Tinka]

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 hoping that a CTO and CEO near you do not drink the Kool-Aid, and
for once, can see right through a vendor's intentions.

Mark.

Re: SRv6

[Nick Hilliard]

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

Re: SRv6

[Mark Tinka]

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)
>
> https://www.cisco.com/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::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
> Mon Sep 14 20:27:09.727 UTC
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to fc00:0:4:4::1, timeout is 2 seconds:
> S
> Success rate is 100 percent (5/5), round-trip min/avg/max = 329/371/416 ms
>
>
> RP/0/RP0/CPU0:r1#traceroute fc00:0:4:4::1 source lo0 use-srv6-op-sid 
> fc00:0:0:4:40::
> Mon Sep 14 20:27:19.068 UTC
>
> Type escape sequence to abort.
> Tracing the route to fc00:0:4:4::1
>
>  1  :::0.0.0.0
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 29 msec
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 56 msec
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 12 msec
>  2  :::0.0.0.0
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 118 msec
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 101 msec
> [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1)   
>   ] 99 msec
>  3  fc00:0:4:4::1 224 msec 277 msec 254 msec
>  4  :::0.0.0.0 237 msec 209 msec 204 msec
>  5  fc00:0:4:4::1 386 msec 431 msec 403 msec
>
>
> Now I see this on the wireshark capture...
>
> Ethernet - 86dd
> Ipv6 - DA fc00:0:0:4:40:: (cool, this is the active/top SID, and not the 
> ping'ed DA)
> - routing header for v6 (segment routing)
> --- segments left: 1
> --- address next segment: fc00:0:4:4::1
> Icmpv6

My head hurts :-)...

Mark.

RE: SRv6

[aaron1]

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)

https://www.cisco.com/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::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
Mon Sep 14 20:27:09.727 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to fc00:0:4:4::1, timeout is 2 seconds:
S
Success rate is 100 percent (5/5), round-trip min/avg/max = 329/371/416 ms


RP/0/RP0/CPU0:r1#traceroute fc00:0:4:4::1 source lo0 use-srv6-op-sid 
fc00:0:0:4:40::
Mon Sep 14 20:27:19.068 UTC

Type escape sequence to abort.
Tracing the route to fc00:0:4:4::1

 1  :::0.0.0.0
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 29 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 56 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 12 msec
 2  :::0.0.0.0
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 118 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 101 msec
[IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1   ,SL=1) 
] 99 msec
 3  fc00:0:4:4::1 224 msec 277 msec 254 msec
 4  :::0.0.0.0 237 msec 209 msec 204 msec
 5  fc00:0:4:4::1 386 msec 431 msec 403 msec


Now I see this on the wireshark capture...

Ethernet - 86dd
Ipv6 - DA fc00:0:0:4:40:: (cool, this is the active/top SID, and not the 
ping'ed DA)
- routing header for v6 (segment routing)
--- segments left: 1
--- address next segment: fc00:0:4:4::1
Icmpv6



-Aaron

Re: SRv6

[Nick Hilliard]

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 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

RE: SRv6

[aaron1]

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

Re: SRv6

[Nick Hilliard]

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 Extension Headers in the underlay packet.

Nick