Re: Proposed update to ULA Draft (-09)

[Brian Haberman]

On Jan 17, 2005, at 14:57, Stephen Sprunk wrote:
Thus spake "Bob Hinden" <[EMAIL PROTECTED]>
At 04:40 AM 01/17/2005, Mark Smith wrote:
(as a side note, this is from Rev 8, the nokia web site resolves to  
an
IPv6 address, I don't seem to be able to get to it via my 6to4
connection though)

   For link-state IGPs, it is suggested that a site utilizing ULA
   prefixes be contained either within one IGP domain or area.  By
   containing a ULA prefix to a single link-state area or domain, the
   distribution of prefixes can be controlled.
I think it potentially could cause conflicts with the idea of using  
the
same subnet numbers as those used with a global prefix.
The language "it is suggested" was chosen to allow flexibility.  As  
you
point out in large multi domain/area deployments there are reasons to  
do
it
differently.
I think removing "area" and just leaving "domain" makes more sense; I  
can't
see anyone actually deploying different ULA prefixes per area.  The  
only
possible justification would be different ULAs per business unit (to  
prepare
for sell-offs) but business unit lines are rarely reflected in  
topology, in
my experience.
This change was made to address a DISCUSS comment specifically talking  
about
link-state routing protocols and area boundaries.  The text of the  
comment
is available at  
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_comment&id=26775.

Also, why does this suggestion only apply to link-state IGPs?  What  
are our
recommendations for people using RIPv6, EIGRPv6, etc?  Or with  
internal BGP
peering between multiple IGPs?

Distance-vector protocols are not generally broken up into admin areas  
like
OSPF & IS-IS.  I used to run a modified ripv6 daemon that routed the  
original
site-locals without issues (wrt internal routing).  So, I don't see  
much need in
giving a bunch of guidance there.

As to internal BGP, my question is "How many scenarios do we want to  
carry
around in this document?

Regards,
Brian


smime.p7s
Description: S/MIME cryptographic signature
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------