RE: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48 and ULA multicast scope matching ...

["John Spence" <spence@commandinformation.com>]

> > I'm slightly confused be this, and I think the comment about not
> > being able to summarize 16 /48 ULAs is what is confusing me.
> > Summarization seems to me to only be useful if you are going to
> > announce a summary to an upstream entity of some sort, and is really
> > only for the benefit of the upstream entity (e.g. upstream ISP, IGP
> > backbone area, other areas carrying inter-area routes rather than a
> > default etc.), as it reduces their route table and other routing
> > resource requirements.
> > 
> > As ULAs are kept within private entity, and therefore there isn't
any
> > upstream entity, is there really any need to summarize to less than
> > 16 /48 ULAs (in your scenario, for example)? If, within your
> > organization, your routers can't cope with 16 /48 ULAs, I'd think
you
> > probably have bigger routing problems to deal with (and a default
> > route only might be a main (and only) solution to that)!
> > 
> > If you were summarizing ULAs internally to scale an IGP by dividing
the
> > IGP into areas, would 16 areas, corresponding to the 16 /48s (global
> > and ULAs), be too many to cope with ? I'm not really sure they
would.

For me this is all about defining best practices and laying out
alternatives.  All situations are different and the engineer on the
ground best placed to decide how to apply recommendations or
considerations from the RFC.

I agree in most cases people would do fine with multiple (in this
example 256) non-contiguous /48 ULAs, even if they had a /40 (say)
global prefix.  But it seems a reasonable insight to suggest that they
could, for whatever reason, generate a contiguous /40 ULA, modifying the
documented procedure, if that would work better for them in their
specific deployment.  Subject to the caution that the more ULA space
they generate and deploy the greater the odds (although in most all
cases still very, very small) of a collision when merging with a future,
unknown network.  In general even internal aggregation can be valuable,
and having an allocation that lends itself to summarization seems like a
benefit.  Seems like a good thing to enable, and allow the network
designer to decide if they want to take advantage of it.

> > I do see the operational benefits of having the /44 to /64 bits in
the
> > global and ULA addresses match. I'm not quite sure I see how
> > summarization by itself, which is how I read your paragraph, would
be a
> > justification to do that, when the consequences are increased
chances
> > of collision, should you join your /44 ULA domain with somebody
else's.

I don't think you are more likely to encounter a collision later if you
deploy, say, a contiguous /44 ULA or 16 non-contiguous /48 ULAs
(disclaimer: not a mathematician).  I agree you are more likely to avoid
collision by only generating, say, one /48 ULA to go with your /44
global, if that suits your needs.

Spence