Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

I have worked on more than one BGP implementation, but not all of them, of 
course.
On memory requirements for as-paths:
Attribute sets are shared among stored routes.
That means if two stored routes have the same attribute sets, the attribute set 
is stored only once.
As-paths are shared among attribute sets.
That means if two stored attribute sets have the same as-path, then the as-path 
is stored only once.
Storing them in the control plane is not a big problem.

However, as-paths can be sent in netflow.
Netflow is generated in the forwarding plane.
AS-paths are not stored in expensive fast memory on the forwarding plane, but 
still,
using memory on the forwarding plane has greater impact than on the control 
plane.

An as-path consists of AS_SEQUENCEs (and other elements). An AS_SEQUENCE can 
contain
a maximum of 255 ASNs. If the as-path is longer, then multiple AS_SEQUENCEs are
required. The code to parse them and create them is not often exercised and
is a potential for bugs in fresh code. The older implementations have these bugs
well and truly shaken out of them.

Regards,
Jakob.

From: GROW  On Behalf Of Michael McBride
Sent: Sunday, July 26, 2020 11:42 AM
To: grow@ietf.org
Subject: [GROW] AS_Path prepend BCP

Hello wg,

We have submitted 
https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ which is 
intended to be a bcp in the use of AS_Path prepend based on work of Doug 
Madory. As we state in the intro: AS_Path prepending is discussed in Use of BGP 
Large Communities [RFC8195] and this document provides additional, and 
specific, guidance to operators on how to be a good internet citizen with the 
proper use of AS_Path prepend.

We would encourage feedback on this document.

thanks,
mike
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : Methods for Detection and Mitigation of BGP Route 
Leaks
Authors : Kotikalapudi Sriram
  Alexander Azimov
Filename: draft-ietf-grow-route-leak-detection-mitigation-03.txt
Pages   : 9
Date: 2020-07-27

Abstract:
   Problem definition for route leaks and enumeration of types of route
   leaks are provided in RFC 7908.  This document describes a new well-
   known Large Community that provides a way for route-leak prevention,
   detection, and mitigation.  The configuration process for this
   Community can be automated with the methodology for setting BGP roles
   that is described in ietf-idr-bgp-open-policy draft.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-03
https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Hongwei Li]

In reality, economic cost (as Martijn pointed out), easy to remember and
use, what you get is what you see, human brains like to walk shortcut, etc,
affect which attribute to use.
Prepending as_path has been demonstrated as the way most operators choose.
It will be very good that we can have best practice.
To make the best practice widely used, it had better provide alternative
practical ways for the don'ts.

BR,
Hongwei

On Mon, Jul 27, 2020 at 5:58 AM Martijn Schmidt  wrote:

> On 7/27/20 1:16 AM, Randy Bush wrote:
> >> That being said, selective more specific prefix announcements are the
> >> bane of my existence when attempting to keep traffic local in the less
> >> mainstream regions of the world. When a given network has some local
> >> transit/peer and some backhauled transit/peer to which it sends a
> >> different set of more specifics, resolving routing hairpins can become
> >> extremely time consuming since we have to convince the team running
> >> that network to adjust their routing policy - as opposed to
> >> unilaterally assigning a higher LocalPref to the announcement which
> >> may have a longer AS-path but doesn't take a scenic route through
> >> $cheap_transit/peering_region.
> > i am probably misreading, but on the surface this seems to be a routing
> > policy problem in the "local transit/peer."  perhaps a diagramatic
> > example would help.
> >
> > randy
> In certain regions of the world it's common for networks to buy all
> their transit in a foreign country, and then backhaul it to the end user
> population over a submarine cable. Some of those submarine cables are
> relatively short (in the order of 1300km to a regional interconnection
> hub) and others are relatively long (in the order of 8500km to one of
> the mainstream interconnection hubs). Usually the transit backhauled
> over the short cable is from a tier-2 network with local peerings, and
> the transit backhauled over the long cable is from a global tier-1
> network that only peers other tier-1 providers.
>
> You can guess that, all announcements being equal, the nearby tier-2
> transit will take a lot more traffic than the far away tier-1 transit.
> Because the main cost of buying transit is in the submarine cable costs
> for these networks, they will do their best to implement traffic
> engineering with the goal of maximizing utilization on all links they
> have - and that load distribution is often achieved through selective
> more specific prefix announcements, rather than prepending.
>
> This would not be a major issue if both transits were equal in terms of
> peering policy and geographical distance, but the reality is that this
> frequently results in certain prefixes only being available through a
> distant tier-1 transit no matter how much LocalPref you throw at it. And
> that's quite detrimental to the service quality when one has built a PoP
> in the regional interconnection hub at the other end of that
> aforementioned 1300km cable with the purpose of running multiplayer
> videogame services for the wider region so that there's sufficient
> playerbase to start a match at all times of the day. By the way, this
> type of traffic is real-time with reaction speeds measured in
> milliseconds - it can't be cached and served through a CDN.
>
> Best regards,
> Martijn
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Martijn Schmidt]

On 7/27/20 1:16 AM, Randy Bush wrote:
>> That being said, selective more specific prefix announcements are the
>> bane of my existence when attempting to keep traffic local in the less
>> mainstream regions of the world. When a given network has some local
>> transit/peer and some backhauled transit/peer to which it sends a
>> different set of more specifics, resolving routing hairpins can become
>> extremely time consuming since we have to convince the team running
>> that network to adjust their routing policy - as opposed to
>> unilaterally assigning a higher LocalPref to the announcement which
>> may have a longer AS-path but doesn't take a scenic route through
>> $cheap_transit/peering_region.
> i am probably misreading, but on the surface this seems to be a routing
> policy problem in the "local transit/peer."  perhaps a diagramatic
> example would help.
>
> randy
In certain regions of the world it's common for networks to buy all 
their transit in a foreign country, and then backhaul it to the end user 
population over a submarine cable. Some of those submarine cables are 
relatively short (in the order of 1300km to a regional interconnection 
hub) and others are relatively long (in the order of 8500km to one of 
the mainstream interconnection hubs). Usually the transit backhauled 
over the short cable is from a tier-2 network with local peerings, and 
the transit backhauled over the long cable is from a global tier-1 
network that only peers other tier-1 providers.

You can guess that, all announcements being equal, the nearby tier-2 
transit will take a lot more traffic than the far away tier-1 transit. 
Because the main cost of buying transit is in the submarine cable costs 
for these networks, they will do their best to implement traffic 
engineering with the goal of maximizing utilization on all links they 
have - and that load distribution is often achieved through selective 
more specific prefix announcements, rather than prepending.

This would not be a major issue if both transits were equal in terms of 
peering policy and geographical distance, but the reality is that this 
frequently results in certain prefixes only being available through a 
distant tier-1 transit no matter how much LocalPref you throw at it. And 
that's quite detrimental to the service quality when one has built a PoP 
in the regional interconnection hub at the other end of that 
aforementioned 1300km cable with the purpose of running multiplayer 
videogame services for the wider region so that there's sufficient 
playerbase to start a match at all times of the day. By the way, this 
type of traffic is real-time with reaction speeds measured in 
milliseconds - it can't be cached and served through a CDN.

Best regards,
Martijn
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

[Robert Raszuk]

If people still think of adding p2p config push to the protocol which
allows all of us to function - by all means the answer to your question is
YES.

Thx,
R.

On Mon, Jul 27, 2020 at 2:21 AM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the explanation.
>
> “new BGP Transport Instance with new separate port and separate process”,
> very interesting perspective.
>
>
>
> But draft-raszuk-ti-bgp-01 was written 10 years ago. Is it still valid and
> worth pursuing?
>
>
>
> Thank you
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar 
> *Cc:* Lizhenbin ; Jakob Heitz (jheitz) <
> jhe...@cisco.com>; i...@ietf.org; grow@ietf.org grow@ietf.org <
> grow@ietf.org>; rt...@ietf.org
> *Subject:* Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt
> can be used for draft-ietf-rtgwg-net2cloud-gap-analysis
>
>
>
> Hi Linda,
>
>
>
> So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow
> ... Note BGP is not too secure transport ! I would never allow any peer to
> push me policy via eBGP to my ASBRs regardless how much I would trust it.
>
>
>
> That aside I think no one is questioning that overall this is nice to have
> BGP policy distributed in a dynamic way. We are however concerned in
> three planes ...
>
>
>
> Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly
> make this proposal p2p. And no Robin p2p is not a special case of p2mp :)
>
>
>
> Aspect #2 - This proposal adds additional burden to IP Routing BGP
> subsystem and its clear that if approved there will be more and more
> extensions to new MATCH and SET sub-TLVs coming. While it is easy to write
> a draft that at the end requires a serious commitment from any vendor to
> now turn BGP into configuration channel. That means overall more cycles
> spend and more burden on BGP dev teams.
>
>
>
> Aspect #3 - The proposal has lots of technical issues (as described) which
> can not just be swapped under the carpet.
>
>
>
> My recommendations (in order of preference):
>
>
>
> *1*
>
>
>
> Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along
> with real time response status codes to send required policy over targeted
> TCP sessions just using curl to remote ASBRs. Note all vendors today
> support RESTful commands or httpd on the routers. Some already even support
> JSON based BGP configuration for some time now (ex: NX-OS).
>
>
>
> *2*
>
>
>
> At least decouple it from routing BGP - support new BGP Transport Instance
> with new separate port and separate process. Whenever we need to use such
> protocol (call it Configuration Transport Protocol "CTP") for loop free
> information dissemination such isolation could deliver what you are really
> after with no impact to stability of IP routing.
>
> Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
> 
>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar 
> wrote:
>
> Robert, Jakob, etc.
>
>
>
> Thank you very much for detailed explanation of the issues.
>
> One of the points you all raised is that p2p policies should be
> administrated by controller via NETCONF.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
> 
> describes a scenario of one vCPE in cloud DC reachable by multiple PEs.
> Depending on the nature of the applications or/and network conditions, some
> applications may need to egress or ingress from PE1, others may need to
> egress or ingress from PE2.
>
>
>
> Today’s Cloud DC configuration can use the AS Path metric to influence the
> preferred path to/from a specific PEs. But requires manual configuration.
>
> After reading through the draft-ietf-idr-rpd-05, I think the automatic
> approach can make the change on demand. The policy change can be ephemeral.
>
> Therefore, if one side doesn’t implement the feature, the “spray” doesn’t
> have any impact. The traffic egress or ingress to the peer network would
> just go with the configuration. If the “spray” is answered, then the
> performance can be improved.
>
>
>
>
>
>
>
>
>
>
>
>
>
> If not using the automatic method proposed by draft-ietf-idr-rpd, do you
> have other suggestions?
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
>
> *From:* Robert Raszuk 
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar ; Lizhenbin <
>