Re: draft remarks

On 18-jun-04, at 16:12, Eliot Lear wrote:

>> - are there any questions about how site policy can be applied? 
>> (where "policy" has a big overlap with "traffic engineering"

> You mean like access-lists?  There are specific questions regarding TE.

No, ACLs or traffic engineering in general are not not what I mean. 
Different people mean different things when they talk about policy. The 
subset that I'm interested in is the situation where a network is 
multihomed, and it wants/needs to reach certain destinations over one 
particular link under normal circumstances. In a situation where 
decisions by hosts determine the link used for incoming and/or outgoing 
packets, there is no obvious way to push such a policy out to all hosts 
within the site.


>> - I would like to see a new question: "Is it possible to implement 
>> the solution in middleboxes?

> 3.10  Middlbox interactions

>    What are the implications for firewalls?  What are the interactions
>    with NAT?  What are the interactions with web caches? What
>    complications are introduced with your solution?  For instance, are
>    there implication for ingress filters?  If so, what are they?

This question assumes that the solution is implemented somewhere (such 
as in hosts) and asks how otherwise unrelated middleboxes are going to 
function in the presence of multihoming. What I'm getting at is that 
the situation that the solution is implemented inside a middlebox or 
site exit router such that unodified hosts can benefit from being 
multihomed. That's a different issue.

>> 3.4 I think the question about MPLS traffic engineering warrants a 
>> pointer to what exactly this is about, as this is a layer 2 thing 
>> which we can't assume everyone is familiar with

> Got a suggestion?

No. Quite the reverse: I'd like to read such a document in order to see 
what all the fuss is about.

>> 2.4.12 I think it's important to split between interaction of updated 
>> hosts in a multihomed site with unmodified correspondents, and 
>> operation of "legacy" hosts in multihomed sites.

> This is where 2.4.15 was going.  Is that not sufficient?

At first glance this seems to be about deployment scenarios, this 
question isn't very clear.

>> 2.4.15 An IETF meeting isn't really an example of an ad-hoc network. 
>> Some people sitting together and creating a network on the fly 
>> without being able to request address space and such would be a 
>> better example.

> You mean like our just concluded interim meeting? ;-)

Right. I was also thinking about networks without any connectivity at 
all, but I just realized those aren't going to be multihomed so they 
are of no interest to us.  :-)

> We could probably use iPass or T-Mobile as the case in point I 
> actually had in my head.

I've never heard of iPass and T-Mobile is the outfit that bills me for 
using my cellphone, so I'm not sure if those names are helpful...

>> 2.4.19 Referrals don't work all that well in IPv4 either. I think a 
>> "must" is too strong here. For instance, if referrals fail after a 
>> rehoming event I would consider that acceptable. A separate effort to 
>> make referrals work well regardless of multi6 would be good, too.

> This is an area that I think needs just a bit more work, in any event. 
> First of all, this is not a requirements document, and if you read it 
> as such, then I went afoul of my own intent.

Yes, this alone is sufficient reason to remove the "must". However, I 
was overlooking that fact and arguing that even in a requirements 
document (which this isn't and we don't have) this requirement would 
probably be too strong.

> But beyond that, many people *are* concerned about what the binding 
> between location and address means.  For instance, will that binding 
> vary based on who's asking? Will the same binding work if one of the 
> two correspondents move?  FTP was (I thought) the trivial case of 
> this, because time is not generally a factor.  Of course, firewalls 
> are.

FTP is an interesting case because it supports a controller X directing 
Y to send a file to Z and Z to receive it from Y. Now consider the 
situation where X communicates with addresses Y1 and Z1, but Y and Z 
can only reach each other at Y2 and Z2.

I guess all of this is solvable by introducing an identifier and a 
mapping service, or going through a reverse, forward DNS lookup cycle 
(if the FQDN - host relationsip is 1-on-1), but I think this is a 
challenging problem in its own right rather than just a footnote in the 
history of multihoming.

Iljitsch