Re: [Idr] draft-uttaro-idr-bgp-persistence-00

[Robert Raszuk <[e-mail]>]

Jim,

[Jim U>] So
> two distinct items here.. 1) GR cannot propagate information in re
> paths. From the draft there seems to be no way to do this for all
> paths or some subset of paths without major surgery. So, do you agree
> with this statement?

Yes I do. First we need to agree if such introduction of propagation of 
information is a feature or a bug.

I am personally completely not convinced that there is any value in 
informing my peers that one of my BGP sessions went down. You either 
have reachability to next hop and can attract traffic or you do not and 
if so you withdraw.

Telling peers that "I may be perhaps used to reach prefix X as last 
resort" is of highly questionable value.

Then as it has been said GR could be instrumented to upon session down 
event in case some/all best paths were on this session they could be re 
advertised with low local pref or with cost community. This is your own 
personal decision and I do not have anything against you configuring 
your network this way - if anything blackholed customers will seek new 
SP - so I am supportive my competitors to enable such knob.


2) Punching holes?? So here are a few examples
> where holes have been punched RT-Constrain, AIGP, L2VPN, etc...

I think you are mixing things ... RT-Constrain is a new SAFI and you can 
define for each new SAFI rules how best path is computed. Same for 
L2VPNs - the key is that you define it along the new SAFI definition.

AIGP as far as I know is in the IDR holding pattern till we figure out 
how to consistently modify best path selection with external influences.

If it comes after you are much better to use standard best path 
modification which guarantees best path correctness across your network.

> Back to the persistence draft ... GR can address 90% of the
> persistence draft requirements. [Jim U>] Disagree.. See my prior
> note..

So what else is missing ? Propagation part that path is "suspicious" and 
all routers in the given AFI/SAFI reachability in the Internet should 
sort of dislike it ? Is that it ?

I think it would be great for all to understand the delta. So if this is 
the delta I think in fact that Bruno who presented the draft is very 
flexible in this space.

Other co-authors I spoke with were not even aware some communities were 
added to the draft like STALE .....

  [Jim U>]
> Need to be careful when we use customer tools i.e LP to accomplish
> provider goals. This type of approach may conflict with RFC1998..

Local pref is AS tool - not customer tool. It is not propagated across 
AS boundaries.

Besides your STALE community already is said to overwrite any other 
preference so I see completely no substantial point of your above comment.

> Marking paths with CVs does not influence best path decision unless
> policy is applied at every point. This is not a workable solution in
> a large network

Local pref is applied at every router as far as I know. STALE will also 
not be magically enabled everywhere in the network till the network is 
upgraded and knob is configured. Is this workable in large network ???

> Also I think current -00 version has serious issues as already
> pointed on the list. We need to wait till -01 is published in order
> to see if those issues have been fixed. [Jim U>] Disagree.. I do
> believe that the draft needs to evolve in how it deals with different
> use cases and the peculiarities of each.. IMO the purpose of IETF
> specifications is to provide tools for designers. We cannot take an
> approach that we will not develop tools as designers may not
> understand how to use them and could screw up their networks.. if
> this is the approach then we probably need to retire lots of
> technology that can be used incorrectly.. The argument that designers
> can screw up their network is specious at best..

I think this proves you are missing the loop case I described in the 
other email. It is fine to provide rope and count that you use it wisely 
for climbing the cliff.

However it is IMHO wrong thing to provide a tool which has no way of 
working correctly ... in this particular case STALE CV across EBGP 
session - simply as you as operator are not aware about your peers 
topology and support of routing platform in their ASes.

Bruno offered to change this to G-SHUT which in turn is designed to be 
mapped to local-pref. I have no problem with this approach. So you can 
achieve exactly what you need safely.

To summarize .. I do recommend the same as Enke said at the mic .. It 
would be much better to turn this current document into requirements 
document so WG could provide opinions and proposals on how to solve them 
(provided they are valid) rather then propose a solution and keep 
arguing that this is the best one to solve your yet to be well defined 
problem.

Best,
R.