Subject: [mif] comments on charter

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2009 14:23:24 +0200

I'm looking at the charter at 
http://www.arkko.com/ietf/ietf-74/mif/charter.txt

> Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem".
>   

The second sentence comes a bit out of the blue. One of the things that 
I struggle with on this effort is how it relates to:

1) RFC 5113
2) various multihoming efforts
3) what is already stated in existing RFCs, such as RFC 1122

I do believe there is a problem here that is beyond what has been done 
before and different from the full multihoming question. However, we 
need to put effort into distinguishing ourselves from those other 
things. I.e., scope needs to be defined precisely.

> all the flows will go
>    to the default gateway based on RFC1122 description when the host has no 
>    route cache entry for the destination host address of flows.
s/... host address of flows./... host address./

>    A multi-homed host receives node configuration information from each
>    of its access networks.  Some configuration objects are global to the
>    node, some are local to the interface.  Various issues arise when
>    multiple configuration objects that are global to the node are
>    received on the many interfaces the multi-homed host has.  Therefore,
>    there is a need to define the appropriate behavior of an IPv4 or IPv6 
>    stack

Makes sense.

>  and possibly define protocols to manage these cases.

I would try to keep this effort first on the level of defining 
behaviours with existing protocols. We can go to new protocol 
development later.

>  RFC 3484 proposed default address selection for IPv6 could be a refernce to this work.
>   
Its not clear to me what this tries to say.

First of all, 3484 is undergoing revision. That is a 6MAN effort. But 
yes, of course 3484 is going to be referenced by what ever we might 
produce here. Why does it have special role in the charter text, though? 
I see it no different from DHCP, DNS, ND, etc.

>  Split DNS:
>
>    o A multi-homed host may have one of its interfaces facing a DNS
>    service which resolves private names and addresses(Proposed Standard)
>   

This is a statement of fact. What work are you proposing? Please define 
what the PS RFC would change from today's situation.

>  Routing of multiple interfaces:
>
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough information to choose 
>    the best interfaces for different unicast applications/flows in the host. 
>    Thus a IPv4/IPv6 host would need to be provided with more information 
>    for interface selection which is different from RFC 4191(Proposed Standard)
>   

Seems sensible. But again, I'd like to see some idea about what exactly 
you are doing beyond 4861, 4191 and others.

>  Address Selection Policy:
>
>    o a multi-homed host with IPv4 and IPv6
>    connectivity might need to receive an update of its default address
>    selection policy.  However, that policy is only valid within the
>    context of the interface it received it from.  Each network on which
>    the node is connected might have a different address policy to push
>    to the connecting nodes"(Proposed Standard)
>   
So the idea is to use the 6MAN work on one interface, and then MIF will 
talk about how the information will be merged, or creates additional 
protocols to deliver node-specific information?

I actually have a slightly different idea. We should write an RFC that 
describes the best practices around merging configuration information 
received on IP layer autoconfiguration mechanisms across multiple 
interfaces. This would cover not just the address selection policy 
issues, but also other data, such as various DHCP options.

Jari

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 05 Feb 2009 10:07:25 -0500

> issues, but also other data, such as various DHCP options.

agree. completly. 100%.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 05 Feb 2009 10:17:44 -0500

Jari Arkko a écrit :
> things. I.e., scope needs to be defined precisely.

yes. I agree. there is a fine line. I have good confidence that between
now and SFO, the scoping will be more precise and would be more
efficient BOF as scoping is getting worked out before SFO.

> behaviours with existing protocols. We can go to new protocol

agree. might be a wg charter in two phases: one: defining problem and
current practices. and then recharter for protocol work or send protocol
work to other wg.

Marc.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Feb 2009 16:51:12 +0100

> current practices. and then recharter for protocol work or send protocol
that makes perfect sense to me

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 00:33:06 +0800

Hi, Jari,

thanks for your review.
I think you made most key points here, we will do below shortly:
1. Revise the first paragraph to clarify the scope and difference with
others.
2. Keep exisit protocol design at the moment, left new protocol future.
3. Update DNS split work
4. RFC 3484 related matter.
5. Routing of multiple interfaces: update
6. Add a new item about the currrent practice, excuse for forgetting it:)
7. Address Selection Policy:

thanks again.

-Hui

2009/2/5 Jari Arkko <[email-masked]>

> Current laptops and smartphones typically have multiple access network
>> interfaces. RFC 5113 already specify basic "Network Discovery and Selection
>> Problem".
>>
>>
>
> The second sentence comes a bit out of the blue. One of the things that I
> struggle with on this effort is how it relates to:
>
> 1) RFC 5113
> before and different from the full multihoming question. However, we need to
> put effort into distinguishing ourselves from those other things. I.e.,
> scope needs to be defined precisely.
>
> all the flows will go
> I would try to keep this effort first on the level of defining behaviours
> with existing protocols. We can go to new protocol development later.
>
> First of all, 3484 is undergoing revision. That is a 6MAN effort. But yes,
> of course 3484 is going to be referenced by what ever we might produce here.
> Why does it have special role in the charter text, though? I see it no
> different from DHCP, DNS, ND, etc.
>
>  Split DNS:
>>
>>   However, by default, it may not have enough information to choose   the
>> best interfaces for different unicast applications/flows in the host.   Thus
>> a IPv4/IPv6 host would need to be provided with more information   for
>> interface selection which is different from RFC 4191(Proposed Standard)
>>
>>
>
> Seems sensible. But again, I'd like to see some idea about what exactly you
> are doing beyond 4861, 4191 and others.
>
> interfaces. This would cover not just the address selection policy issues,
> but also other data, such as various DHCP options.
>
> Jari
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 00:36:21 +0800

one reply last line.

2009/2/5 Marc Blanchet <[email-masked]>

> current practices. and then recharter for protocol work or send protocol
this need one more round discussion.

-Hui

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Feb 2009 11:16:39 +0200

Marc,

> current practices. and then recharter for protocol work or send protocol
This seems like a sensible idea.

Jari