[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>, <idr at ietf.org>
- Subject: Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt
- From: "Ilya Varlashkin" <Ilya.Varlashkin at de.easynet.net>
- Date: Tue, 6 May 2008 13:05:15 +0200
- Cc: "NGUYEN, HAN Q, ATTLABS" <hnguyen at att.com>, "LONGHITANO, ANTHONY C, ATTLABS" <aclonghitano at att.com>, "RAMSAROOP, JEEWAN P, ATTLABS" <jramsaroop at att.com>
- Delivered-to: ietfarch-idr-web-archive at core3.amsl.com
- Delivered-to: idr at core3.amsl.com
- In-reply-to: <A1F50CB516D211409DFD05D6B3CE6D300ED2856E@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>
- Sender: idr-bounces at ietf.org
- Thread-index: Aciuy4OvU2oYSkWGS6Gg6XwRJbtl7QAm6cPg
- Thread-topic: [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.
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.
Cheers,
iLya
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr