Re: [mif] WG Review: Multiple InterFaces (mif)

[Hui Deng]

Hi, Ted,

Excuse me for late reply, thanks for the discussion.

The reason why I said before is that currently there are limtied ISP
providing ICE support for open applications, anyhow, P2P made a smart
way to reach it.

For what I know application which need ICE like IMS is normally go to
independent APN.
That could be guaranteed since it is kind of application binding APN.

Today most mobile application binding with APN(kind of interface like)
or could be on-demand select for user. I guess Marc raised similar
consideration which allow application to call such interface API, then
it can run depending on different connection's characteristic.

Please kind help to provide your text regarding this application
scenario, it will be helpful for MIF PS could include those.
I will re-read the spec which you recommend and to know the potential needs.

thanks again

-Hui


2009/4/24 Ted Hardie :
> At 6:30 AM -0700 4/23/09, Hui Deng wrote:
>>For what I know at the moment service provider deployment experience,
>>ICE like solution has been deployed by a dedicate close network, this
>>is not interact with MIF space we talked here, mif are resolve general issue
>>with host connections, in that scenario, application is isolated.
>>
>>thanks.
>>
>>-Hui.
>
> Forgive me, Hui, but it is not clear to me whether you think the application
> is isolated in situations where ICE is in use, or whether it is isolated in 
> the
> work for which MIF might be chartered.
>
> If your point is that not all applications have a signalling-path mechanism
> for trading candidates using SDP, that is certainly true.  What is truly scary
> is that this makes applications which can use ICE better off than the common
> case, despite ICE's complexity.  I hope, after reading the full ICE spec and
> recognizing that there are *still* cases where it does not work to establish
> connectivity, you will see the scope of the problem.
>
> Interfaces/network attachments may have different reachability characteristics
> (e.g. be part of different address realms or otherwise have substantially
> different access to parts of the network).  There are classes of application
> which will want to make interface choices based on those characteristics.
>
> There are many other characteristics which may play into interface choices
> (do I already have a data channel on interface X, and need to acquire it on
> interface y?), and I do not want to minimize those, power savings being
> a big deal in my day job choices for this type of thing.  But the
> applications' needs here can't be subordinate to those, or the whole point
> of the link--you know, traffic across it--is lost.
>
> Just my personal opinion, despite the mention of a day job,
>                                regards,
>                                        Ted
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Hui Deng]

Christian,

I agree with what you said here, MIF should tackle this thoroughly.

I just wondering whether any ISP provider ICE service for open applications?
maybe my limited knowledge.

Regards,

-Hui

2009/4/24 Christian Vogt :
>
> On Apr 23, 2009, Hui Deng wrote:
>
>> For what I know at the moment service provider deployment experience,
>> ICE like solution has been deployed by a dedicate close network, this
>> is not interact with MIF space we talked here, mif are resolve general
>> issue with host connections, in that scenario, application is isolated.
>
>
> Hui -
>
> If the to-be MIF working group is to tackle the issue of address selection,
> then doing so thoroughly would require to also look into NAT traversal, and
> this includes ICE.  ICE specifies address selection rules for a large group
> of applications.
>
> - Christian
>
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Status of the 16-bit AS Number space

[Phillip Hallam-baker]

What are the potential consequences of multiple assignments of the  
same AS?


My initial reaction was that this would be very bad

But that is not necessarily the case and we might have a CIDR type  
workaround possible


Sent from my iPhone

On Apr 23, 2009, at 8:13 AM, Russ Housley  wrote:

I thought that the whole community would like to be aware of this  
status.


Russ



From: Michelle Cotton 
To: "i...@ietf.org" 
Date: Wed, 22 Apr 2009 20:52:18 -0700
Subject: Status of the 16-bit AS Number space

Dear IESG,

This is to let you know what we now have fewer than 10 blocks of 16- 
bit AS Numbers left in the IANA free pool.


Yesterday we allocated two blocks of 1,024 AS Numbers to ARIN, as  
per the Global Policy for Allocation of ASN Blocks to Regional  
Internet Registries, which was ratified by the ICANN board in July  
last year.


http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm


The unallocated 16-bit AS Number space is now 54272-64511. The full  
registry can be viewed at:


http://www.iana.org/assignments/as-numbers/as-numbers.xml

We agreed to notify the IESG when we got to this point in the AS  
Numbers registry.  Please let me know if you have any questions or  
comments.


Kind regards,

Michelle Cotton
IANA


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ted Hardie]

At 6:30 AM -0700 4/23/09, Hui Deng wrote:
>For what I know at the moment service provider deployment experience,
>ICE like solution has been deployed by a dedicate close network, this
>is not interact with MIF space we talked here, mif are resolve general issue
>with host connections, in that scenario, application is isolated.
>
>thanks.
>
>-Hui.

Forgive me, Hui, but it is not clear to me whether you think the application
is isolated in situations where ICE is in use, or whether it is isolated in the
work for which MIF might be chartered.

If your point is that not all applications have a signalling-path mechanism
for trading candidates using SDP, that is certainly true.  What is truly scary
is that this makes applications which can use ICE better off than the common
case, despite ICE's complexity.  I hope, after reading the full ICE spec and
recognizing that there are *still* cases where it does not work to establish
connectivity, you will see the scope of the problem.

Interfaces/network attachments may have different reachability characteristics
(e.g. be part of different address realms or otherwise have substantially
different access to parts of the network).  There are classes of application
which will want to make interface choices based on those characteristics.

There are many other characteristics which may play into interface choices
(do I already have a data channel on interface X, and need to acquire it on
interface y?), and I do not want to minimize those, power savings being
a big deal in my day job choices for this type of thing.  But the
applications' needs here can't be subordinate to those, or the whole point
of the link--you know, traffic across it--is lost.

Just my personal opinion, despite the mention of a day job,
regards,
Ted

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Rémi Denis-Courmont]

On Saturday 18 April 2009 12:25:17 ext Jari Arkko wrote:
> When the work started, it was clearly about multiple interfaces. Upon
> closer inspection, we have realized that the overall problem is somewhat
> larger. Problems that occur with multiple interfaces also occur even
> with one interface, when you have a number of default routers on the
> same link. The current charter text reflects this in some parts of the
> text, e.g.,

I don't quite agree here.

Multiple interfaces will typically have some differing properties, such as:
 - bandwidth,
 - latency,
 - charging,
 - power consumption,
 - reliability,
 - address transparency (e.g. what kind of NAT if any)
 - filtering policy,
 - IP protocol versions availability,
 - set of reachable hosts (the Internet, the home, the office...),
 - recursive DNS servers,
 - DNS namespace,
 - address filtering rules.

A host may have multiple default gateways on the same "interface". However, 
those gateways should be usable interchangeably. All of those gateways should 
have the same "values" for the properties above. Otherwise, I would argue the 
network is broken and/or the host is misconfigured. In other words, it can 
pick any of its live gateways outbound, and may receive packets from any of 
those gateways in the other direction. If I'm not mistaken, the IETF IPv6 
wireless network is an example of this.

But I think /that/ form of multi-homing has been solved for a long time by Ip 
stack implementors. What was discussed at the MIF BoF were quite different 
scenarios.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf