[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 16:50:20 +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-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
- Thread-index: Aciuy4OvU2oYSkWGS6Gg6XwRJbtl7QAm6cPgAAWRgtAAAhV9oA==
- Thread-topic: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt
Jim,
I didn't mean networks without RR, but rather networks where
'client-to-client reflection' is disabled because clients are fully
meshed. Also, I didn't dig deeply into details but there might (or might
not) be pitfals with label allocation for routes injected with
ACCEPT_OWN.
By core functionality I refered to part of BGP that is responsible for
route announcement, validation and selection as opposed to dealing with
different address families, labels and so on.
And as regards to whether or not policy is routing information or not -
if you leave only abstraction, then nearly anything could be considered
as routing information. With policy - the client process of respective
address family (say AF_POLICY) will know what to do with that
information, just like advertising labels in BGP - respective code knows
what to do with those labels.
P.S.: removed original message since I have difficulties commenting on
HTML-formatted mails.
Cheers,
iLya
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr