Hello, Thank you for your comments. Thanks to Jinmei's and other messages to the mailing list, I got keenly aware of the fact that what is obvious and what is unobvious depends much on the background of each person. I thought "directly-connected" was an obvious concept, but it was not. I'm sorry for the ambiguity.
> 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. Yes, it can. But it matters and is distinguished. It's hard to tell if it's just a convention or not. However, if there is a gap between the protocol theory and the reality (operational practice and actual implementation), I think it's good to make some concession. It's OK to regard the /127 usage as an instance of "off-link", especially if it's less controversial. Thanks again for the inputs. Miya -----Original Message----- From: JINMEI Tatuya / 神明達哉 [mailto:jin...@isc.org] Sent: Friday, July 30, 2010 8:06 AM To: Miya Kohno Cc: Hemant Singh (shemant); dtha...@wollive.windowsmedia.com.akadns.net; ipv6@ietf.org Subject: Re: 6man discussion on /127 document @ IETF78 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 --------------------------------------------------------------------
