[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: Tue, 6 May 2008 16:08:25 -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: <20080506194653.GA8171@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>
- Sender: idr-bounces at ietf.org
Jeff,
On May 6, 2008, at 3:46 PM, Jeffrey Haas wrote:
> I still recommend to the authors that they don't consider a well-known
> standard community. Please consider either using a new extended
> community
That would be your earlier suggestion:
> 2. A new version of the route-target extended community that has the
> "accept this with your own originator" semantics.
That would work and I don't have a huge problem with it, but I don't
see how it's semantically different from the current proposal. In the
current proposal, we decompose things orthogonally into the routing
table context of the route (the route target) and the handling of the
route (the ACCEPT_OWN community). What you describe above combines
those two semantics into a single new-type route target, but otherwise
would seem to be the same.
> or adding a configuration knob for the existing route-target
> community.
And that would be:
> 1. Add a configuration knob that says "accept this route with
> route-target and ignore originator".
If you mean "add a configuration knob on the PE" then that wouldn't
satisfy the use case requirements, which is exactly to avoid
configuration on PEs. Maybe you could describe in a few more words
exactly what the knob you're imagining would do.
> I think that would serve your requirements without otherwise
> complicating existing non-VPN situations.
I don't think non-VPN situations are complicated at all since you
wouldn't turn the feature on -- modulo the comment others have made
that there would necessarily some code introduced to support this
feature even if it wasn't configured. But some code would be
introduced in either of the approaches you suggest as well, so that
can't be what you mean.
By the way -- you specifically say "don't consider a well-known
standard community". Does that mean you wouldn't have a problem with
a well-known *extended* community (without RT semantics of its own)?
If so, how come?
Thanks,
--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr