dear Remi, i think you won't be against if i change the subject of this specific discussion, focusing on the routing issues regarding virtual link. 2012/3/26 Rémi Després <despres.r...@laposte.net>
> Different understanding. >> An detailed E use case that cannot be supported by U (if it exists) would >> give substance to this claim. >> Open to look at it. >> > > in my personal experience i could give you at least three quick examples > of the use case for the building block of "virtual link": > > first example, if the IPv4 customer network plays BGP over IPv4 with the > provider, through the BGP session between CE and BR, a virtual link is > desired. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 > world) > > > I don't see in this scenario why anything that works with E (i.e. between > CEs and BRs) wouldn't also work with U. > > by default, ebgp requires direct link (some implementations specify TTL = 1 to achieve this). U decreases TTL when packet goes through IPv6 cloud, and therefore CE---BR ebgp session cannot be established with regular BGP configurations. > second example, there are dynamic routing protocols like RIP running in > the following (multihoming) topology for IPv4 routing. the operator may > want to treat the CE-BR as a single hop in order the virtual link is > considered the distance vector calculation. > > (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 > world) > \ / > \ / > +------------ CE ----(Another, IPv4 domain)----------+ > > > Same comment. > > similar misunderstanding. RIP distance vectors are delivered to neighbors but the operators are easy to be confused by the fact that CE---BR are shown as multihop with tools like traceroute. > > > third example, same topology as above but OSPF are applied, and OSPF > TTL-security check are enabled to ensure hop-passings less than a specified > threshold. if the operator would like to treat CE---(IPv6-only domain)---BR > as one hop because it is considered as virtual link, 4rd-u's rudiness in > decreasing TTL will hurt. > > > Same comment. > > same misunderstanding. without knowing the details of the IPv6 domain backbone, it is difficult for the operator to set up a proper value of the TTL-security parameter for the OSPF regarding the CE---BR section. virtual link (full encapsulation) eliminates this trouble. > > > MAP-E (and other E) surely has no limitation in supporting any features of > existing routing protocols. > > > Why U would be less transparent between CEs and BRs than E for any L4 > protocol remains unexplained. > > hope the above helps. it is not about the transparency but about the behavior of virtual link. it is not about any L4 protocol but about routing protocols. > > > > with at least the above three examples, i conclude "U cannot replace E at > all"! > > > See above. > > see above. - maoke > > > (btw, surely the translation has the same limitation not to support the > above features but, e.g., as you also said, it opens transport-layer stuff > to the middle boxes). therefore i said operators may use either > encapsulation or translation according to what they attach importance to.) > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
