[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt
- To: "UTTARO, JAMES, ATTLABS" <uttaro at att.com>
- Subject: Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt
- From: Danny McPherson <danny at tcb.net>
- Date: Tue, 6 May 2008 08:30:37 -0600
- Cc: idr at ietf.org, "RAMSAROOP, JEEWAN P, ATTLABS" <jramsaroop at att.com>, "LONGHITANO, ANTHONY C, ATTLABS" <aclonghitano at att.com>, "NGUYEN, HAN Q, ATTLABS" <hnguyen at att.com>
- Delivered-to: ietfarch-idr-web-archive at core3.amsl.com
- Delivered-to: idr at core3.amsl.com
- In-reply-to: <A1F50CB516D211409DFD05D6B3CE6D300ED28575@KCCLUST06EVS1.ugd.att.com>
- List-archive: <http://www.ietf.org/pipermail/idr>
- List-help: <mailto:idr-request@ietf.org?subject=help>
- List-id: Inter-Domain Routing <idr.ietf.org>
- List-post: <mailto:idr@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
- References: <A1F50CB516D211409DFD05D6B3CE6D300ED2856E@KCCLUST06EVS1.ugd.att.com> <7000E71D8C525042A815432358B2F1240138D477@paul.adoffice.local.de.easynet.net> <A1F50CB516D211409DFD05D6B3CE6D300ED28575@KCCLUST06EVS1.ugd.att.com>
- Sender: idr-bounces at ietf.org
On May 6, 2008, at 8:02 AM, UTTARO, JAMES, ATTLABS wrote:
>
> 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.
Only as well as BGP scales. If you're making an argument that policy
application won't scale unless it's centralized, I'm not subscribing to
that.
> 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
The same code is going to be modified to accommodate this, that's
the point. The code you use to do this is driving the same mechanics
that everyone else uses for "Internet routing".
> 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.
No more fundamental than disabling loop detection mechanisms
and all the underlying machinery.
> 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.
I'm not sure what triggered this response, but I suspect I could use
that argument to counter your proposal.
-danny
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr