Re: draft remarks

[Eliot Lear <lear@cisco.com>]

Hi!

I've reworked the document based on Geoff's comments.  Questions are the 
same, but just in different order.

Iljitsch van Beijnum 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.

4.2  Does your solution impact existing traffic engineering methods,
    such as MPLS-TE?

   Traffic engineering allows for source-based traffic aggregation to a
   particular destination.  How will your mechanism interact with such
   existing methods?


> - 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?


"
> 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?

> 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?


   How will your solution interact with
> 2.4.13 "compatable"?
> 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? ;-)  You're right. 
And that's a case to point out.  What I really meant were short-lived 
network associations.  We could probably use iPass or T-Mobile as the 
case in point I actually had in my head.

> 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.  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.

> 2.4.20 Quotation marks gone astray.

doh.

> 4. You misspelled my name, and Patrik's too, I think.

doh * 2.  My apologies to you both.

Eliot