Subject: RE: [arch-d] Major practical decision

From: [email-masked] (Noel Chiappa)
Date: Sat, 9 Dec 2006 11:16:03 -0500 (EST)

> From: "Bound, Jim" <[email-masked]>

    >> I get the sense that it is now generally accepted that widespread
    >> multi-homing has to be handled by use of multiple routing-names, and
    >> identity/location separation.

    > We need to crisply define and obtain consensus on Routing-Names.

Routing-names are, very simply, the names for things which the
path-selection (routing) uses. End of definition! :-)

So from my perception there's not really a lot, at a fundamental level, to
obtain consensus on. I think it's obvious that you have to have
path-selection, and in turn that it has to use some sort of names. So the
fact that we have to have them, and a lot about their basic properties, are
necessarily defined for us right there.

Yes, there are issues of detailed syntax etc, but I think those should be put
off *until we know more about how the routing is going to work*. Once we've
done that, we can turn to transforming generic A.p.1 kind of notation into
specific bit patterns, etc.

    >> we may be forced to convert the current IPvN addresses into end-end
    >> names, "jack up" the internetwork layer, and insert a new layer
    >> underneath, and deploy some sort of mapping system to map from IPvN
    >> "addresses" to some new routing-name namespace.

    > These are three efforts that can happen regarding our work to define an
    > architecture in parallel

Sorry, I'm not sure I understand your comment.

First, are you saying that you think the jack-up path is the way to go?
Because further down you say that you prefer a new end-end namespace ("my
view currently we should move to a new namespace for end-to-end entities"),
which is the other path. Or are you saying take both: jack-up short term,
new end-end names long-term?

Second, if I decompose 'jack-up' into separate engineering elements, I'm not
sure I see three pieces. I come up with:

1 - Decide what the new lower layer packet routing-name format is going to be.
2 - Figure out how the routing is going to work.
3 - Decide what the new lower layer packet format is going to be.
4 - Depending on the previous one, we may need to design an encapsulation.
5 - Design and plan deployment of the mapping database.

Some are fairly simple (1, 3 and 4), but others are pretty significant. And
of course 3 depends on 1 (as in, can't start 3 until 1 is done), and 4
depends on 3.

Finally, are you suggesting that we do detailed designs on all possible
alternatives (e.g. one or more jack-up systems, etc), and only pick one once
more detailed designs are in hand? I'm rather concerned that that would
spread us too thin, and we'd be better off trying to decide on one (or maybe
two) to persue up front. However, that's just my opinion; luckily, I don't
have to make that sort of call anymore! :-)

    >> [possibly] this is the only solution that's viable in a short
    >> time-frame.

    > I think we must define short and long term before one can answer this
    > question.

Short-term = (roughly) before the Internet routing tables melt down. :-)

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 9 Dec 2006 16:56:12 -0500

> Routing-names are, very simply, the names for things which 
> the path-selection (routing) uses. End of definition! :-)

I prefer then at this point routing-name-space otherwise no different to
me than an address.  But name-apace to me is a more appropriate
architecture term for this work.

> 
> So from my perception there's not really a lot, at a 
> fundamental level, to obtain consensus on. I think it's 
> obvious that you have to have path-selection, and in turn 
> that it has to use some sort of names. So the fact that we 
> have to have them, and a lot about their basic properties, 
> are necessarily defined for us right there.

I am fine with the above definition with namespace suffix of "space" so
lets get that done besides from memory on a mail list in some way.  Do
we need a draft for terminology?

> 
> Yes, there are issues of detailed syntax etc, but I think 
> those should be put off *until we know more about how the 
> routing is going to work*. Once we've done that, we can turn 
> to transforming generic A.p.1 kind of notation into specific 
> bit patterns, etc.

Yes, but a problem statement draft and initial terminology would be
good.

> Sorry, I'm not sure I understand your comment.

#1 what is the architecture of the routing-name-space?

#2 what is the transition to use #1 above with current IPvN addresses.

#3 what are the operational abstractions and requirements for a new
layer.

That is the three and all can be done in parallel by three different
design teams all sharing and communicating of course.

> First, are you saying that you think the jack-up path is the 

Not for new architecture work on this list.

> Because further down you say that you prefer a new end-end 
> namespace ("my view currently we should move to a new 
> namespace for end-to-end entities"), which is the other path.

I will respond below but I am saying separate entirely transport from
all other layers in the new architecture and that requires a new
end-to-end name space and operational changes similar to SHIM6 and HIP.
Minus the CGA which I can not support at least for real implementation
in the market. I don't consider this jack-up nor a routing problem thus
not one of my three above.
 
> Or are you saying take both: jack-up short term, new end-end 
> names long-term?
> 
> Second, if I decompose 'jack-up' into separate engineering 
> elements, I'm not sure I see three pieces. I come up with:
> 

My #1 above.

> 2 - Figure out how the routing is going to work.

My #2 above.

> 3 - Decide what the new lower layer packet format is going to be.

Same as my #1.

> 4 - Depending on the previous one, we may need to design an 

Same as my #1.

> 5 - Design and plan deployment of the mapping database.

New task #4 when my #1 and #2 are done.

> 
> Some are fairly simple (1, 3 and 4), but others are pretty 
> significant. And of course 3 depends on 1 (as in, can't start 
> 3 until 1 is done), and 4 depends on 3.

Hmmm will respond as we evolve here I think the dependencies may be more
interrelated.

> 
> Finally, are you suggesting that we do detailed designs on 
> all possible alternatives (e.g. one or more jack-up systems, 
> etc), and only pick one once more detailed designs are in 
> hand? I'm rather concerned that that would spread us too 
> thin, and we'd be better off trying to decide on one (or maybe
> two) to persue up front. However, that's just my opinion; 
> luckily, I don't have to make that sort of call anymore! :-)

One focus but to move our pace that 3 parallel design teams could be at
work.

> Short-term = (roughly) before the Internet routing tables 

So short term is 5-7 years ?

Long Term == Short-Term+

/jim