Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt

Ilya,

Comment In-Line.

Thanks,
    Jim Uttaro

________________________________

From: Ilya Varlashkin [mailto:Ilya.Varlashkin@de.easynet.net] 
Sent: Tuesday, May 06, 2008 7:05 AM
To: UTTARO, JAMES, ATTLABS; idr@ietf.org
Cc: NGUYEN, HAN Q, ATTLABS; LONGHITANO, ANTHONY C, ATTLABS; RAMSAROOP,
JEEWAN P, ATTLABS
Subject: RE: [Idr] Fwd:
I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt

Jim,

it's well understanable why you'd like to have ACCEPT_OWN capability.
However the problem you're trying to solve is more global than the
solution can  address. ACCEPT_OWN may solve issue for some networks that
follow certain rules, but there will be still those with different
network design but similar problem and ACCEPT_OWN won't address their
needs (e.g. with client-to-client reflection disabled). Such networks
will then go on and design yet another solution for the same problem.  

J.Uttaro>
Not really looking to change the global rules of BGP. I do agree that a
network without a centralised point of dissemination of routing
information would not be able to take advantage of the ACCEPT-OWN
capability. The question that comes to mind  how big could the network
be? If it is not that large then probably not many customers in general
and certainly very few large enterprise customers. I  do agree that to
take advantage a customer would need to deploy some RR functionality.  

I believe it's not optimum to modify core protocol functionality just to
address special case scenarios, in contrary - protocols should be more
generic. Couldn't the problem with building extranets solved in some way
that wouldn't require modification of the fundamental BGP functionality?
One such possibility could be to add a new address family to BGP that
would redistribute import/export policies among all routers within
arbitrary boundaries. This way you don't modify core protocol and people
could take advantage of new functionality without being forced to
redesign their networks.

J.Uttaro>
The notion of "core protocol functionality" is something that came up in
another thread in re Accept-OWN. My thoughts on this is that the idea
that BGP is a "core protocol" is not exactly true any longer. In the
past in a traditional internet network there was a one-to-one
correlation of BGP and IGP domains. It is possible and extraordinarily
probable that today's large networks are constructed with a core running
some form of IGP/Label Protocols and is overlaid with multiple BGP
domains. Each BGP domain co-exists on the same core and is responsible
for dissemination of routing information for the service it is
supporting. This can be VPN, VPNV6, VPLS, Internet etc. In today's large
networks the reality is the it is a many-to-one arrangement. So, I make
a fundamental distinction between a Service BGP Domain as opposed to
Core BGP Domain

I do resonate with your thinking in terms of expanding the scope of BGP
to encompass modification of PE specific resources i.e add/delete/mod
policy. But this is a fundamental change to what BGP was designed to do.
BGP is a protocol built to deliver routing information changing it into
more of a network management type of protocol to get this capability is
probably not going to garner significant support.

Cheers, 

iLya