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

["UTTARO, JAMES, ATTLABS" <uttaro at att.com>]

Ilya,

 

Comment In-Line.

 

Thanks,

    Jim Uttaro

 

 

---

From: Ilya Varlashkin [mailto:Ilya.Varlashkin at de.easynet.net]
Sent: Tuesday, May 06, 2008 7:05 AM
To: UTTARO, JAMES, ATTLABS; idr at 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

 

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr