Subject: [mif] Recharter discussion

From: Hui Deng <[email-masked]>
Date: Wed, 18 Aug 2010 15:58:10 +0800

Hello all

We had a good discussion during last IETF meeting,  below are concensused
recharter items and proposed text, please feel free to comment on it thanks,

and problems have been conformed during the meeting were:
1) This is a problem where a node has more than one next hop and one or more
interfaces need to decide what next hop need to forward the packet
2) Next hop selection for situations where existing RA and routing protocol
based solutions are deemed inadequate
3) Is this define abstract API to expose the multiple interfaces
functionality.

1) Split-DNS solution:
a specification for describing a way for a network to communicate to
nodes information required to perform advanced DNS server selection
in split-DNS deployments. The specification shall describe the
information to be delivered for nodes and the protocol to be used
for delivery.

2) DHCPv6 routing configuration:
a specification of an option to DHCPv6 to inform hosts information
required to perform advanced routing table configuration, to avoid
the all flows being led to the default route.

3) MIF API:
an abstract API describing how applications can exploit additional
features of multiple interface enabled stack. While MIF does
not need any application changes, this API should be an optional
extension that provides ability of source address selection, DNS
selection and etc.

 Goals and Milestones
Nov 2010: Initial WG draft on Split-DNS solution
Nov 2010: Initial WG draft on DHCPv6 option for routing configuration
Nov 2010: Initial WG draft on MIF API extension.
Nov 2011: Submit Split-DNS solution to IESG for publication as
 a Proposed Standard RFC
Nov 2011: Submit DHCP extension solution to IESG for publication as a
 Proposed Standard RFC
Nov 2011: Submit MIF API extension solution to IESG for publication
 as an Informational RFC

Anyway, we fail to have time to discuss other proposals such as:
1) Holding the on-going sessions
2) Connection manager requirements
3) Virtual Interface
4) Recommendation for routing metric implementation
5) DHCPv4 routing configuration

Best regards,

-Hui

---

From: Tomasz Mrugalski <[email-masked]>
Date: Wed, 18 Aug 2010 10:29:10 +0200

2010/8/18 Hui Deng <[email-masked]>

> the all flows being led to the default route.
There are several aspects of routing configuration, and I'm 100% sure that
we won't be able to stuff everything in a single option. We should reword
that to "DHCPv6 options".

By explicitly mentioning host, we exclude routers. Although I believe we
don't want to deal with moving routers right now, we should not exclude that
path. As we are dealing with DHCPv6, there's commonly used feature called
prefix delegation (RFC3633). Clients that use it are actually routers. By
limiting our solution to hosts only, we actually saying "this will be
incompatible with widely deployed PD". Hence nodes, instead of hosts.

I propose to reword that sentence as:
"a specification of DHCPv6 options to provide nodes with the information
required to perform advanced routing table configuration, to avoid all flows
being led to the default route."

 Goals and Milestones
> Nov 2011: Submit DHCP extension solution to IESG for publication as a
I suppose we are dealing with DHCPv6 only, right? If that is so, please
substitute DHCP with DHCPv6 to avoid confusion.

> Nov 2011: Submit MIF API extension solution to IESG for publication

Best regards,
Tomasz Mrugalski

---

From: W Dec <[email-masked]>
Date: Wed, 18 Aug 2010 12:47:34 +0200

Some comments inline

> incompatible with widely deployed PD". Hence nodes, instead of hosts.

Agree.

> being led to the default route."

Since one doesn't quite know what an advanced vs simple routing table is,
besides the notion of a flow , I'd propose an even simpler sentence
"a specification of DHCPv6 options allowing client nodes to perform route
table configuration."

Regards,
Woj.

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Aug 2010 07:44:46 -0700 (PDT)

Hi Hui,

>
>From: Hui Deng <[email-masked]>
>To: MIF Mailing List <[email-masked]>; Jari Arkko <[email-masked]>; Margaret 
>
>Wasserman <[email-masked]>; Ralph Droms <[email-masked]>
>Sent: Wed, August 18, 2010 2:58:10 AM
>Subject: [mif] Recharter discussion
>
>
>Hello all
> 
>3) Is this define abstract API to expose the multiple interfaces functionality.
> 
>1) Split-DNS solution: 

I agree.

DHCP Option guidelines document draft-ietf-dhc-option-guidelines has some good 
text when to use options 

and when to group them into suboptions.

I think that it is OK 
to group options that may be requested 
at the same time by the same client which is the case here.

I think that we should not be religious about this :-).

Regards,

Behcet

---

From: <[email-masked]>
Date: Fri, 27 Aug 2010 13:52:31 +0200

Hi all,
 
IMHO, the text on API is a bit misleading. The text implicitly says that source address selection, DNS 
selection and etc. are functions of the API. So, it seems to close the door to other scenarios where selection functions are supported by applications or connection manager. I think these scenarios are valid, so I'd propose to revise the API text:

3) MIF API: 
an abstract API describing how applications can exploit additional 
features of multiple interface enabled stack. While MIF does 
not need any application changes, this API could provide additional services 
to MIF related functions, such as first-hop selection, source address selection, DNS 
selection, etc.  

BR,
Pierrick
 
________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : mercredi 18 août 2010 09:58
À : MIF Mailing List; Jari Arkko; Margaret Wasserman; Ralph Droms
Objet : [mif] Recharter discussion
 
Hello all
 
We had a good discussion during last IETF meeting,  below are concensused 
recharter items and proposed text, please feel free to comment on it thanks, 
and problems have been conformed during the meeting were:
1) This is a problem where a node has more than one next hop and one or more interfaces need to decide what next hop need to forward the packet
2) Next hop selection for situations where existing RA and routing protocol based solutions are deemed inadequate
3) Is this define abstract API to expose the multiple interfaces functionality.
 
1) Split-DNS solution: 

3) MIF API: 
 
 Goals and Milestones

Best regards,
 
-Hui