[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
- To: Jeffrey Haas <jhaas at pfrc.org>
- Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
- From: "John G. Scudder" <jgs at juniper.net>
- Date: Wed, 7 May 2008 10:38:42 -0400
- Cc: idr at ietf.org, "RAMSAROOP, JEEWAN P, ATTLABS" <jramsaroop at att.com>, "NGUYEN, HAN Q, ATTLABS" <hnguyen at att.com>, "LONGHITANO, ANTHONY C, ATTLABS" <aclonghitano at att.com>
- Delivered-to: ietfarch-idr-web-archive at core3.amsl.com
- Delivered-to: idr at core3.amsl.com
- In-reply-to: <20080507141250.GA17332@scc.mi.org>
- 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: <20080506180029.GA26405@scc.mi.org> <9A3A6AC97A8CF44DACD99DC00BEC235A02F132D4@xmb-rtp-203.amer.cisco.com> <20080506194653.GA8171@scc.mi.org> <42F67934-71FE-4D36-B793-91A9B7122096@juniper.net> <20080506212850.GA21845@scc.mi.org> <F5EFC2D4-6F27-4E32-A462-6706E23B59FC@juniper.net> <20080507141250.GA17332@scc.mi.org>
- Sender: idr-bounces at ietf.org
On May 7, 2008, at 10:12 AM, Jeffrey Haas wrote:
>> That
>> actually would be OK as long as the other rules I've cited above are
>> followed, i.e. the route may only go into a VRF other than the
>> source. In that sense, the ACCEPT_OWN community is belt-and-
>> suspenders rather than being strictly necessary.
>
> Exactly. With such a knob, no additional well known communities are
> really required. However, for your use case, you still require
> information present to help prevent loops.
Actually given the other rules we've discussed I don't see where
there's potential for loops even absent the ACCEPT_OWN community,
which is why I referred to it as "belt-and-suspenders". If you can
think of a specific loop scenario, I'd be interested to hear it.
> This would potentially
> change your draft from "add this well known community" to "routers may
> be configured to accept their own routes under these circumstances".
> This potentially moves ACCEPT_OWN to an advisory community.
Seems like an editorial rather than normative change -- essentially
emphasizing that the behavior is controlled by configuration and
defaults off. As such, I don't think I'd have a problem with it.
--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr