Hi Noel,

> In prior conversations with you, you have suggested that the broad
> architectural approach I prefer for path selection - i.e. topology
> distribution, with unified path computation (although perhaps 'monolithic'
> is a better term than 'unified', since the latter term was used elsewhere
> in routing) - is problematic. I don't recall your reasoning exactly (not
> that I ever got it in detail, I don't think), IIRC it was something to do
> with a combination of:
> 
> i) ISPs didn't want to hand out topology information


And perhaps more importantly, they are unwilling to disclose their policy 
information.  Peering policies are a very touchy subject.  Being nice to 
competitor A and not nice to competitor B is the type of diplomatic fodder that 
starts corporate battles.


> ii) ISPs like the kind of policies about traffic flow they can impose
>       with destination vector architectures


Specifically, the ability to do hot-potato and cold-potato routing, as well as 
destination originated traffic engineering.


> iii) the overhead of path computation needs to be distributed


This is the least of the issues.  Yes, this needs to be distributed for 
scalability.  But then I come from a church where _everything_ needs to be 
distributed for scalability.


> So perhaps a discussion about what you see as the shortcomings of that
> approach, and discussion about whether those issues are or are not
> handlable, would be a good thing to do here?


So I'm more than happy to have that conversation, but I would very much like it 
to proceed into a concrete topic proposal if we're doing it on RRG.  If we're 
having just a fun architectural discussion, then routing-discussion might be 
more appropriate, so that this list could be reserved for those developing 
topics.

Warmest regards,
Tony

_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to