Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

Hi Robert,

> On Aug 2, 2020, at 3:22 AM, Robert Raszuk  wrote:
> 
> Hi Greg,
>  
> > Have anyone tried to document that instead of doing AS-PATH prepend across 
> > set of upstreams (for whatever valid reason that may be) the preferred 
> > entrance should advertise the paths with IGP or EGP origin while the other 
> > ASBRs (which would otherwise prepend N times) with INCOMPLETE ? BGP best 
> > path should automatically across most implementations do the right path 
> > selection. 
> 
> Offhand, I don’t know of anyone who has tried to document this.  But why EGP 
> origin?  EGP is a Historic protocol that is rarely if ever used.  IMO, 
> although this technique could work, it is misleading.
> 
> I thought it is not used too but looking at the BGP table it is there: 
> 
> cto-asr1x-ny1#sh ip bgp detail | count .*EGP.*external, best.*
> Number of lines which match regexp = 826
> 
> cto-asr1x-ny1#sh ip bgp detail |  count .*EGP.*
> Number of lines which match regexp = 2345

Actually, I meant that EGP protocol speakers (implemented according to RFC 904 
) are rarely if ever used anymore.  
I’m sorry if I was unclear.

> Then looking at some vendor's docs I see that they apply it if the advertised 
> route was learned via different ASN (many folks run more then one AS 
> globally)  bit of surprise as RFC4271 never mentioned such use case.
> 
> origin egp—(Optional) BGP origin attribute that indicates that the path 
> information originated in another AS.
> 
> So one could argue that it is misleading already today :)

Agreed.

> > If not maybe we should think about a new attribute along the lines of cost 
> > community to be more widely used in a transitive manner and to have single 
> > meaning to allow to deprefer a prefix originated by given AS across number 
> > of ISP uplinks with a numeric value (just like MED or Local Pref are used 
> > locally).
> 
> IMO, this is a better idea.
> 
> Well sure, but you know the time we take to define it, the time vendors take 
> to implement it, the time it takes to deploy it then the time it takes for 
> folks to actually start using it we are talking years  
> 
> Sure if we never start we will never get there but in the mean time perhaps 
> we could use what's deployed everywhere to trim size of AS-PATHs yet get all 
> the benefits of AS-PATH prepends ?

Perhaps a better way for me to express my concern is (ideally), any mention of 
"origin egp" in future RFCs should not recommend its use unless the Historic 
EGP protocol is used.  I hope that is more clear.  That would at least be 
consistent with the original, intended use of “origin egp”.

> Clearly I am here just trying to probe the WG list on three questions  
> 
> Is it worth to try it - ie. do we have a problem, 
> Is this a good idea - ie. do we break anything,
> Should this option be added to draft-mcbride-grow-as-path-prepend as 
> something to consider instead of doing N times AS-PATH prepend (often N > 5 
> or N> 10 )
> 
> See at the end of the day the best thing about this is that anyone can try to 
> advertise his paths with different origin even today and it should just work 
> - without anyone else doing anything configuration wise in the upstream ASNs. 
> 
> Thx,
> R.


I’m thinking along the lines that (excessive) prepending is used because there 
isn’t an alternative that more clearly expresses the intent of the operator.  
If specifying a new attribute would facilitate that, I would be in favor of it.

Regards, Greg

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

Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

> On Jul 26, 2020, at 12:28 PM, David Farmer  wrote:
> 
> 
> 
> On Sun, Jul 26, 2020 at 2:10 PM Randy Bush  > wrote:
>  
> no need to attribute nationality to bad practice examples 
> Also, there is no need to attribute the bad examples to anyone, anonymize the 
> bad examples using documentation prefixes and documentation ASNs. We all have 
> made mistakes, I know I wouldn't want mine memorialized forever in an RFC.

OK, fair enough.  But I’m concerned that if there are no references to examples 
(good or bad), a reader who has little or no experience with this issue will 
have no basis to compare the different types of prepending.

I’d like to see the approach taken in RFC 7908 
 used here also.  There were several 
incidents of route leaks cited, but route leaks were also classified according 
to types identified in the incidents.

Out of curiosity, were people unhappy that 7908 called attention to the 
organizations involved in the route leak incidents?  Also, arguably, the 
mistakes called attention to in the AS_Path prepend draft have been 
“memorialized” because they can be accessed through the Datatracker (provided 
one knows how to use its history features).

Regards, Greg


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

Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

Comments inline

> On Jul 26, 2020, at 12:50 PM, Robert Raszuk  wrote:
> 
> All,
> 
> Happy to see this draft ! Have been struggling with explaining some of those 
> issues and lack of such BCPs was sort of implicit prove that it is all fine 
> to prepend at will. 
> 
> Said this it seems clear that putting aside cases of unnecessary use or use 
> by errors AS-PATH prepends we are still facing no Internet wide path 
> de-prefernecing in BGP being commonly used other then mangling AS-PATH. 
> 
> The point is that multihoming is common and if someone needs at least to try 
> to influence entrance to his domain AS-PATH prepend comes as low hanging 
> fruit. 
> 
> Longer prefix will not work when on both ASBRs a /24 is injected.. 
> 
> So let me ask a question here ... 
> 
> Have anyone tried to document that instead of doing AS-PATH prepend across 
> set of upstreams (for whatever valid reason that may be) the preferred 
> entrance should advertise the paths with IGP or EGP origin while the other 
> ASBRs (which would otherwise prepend N times) with INCOMPLETE ? BGP best path 
> should automatically across most implementations do the right path selection. 

Offhand, I don’t know of anyone who has tried to document this.  But why EGP 
origin?  EGP is a Historic protocol that is rarely if ever used.  IMO, although 
this technique could work, it is misleading.

> Anyone see any issue with that ? If that works we could actually start to 
> strongly discourage use of AS-PATH prepending. 
> 
> If not maybe we should think about a new attribute along the lines of cost 
> community to be more widely used in a transitive manner and to have single 
> meaning to allow to deprefer a prefix originated by given AS across number of 
> ISP uplinks with a numeric value (just like MED or Local Pref are used 
> locally).

IMO, this is a better idea.

> Another question the draft talks about AS-PATH prepends by actual sources ... 
> well suffice to just take a look at Internet tables in few places to see that 
> even some transit operators prepend themselves to the original paths (also 
> already prepended). And yes I do have captures of those. 
> 
> Thx,
> R.

Regards, Greg

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

Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Greg Skinner]

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) Bof 
 from IETF 52 (10 December 2001) 
the meeting you were thinking of?  There are also references to an IAB meeting 
in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, Netflow 
 that culminated in 
RFC 3535 .

Robin,

Regarding the draft in question, I generally agree with the concerns others 
have made that it doesn’t appear to provide anything that other technologies 
such as YANG provide.  Also, IMO, the draft needs considerable work to be more 
easily understood.  For example, there are many acronyms such as CSNP and PSNP 
that are not defined, and may be misunderstood by readers not familiar with 
ISIS.  In the packet format sections, there are several uncapitalized uses of 
‘should’..  Do the authors consider these to be non-normative requirements?  
There are also statements such as "Network OAM statistics show that a 
relatively large part of the network issues are caused by the disfunction of 
various routing protocols and MPLS signalings” that are offered without 
citations.

Regards,
Greg

> On Jul 7, 2018, at 8:25 PM, Randy Bush  wrote:
> 
> robin,
> 
> i am not ignoring you.  i did not want to write unless i had something
> possibly useful to say; and that requires pretending to think, always
> difficult.
> 
>> I would also like to propose following draft for your reference which
>> trigger us to move forward for better network maintenance with
>> multiple tools in which gRPC/NETCOF and NMP/BMP may play different
>> roles: https://datatracker.ietf.org/doc/draft-song-ntf/
> 
> [ warning: my memory is likely fuzzy, and the glass is dark ]
> 
> at an ietf in the late '90s[0], there was a hastily called meeting of
> the snmp standards bearers and a bunch of operators.  the snmp folk were
> shocked to learn that no operators used snmp for other than monitoring;
> no one had snmp write enabled on devices; ops configured with the
> cli[1].  from this was born netconf and the xml path.  credit where due:
> phil eng was already well down this path at the time of that meeting.
> 
> but netconf/xml was a mechanism and lacked a model.  snmp had models,
> whether we thought they were pretty or not.  thus yang was born, and ,
> of course, a new generation wants to use the latest modern toys such as
> restconf, openconfig, json, ...
> 
> draft-song-ntf yearns for an "architectural framework for network
> telemetry," a lofty and worthwhile goal not, a priori, a bad one.  but a
> few comments from a jaded old dog.
> 
> for a new paradigm to gain traction, it must be *significantly* better
> than the old one, or the old paradigm must be clearly failing.  in the
> story above, snmp was clearly failing, aside from using an unfashionable
> encoding.  and yang clearly provided something needed and missing from
> netconf.  note that this paradigm shift has taken over 20 years; and we
> dis the itu et alia.
> 
> second, draft-song-ntf is an export-only model.  while telemetry is
> extremely important, i will be very frustrated if i can only hear and
> may not speak.  and the more it evolves to a really attractive paradigm
> and model, the more annoyed i will be that i can not use it for control.
> 
> and lastly, to quote don knuth, "premature optimization is the root of
> all evil."  do not get distracted by squeezing bits out of an encoding.
> focus on things such as simple, clear, securable, extensible ...
> 
> randy
> 
> ---
> 
> 0 - i would love help pinning down which meeting
> 
> 1 - i still have the "it's the cli, stupid" tee shirt.  an american
>political slogan of the era was "it's the economy, stupid."
> 

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

Re: [GROW] Finishing up the last call for draft-ietf-grow-blackholing

[Greg Skinner]

Indeed, RFC 7454 uses "longer", rather than "larger", in this case.  This has 
also been my experience.

https://tools.ietf.org/html/rfc7454#section-6.1.3

On Aug 04, 2016, at 02:18 AM, Mikael Abrahamsson  wrote:

On Fri, 15 Jul 2016, joel jaeggli wrote:

Folks,

During the IETF last call there were signficant concerns raised with
this draft resulting in two revisions and a change in intended status to
informational. Criticism of the proposal revolved largly along two axis.

Just to bring it up to the list as well:

https://tools.ietf.org/html/draft-ietf-grow-blackholing-02

3.3. Accepting Blackholed IP Prefixes

It has been observed that announcements of IP prefixes larger than
/24 for IPv4 and /48 for IPv6 are usually not accepted on the
Internet (see section 6.1.3 [RFC7454]).


The "larger" here is definitely in error. I guess it's supposed to be 
"longer"?


--
Mikael Abrahamsson email: swm...@swm.pp.se

___
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] I-D Action: draft-ietf-grow-filtering-threats-04.txt

[Greg Skinner]

Brief comment inline.

On Feb 12, 2015, at 09:58 AM, Rick Casarez rick.casa...@gmail.com wrote:

Hello Pierre,

With the hope of not cluttering it up too much I will also respond in line. 


---
Cheers, Rick

Experiences not things.

On Thu, Feb 12, 2015 at 12:15 PM, Pierre Francois pierre.franc...@imdea.org 
wrote:

Hello Rick, 

Please see my comments inline.

On Feb 12, 2015, at 8:18 AM, Rick Casarez rick.casa...@gmail.com wrote:

I checked the history of the document but did not see this so forgive me if 
these were discussed before.


No problem. Thank you for your interest and time spent on giving us feedback. 



In section 2.2.1: In the scenario and figure listed I am having trouble finding what the issue is. The forwarding is following the exact path the end AS wants based on policy so I am not sure how this is unexpected. 



The issue is not on the end AS side, the end AS is happy with the situation. 
The issue is that AS64502 configures bgp to not provide connectivity between 
64503 and 64504, (typically because they both are peers and 64502 does not want 
to provide a free ride on its network), 
and yet, it does so due to the game going on. 

Ah, I see where you are going with it now although I think you meant AS64505 which is the Peer AS and not customer AS (64504). 


While I understand it I am still somewhat confused. Since AS64505 does not have 
a connection to AS64501 it will still use 64502 as a transit AS to get to the 
destination AS (AS64501). So the problem is not the usage of AS64502 as a 
transit AS (Since that still occurs if the /34 is withdrawn), nor is it that 
the routing shown is unexpected given the prefix being leaked and the 
limitations of propogation set by the originator. It is the fact that the 
traffic-engineering being done by AS64501 may impact the interconnect or 
Peering policies between AS64502 and AS64503 adversely. This would especially 
be important if as part of the Peering relationship between AS64502 and AS64503 
there is a ratio requirement or the interconnect is already running near peak.

Perhaps instead of unexpected routing it should be adverse effects of this type of 
routing. I would even posit that the word unintentional might also be added since most 
peering agreements are locked under NDAs and the originator AS64501 might not know he is having an impact or 
even the nature of the relationship between AS64502 and AS64503 legally.



Now if you were to shift AS64505 so that it dual homed to both AS64502 AND AS64503 you can demonstrate a scenario of inefficient (and unexpected) routing if I am reading the figure correctly. Since AS64505 only sees the /32 from both AS upstreams from AS64501 but its algorithm selects AS64502. We know that AS64502 forwards to AS64503 and then on to the originating AS (AS64501). This is inefficient since AS64505 has a direct connection to AS64503 it could have saved an AS hop (and consequently line/equipment induced delays) by going direct to that AS had the /34 prefix been allowed to propagate further.   


The very first time we presented this case, we've been invited by an operator 
telling us the following story:

It happened to me.

(I put it in context of figure 2.1.1).

Transit to 64502 is expensive and 64501 tends to use its link too much.
64503 is not expensive, nice capacity, and some common business interests with 
64501. 

64502 has much better reach to 64504 than 64503 (capacity, delay), because 
64503 uses 64505 to reach 64504 and well, 64505 is not the best transit network 
ever.
So 64503 and 64502 have both interest in having the trick path followed. 

so, to summarize: 

64501 - 64502 - 64504 : best path but expensive and transit link to 64502 tends 
to saturate on rainy days. 
64501 - 64503 - 64505 - 64504 : the other path 64501 could pick, but it's not a 
nice one, 64505's reach to 64504 is not good. 

The config trick leads to the following path being established

64501 - 64503 - 64502 - 64504 : Same length as the alternative in AS count, but 
much much better reach. 

Problem: 64502 does not make a single dime on the flows following that path. 

Message of the draft for operators: it's complicated/inefficient/dangerous to 
defend against this actively, so adding some checks in monitoring tools, and 
interaction with customers and peers is probably the way to go…

Let the problem take place and fix it. Some do not like this but well, not many 
like the proposed alternatives.


I agree with the problem statement for sure. That is the risk when doing 
settlement-free interconnects. It is also one of the main reasons some ISPs 
made settlement-free peering requirements so high or did away with it 
altogether and do 'Paid Peering' instead. I am not sure if either of those are 
within the scope for this document but those are alternative actions that can 
be taken as well. In addition to turning down the Peer if they violate their 
agreement. Those are really business decisions though.