I-D Action:draft-azinger-scalable-addressing-00.txt

Gert Doering gert at space.net
Thu Sep 30 22:51:20 CEST 2010


On Thu, Sep 30, 2010 at 09:37:23AM -0700, Tony Li wrote:
> So if you have N entries then your network admins won't bother to make them work?
> Seems to me like you need new network admins.

What exactly can the network admin do here?

Let me try to illustrate this with a specific example.  No complex policies
for now, just focusing on "shortest path to destination".

There's a source prefix S1 that is routed via ISP 1, and a source prefix 
S2 that is routed via ISP 2 (both prefixes coming from the respective 
ISP's PA space, so BCP 38 filters will require that source address 
selection automatically selects egress ISP).

Destination prefix D1 is connected to peer of ISP 1, while destination
prefix D2 is connected to something 20 hops behind ISP 2 (assuming that
"20 hops" means "more latency, less bandwidth", for the simplicity of
the model).

    +--- S1 === ISP 1 === ISP X ======== D1 ---+
  source         (*)                         destination
    +--- S2 === ISP 2 --- ISP A, B, C -- D2 ---+

How exactly is the end host supposed to know that "S1->D1" is good, while
"S2->D2" is bad and "S1->D2" is very bad?  (Assume that "use the longest
sequence of common bits in the addresses" won't help, which is the normal
case when crossing RIR regions).

If I have a single S and D prefix, the end host does not *need* to know,
and the network *will know* that the path via ISP 1 to its peer to D is 
shorter than via ISP 2.

I hope I have succeeded this time in explaining where "we the operators"
see a gap in the N*M model - and that has nothing whatsoever to do with
"network admins not being up to the job".   

Gert Doering
        -- NetMaster
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100930/66dd5dd5/attachment.bin 

More information about the ipv6-ops mailing list