Re: BFD for routes learned trough Route-servers in IXPs

[Randy Bush]

> a) Check if there is anything hindering the evolution of this draft to
> an RFC.

was i unclear?

> the draft passed wglc in 1948.  it is awaiting two
> implementations, as is the wont of the idr wg.

randy

Re: BFD for routes learned trough Route-servers in IXPs

[Paul Timmins]

On 9/17/20 1:51 PM, Douglas Fischer wrote:

But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any 
router in the LAN.


Especially given how some exchanges lock the mac address of 
participants. You could probably get away with ARP timeouts of a day or 
even just permanent with manual clearing when you see a peer go down.


-Paul

Re: BFD for routes learned trough Route-servers in IXPs

[Douglas Fischer]

If you look just to the normal situations...
1.2K vs 576K may not represent very much.

But if you look tho ARP Requests Graphs on a significative topology
changing on a big IXP, and also look to CPU-per-process graphs, maybe what
I'm suggesting could be more explicit.

I'm talking of good boxes freezing because of that.
Of course CoPP exists to avoid that. But the vanilla configurations of CoPP
combined with lunatic ARP-Timeout causes many day-by-day problems...

So, in this case, the solution would but a BCP with some "MUST"s defining
acceptable rates.

And with that, every that doesn't like to be waked up at dawn will become
happy(at least by this reason).


Em qui., 17 de set. de 2020 às 15:07, Saku Ytti  escreveu:

> On Thu, 17 Sep 2020 at 20:51, Douglas Fischer 
> wrote:
>
> > Why should we spend CPU Cycles with 576K ARP Requests a day(2K
> participants, 5 min ARP-Timeout).
> > Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
> > I would prefer to use those CPU cycles to process other things like BGP
> messages, BFD, etc...
>
> I think this communication may not be very communicative.
>
> How many more BGP messages per day can we process if we do 1.2k ARP
> requests a day instead of 576k? How many more days of DFZ BGP UPDATE
> growth is that?
>
> --
>   ++ytti
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: BFD for routes learned trough Route-servers in IXPs

[Saku Ytti]

On Thu, 17 Sep 2020 at 20:51, Douglas Fischer  wrote:

> Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants, 
> 5 min ARP-Timeout).
> Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
> I would prefer to use those CPU cycles to process other things like BGP 
> messages, BFD, etc...

I think this communication may not be very communicative.

How many more BGP messages per day can we process if we do 1.2k ARP
requests a day instead of 576k? How many more days of DFZ BGP UPDATE
growth is that?

-- 
  ++ytti

Re: BFD for routes learned trough Route-servers in IXPs

[Douglas Fischer]

Well...
My idea with the initial mail was:

a) Check if there is anything hindering the evolution of this draft to an
RFC.

b) Bet in try to make possible a thing that nowadays could be considered
impossible, like:
   "How to enable the BFD capability on a route-server with 2000 BGP
Sessions without crashing the box?"


And maybe:
c) How about suggesting a standard best practice dor ARP-Timeout for IXPs.
   And creating tools to measure the ARP-Timeout configurations of each
participant, and make this info available trough standard protocols.


Em qua., 16 de set. de 2020 às 18:14, Christopher Morrow <
morrowc.li...@gmail.com> escreveu:

> On Wed, Sep 16, 2020 at 4:55 PM Randy Bush  wrote:
> >
> > >>> So, I was searching on how to solve that and I found a draft (8th
> release)
> > >>> with the intention to solve that...
> > >>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
> > >>>
> > >>> If understood correctly, the effective implementation of it will
> depend on
> > >>> new code on any BGP engine that will want to do that check.
> > >>> It is kind of frustrating... At least 10 years after the release of
> RFC
> > >>> until the refresh os every router involved in IXPs in the world.
> > >>
> > >> you have a better (== easier to implement and deploy) signaling path?
> > >>
> > >> the draft passed wglc in 1948.  it is awaiting two implementations, as
> > >> is the wont of the idr wg.
> > >
> > > I think you also mean to say: "this is actually still a DRAFT and not
> > > an RFC, so really no BGP implementor is beholden to this document,
> > > unless they have coin bearing customers who wish to see this feature
> > > implemented"
> >
> > if i had meant to say that, i probably would have.  no one on this
> > thread has called it anything other than a draft, so i am quite unsure
> > what your point is; and i will not put words in your mouth.
>
> I think the OP said:
> " At least 10 years after the release of RFC
> > >>> until the refresh os every router involved in IXPs in the world."
>
> it's not an rfc yet.
>
> > sadly, these years, vendors do not seem to care a lot about drafts,
> > rfcs, ...  anything which sells.
>
> sure :(
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: BFD for routes learned trough Route-servers in IXPs

[Douglas Fischer]

About this comparison between CAM-Table Timeout, and ARP-Table Timeout.
I tend to partially agree with you...

Ethernet is a so widely used protocol to sever scenarios.
We need to consider the different needs of the type of communications.


For example:
I'm not a big fan of Mikrotik/RouterOS.
But I know they are there, and liking or not, I need to accept that I will
need to deal with then(as a peer or even as an operator).

One of most common uses of Mikrotik is for HotSpot/Captive Portal.
And for that, an ARP Timeout of 30 seconds is very OK!
Is a good way to check if the EndUser is still reachable on the network,
and based on that do the billing.

But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any router in
the LAN.

Another example:
You suggested equalizing ARP-Timeout and MAC-Timeout
For a campus LAN? With frequent topology changes, add/removes of
hosts every time...
That is perfect!


But talking about an IXP LAN:
In an ideal scenario, how often should happen topology changes on an IXP?
How often new hosts get ins/outs of hosts in the and IXP LAN?

Why should we spend CPU Cycles with 576K ARP Requests a day(2K
participants, 5 min ARP-Timeout).
Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
I would prefer to use those CPU cycles to process other things like BGP
messages, BFD, etc...





Em qui., 17 de set. de 2020 às 02:54, Saku Ytti  escreveu:

> On Wed, 16 Sep 2020 at 23:15, Chriztoffer Hansen
>  wrote:
> > On 16/09/2020 04:01, Ryan Hamel wrote:
>
> > > CoPP is always important, and it's not just Mikrotik's with default low
> > > ARP timeouts.
> > >
> > > Linux - 1 minute
> > > Brocade - 10 minutes
> > > Cumulus  - 18 minutes
> > > BSD distros - 20 minutes
> > > Extreme - 20 minutes
> > Juniper - 20 minutes
> > > HP - 25 minutes
> IOS - 4 hours
>
> Why are these considered (by Ryan) low values? Does low have a
> negative connotation here?
>
> ARP timeout should be lower than MAC timeout, and MAC timeout usually
> is 300 seconds. Anything above 300seconds is probably poor BCP for
> default value, as defaults should interoperate in a somewhat sane
> manner.
> Of course operators are free to configure very high ARP timeout, as
> long as they also remember to equally configure higher MAC timeout.
>
> --
>   ++ytti
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: SRm6 (was:SRv6)

[Jeff Tantsura]

MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is.
draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to 
provide an end2end SR path.

Cheers,
Jeff
On Sep 17, 2020, 9:32 AM -0700, James Bensley , 
wrote:
>
>
> On 17 September 2020 11:05:24 CEST, Saku Ytti  wrote:
> > On Thu, 17 Sep 2020 at 11:03, James Bensley 
> > wrote:
> >
> > > MPLSoUDP lacks transport engineering features like explicit paths,
> > FRR LFA and FRR rLFA, assuming only a single IP header is used for the
> > transport abstraction [1]. If you want stuff like TI-LFA (I assume this
> > is supported in SRm6 and SRv6, but I'm not familiar with these, sorry
> > if that is a false assumption) you need additional transport headers or
> > a stack of MPLS labels encapped in the UDP header and then you're back
> > to square one.
> >
> > One of us has confusion about what MPLSoUDP is. I don't run it, so
> > might be me.
> >
> > SPORT == Entropy (so non-cooperating transit can balance)
> > DPORT == 6635 (NOT label)
> > Payload = MPLS label(s)
> >
> > Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
> > another MPLS point-to-point adjacency after the MPLSoUDP
> > abstraction/tunnel.
>
> Nope, we have the same understanding. But the email I was responding to was 
> talking about using MPLSoUDP for service label encapsulation *only*, not 
> transport & services labels:
>
>
> > > If you want an IPv6 underlay for a network offering VPN services
> >
> > And what's wrong again with MPLS over UDP to accomplish the very same with 
> > simplicity ?
> >
> > MPLS - just a demux label to a VRF/CE
> > UDP with IPv6 header plain and simple
> >
> > + minor benefit: you get all of this with zero change to shipping hardware 
> > and software ... Why do we need to go via decks of SRm6 slides and new wave 
> > of protocols extensions ???
>
>
> Cheers,
> James.

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: SRm6 (was:SRv6)

[James Bensley]

On 17 September 2020 11:05:24 CEST, Saku Ytti  wrote:
>On Thu, 17 Sep 2020 at 11:03, James Bensley 
>wrote:
>
>> MPLSoUDP lacks transport engineering features  like explicit paths,
>FRR LFA and FRR rLFA, assuming only a single IP header is used for the
>transport abstraction [1]. If you want stuff like TI-LFA (I assume this
>is supported in SRm6 and SRv6, but I'm not familiar with these, sorry
>if that is a false assumption) you need additional transport headers or
>a stack of MPLS labels encapped in the UDP header and then you're back
>to square one.
>
>One of us has confusion about what MPLSoUDP is. I don't run it, so
>might be me.
>
>SPORT == Entropy (so non-cooperating transit can balance)
>DPORT == 6635 (NOT label)
>Payload = MPLS label(s)
>
>Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
>another MPLS point-to-point adjacency after the MPLSoUDP
>abstraction/tunnel.

Nope, we have the same understanding. But the email I was responding to was 
talking about using MPLSoUDP for service label encapsulation *only*, not 
transport & services labels:


>>  If you want an IPv6 underlay for a network offering VPN services 
>
> And what's wrong again with MPLS over UDP to accomplish the very same with 
> simplicity ? 
>
> MPLS - just a demux label to a VRF/CE
> UDP with IPv6 header plain and simple 
> 
> + minor benefit: you get all of this with zero change to shipping hardware 
> and software ... Why do we need to go via decks of SRm6 slides and new wave 
> of protocols extensions ???


Cheers,
James.

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: SRm6 (was:SRv6)

[Robert Raszuk]

Spot on.

And on the point of protection ... in all cases it is orthogonal to the
service itself. If you want to use it you enable it regardless if your
packet's transport is IPv4, IPv6, MPLS or any SR flavor.

Sure if you need to traffic engineer your services some form of path
control is required. It can be stack of SIDs, it can be pre-signalled paths
or it can be pure encap-decap on selected anchor points. Your network -
your choice.

Thx,
R.


On Thu, Sep 17, 2020 at 11:07 AM Saku Ytti  wrote:

> On Thu, 17 Sep 2020 at 11:03, James Bensley 
> wrote:
>
> > MPLSoUDP lacks transport engineering features  like explicit paths, FRR
> LFA and FRR rLFA, assuming only a single IP header is used for the
> transport abstraction [1]. If you want stuff like TI-LFA (I assume this is
> supported in SRm6 and SRv6, but I'm not familiar with these, sorry if that
> is a false assumption) you need additional transport headers or a stack of
> MPLS labels encapped in the UDP header and then you're back to square one.
>
> One of us has confusion about what MPLSoUDP is. I don't run it, so might
> be me.
>
> SPORT == Entropy (so non-cooperating transit can balance)
> DPORT == 6635 (NOT label)
> Payload = MPLS label(s)
>
> Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
> another MPLS point-to-point adjacency after the MPLSoUDP
> abstraction/tunnel.
>
> --
>   ++ytti
>

Re: SRm6 (was:SRv6)

[Saku Ytti]

On Thu, 17 Sep 2020 at 11:03, James Bensley  wrote:

> MPLSoUDP lacks transport engineering features  like explicit paths, FRR LFA 
> and FRR rLFA, assuming only a single IP header is used for the transport 
> abstraction [1]. If you want stuff like TI-LFA (I assume this is supported in 
> SRm6 and SRv6, but I'm not familiar with these, sorry if that is a false 
> assumption) you need additional transport headers or a stack of MPLS labels 
> encapped in the UDP header and then you're back to square one.

One of us has confusion about what MPLSoUDP is. I don't run it, so might be me.

SPORT == Entropy (so non-cooperating transit can balance)
DPORT == 6635 (NOT label)
Payload = MPLS label(s)

Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
another MPLS point-to-point adjacency after the MPLSoUDP
abstraction/tunnel.

-- 
  ++ytti

Re: BFD for routes learned trough Route-servers in IXPs

[Robert Raszuk]

>
> If the traffic is that important then the public internet is the wrong
> way to transport it.


Nonsense.

It is usually something said by those who do not know how to use Internet
as a transport in a reliable way between two endpoints.

In your books what is Internet good for ? Torrent and porn ?

>  The internet has convergence times up to multiple minutes.

It does not matter how long does it take to "converge" any single path.

Hint: Consider using multiple disjoined paths and you see that for vast
majority of "Internet failures" the connectivity restoration time would be
very close to your RTT time between your endpoints.

Rgs,
R.

Re: SRm6 (was:SRv6)

[James Bensley]

On 16 September 2020 23:51:03 CEST, Robert Raszuk  wrote:
>Hi Ron,
>
>>  If you want an IPv6 underlay for a network offering VPN services
>
>And what's wrong again with MPLS over UDP to accomplish the very same
>with
>simplicity ?
>
>MPLS - just a demux label to a VRF/CE
>UDP with IPv6 header plain and simple
>
>+ minor benefit: you get all of this with zero change to shipping
>hardware
>and software ... Why do we need to go via decks of SRm6 slides and new
>wave
>of protocols extensions ???
>
>Best,
>Robert.
>
>

>>
>>
>> Please consider the TE mechanism described in
>> draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism
>described
>> in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and
>match
>> basis. For example can deploy:
>>
>>
>>
>>- Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow
>the
>>least-cost path from PE to PE.
>>- Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy
>method
>>(VXLAN, RFC 4797) to label services.
>>
>>
>>
>> In all cases, the semantic of the IPv6 address is unchanged. There is
>no
>> need to encode anything new in the IPv6 address.

MPLSoUDP lacks transport engineering features  like explicit paths, FRR LFA and 
FRR rLFA, assuming only a single IP header is used for the transport 
abstraction [1]. If you want stuff like TI-LFA (I assume this is supported in 
SRm6 and SRv6, but I'm not familiar with these, sorry if that is a false 
assumption) you need additional transport headers or a stack of MPLS labels 
encapped in the UDP header and then you're back to square one.

Cheers,
James.

[1] I'm interested to hear if anyone has done any large scale MPLSoUDP work. 
Did you hack in this functionality with static egress interface entries/static 
routes pushed from a central controller for specific IPs reserve as "path" IPs?

Re: BFD for routes learned trough Route-servers in IXPs

[Karsten Elfenbein]

Am Mi., 16. Sept. 2020 um 02:57 Uhr schrieb Douglas Fischer
:
>
> Time-to-time, in some IXP in the world some issue on the forwarding plane 
> occurs.
> When it occurs, this topic comes back.
>
> The failures are not big enough to drop the BGP sessions between IXP 
> participants and route-servers.
>
> But are enough to prejudice traffic between participants.
>
> And then the problem comes:
> "How can I check if my communication against the NextHop of the routes that I 
> learn from the route-servers are OK?
> If it is not OK, how can I remove it from my FIB?"

If the traffic is that important then the public internet is the wrong
way to transport it. The internet has convergence times up to multiple
minutes. Failures can occur everywhere.
Reacting to these changes comes at a global cost.

> Some other possible causes of this feeling are:
> - ARP Resolution issues
> (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a 
> bombastic recipe)
> - MAC-Address Learning limitations on the transport link of the participants 
> can be a pain in the a..rm.

IXP can/do limit the participant port allowed MAC
IXP usually provide a sane config which includes ARP timeouts (which
can be checked and an ARP sponge helps as well)
The same goes for all the other multicast/broadcast protocols.

>
> So, I was searching on how to solve that and I found a draft (8th release) 
> with the intention to solve that...
> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>
> If understood correctly, the effective implementation of it will depend on 
> new code on any BGP engine that will want to do that check.
> It is kind of frustrating... At least 10 years after the release of RFC until 
> the refresh os every router involved in IXPs in the world.
>
>
> Some questions come:
> A) There is anything that we can do to rush this?
> B) There is any other alternative to that?

IXP are not simple L2 switches anymore, forwarding is done with
LACP/MPLS/VXLAN/... over multiple paths. When A and B can reach a
route-server it does not guarantee that A can reach B.
Using BFD between members might help or might not as you can not check
the complete topology below.

The IXP should use BFD and maybe even compare interface counters on
both sides of a link in their infrastructure.

@past dayjob: We monitored IXP health by pinging our peers/next-hops
every X minutes and alerted NOC when there would be bigger changes.
Like 10% of peers/next-hops that responded before stopped responding
to ICMP.

>
> P.S.1: I gave up of inventing crazy BGP filter polices to test reachability 
> of NextHop. The effectiveness of it can't even be compared to BFD, and almost 
> kill de processing capacity of my router.
>
> P.S.2: IMHO, the biggest downside of those problems is the evasion of 
> route-servers from some participants when issues described  above occurs.

route-servers caused some issues in the past like not propagating the
revocation/timeout of prefixes
some peers like a more direct relationship