[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: "John G. Scudder" <jgs at juniper.net>
- Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
- From: Jeffrey Haas <jhaas at pfrc.org>
- Date: Wed, 7 May 2008 11:27:11 -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: <B1A246D0-56A0-481F-984E-353BB0975C18@juniper.net>
- 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> <B1A246D0-56A0-481F-984E-353BB0975C18@juniper.net>
- Sender: idr-bounces at ietf.org
- User-agent: Mutt/1.5.9i
On Wed, May 07, 2008 at 10:38:42AM -0400, John G. Scudder wrote:
> 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.
My concern has always been if this mechanism is inadvertantly applied to
a box that doesn't have "multiple contexts". While I think we can both
agree that if people follow the spec (presuming a good spec) that this
shouldn't be an issue I think we've both seen poor implementations and
the hazards surrounding such. This seems more likely in the case where
someone tries to apply this outside of a VPN context.
> 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.
Then I suspect we've converged. I'm looking forward to the next
revision.
-- Jeff
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr