[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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