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

From: [email-masked] (Noel Chiappa)
Date: Mon, 11 Dec 2006 10:49:42 -0500 (EST)

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

    >> The question of whether we add a new end-end namespace, or a new
    >> routing-names namespace

    > I think we need two new name spaces.

Actually, as I was thinking all this over last night, I decided that I had
missed one option I had spoken of earlier, which is (exactly as you say) to
have two new namespaces; one for routing-name, and one for end-end identity.
I.e. migrate out of the existing IPvN "addresses" in both directions at once.

However, I worry that that will be a bit much for everyone to swallow! :-)

    > The transition will require jack-up but eventually the jack-up should
    > not be required in either case.

Well, by "jack-up" I simply mean the insertion of a new layer. *How* that
happens I was not yet discussing (as Pekka pointed out, that's to some degree
orthagonal to more basic questions like "how many namespaces"). I would
assume that initially it would be done invisibly to the hosts, by "mapping
boxes" acting on their behalf (so we don't need to change any hosts), but
that over time hosts might become aware of the existence of another layer
down there.

I may be misunderstanding the implications of your comment, but let me see if
this is what you meant: were you saying that initial deployment of jack-up
would be invisible to hosts, but that eventually we might dispense with the
mapping boxes, and the hosts would do it all themselves?

I say that because if the jack-up inserts a new layer which is used for
routing, I can't see how we'd ever be able to stop using that new layer
(which is what your comment "eventually the jack-up should not be required"
might be read to mean).

    > Where we can use existing tools to help is probably a wise excercise
    > depending on our time-to-market resolution to IAB concerns.

Do you mean that we might re-cycle existing protocols/code for the new higher
and lower layers? I agree that's a good goal, but I would not like to cramp
long-term development by insisting that we have to use the most simplistic
option.

E.g. if we do jack-up, I'd like to use MPLS as the inter-router forwarding
element of the new internetworking layer, rather than IPvN. The original IPv4
architecture assumed the same packet format for inter-router communication as
for host-router communication, but I'm not sure that simplification is really
apt anymore in such a large system (since larger systems always benefit from
more specialization).

	Noel

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:36:38 -0500

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Monday, December 11, 2006 10:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [arch-d] Major practical decision
> 
> Actually, as I was thinking all this over last night, I 
> decided that I had missed one option I had spoken of earlier, 
> which is (exactly as you say) to have two new namespaces; one 
> for routing-name, and one for end-end identity.

Agree I would suggest using the word "transition" than migration.

> However, I worry that that will be a bit much for everyone to 

Not with a good transition strategy.  That is key.

> Well, by "jack-up" I simply mean the insertion of a new 
> layer. *How* that happens I was not yet discussing (as Pekka 
> pointed out, that's to some degree orthagonal to more basic 
> questions like "how many namespaces"). 

I agree with Pekka for idea generation I do not agree that we can
complete any new model or architecture without considering transition at
some point.

>I would assume that 
> initially it would be done invisibly to the hosts, by 
> "mapping boxes" acting on their behalf (so we don't need to 
> change any hosts), but that over time hosts might become 
> aware of the existence of another layer down there.

That is where we discuss SHIM6 as potential Jack-Up at least for
end-to-end and for routing I agree it should be transparent to hosts.
But the concept of routers, switch, and gateway nodes is becoming
blurred in the market as a point to note.  

> 
> I may be misunderstanding the implications of your comment, 
> but let me see if this is what you meant: were you saying 
> that initial deployment of jack-up would be invisible to 
> hosts, but that eventually we might dispense with the mapping 
> boxes, and the hosts would do it all themselves?

For hosts end-to-end yes.

> 
> I say that because if the jack-up inserts a new layer which 
> is used for routing, I can't see how we'd ever be able to 
> stop using that new layer (which is what your comment 
> "eventually the jack-up should not be required"
> might be read to mean).

I guess that depends on how we arechitect the new model.  Have to
reserve the right to comment later as we progress but I do see your
point today.

> Do you mean that we might re-cycle existing protocols/code 
> for the new higher and lower layers? I agree that's a good 
> goal, but I would not like to cramp long-term development by 
> insisting that we have to use the most simplistic option.

This gets to the engineering part of the job.  Due dilligence for
engineering I believe will guide what we need to do as opposed to
computer science exercise where we may not worry as much about the
business case, deployment with current infrastructure etc.  Big diff
between engineering and computer science for "networking".

> 
> E.g. if we do jack-up, I'd like to use MPLS as the 
> inter-router forwarding element of the new internetworking 
> layer, rather than IPvN. The original IPv4 architecture 
> assumed the same packet format for inter-router communication 
> as for host-router communication, but I'm not sure that 
> simplification is really apt anymore in such a large system 
> (since larger systems always benefit from more specialization).

I understand what your saying and will agree IFF we mean a core between
to edge networks.

Best,
/jim