Margaret Wasserman writes: > >Point taken. How about: > >A proxy MUST ensure that loops are prevented, either by running > >the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all > >proxy interfaces as described below, or by being deployable only in > >an environment where physical loops cannot occur. For example, in a > >cell phone which proxies between a PPP dialup link and a local Ethernet > >interface, it is typically safe to assume that physical loops are not > >possible and hence there is no need to support the Spanning Tree > >Protocol (STP). > > This suggestion appears to be operational advice (about what features > be enabled in given situations, not what should be supported by > implementations),
Find, will change "A proxy MUST" to "An implementation MUST" if that would be clearer that this is indeed an implementor's decision. > and implementations can't really know that that > they will always be deployed in situations where loops are > impossible... Several folks have argued that this is not true, which is why it's worded the way it is. > So, you would do better to say something like "all > implementations MUST support loop prevention. A configuration option > to disable loop prevention MAY be supported, but all implementations > MUST have loop prevention enabled by default". That is what the draft used to say prior to the Vienna IETF, but was changed due to feedback from the WG. This was Issue #2 http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%202 (which is what we're revisiting now in #16). > You could certainly avoid loops in ND Proxy by using STP, although I > think you would have to say a lot more about how it would be > applied... I don't understand your point. It's applied just like in a layer 2 bridge. The behavior is fully specified in the reference, and the application is exactly the same as on a layer 2.5 (arp/nd proxy) bridge, since the forwarding part is orthogonal. > A reference to the rbridges work might be premature. > > Ultimately, though, I am not sure why we would want to add this > complexity to ND Proxy as I don't view it as a sound, scalable > mechanism for link aggregation. It is quite similar to the Proxy ARP > mechanisms supported in some IPv4 implementations, and it seems > likely to have the same problems. > > My understanding of the current ND Proxy work (and why I grudgingly > agreed to leave it on the most recent IPv6 charter despite the fact > that we had not managed to reach consensus on this proposal for > several years) was that we were planning to trim down the original ND > Proxy proposal to a one-hop prefix delegation mechanism (perhaps with > a flag to indicate whether the prefix has already been delegated, in > which case it mustn't be delegated again) to provide a non-DHCP > alternative for one-hop prefix delegation. I've never been quite > sure why a non-DHCP mechanism is needed, but I'm also not religiously > against the idea of standardizing an alternative. For prefix delegation I agree the DHCP mechanism is sufficient, and it was never my understanding that the ND Proxy draft would ever try to become prefix delegation (see Appendix A for some discussion on a related point which WAS suggested by a number of folks at one point). > From my perspective, though, the ND Proxy spec doesn't seem to have > been trimmed down into a simple prefix delegation mechanism at all. > And, now we are talking about complicating it even further with a > complex loop prevention scheme (or two). Again, this draft is not complicating prefix delegation. This is about scenarios were people use IPv4 ARP Proxies today, and prefix delegation is inappropriate in some of these scenarios, as discussed in the doc right above the Scenario 2 picture. > Is there any reason to believe that we can reach consensus on this > more complex version of ND Proxy given that we haven't managed to > achieve consensus on the basic concept in the past ~5 years? It is my understanding that the WG has reached (rough) consensus on it. -Dave > Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
