Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Mon, 5 May 2008 11:17:29 -0500

I wanted to take an opportunity to discuss the rationale for this draft.
 
We have seen an explosion in the growth of our VPN services both
domestically and globally. Many customers span multiple IGP and BGP
domains with sites in both the AP, EMEA, etc... There are multiple BGP
domains with the number of edge devices supporting RFC 2547 numbered in
the thousands. 
 
As a SP we have seen these customers demanding more and more
sophisticated routing services/solutions. These range from providing
routing granularity at a regional/global/PE level, providing SP value
added content and VPN Stitching.
 
As we have thousands of customers and millions of routes there is a
tremendous opportunity to stitch VPNs. These opportunities services
include stitching SP value added services into customer VPNs, providing
middleman services to stitch routing between multiple VPNs ( GM , Ford,
etc... ) and TOD services within the context of a single VPN or between
VPNs. The biggest challenge is how to operationalize these services in a
way that is simple, efficient and easily modified. 
 
The current state of the art is to either modify import/export lists on
each VRF A and VRF B on each PE to leak routes. Of course on a PE with
VRF A and VRF B we need to apply different configuration to leak routes
locally. The major disadvantages to this approach are:
 
a) Operational Complexity
 
For a simple gross extranet multiple PEs need to be touched with
configuration applied to each VPNs routing context to create a complete
stitch. Assume two multi-national multi-national corporations that span
US, EMEA and AP with VPN instantiated on 300-400 PEs that want to share
routing state. Our systems need to re-configure all of these PEs to
modify the import/export lists. Of course we have a multiple vendors
where each vendor has different platforms with different code bases.
This makes for a laborious set of requirements on our software
development staff. 
 
If we want to create a more complex extranet these same issues are
magnified. Each additional VPN stitched requires additional
configuration on the n-1 VPNs currently participating in the extranet as
each VPNs routing context now needs to import the additional RT
representing the newly stitched VPN. 
b) Dynamic/Temporal Stitching
 
One variation of VPN stitching is where customers want to stitch for
some period of time. The example that immediately comes to mind is
"Follow the SUN" although this is by no means the only one. In this case
customers may want to stitch VPNs together for some period of time that
is configurable and agreed to by all parties. This would require that a
SP would need to reconfigure PEs quite often assuming the current state
of the art. This creates a lot of configuration churn that can lead to
customer routing instability as VRF are re-built with the new RTs.
 
c) Route Granularity
 
In the above two examples the simple modification of the import/export
list would create a situation where all of the routes within in each VPN
would be leaked to the other. This is not only undesirable but
unacceptable. Customers do not want to simply create a merged VPN where
all of the routing information is made available to the other VPN. They
want to selectively leak a set of prefixes between them. This is the
same for two or more customer VPNs as well as SP value added stitching.
This level of granularity would require an entirely different set of
software tools which identify prefixes on a per VPN/PE level and then
apply the appropriate RT information. 
 
Why is this draft so powerful? With this draft the SP can simply manage
routing information from  central location. In order to create a VPN
stitch, the SP simply applies RTs to facilitate the stitch and reflects
to all PEs. In order to deliver these services from a central location (
RR, etc... ) we need to be able to reflect a route back to the PE that
originated it. This is due to the fact the the two VPNs being stitched
may reside on the same PE. Assuming a central distribution paradigm we
need to have this Accept-Own capability. Without it we will need to
either capacity manage the PEs so that two VPNs that will be stitched
now or in the future are not on the same PE. We can never now apriori so
that means we would need to migrate entire VPN routing contexts with
associated multiple interfaces from one PE to another which would create
customer outages. This is simply not acceptable.
 
Thanks,
    Jim Uttaro

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 6 May 2008 13:05:15 +0200

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 May 2008 07:15:23 -0400

Jim,

> I wanted to take an opportunity to discuss the rationale for this draft.

Thanks for taking the time to go over this.

> routing information from  central location.

That may be an admirable goal but it has a bit more scope than may make
many people comfortable, including me.  In your offered example of
managing VPNs this is reasonable, although IMO only weakly so.  However,
since this is a general community rather than a different form of an
extended community, this has semantics that might be hazardous under
misconfiguration to non-VPN infrastructure.

The argument has been made that under proper implementation that it
wouldn't be dangerous.  I'll just leave it that I'm skeptical.

At least two modifications to the protocol mechanism suggest themselves
to me:

1. Add a configuration knob that says "accept this route with
route-target and ignore originator".  
2. A new version of the route-target extended community that has the
"accept this with your own originator" semantics.

Both of these options limit the scope of this feature to the VPN case.

> In order to create a VPN
> may reside on the same PE.

I think one of the things I find unfortunate here is that this feature
shouldn't be necessary.   The code path for sending your BGP
routes could simply reflect them internally back to your router as an
"incoming route" when a route-target of interest is being appended on an
outbound basis.  

Having been involved in an implementation that did this, it's certainly
possible even if the code path is awkward.

-- Jeff

---

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Tue, 6 May 2008 09:02:26 -0500

Ilya,
 
Comment In-Line.
 
Thanks,
    Jim Uttaro

________________________________

From: Ilya Varlashkin [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 7:05 AM
To: UTTARO, JAMES, ATTLABS; [email-masked]
Cc: NGUYEN, HAN Q, ATTLABS; LONGHITANO, ANTHONY C, ATTLABS; RAMSAROOP,
JEEWAN P, ATTLABS
Subject: RE: [Idr] Fwd:
I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt

Jim,

J.Uttaro>
Not really looking to change the global rules of BGP. I do agree that a
network without a centralised point of dissemination of routing
information would not be able to take advantage of the ACCEPT-OWN
capability. The question that comes to mind  how big could the network
be? If it is not that large then probably not many customers in general
and certainly very few large enterprise customers. I  do agree that to
take advantage a customer would need to deploy some RR functionality.  

J.Uttaro>
The notion of "core protocol functionality" is something that came up in
another thread in re Accept-OWN. My thoughts on this is that the idea
that BGP is a "core protocol" is not exactly true any longer. In the
past in a traditional internet network there was a one-to-one
correlation of BGP and IGP domains. It is possible and extraordinarily
probable that today's large networks are constructed with a core running
some form of IGP/Label Protocols and is overlaid with multiple BGP
domains. Each BGP domain co-exists on the same core and is responsible
for dissemination of routing information for the service it is
supporting. This can be VPN, VPNV6, VPLS, Internet etc. In today's large
networks the reality is the it is a many-to-one arrangement. So, I make
a fundamental distinction between a Service BGP Domain as opposed to
Core BGP Domain
 
I do resonate with your thinking in terms of expanding the scope of BGP
to encompass modification of PE specific resources i.e add/delete/mod
policy. But this is a fundamental change to what BGP was designed to do.
BGP is a protocol built to deliver routing information changing it into
more of a network management type of protocol to get this capability is
probably not going to garner significant support.

Cheers, 
 
iLya

---

From: Danny McPherson <[email-masked]>
Date: Tue, 6 May 2008 08:30:37 -0600

On May 6, 2008, at 8:02 AM, UTTARO, JAMES, ATTLABS wrote:
>
> J.Uttaro>
> Not really looking to change the global rules of BGP. I do agree  
> that a network without a centralised point of dissemination of  
> routing information would not be able to take advantage of the  
> ACCEPT-OWN capability. The question that comes to mind  how big  
> could the network be? If it is not that large then probably not many  
> customers in general and certainly very few large enterprise  
> customers. I  do agree that to take advantage a customer would need  
> to deploy some RR functionality.

Only as well as BGP scales.  If you're making an argument that policy
application won't scale unless it's centralized, I'm not subscribing to
that.

> J.Uttaro>
> The notion of "core protocol functionality" is something that came  
> up in another thread in re Accept-OWN. My thoughts on this is that  
> the idea that BGP is a "core protocol" is not exactly true any  
> longer. In the past in a traditional internet network there was a  
> one-to-one correlation of BGP and IGP domains. It is possible and  
> extraordinarily probable that today's large networks are constructed  
> with a core running some form of IGP/Label Protocols and is overlaid  
> with multiple BGP domains. Each BGP domain co-exists on the same  
> core and is responsible for dissemination of routing information for  
> the service it is supporting. This can be VPN, VPNV6, VPLS, Internet  
> etc. In today's large networks the reality is the it is a many-to- 
> one arrangement. So, I make a fundamental distinction between a  
> Service BGP Domain as opposed to Core BGP Domain

The same code is going to be modified to accommodate this, that's
the point.  The code you use to do this is driving the same mechanics
that everyone else uses for "Internet routing".

>  I do resonate with your thinking in terms of expanding the scope of  
> BGP to encompass modification of PE specific resources i.e add/ 
> delete/mod policy. But this is a fundamental change to what BGP was  
> designed to do.

No more fundamental than disabling loop detection mechanisms
and all the underlying machinery.

> BGP is a protocol built to deliver routing information changing it  
> into more of a network management type of protocol to get this  
> capability is probably not going to garner significant support.

I'm not sure what triggered this response, but I suspect I could use
that argument to counter your proposal.

-danny

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 6 May 2008 10:40:25 -0400

Jeff,

> possible even if the code path is awkward.

Can you elaborate on this point?  One of us is missing something and  
Murphy's Law says that quite possibly it's me.  Jim's point, which  
you've quoted above, is that he desires for the RR to be the only  
control plane entity in the network which knows by configuration what  
the "route-target of interest" is.  As such, the control plane path  
from the PE to itself, as it were, is necessarily PE->RR->PE, since  
the PE doesn't know that it's interested in its own routes.  To make  
the terminology slightly less tormented, the desired control path is  
VRF1_on_PE->RR->VRF2_on_PE.  The VRF1->VRF2 on PE path isn't feasible  
in this use case because PE doesn't know that this relationship exists  
between the two VRFs, only the RR knows that.  (Of course that path is  
feasible if the use case admits of configuration on the PE.)

Thanks,

--John

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 6 May 2008 10:47:46 -0400

I think the key point to grasp is this; using existing technology if you
want to create an extranet then you have to manipulate the import/export
maps at the PE so as to import/export the locally assigned RTs for each
given VRF. It is also important to understand that this is on a
*per-VRF* basis e.g. there is no prefix-specific granularity (unless you
resort to import filters which is even worse). This is a *pain* with a
large number of PEs/VPNs, and is also not very flexible in a real
deployment. I believe what is being proposed is to add the ability to
change the RT value of an exported route at the RR so as it becomes the
RT value of an importing VRF at the originating PE (the accept-own is a
by-product of the fact that the extranet happens to be on the same PE).
In this case the import/export configuration at the PEs remains
*unchanged*.

Jim Guichard 
Principal Engineer - MPLS Technologies
CCIE # 2069

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
John
> G. Scudder
> Sent: Tuesday, May 06, 2008 10:40 AM
> To: Jeffrey Haas
> Cc: [email-masked]; LONGHITANO, ANTHONY C, ATTLABS; RAMSAROOP, JEEWAN P,
> ATTLABS; NGUYEN,HAN Q, ATTLABS
> Subject: Re: [Idr] Fwd:
I-DACTION:draft-pmohapat-idr-acceptown-community-
> 01.txt

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Tue, 6 May 2008 16:50:20 +0200

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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 6 May 2008 12:03:07 -0400

On May 6, 2008, at 10:50 AM, Ilya Varlashkin wrote:
> Also, I didn't dig deeply into details but there might (or might

For router architectures with which I'm familiar, there would be no  
problem related to label allocation.  If someone is aware of a  
specific case where there would be a problem, I'm sure they'll speak up.

Regards,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 May 2008 14:00:29 -0400

John,

On Tue, May 06, 2008 at 10:40:25AM -0400, John G. Scudder wrote:
> Murphy's Law says that quite possibly it's me.

It's probably not you.  I'll respond to your points in Jim's reply.

On Tue, May 06, 2008 at 10:47:46AM -0400, Jim Guichard (jguichar) wrote:
> I believe what is being proposed is to add the ability to

Typical VRF configuration is import-route-target A and
export-route-target B.  If A == B for some A and B in the extended
community set they're in the same VPN.

I'm curious as to the configuration of the route targets that would
require this to be done.  I hadn't thought about the case where the RR
is actively manipulating the route-targets.  If the goal is to stitch
together a single set of VRFs, you have the additional problem of
needing to constrain where the route is reflected.  

If it's across multiple PEs, this implies something along the lines of
RT A and RT B are distinct on a per VRF basis.  This seems somewhat
unlikely (at least on the completely distinct basis) since it wouldn't
scale well for many VRFs being in the same VPN.

Could you clarify on the likely setup for this feature?

-- Jeff

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 6 May 2008 14:07:09 -0400

> community set they're in the same VPN.

I would say that the typical VRF configuration is
import-route-target/export-route-target are the same value.

> needing to constrain where the route is reflected.

Lets say VPN-a uses RT 100:1 and VPN-b uses RT 100:2. In order to create
an extranet you need to import RT 100:2 into VPN-a and RT 100:1 into
VPN-b. This is an additional import statement. However, if you change
the VPN-b route RT values at the RR then VPN-a can import based on RT
100:1.

> scale well for many VRFs being in the same VPN.

It is 100% likely and indeed necessary should you want different VPNs.

---

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Tue, 6 May 2008 13:31:06 -0500

Comments In-Line.. 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 2:00 PM
To: John G. Scudder; Jim Guichard (jguichar)
Cc: Jeffrey Haas; UTTARO, JAMES, ATTLABS; [email-masked]; LONGHITANO,
ANTHONY C, ATTLABS; RAMSAROOP, JEEWAN P, ATTLABS; NGUYEN, HAN Q, ATTLABS
Subject: Re: [Idr] Fwd: I-D
ACTION:draft-pmohapat-idr-acceptown-community-01.txt

John,

J.Uttaro> In most cases VRFs have the same Import/Export RT value. Hub
and Spoke and Arbitrary topologies would not.

J.Uttaro>
Yes.. The centralized point could decide to reflect to only a sub-set of
PEs that a VPN participates in. A more intelligent RR could be made to
have this capability. But IMO I believe that the stitch would be on a
per prefix basis from VPN A -> VPN B and vice versa across the entire
set of PEs that these VPNs participate in.

J.Uttaro> 
I don't know if I fully understand your question here. The setup would
be VPN A and VPN B would be instantiated on a set of PEs. All VRFs
associated with VPN A use RT1, All VRF associated with VPN B use RT2. We
want to stitch some X/24 from VPN A into VPN B and Y/24 from VPN B to
VPN A. X/24 is advertised from PE to RR, X/24 has RT1, RR attaches RT2
to X/24 and reflects to all speakers. The ACCEPT-OWN takes care of the
case where X/24 is advertised from a PE that also instantiates VPN B.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 May 2008 15:46:53 -0400

[Note to John S. - I was definitely the confused one here.  The issue is
not that the routers in question can't be configured to handle the
leaking from one VRF to another internally without a BGP announcement.
The issue is that the users don't want the administrative overhead of
doing that at the configuration level for each VRF on each router.]

> the VPN-b route RT values at the RR then VPN-a can import based on RT

Ok, the typical configuration on the router is what I expected it to be.
The piece I didn't understand was the alteration of the RT via "BGP VPN
route server".

> It is 100% likely and indeed necessary should you want different VPNs.

To clarify: This wasn't per-VPN.  My comment was effectively each box
was it's own VPN.  That's not what you had meant.

My apologies for the long message train to reach this conclusion.

I still recommend to the authors that they don't consider a well-known
standard community.  Please consider either using a new extended
community or adding a configuration knob for the existing route-target
community.  I think that would serve your requirements without otherwise
complicating existing non-VPN situations.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 6 May 2008 16:08:25 -0400

Jeff,

On May 6, 2008, at 3:46 PM, Jeffrey Haas wrote:

> community

> "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.

> 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

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 May 2008 17:28:50 -0400

On Tue, May 06, 2008 at 04:08:25PM -0400, John G. Scudder wrote:
> see how it's semantically different from the current proposal.

Mostly in the sense that it's far less likely to be attached to
something other than VPN traffic.

> In the  
> route (the ACCEPT_OWN community).

If the semantics of the draft was intended to be "accept own, but only
if a route target is attached as well", that's not how I thought I read
it.  If that was the case, I'd have less of a problem with it but would
probably still prefer more unified semantics.

> exactly what the knob you're imagining would do.

vrf foo
accept-bgp-vpn-originator-self

This marks a vrf as willing to accept routes with itself as the
originator.  

> introduced in either of the approaches you suggest as well, so that  

My primary concern is the "accept your own originator" feature in the
cases where there aren't vrfs involved - or even when pulling into the
originating vrf.  At minimum this would seem to lead to a cycle of
withdrawing the route which causes the reflected route to be withdrawn
which causes it to be re-advertised...

> a well-known *extended* community (without RT semantics of its own)?   

I'd prefer this feature, if deployed, to have VRF-related semantics.
Tying it to a route target would seem to address those concerns.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 6 May 2008 19:15:56 -0400

On May 6, 2008, at 5:28 PM, Jeffrey Haas wrote:
...
> probably still prefer more unified semantics.
...
> which causes it to be re-advertised...

In fact, this is exactly what the draft intends:

2. Introduction

    In certain scenarios, a BGP speaker may maintain multiple contexts,
    in which case the speaker originates and receives routes within a
    particular context (an example of such a context could be a VRF used
    by BGP/MPLS VPNs [RFC4364]).
...
    To prevent routing information loops, a BGP speaker SHOULD accept a
    route with its own ORIGINATOR_ID or NEXT_HOP value only if the
    ACCEPT_OWN community value is present and the context in which the
    speaker originated the route is different than the context in which
    the speaker accepts the route.

To me this spells out exactly what you're asking for, the only  
difference being that it allows for the possibility of applying to  
"contexts" defined by something other than route targets if such  
should be standardized in the future.

I for one would be fine with clarifying the text to make it clear that  
the latter paragraph cited above means that you should accept your own  
route only if the ACCEPT_OWN community is present, AND there is an RT  
attached, AND that RT specifies a VRF other than the source VRF.  Some  
further words would be called for to indicate that this is meant to  
clarify operation with route targets, but not limit other applications  
that might be dreamed up in the future which allow a route to be  
targeted to a different destination routing table.  In any case, the  
concerns you cite (no VRFs involved, pulling into the originating VRF)  
are precluded.

> This marks a vrf as willing to accept routes with itself as the

In order to satisfy the use case as I understand it, all PEs would  
have to have this knob set for all VRFs, since any VRF might at some  
point need this functionality and the desire is to avoid PE config  
touches when possible.  So the knob would *in effect* be no different  
from a global knob to accept routes with self as the originator.  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.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 May 2008 10:12:50 -0400

On Tue, May 06, 2008 at 07:15:56PM -0400, John G. Scudder wrote:
> attached, AND that RT specifies a VRF other than the source VRF.

Adding the above text would help address my concerns significantly.
This would more strongly tie the feature to BGP MPLS VPNs than the
previous text. 

> Some  

I would further suggest that you discuss the necessity of routers
originating reachability that may be reflected back with this community
need to include sufficient information to prevent such loops.  As a
specific example, the site of origin extended community.

> from a global knob to accept routes with self as the originator.

That would be fine.  The per-vrf example was meant to illustrate the
case where a given VRF may not be willing to accept such reflected
routes.

> That  

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.  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.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 7 May 2008 10:38:42 -0400

On May 7, 2008, at 10:12 AM, Jeffrey Haas wrote:
> 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

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 May 2008 11:27:11 -0400

> 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.

> 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