Subject: RE: [saad] About saad

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 16 Oct 2003 12:15:53 -0400

> From: "Michel Py" <[email-masked]>

    >> which are allocated and administered using a topology dependent model,
    >> implying a service provider dependent model
 
    > For IPv4 this is untrue, as PI addresses are not allocated using a
    > topology dependent model and do not imply a server provider dependant
    > model.

IPv4 tries to make sparing use of PI addresses for *exactly* the same reasons
as in IPv6 - too many will overload the routing.

The only difference is that with its greater address space, IPv6 has even
*more* rope to hang itself with, if it starts handing out PI addresses.

    >> But we run into problems (the architecture doesn't quite fit when we
    >> try to address some scenarios encountered in real life: multihoming
 
    > Untrue for IPv4.

The semantics of IPv4 and IPv6 addresses are basically identical. The only
difference is in the number of bits.

    > The issue with IPv4 multihoming is a scalability issue: the growth of
    > the routing table (resulting in part from the announcement of
    > multihomed blocks) induces instability, which is not good.

Well, I suppose the eventual "real" IPv6 multi-homing will have fixed this,
but if anyone's using "naive" IPv6 multihoming now - i.e. doing it like IPv4
does it, with a PI address (or a chunk of PA address which it advertises
globally - the two are indistinguishable technically) - it has exactly the
same scaling problem.

    > Possibly, a protocol other than BGP4+ would have a lot less of a
    > scalability issue, so I don't consider this an architecture issue.

A different routing algorithm/protocol might have a *one-time* improvement in
overhead, but in the long run, the curve is going to have the same kind of
shape. Having to track too many distinct destinations (which is roughly
equivalent to "routing table size") will overwhelm *any* routing architecture.

So, it *is* an architectural issue.

    >> choosing between different identifiers for an object
				  ^^^^^^^^^^^
    >> which has different "reachability" and the reachability
    >> is context-dependent
 
    > Shouldn't "identifiers" above be "locators"? I vaguely assume that an
    > object can have multiple locators but should have only one identifier.
 
It all depends on what is meant by the term "identifier" here. (The document
probably needs some editing for precision, etc.)

If it means "a name used for end-end identification", it would be a problem;
and I would like to understand what the architectural need is for multiple
end-end names for a single end-end entity.

If it means "address" or "locator", it ought to say so.

	Noel

_______________________________________________
Saad mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/saad