>From: Francis Dupont <[EMAIL PROTECTED]> >To: Margaret Wasserman <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED] >Subject: Re: IPv6 Scoped Addresses and Routing Protocols >Date: Sat, 25 May 2002 18:48:50 +0200 >Sender: [EMAIL PROTECTED] >X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr > > In your previous mail you wrote: > > Sites boundaries run through routers, so a single router (called a > site border router (SBR)) can have interfaces in more than one site. > >=> a SBR is a nightmare... It needs a scoped routing table in the kernel >and separate IGPs for each site. I don't want to imagine how we can >support site reconfiguration on a running SBR. > > SBRs will need to enforce site boundaries > >=> this part is easy: a very small number of lines of code in the forwarding >routine. > > not mixing site-local routing information > >=> this is called a scoped routing table (zoned should be a better term >but unfortunately it is too late to fix RFC 2553 or even 2553bis...) > > and not forwarding packets outside of a given site. > >=> this is "enforcing site boundaries", isn't this? > > To do this, it is expected that SBRs will need to maintain multiple > "conceptual routing tables", including one site-local routing table > for each attached site, and one global routing table. > >=> in fact usually a zone ID is added to addresses for the same result. > > None of our IPv6 routing protocol documents deal with site-local > boundaries or SBR behaviour explicitly. > >=> one can expect a site is a routing domain and an internal gateway protocol >should be run in the site. As routing protocols carry raw addresses (i.e., >in a case of a scoped address, the address without its zone indication) >this is the only reasonable way. > > Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing: > http://www.ietf.org/rfc/rfc2545.txt > >=> two remarks: > - usually BGP is used as an inter-domain routing protocol so is supposed > to manage routes for global prefixes. > - the issue is partially addressed in the section 2 (partially == not > fully solved). >In fact, the multi-protocol feature of BGP 4+ provides some ways to carry >extra information in a NLRI. For instance, we can reuse a VPN-like >(cf RFC 2547) way to manage site-local addresses with site identifiers. > > RIPng for IPv6 > http://www.ietf.org/rfc/rfc2080.txt > >=> its poor scalability makes RIPng a bad candidate for multi-sited stuff. > > So here are my actual questions: > > (2) BGP-IPv6: > > Would it ever be reasonable for BGP to propagate site-local routing > information? > >=> I've already answered this should be possible in the hard (== multi-sited) >case. Personally I believe site-local addresses should be reserved to the >not-connected organizations: the "non-link-local" argument applies. >(PS: here not-connected is at the network layer) > > Why, under what circumstances? > >=> very large not-connected organizations? > > Would it be reasonable to assume that an Inter-Domain Routing protocol > shouldn't propagate site-local information at all? > >=> I'd like to say site-local information should not cross site boundaries. > > If BGP should be capable of propagating site-local information, > will it be possible, using existing BGP standards for a BGP SBR router > with four interfaces (A, B, C & D), in two sites (A & B in S1, and C & > D in S2) to maintain two separate sets of information for prefix > FEC0::/10, one that applies to S1 (interfaces A & B) and one that > applies to S2 (interfaces C & D), and to propagate that information > accordingly? > >=> I am not an expert of RFC 2547 but site-local addressing fulfills >the 1.3 requirement about overlapping address spaces so a similar >tagging of site-local addresses (RFC 2547 adds a "Route Distinguisher" >which identifies a VPN, we can use the same concept for identifications >of sites) should work. > > Is this really just an issue of configuring the router properly, as > BGP-IPv6 implies? > >=> not for the multi-sited case because a router is not supposed to run >more than one BGP-IPv6 process. But in other cases I agree with the >suggession of BGP-IPv6 (i.e., I still believe BGP-IPv6 doesn't need >to be updated). > > (3) OSPF-IPV6: > >=> OSPF-IPv6 has the new (over OSPFv2) property that one is allowed to >run more than one OSPF-IPv6 process per router. So with a dangerous but >possible configuration the multi-sited case can be handled. > > Unlike the previous specification (BGP-IPv6), this assumption is > not stated up-front. Instead, everywhere in the draft where either > site-local or global addresses are mentioned they are both mentioned > (i.e. "site-local or global IPv6 addresses"). > >=> results are 5 and 80 pages (totally unfair comparison :-)! > > Or to assume that an OSPF AS will always be completely contained > within one site -- which is what the current draft seems to assume? > >=> I agree but this is not a limitation because one may run multiple >OSPF-IPv6 processes per router, i.e. put a router in multiple ASs. > > (4) IS-IS-IPv6: > > Any thoughts? > >=> I believe IS-IS-IPv6 assumes an AS is completely contained in one site >but there is no multiple process capability (my argument is the CLNS >addressing is per node, not per interface. A well-known consequence is >IS-IS can not run as an external gateway protocol). But this applies >to the original IS-IS lightly modified to carry IPv4 addresses (as decribed >in the reference). > > (5) RIP-IPv6: > > The RIP-IPv6 document explicitly states that there is a single IPv6 > routing table. > >=> so RIP-IPv6 has explicitly no provision for the multi-sited case. > > (6) Will the MIBs for any of these routing tables be capable of > representing multiple independent, possibly overlapping sets of > site-local routing information? > >=> in the case of BGP 4 (the only one I know because MIBs are the reason >the RFC 2553 is not yet a Draft Standard :-) all references in >draft-ietf-idr-bgp4-mibv2-02.txt point to RFC 3291 which defines ipv6z >addresses: "A non-global IPv6 address including a zone index as >defined by the InetAddressIPv6z textual convention"! > > (7) Do you think that there would be some utility to defining the > actual routing architecture (as opposed to just the addressing > architecture) for IPv6? > >=> no because we shan't easily get a consensus (there are two strong >opposite opinions about the use of sites). > > (8) Should we mention link-local addresses anywhere in these specifications? > >=> not in specifications when they are enough clear but in applicability >documents. > > We certainly would not want to propagate routing information for > link-local addresses. > >=> perhaps this is the opportunity to solve a very old issue raised by >Jean-Luc Richier many years ago: a topology discovery tool using SNMP >to dump routing tables can not go beyond directly connected routers >because it gets useless link-local addresses of next routers... > >Thanks > >[EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
