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

["UTTARO, JAMES" <[e-mail]>]

Robert 

Comments In-line..

Jim Uttaro

-----Original Message-----
From: Robert Raszuk [mailto:[e-mail]] 
Sent: Tuesday, November 15, 2011 10:55 AM
To: UTTARO, JAMES
Cc: 'Enke Chen'; '[e-mail] List'
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

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.
[Jim U>] Ok.. Then you should revisit GR not propagating the failure and determine if it is a bug or a feature..

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.
[Jim U>] Ok so GR is still propagating some path from a BGP session that went down or is compromised.. So what is the point here? Ok for GR but not ok for Persistence??

Telling peers that "I may be perhaps used to reach prefix X as last 
resort" is of highly questionable value.
[Jim U>] As opposed to not telling peers that X, that may be of questionable value is still the best path? Just because you are not literally informing your peers does not mean that you are still essentially maintaining an X of questionable value throughout the routing context. The difference between the two is GR hides this information Persistence does not. GR is opaque, Persistence is transparent.. It seems arrogant to hide the information from your customers especially when it is their VPN routing context..

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.
[Jim U>] The point is that RT-Constrain modifies the best path selection by essentially punching holes.. So I guess your point is it is ok for this AFI/SAFI but not other.. From the RT-Constrain draft:

     " ii.  When advertising a RT membership NLRI to a non client peer,
      if the best path as selected by path selection procedure described
      in section 9.1 of the base BGP specification [5] is a route
      received from a non-client peer, and there is an alternative path
      to the same destination from a client, the attributes of the
      client path are advertised to the peer. "

This seems like a punched hole.. NO? 

 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.
[Jim U>] Really..

If it comes after you are much better to use standard best path 
modification which guarantees best path correctness across your network.
[Jim U>] so, I guess your point is if Best Path changes are required by some drafts deemed by folks in the know then they are warranted. I think a consistent message is needed if you want to use Best path "Hole Punching" as a rationale..

> 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 ?
[Jim U>] Internet?? I think that you need to realize that BGP is being used for many different applications.. So, GR makes a decision in the internet that a path is still valid even though a session went down. This is deterministic in that a decision has been made to not inform, Persistence allows a customer to choose. There is a lot of value in this from a customer point of view..

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 .....

> 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.
[Jim U>] Do not agree.. It has nothing to do with propagation across AS Boundaries.. VPNV4 routing context belongs to the customer.. They use LP to accomplish their routing designs in our network. RFC1998 is the agreed upon method. 

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 ???
[Jim U>] Knob?? STALE is appended to a path when the session is was learned over has been compromised, that path is then advertised.. Part of the implementation..

> 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.
[Jim U>] Your example although contrived does illustrate a case where a customer who does not understand the technology implements incorrectly.. Again this can happen with many of the technologies as I mentioned before.. i.e RT-Constrain, Addpath, etc.. So let's either be consistent in how much rope is allotted for different technical enhancements or do away with it completely.. We cannot have some drafts get lots of rope and other get some twine..

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.
[Jim U>] I do not understand.. Why does it have no way of working correctly? Because someone implemented it incorrectly.. More importantly I want the customers to know about the state of their VPN when it transits the routing context they have purchased in our network..

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.
[Jim U>] We will consider all approaches..

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.
[Jim U>] Do not agree.. The assumption that GR can be manipulated to accomplish the requirements is incorrect.. It is not right to select a solution that has not before considered the requirements and then reverse engineer a bottom up solution in attempt to patch it.. 

Best,
R.