Bill,
> https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2
>
> "a) Remove from consideration all routes that are not tied for having
> the smallest number of AS numbers present in their AS_PATH
> attributes."
>
> So literally, the first thing BGP does when picking the best next hop
>
All,
> But that ship seems to have sailed.
The problem is well known and it consists of two orthogonal aspects:
#1 - Ability to signal the preference of which return path to choose by
arbitrary remote ASN
#2 - Actually applying this preference by remote ASN.
For #1 I have proposed some time
Schools
> michael.bro...@adams12.org
> ::::::::
> "flying is learning how to throw yourself at the ground and miss"
>
>
>
> On Fri, Aug 18, 2023 at 1:39 AM Robert Raszuk wrote:
>
>> Ja
t I was making is that this is not the fault of the Community
Attribute itself but rather the poor implementation choice.
Kind regards,
RR
On Fri, Aug 18, 2023 at 10:40 PM Matthew Petach
wrote:
>
>
> On Fri, Aug 18, 2023 at 12:31 PM Robert Raszuk wrote:
>
>> Hi Jakob,
k on code and with customer issues that escalate to code.
>
>
>
> Kind Regards,
>
> Jakob
>
>
>
>
>
> *From: *Robert Raszuk
> *Date: *Friday, August 18, 2023 at 10:59 AM
> *To: *Jakob Heitz (jheitz)
> *Cc: *nanog@nanog.org
> *Subject: *Re: Destination
at has any chance to go multiple ASes is as-path.
>
> Need to be careful with that too because long ones get dropped.
>
>
>
> route-policy testRP
>
> if as-path length ge 200 then
>
> drop
>
> endif
>
> end-policy
>
>
>
> Kind Regards,
>
Jakob,
With AS-PATH prepend you have no control on the choice of which ASN should
do what action on your advertisements.
However, the practice of publishing communities by (some) ASNs along with
their remote actions could be treated as an alternative to the DPA
attribute. It could result in
> This means you'd need to tag EVERYTHING - and that may be operationally
> problematic for Internet routes.
When I wrote my note I envisioned that RS on inbound may tag routes with
RTs (based on the very same communities you would filter without RTs)
Then enabling RTC SAFI would be pretty easy.
Hi Doug,
But what you need you can do today in any shipping decent implementation of
BGP using RTC.
https://datatracker.ietf.org/doc/html/rfc4684
While originally designed for L3VPNs long ago the use of RTC has been
extended for other address families including SAFI 1.
As a matter of fact
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
>
> 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
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
:
>
>
> On 9/Sep/20 15:25, Robert Raszuk wrote:
>
> That's not quite true.
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and inter-domain use
> is to help you to use the same encoding acros polic
>
> Well, the proposed de facto standard is only useful for what we need to
> signal outside of the AS.
That's not quite true.
See the entire idea behind defining a common mechanism for signalling
policy in communities in a flexible way for both intra and inter-domain use
is to help you to use
And use of BGP without IGP left and right when even today bunch of DCs can
do just fine with current IGPs scaling wise is IMO not a good thing.
Thx
R.
On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG wrote:
> I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP,
> example of
Mark,
Nope .. it is the other way around.
It is all easy if you look from your network centric view.
But if I am connected to 10 ISPs in each POP I have to build 10 different
egress policies, each embedding custom policy, teach NOC to understand it
etc...
I think if there is a defined way to
to customers or to others as you choose. Nothing there is
about trust. It is all about mechanics how you pass embedded instructions.
Best,
R.
On Wed, Sep 9, 2020, 06:25 Mark Tinka wrote:
>
>
> On 8/Sep/20 20:15, Robert Raszuk wrote:
>
> > This does not require any more trus
/20 18:41, Robert Raszuk wrote:
>
> > I don't think this is the ask here.
> >
> > Today NO_EXPORT takes no parameters. I think it would be of benefit to
> > all to be able to signal NO_EXPORT TO ASN_X in a common (std) way
> > across all of my peers connected to ASN_X
Mark,
> The standard already exists... "NO_EXPORT".
I don't think this is the ask here.
Today NO_EXPORT takes no parameters. I think it would be of benefit to all
to be able to signal NO_EXPORT TO ASN_X in a common (std) way across all of
my peers connected to ASN_X. Moreover policy on all
Hi Douglas,
Just FYI I have tried to capture most common use cases of communities and
register them as part of a wide-community effort in IANA.
https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02
That draft is pending standardization of wide-communities itself.
You
And just to add just a little bit of fuel to this fire let me share that
the base principle of BGP spec mandating to withdraw the routes when the
session goes down could be in the glory of IETF soon a history :(
It started with the proposal to make BGP state "persistent":
Sure thing :)
Btw my point was to avoid the potential impression that origin validation
brings any real security to bgp.
Cheers,
R.
On Mon, Aug 24, 2020 at 3:12 PM John Kristoff wrote:
> On Mon, 24 Aug 2020 13:01:15 +
> Robert Raszuk wrote:
>
> > I would not say that eith
John,
> Two precursors to the system we have today.
I would not say that either S-BGP nor so-BGP were precursors to BGP origin
validation ( I am assuming this is what you are referring to as "system we
have today").
If I recall, securing BGP and validating src ASN were independent projects
both
> I doubt we want to move away from those concepts.
I think we all do - except technology is not there yet. Just imagine if
over a single piece of fiber you will get infinite bandwidth delivered over
unlimited modulation frequency spectrum ...
IMHO till real true optical switching is a
imit the iBGP routes to go out over eBGP
this is all sufficient and we do not need a bit more protection there then
case solved.
Cheers,
R.
On Sun, Aug 2, 2020 at 4:42 PM Ca By wrote:
>
>
> On Sun, Aug 2, 2020 at 4:34 AM Robert Raszuk wrote:
>
>> All,
>>
>> Watching
All,
Watching this thread with interest got an idea - let me run it by this list
before taking it any further (ie. to IETF).
How about we learn from this and try to make BGP just a little bit safer ?
*Idea: *
In all stub (non transit) ASNs we modify BGP spec and disable automatic
iBGP to eBGP
>
> I reason that Intel's implication is that virtualization is becoming
> obsolete.
> Would anyone care to let me know his thoughts on this prediction?
>
Virtualization is not becoming obsolete ... quite reverse in fact in all
types of deployments I can see around.
The point is that VM provides
Bill,
> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices."
That's not exactly the real beginning ... the above is more like oh where
do we plug this SDN into and how do we sell
> Unfortunately not.
Fortunately very fortunately Mark.
L2VPNs running on someone's IP backbone sold by many as "circuits" has many
issues ... stability, MTU blackhols, random drops - and that is pretty much
the same all over the world :(
Very unfortunate technology just to mux more users
>
> > So to sum it up you simply can not run into any scaling ceiling with
> MP-BGP
> > architecture.
>
> Flooding nature of BGP requires all the related entities treat
> everything, regardless of whether they need it entirely or not.
That is long gone I am afraid ... Hint RFC 4684. Now
t; On 21/Jun/20 22:21, Robert Raszuk wrote:
>
>
> Well this is true for one company :) Name starts with j
>
> Other company name starting with c - at least some time back by default
> allocated labels for all routes in the RIB either connected or static or
> sourced from
>
> I should point out that all of my input here is based on simple MPLS
> forwarding of IP traffic in the global table. In this scenario, labels
> are only assigned to BGP next-hops, which is typically an IGP Loopback
> address.
>
Well this is true for one company :) Name starts with j
ers of
local label block.
So it is always the case that LFIB table (max 2^20 entries - 1M) on PEs is
much larger then LFIB on P nodes.
Thx,
R.
On Sun, Jun 21, 2020 at 6:01 PM Mark Tinka wrote:
>
>
> On 21/Jun/20 15:48, Robert Raszuk wrote:
>
>
>
> Actually when IGP changes
> I'm saying that, if some failure occurs and IGP changes, a
> lot of LSPs must be recomputed, which does not scale
> if # of LSPs is large, especially in a large network
> where IGP needs hierarchy (such as OSPF area).
>
> Masataka Ohta
>
Actually
Let's clarify a few things ...
On Sun, Jun 21, 2020 at 2:39 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat
Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Robert Raszuk wrote:
>
> > MPLS LDP or L3VPNs was NEVER flow driven.
> >
> > Since day one till today it was and still is purely destination based.
>
> If information to create labels at or near source
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the destination is necessary
> to prepare nested labels at the source, which costs a lot and should
> be attempted only for detected flows.
>
MPLS is not flow driven. I sent some mail
> there is saku's point of distributing labels in IGP TLVs/LSAs. i
> suspect he is correct, but good luck getting that anywhere in the
> internet vendor task force.
Perhaps I will surprise a few but this is not only already in RFC formats -
it is also shipping already across vendors for some
>
> One of the advantages cited for SRv6 over MPLS is that the packet contains
>> a record of where it has been.
>>
>
Not really ... packets are not tourists in a bus.
First there are real studies proving that most large production networks
for the goal of good TE only need to place 1, 2 or 3
>
> But, today, people are seems to be using, so called, MPLS, with
>
explicitly configured flows, administration of which does not
> scale and is annoying.
>
I am actually not sure what you are talking about here.
The only per flow action in any MPLS deployments I have seen was mapping
flow
Hi Mark,
As actually someone who was at that table you are referring to - I must say
that MPLS was never proposed as replacement for IP.
MPLS was since day one proposed as enabler for services originally L3VPNs
and RSVP-TE. Then bunch of others jumped on the same encapsulation train.
If at that
Hi Saku,
To your IGP point let me observe that OSPF runs over IP and ISIS does not.
That is first fundamental difference. There are customers using both all
over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with
>
> Anything that can support LDPv4 today can support LDPv6, in hardware.
>
While I am trying to stay out of this interesting discussion the above
statement is not fully correct.
Yes in the MPLS2MPLS path you are correct,
But ingress and egress switching vectors are very different for LDPv6 as
43 matches
Mail list logo
