>X-Sender: [EMAIL PROTECTED]
>Date: Fri, 24 May 2002 21:29:52 -0400
>To: Margaret Wasserman <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>From: Jeff Parker <[EMAIL PROTECTED]>
>Subject: Re: IPv6 Scoped Addresses and Routing Protocols
>
>At 12:17 PM -0400 5/24/02, Margaret Wasserman wrote:
>>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped
>>addressing and our current IPv6 routing protocol specifications
>>...
>>(4) IS-IS-IPv6:
>>
>>IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this
>appropriate? How will IS-IS
>>SBRs know not to propagate site-local routing information between two attached
>sites? I don't yet
>>know enough about IS-IS to understand how site-local routing information would best
>be handled
>>in IS-IS. Any thoughts?
>
>Margaret -
> I don't know anymore about site-local than what I've read above, but perhaps
>I can help with how you might use ISIS.
> ISIS is used today is as an interior routing protocol. The boarder routers
>run ISIS on the 'inside' ('in site', in your terminology?) and use BGP to peer with
>the rest of the world. In this scheme, BGP could filter out the site addresses when
>communicating with the outside.
> Neither IS-IS nor OSPF scales past a certain size, somewhere in the 100 to
>1000 router range. But both have the notion of an area, and it should be possible to
>connect multiple sites (areas) together using the ISIS Level 2 notion, or OSPFs Area
>0. There would have to be provision to filter site address announcements from
>leaking into Level 2 (Area 0) if you tied multiple sites together with the IGP.
>
>- jeff parker
>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]
--------------------------------------------------------------------
