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

[Gert Doering]

Hi,

I have not responded for this for a while, because I felt like "no matter
what I say, it's going to be twisted around and ignored", but there's a
few things in there that prompt a response...

On Thu, Sep 30, 2010 at 02:13:21PM -0700, Tony Li wrote:
> > Let me try to illustrate this with a specific example.  No complex policies
> > for now, just focusing on "shortest path to destination".
> 
> Nope, sorry, you don't get to change the game in the middle.  You asked 
> for a path equivalent or better than what a single prefix would give you.

Yes.  So how is this changing the game?

For the sake of the example, I was reducing the policies involved to
a very simple one, to make the problems obvious.  I am well aware of
real-world routing requirements, but that doesn't change the results,
it just makes the discussion more fuzzy and harder to follow.

> Specifically, routing today does NOT give you the shortest path 
> to the destination.

True, but not relevant to understanding the problem "we the operators"
see with the currently existing technology.


> > 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).
> 
> No, BCP 38 requires that the source address MATCH the egress.  If the 
> egress prefix is applied at the ASBR, that also suffices.

Since we're talking about *current* technology, the egress prefix has
to be selected by the sending host.  There is nothing in my ASBRs today
that could "apply a prefix".


[..]
> > 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.
> 
> No, it will not.  It will simply use the path selected by BGP.  That 
> could easily be S1 to D2.

If you mix in policy, you can always construct an example where BGP would
be configured to pick a bad path.  Yes.  But this is missing the point -
if you mix in policy, N*M is likely to have more not-working-at-all
combinations, not just worse-than-best.


> > 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".   
> 
> No, sorry.  What you've shown is that the N*M model doesn't give you 
> a panacea.   It will not read your mind and give you ultimate optimality.

Nice wording, but again missing the point.  This has nothing to do with
"reading my mind".

> What the N*M model _can_ do, specifically with ILNP, is to present 
> all prefixes to the end host, in the preference order that the 
> destination selects.   Assuming that the destination is only 
> advertising working prefixes, then this gives you equivalent semantics 
> to what you have today.

I'm talking existing technology.  There is no ILNP today.

Even if it were, how can the destination know what the best prefix order
is for a given source?  How can the destination know which prefixes are
*working* prefixes without knowing the network topology in between?

> Further, if the hosts also support MPTCP, you can make use of all 
> N*M paths in parallel.  

I'm talking existing technology.  There is no MPTCP today.  (Even
though it certainly sounds very cool, as does SCTP, which isn't deployed
very widely either, unfortunately).


So, to summarize again: with existing technology, N*M is not something
that is fully usable yet - there's a gap.  Future technologies are quite
likely going to change this approach, but this isn't helping deployment 
*today* - and last I heard, we're somewhat in a hurry to get IPv6 out.

I'm sorry that I happen to live in the real world of today.

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/20101007/e0653639/attachment.bin