At Wed, 28 Jul 2010 19:14:58 +0900, Miya Kohno <mko...@juniper.net> wrote:
> The draft is discussing about inter-router backbone link, where > "directly-connected neighbor" has a significant meanings from > routing protocol point of view. So it needs to be assumed > "on-link". I think we should specifically clarify what are "significant meanings", and their implication with "on-link". In particular, it would be helpful to clarify if a common subnet prefix (regardless of how long it is) has to be shared between the two routers. If a "significant meaning" is about the TTL/hop limit check of eBGP to confirm the peer is attached to a directly connected link, the peer address doesn't necessarily have to share the same prefix with the local address of the p2p link. The router only has to know the peer address is reachable via the p2p link, which could be e.g. configured by a manually installed host route. It might even be automatically advertised/learned via an RA with a prefix information option with the L bit on for the "/128" prefix, although I don't know if the original intent of RFC4861 specification allows such an automatic prefix configuration between routers or if an existing router implementations support that. If another "significant meaning" is the check "if an eBGP peer is directly connected by comparing the peer address against directly connected interface addresses" (quoted from another message of this thread), I'm not sure if this is a requirement of the protocol or a requirement/convention of particular implementations. Regarding the protocol specification, RFC4271 doesn't seem to require it: for example, section 5.1.3. 2) states that the source address of the peering connection can be used for NEXT_HOP, whether or not that address shares the same prefix with the peer. If "sharing the same prefix" is not a hard requirement, it would be less controversial to use the so called "off-link" model, that is, the two routers assign two independent addresses to each end of the p2p link, e.g. 2001:db8:1111:2222::0/128 and 2001:db8:1111:2222::1/128, and ensure these addresses are reachable via the p2p link by some other method as mentioned above. It might be even acceptable (for the "address architecture police") to actually configure them as belonging to a "/127" prefix 2001:db8:1111:2222::0/127, as an internal implementation/operational practice, as long as the externally observable behavior is the same as the "off-link" model. btw, not being a router operator (or implementor), I personally don't have a strong opinion on this issue, but I see the need for clarification. Even if the point is so obvious to some wg members (of which I'm not included), if it's not clear for a sufficiently large group of people, it should be worth clarifying. So I basically support (eventually) adopting this draft as a wg document. But it may be better to begin with a clear problem statement without including any specific solution. And, as a result of that, the appropriate wg may be an O&M one (most likely v6ops in that case) rather than this wg. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------