Subject: Re: [mif] Follow up with BBF proposal

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 01:08:41 +0000

Hi Hui,

The BBF requirement as presented in the BBF documents and as interpreted in draft-seite and draft-lhwxz is about enabling a CPE device to attach to multiple access network and perform flow management. However, I look at it, I see this this is a mobility requirement and is really not in the scope of MIF WG. The BBF requirement in question is all about flow switching or flow splitting across access systems. I'm not sure why this work belongs MIF and not DMM which is chartered to handle all mobility use-cases. We have discussed this specific use-case of flow splitting during MIF formation and explicitly disallowed MIF WG from taking up such work. The following is the quote from the MIF chartered text. Also, the MIF WG was primarily looking at issues for a host attached to multiple access networks, but the hybrid access is about a CPE attached to multiple networks. I really think this work should be done in DMM and we did present the requirements in the last IETF meeting.

http://datatracker.ietf.org/wg/mif/charter/

No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Future work in this area requires rechartering the working group or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues.

Regards
Sri

From: Hui Deng <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 31, 2014 4:50 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, 'Xueli' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Ted Lemon' <[email-masked]<mailto:[email-masked]>>, "'STARK, BARBARA H'" <[email-masked]<mailto:[email-masked]>>, 'Alexandru Petrescu' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Follow up with BBF proposal

Hi everybody

I am recommending that Xue Li could help to put down the slide for the problem statement from BBF.

And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly to meet together during IETF meeting
to discuss by adding s thelide about how today solutions meet the requirement or there are some gap still, and whether that problem should be solvable in IETF.

Chairs will talk with AD whether MIF or somewhere else will consider to discuss those issues during the f2f session.

Best regards,

-Hui

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 15:59:23 -1000

> The BBF requirement as presented in the BBF documents and as interpreted in draft-seite and draft-lhwxz is about enabling a CPE device to attach to multiple access network and perform flow manageme…

It's not at all clear that the way the problem is currently framed is even correct.   I am skeptical that this is a flow splitting/flow switching problem.   I agree that if it is, it doesn't belong in MIF.   But I think it's worthwhile to discuss in MIF, and I think it's also germane to what homenet is doing.   If this does actually require flow splitting and/or switching, that's going to have some pretty nasty implications on the home network, so it would be nice to see if there's a better way to approach the problem.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 02:22:39 +0000

Hi Ted,

Having a discussion in MIF WG sounds reasonable to me.

Regarding homenet relation, I'm not sure it belongs to that WG either. The
focus of the homenet is on ingress networks and for realizing simplified
configurations and that has no relation to access selection on egress
paths. FWIW, this work is very much related to what the MIP working group
have been doing for many years. Sure, the device in case of BBF is a fixed
device, but the fundamental requirements are about access selection, flow
mobility and policy exchange. The flow mobility / MCOA work in MIP working
groups have done significant amount of work in this area and the expertise
is in that group.

If the reason for steering this work away from DMM is due the belief that
we will apply only MIP-based solution, I'd say the group will certainly do
that, but the WG may also agree to additional solution/protocol
mechanisms. Also, IETF is in no position to pick one protocol/solution for
this requirement. It is probably reasonable for IETF to identify a set of
solutions and present analysis on each of the solutions and that can be
the basis for the BBF to review and pick one or more solutions. But,
either way I believe the expertise around this topic is in DMM WG and not
in homenet or in MIF WG's.

Regards
Sri

On 11/10/14 5:59 PM, "Ted Lemon" <[email-masked]> wrote:

>> The BBF requirement as presented in the BBF documents and as
>>interpreted in draft-seite and draft-lhwxz is about enabling a CPE
>>device to attach to multiple access network and perform flow management.
>>However, I look at it, I see this this is a mobility requirement and is
>>really not in the scope of MIF WG. The BBF requirement in question is
>>all about flow switching or flow splitting across access systems. I'm
>>not sure why this work belongs MIF and not DMM which is chartered to
>>handle all mobility use-cases. We have discussed this specific use-case
>>of flow splitting during MIF formation and explicitly disallowed MIF WG
>>from taking up such work. The following is the quote from the MIF
>>chartered text. Also, the MIF WG was primarily looking at issues for a
>>host attached to multiple access networks, but the hybrid access is
>>about a CPE attached to multiple networks. I really think this work
>>should be done in DMM and we did present the requirements in the last
>>IETF meeting.
>
>It's not at all clear that the way the problem is currently framed is
>even correct.   I am skeptical that this is a flow splitting/flow
>switching problem.   I agree that if it is, it doesn't belong in MIF.
>But I think it's worthwhile to discuss in MIF, and I think it's also
>germane to what homenet is doing.   If this does actually require flow
>splitting and/or switching, that's going to have some pretty nasty
>implications on the home network, so it would be nice to see if there's a
>better way to approach the problem.
>

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 10 Nov 2014 16:34:57 -1000

Hi Sri,

Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, 
but it doesn't disallow MIF to work on flow split and per packet delivery. This is the key point that PS should explain the clearly.

-Hui

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]] 
Sent: Monday, November 10, 2014 4:23 PM
To: Ted Lemon
Cc: STARK, BARBARA H; Hui Deng; [email-masked]; Brian Haberman; Jouni Korhonen; [email-masked]; Dapeng Liu
Subject: Re: Follow up with BBF proposal

Hi Ted,

Regarding homenet relation, I'm not sure it belongs to that WG either. The focus of the homenet is on ingress networks and for realizing simplified configurations and that has no relation to access selection on egress paths. FWIW, this work is very much related to what the MIP working group have been doing for many years. Sure, the device in case of BBF is a fixed device, but the fundamental requirements are about access selection, flow mobility and policy exchange. The flow mobility / MCOA work in MIP working groups have done significant amount of work in this area and the expertise is in that group.

If the reason for steering this work away from DMM is due the belief that we will apply only MIP-based solution, I'd say the group will certainly do that, but the WG may also agree to additional solution/protocol mechanisms. Also, IETF is in no position to pick one protocol/solution for this requirement. It is probably reasonable for IETF to identify a set of solutions and present analysis on each of the solutions and that can be the basis for the BBF to review and pick one or more solutions. But, either way I believe the expertise around this topic is in DMM WG and not in homenet or in MIF WG's.

Regards
Sri

On 11/10/14 5:59 PM, "Ted Lemon" <[email-masked]> wrote:

>>However, I look at it, I see this this is a mobility requirement and 
>>is really not in the scope of MIF WG. The BBF requirement in question 
>>is all about flow switching or flow splitting across access systems. 
>>I'm not sure why this work belongs MIF and not DMM which is chartered 
>>to handle all mobility use-cases. We have discussed this specific 
>>use-case of flow splitting during MIF formation and explicitly 
>>disallowed MIF WG from taking up such work. The following is the quote 
>>from the MIF chartered text. Also, the MIF WG was primarily looking at 
>>issues for a host attached to multiple access networks, but the hybrid 
>>access is about a CPE attached to multiple networks. I really think 
>>this work should be done in DMM and we did present the requirements in 
>>the last IETF meeting.
>
>implications on the home network, so it would be nice to see if there's 
>a better way to approach the problem.
>

---

From: Alper Yegin <[email-masked]>
Date: Tue, 11 Nov 2014 04:44:41 +0200

MIF focuses on the following issues, and the issue BBF is bringing up is a totally  separate issue.
It's about how two links can be aggregated for capacity and reliability boost.

So, I agree with Sri that this is not a MIF WG issue.

The MIF problem statement document [RFC6418] enumerates the problems into 3 categories:
  1. Lack of consistent and distinctive management of configuration elements, associated with different networks.
  2. Inappropriate mixed use of configuration elements, associated with different networks, in the course of a particular network activity / connection.
  3. Use of a particular network, not consistent with the intent of the scenario / involved parties, leading to connectivity failure and / or other undesired consequences.

Alper

On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote:

> From: Hui Deng <[email-masked]>
> To: Sri Gundavelli <[email-masked]>, 'Xueli' <[email-masked]>, "[email-masked]" <[email-masked]>, 'Ted Lemon' <[email-masked]>, "'STARK, BARBARA H'" <[email-masked]>, 'Alexandru Petrescu' <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Xueli <[email-masked]>
Date: Tue, 11 Nov 2014 03:20:47 +0000

Hello

The MIF charter says like:
" The purpose of the MIF working group is to describe the architecture detailing how devices attach to and operate in multiple networks."
I think my presentation cleanly fits this statement...

Best Regards
XUELI

发件人: mif [mailto:[email-masked]] 代表 Alper Yegin
发送时间: 2014年11月11日 10:45
收件人: Sri Gundavelli
抄送: Brian Haberman; [email-masked]
主题: Re: [mif] Follow up with BBF proposal

The MIF problem statement document [RFC6418<https://tools.ietf.org/html/rfc6418>] enumerates the problems into 3 categories:
  1. Lack of consistent and distinctive management of configuration elements, associated with different networks.
  2. Inappropriate mixed use of configuration elements, associated with different networks, in the course of a particular network activity / connection.
  3. Use of a particular network, not consistent with the intent of the scenario / involved parties, leading to connectivity failure and / or other undesired consequences.

Alper

Hi Hui,

Regards
Sri

Hi everybody

Best regards,

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 11 Nov 2014 05:45:35 +0200

Hi Xueli,

That's one of the general statements in the charter. And it covers so many areas, obviously MIF is not chartered to deal with.
For example, discovery of networks, selection of networks, authentication, accounting, host configuration, traffic management, mobility, etc. etc.
The statements I pulled form the charter pin-points the exact scope of MIF. Anything else is outside the scope, currently.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Nov 2014 17:46:56 -1000

The MIF problem statement describes a particular set of problems on Multiple Interface networks.  If we wrote a problem statement (anywhere in the IETF) for "hybrid access networks", that would be a different problem…  That problem is not covered in any WG's current charter, and it is up to the ADs to decide whether to charter any work related to that problem, and if so where.

In the meantime, would it be possible for us to have a technical discussion of the BBF Hybrid Access problem?  It would be good to discuss what the problem actually is and how existing IETF protocols might apply to that problem.  Ideally we would do this without:  (1) having some unbounded political discussion about where to charter work that we haven't even agreed that we need to do yet, or (2) trying to specify new solutions to the problem, at least until we understand how existing solutions do/don't apply?

Margaret

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 10 Nov 2014 17:52:41 -1000

Hi Alper,

This work hasn’t been clarified where it should belong to, presenting in MIF doesn’t prevent going to any other working group.

Let’s focus on the problem and gap analysis other than where is the place to discuss it.

Thanks

-Hui

From: mif [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Monday, November 10, 2014 5:46 PM
To: Xueli
Cc: Brian Haberman; [email-masked]
Subject: Re: [mif] Follow up with BBF proposal

Hi Xueli,

Alper

Hello

Best Regards

XUELI

The MIF problem statement document [ <https://tools.ietf.org/html/rfc6418> RFC6418] enumerates the problems into 3 categories:

Alper

 

Hi Hui,

 

 

Regards

Sri

Hi everybody

Best regards,

-Hui

---

From: Alper Yegin <[email-masked]>
Date: Tue, 11 Nov 2014 05:59:01 +0200

Sure. 

I was just reacting to the assumption that anything that mentions 2 interfaces automatically falls under the MIF scope :-)
Also, before this work gets on a long journey thru the IETF system, people should be aware that Mobile IP WGs did a lot of work for this space and have solutions.

FYI.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Nov 2014 18:08:37 -1000

Let me see if I can start a technical discussion here...

If you have an ISP today that has two different access networks available, such as one 3GPP network and one DSL network, how do(es) the gateway box(es) (connected to both networks) decide where it should send each packet it receives?  I think there are several possible cases here;

(1) There is one gateway attached to both outbound networks.  This has two sub-cases:

(1.1) Hosts behind the single gateway have separate addresses on the two attached networks.  In that case, the gateway is constrained to send packets over the outgoing network that uses the address prefix that matches the source address, or the packets will be thrown away by ingress filters on the other side.  So, the network choice is made by the hosts.

(1.2) Hosts behind the gateway have only one address each.  This has two sub-cases:

(1.2.1) The gateway has separate addresses on the two networks, and does some sort of translation from internal to external addresses in the prefix of the "right" outgoing link.

(1.2.2) The gateway has only one IP address that is somehow shared across the two links.

(2)  There are two gateways, each attached to a single outbound network.  In this case, hosts will always have separate addresses for the two networks, and will need to make a decision about which outbound network to use. 

Cases 1.1 and 2 are essentially the same from a host standpoint, in that the host needs to make a network choice.  This is a problem we have discussed in MIF -- What sort of information does/should the host need to make that choice, and how is that information communicated to the host?  

Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for multi-homing.  The IETF generally prefers to avoid recommending solutions that use NAT, but do we have a better answer?

Case 1.2.2 becomes a layer 2 problem and is probably outside the scope of the IETF.

Are there cases that I am missing here?

Margaret

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Nov 2014 23:30:14 -0500

> If you have an ISP today that has two different access networks
    > available, such as one 3GPP network and one DSL network, how do(es) the
    > gateway box(es) (connected to both networks) decide where it should
    > send each packet it receives?  I think there are several possible cases
    > here;

These scenarios are all in the homenet architecture document, btw.
Can you tell me if this is IPv4+NAPT or IPv6?  (The IPv4 case without NAPT is
mostly the same as IPv6)

    > (1.2.1) The gateway has separate addresses on the two networks, and
    > does some sort of translation from internal to external addresses in
    > the prefix of the "right" outgoing link.

NAPT.

    > (1.2.2) The gateway has only one IP address that is somehow shared

MPPE or equivalent.

Can you tell me if in your scenarios, the operator of the two access networks
is the same? 

    > (2) There are two gateways, each attached to a single outbound network.
    > In this case, hosts will always have separate addresses for the two
    > networks, and will need to make a decision about which outbound network
    > to use.

As you say, this is a kind of MIF with multi-provisioning domains, and
if the host can decide the right choice of source address, the rest is
"solved" by homenet already.

    > Cases 1.1 and 2 are essentially the same from a host standpoint, in
    > that the host needs to make a network choice.  This is a problem we
    > have discussed in MIF -- What sort of information does/should the host
    > need to make that choice, and how is that information communicated to
    > the host?

Yes, I agree.

    > Case 1.2.1 is a typical case of how NAT (or NPTv6) can be used for
    > multi-homing.  The IETF generally prefers to avoid recommending
    > solutions that use NAT, but do we have a better answer?

    > Are there cases that I am missing here?

I am trying to think whether embedding a second layer of the problem in the
scenario changes anything significantly.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 19:04:04 -1000

> "solved" by homenet already.

Not to rain on your parade, but at the moment with a total of one RFC, homenet isn't solving anything.   Hopefully that will change, but I object to referring to that as a fait accompli.

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Nov 2014 19:43:25 -1000

> (1.1) Hosts behind the single gateway have separate addresses on the two
> attached networks.  In that case, the gateway is constrained to send packets
> over the outgoing network that uses the address prefix that matches the
> source address, or the packets will be thrown away by ingress filters on the
> other side.  So, the network choice is made by the hosts.

I'm not sure this a given.  If both networks are run by the same
operator, it's entirely possible that there might not be any BCP38
internally. (...maybe even desirable?...)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2014 07:19:58 +0100

Le 11/11/2014 04:59, Alper Yegin a écrit :
> Sure.
>
> I was just reacting to the assumption that anything that mentions 2
> interfaces automatically falls under the MIF scope :-)
> Also, before this work gets on a long journey thru the IETF system,
> people should be aware that Mobile IP WGs did a lot of work for this
> space and have solutions.

Sure, but here the reqs are different.

Actually I'd go as far as to say that MIP WG did in the past a lot of 
work without requirements, including the flow-based management schemes.

Alex

>> This work hasn’t been clarified where it should belong to, presenting
>> in MIF doesn’t prevent going to any other working group.
>> *From:*mif [mailto:[email-masked]]*On Behalf Of*Alper Yegin
>> *Sent:*Monday, November 10, 2014 5:46 PM
>> *To:*Xueli
>> *Cc:*Brian Haberman; [email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [mif] Follow up with BBF proposal
>> Hi Xueli,
>> That's one of the general statements in the charter. And it covers so
>> many areas, obviously MIF is not chartered to deal with.
>> For example, discovery of networks, selection of networks,
>> authentication, accounting, host configuration, traffic management,
>> mobility, etc. etc.
>> The statements I pulled form the charter pin-points the exact scope of
>> MIF. Anything else is outside the scope, currently.
>> Alper
>> */"/**/The purpose of the MIF working group is to describe the
>> architecture detailing how devices attach to and operate in multiple
>> networks."
>> /*I think my presentation cleanly fits this statement...
>> Best Regards
>> XUELI
>> *发件人:*mif [mailto:[email-masked]]*代表*Alper Yegin
>> *发送时间:*2014年11月11日10:45
>> *收件人:*Sri Gundavelli
>> *抄送:*Brian Haberman;[email-masked] <mailto:[email-masked]>
>> *主题:*Re: [mif] Follow up with BBF proposal
>> The MIF problem statement document [RFC6418
>> <https://tools.ietf.org/html/rfc6418>] enumerates the problems into 3
>> categories:
>>   1. Lack of consistent and distinctive management of configuration
>> elements, associated with different networks.
>>   2. Inappropriate mixed use of configuration elements, associated
>> with different networks, in the course of a particular network
>> activity / connection.
>>   3. Use of a particular network, not consistent with the intent of
>> the scenario / involved parties, leading to connectivity failure and /
>> or other undesired consequences.
>> Alper
>> device to attach to multiple access network and perform flow
>> management. However, I look at it, I see this this is a mobility
>> requirement and is really not in the scope of MIF WG. The BBF
>> requirement in question is all about flow switching or flow splitting
>> across access systems. I'm not sure why this work belongs MIF and not
>> DMM which is chartered to handle all mobility use-cases. We have
>> discussed this specific use-case of flow splitting during MIF
>> formation and explicitly disallowed MIF WG from taking up such work.
>> The following is the quote from the MIF chartered text. Also, the MIF
>> WG was primarily looking at issues for a host attached to multiple
>> access networks, but the hybrid access is about a CPE attached to
>> multiple networks. I really think this work should be done in DMM and
>> we did present the requirements in the last IETF meeting.
>> *http://datatracker.ietf.org/wg/mif/charter/*
>> *No work will be done to enable traffic flows to move from one
>> interface to another. The group recognizes existing work on mechanisms
>> that require peer or network support for moving traffic flows such as
>> RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile
>> IPv6. This group does not work on or impact such mechanisms. Future
>> work in this area requires rechartering the working group or asking
>> other, specialized working groups (such as DHC or 6MAN) to deal with
>> specific issues.*
>> Regards
>> Sri
>> *From:*Hui Deng <[email-masked] <mailto:[email-masked]>>
>> *Date:*Friday, October 31, 2014 4:50 AM
>> *To:*Sri Gundavelli <[email-masked] <mailto:[email-masked]>>,
>> 'Xueli' <[email-masked] <mailto:[email-masked]>>,
>> "[email-masked] <mailto:[email-masked]>"
>> <[email-masked] <mailto:[email-masked]>>, 'Ted
>> Lemon' <[email-masked] <mailto:[email-masked]>>,
>> "'STARK, BARBARA H'" <[email-masked] <mailto:[email-masked]>>,
>> 'Alexandru Petrescu' <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>> *Subject:*Follow up with BBF proposal
>> Hi everybody
>> to discuss by adding s thelide about how today solutions meet the
>> requirement or there are some gap still, and whether that problem
>> should be solvable in IETF.
>> Chairs will talk with AD whether MIF or somewhere else will consider
>> to discuss those issues during the f2f session.
>> Best regards,
>> -Hui
>> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2014 07:26:25 +0100

Le 11/11/2014 05:08, Margaret Wasserman a écrit :
> gateway box(es) (connected to both networks) decide where it should send
> each packet it receives?  I think there are several possible cases here;
>
> attached networks.  In that case, the gateway is constrained to send
> packets over the outgoing network that uses the address prefix that
> matches the source address, or the packets will be thrown away by
> ingress filters on the other side.  So, the network choice is made by
> the hosts.
>
> (1.2.1) The gateway has separate addresses on the two networks, and does
> some sort of translation from internal to external addresses in the
> prefix of the "right" outgoing link.

I agree with most points above.

> (1.2.2) The gateway has only one IP address that is somehow shared

I think this is hardly possible, in the context of this CPE scenario. 
Even though operators recently are able to control both cellular and DSL 
offerings to end users they really have distinct networks for each. 
'Distinct' in that they are very remote one from another in terms of IP 
hops - makes it hard to have a common IP address shared across two 
egress links of CPE.

Unless of course we speak tunnels.

> networks, and will need to make a decision about which outbound network

This is a difficult case as well but here I think we talk one single CPE 
with multiple egress interfaces.

I think we need to clarify this.

> Cases 1.1 and 2 are essentially the same from a host standpoint, in that
> the host needs to make a network choice.  This is a problem we have
> discussed in MIF -- What sort of information does/should the host need
> to make that choice, and how is that information communicated to the host?

And, alternatively, how does the host make such choices and communicate 
them to the network.

And, alt2, how does the CPE make choices and communicate them to its 
upper gateways.

> solutions that use NAT, but do we have a better answer?

Yes tunnelling.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 09:18:38 +0000

(We have started the technical discussion, but I do want to respond to
this)

Hi Hui,

> Current MIF charter prevent MIF from working on flow switch which is
>mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work
>on flow split and per packet delivery.

You are saying the charter disallows splitting of flows across two access
networks, but it allows splitting of a single flow ? What is the logic
here ?  So, this requirement does not match the prior work because the
flow policy is different ? That's the only reason why we should look at
this as a different problem from the work that was done in the past ?

Per-packet load balancing is probably not explicitly stated as transport
group was never in favor of splitting a single flow across two access
links with different transmission properties (latency, packet loss and
jitter) as that will result in peers requiring to deal with
re-odering/buffering issues.  General recommendation was not to split a
single flow, and so the MIP WG always kept the flow definition at the
granularity of a flow-level and not at a packet level. But, in any case
that's just a policy that is exchanged between two peers.

Regards
Sri

On 11/10/14 6:34 PM, "Hui Deng" <[email-masked]> wrote:

>but it doesn't disallow MIF to work on flow split and per packet
>delivery. This is the key point that PS should explain the clearly.
>
>-Hui
>
>Cc: STARK, BARBARA H; Hui Deng; [email-masked]; Brian Haberman; Jouni
>Korhonen; [email-masked]; Dapeng Liu
>Regarding homenet relation, I'm not sure it belongs to that WG either.
>The focus of the homenet is on ingress networks and for realizing
>simplified configurations and that has no relation to access selection on
>egress paths. FWIW, this work is very much related to what the MIP
>working group have been doing for many years. Sure, the device in case of
>BBF is a fixed device, but the fundamental requirements are about access
>selection, flow mobility and policy exchange. The flow mobility / MCOA
>work in MIP working groups have done significant amount of work in this
>area and the expertise is in that group.
>
>we will apply only MIP-based solution, I'd say the group will certainly
>do that, but the WG may also agree to additional solution/protocol
>mechanisms. Also, IETF is in no position to pick one protocol/solution
>for this requirement. It is probably reasonable for IETF to identify a
>set of solutions and present analysis on each of the solutions and that
>can be the basis for the BBF to review and pick one or more solutions.
>But, either way I believe the expertise around this topic is in DMM WG
>and not in homenet or in MIF WG's.
>
>Regards
>Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 09:18:44 +0000

> If you have an ISP today that has two different access networks available, such as one 3GPP network and one DSL network, how do(es) the gateway box(es) (connected to both networks) decide where it…

The IP address/prefix that is given to the  PDN connection of the mobile node  is topologically anchored on the PGW  and the IP traffic that is routed on the 3GPP link is ONLY the traffic using the source address/prefixes associated with that PDN connection. All the functions in the 3GPP network including QoS, charging ..etc is only for that IP address/prefix.

For the case where the mobile node is a mobile router, we have specified support for prefix delegation in 3GPP Rel-12, where the mobile router can obtain a set of delegated prefixes for its ingress networks. But even those delegated prefixes and the IP address/prefix on the primary PDN connection MUST be part of a single aggregate block and that aggregate block is again topologically anchored on the PGW. So, the IP traffic that is routed and seen on the 3GPP link is only the traffic associated with that PDN connection.

For all other cases such as where the IP prefixes in the ingress network behind the mobile router not belonging to the 3GPP network,  either those packets must NAT/PAT translated, or carried over an overlay tunnel  (GRE/UDP) path. In the later case the ingress prefixes are hidden from the transport network and so the 3GPP network does not care about those prefixes. It never sees them.

Now, if we map this to NEMO use-case, it is exactly the case of a mobile router connected to two access networks; The ingress prefixes behind the mobile router are prefixes anchored on the mobility anchor (HA/LMA/PGW) and the traffic from the ingress network is tunneled to the anchor. An overlay tunnel path is set up between the MR and the HA and the overlay topology is hidden from the transport network.

Please see inline

Regards
Sri

From: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 10, 2014 8:08 PM
To: "[email-masked]<mailto:[email-masked]> List" <[email-masked]<mailto:[email-masked]>>
Subject: [mif] Hybrid Access Problem

[Sri] Not sure, I followed the below conclusions or the assumptions. But, I will try.

[Sri] Ok

[Sri] Hosts can have addresses belonging to the access network, or they can be from the anchor in the home network. For the later case, there can be an overlay topology. The gateway can potentially tunnel the packet to an anchor (Ex: BNG) and in that case the ingress side network prefixes are hidden from the transport network.

[Sri] The gateway can include multiple prefixes in the RA sent on the ingress link and so the hosts CAN have multiple IP addresses/prefixes.

[Sri] Translation is one option for the case where the addresses are private address relevant only on that link. Tunneling is another option when the addresses belong to a remote gateway. There is also the third option, where the ingress prefixes are from the access network and there is normal routing.

[Sri] Not sure, how its possible. The IP address given for the LTE connection cannot be the  IP address given on the DSL link. The connection is tied to a IMSI and that cannot be on two different gateways.

[Sri] Not sure, how the host with a single interface is attached to two gateways simultaneously ? Is the host again another router ?

[Sri] This is nothing to with the host. Its about the addressing and the ownership of the addressing that is enabled on that link. This is a network decision and not  a host decision.

[Sri] NAT is an option, but there are other modes.

  1.  Allocate prefixes from a remote anchor and set up tunneling to that anchor
  2.  Enable routing for the ingress prefixes in the transport network; Make them routable in the transport network (Ex: Rel-12 3GPP PD Work).

[Sri] Not sure I agree with the conclusions.

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 09:31:46 +0000

Typo .. Read Rel-10 .not Rel-12 …

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 11, 2014 1:18 AM
To: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> List" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mif] Hybrid Access Problem

Please see inline

Regards
Sri

[Sri] Ok

Margaret

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 10 Nov 2014 23:46:34 -1000

Hi Sri,

Inline ==> please, trimed.

>mostly mobile ip/dmm based solution, but it doesn't disallow MIF to 
>work on flow split and per packet delivery.

You are saying the charter disallows splitting of flows across two access networks, but it allows splitting of a single flow ? What is the logic here ?  So, this requirement does not match the prior work because the flow policy is different ? That's the only reason why we should look at this as a different problem from the work that was done in the past ?
==> MIF was chartered to avoid the duplicate work with Mobile IP/DMM stuff, the work is outside of Mobile IP/DMM could be done by anywhere including MIF which is decided by AD, does this make sense?

Per-packet load balancing is probably not explicitly stated as transport group was never in favor of splitting a single flow across two access links with different transmission properties (latency, packet loss and
jitter) as that will result in peers requiring to deal with re-odering/buffering issues.  General recommendation was not to split a single flow, and so the MIP WG always kept the flow definition at the granularity of a flow-level and not at a packet level. But, in any case that's just a policy that is exchanged between two peers.
==>We will see what's the requirement from BBF, and could that be allowed to be done by IETF.

Thanks for the discussion

-Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Nov 2014 17:07:23 +0100

Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a écrit :
> granularity of a flow-level and not at a packet level.

That was then.

Again, the MIP work with flows has nothing to do with what we try do here.

When the transport are tells problems may arise with reordering it's 
because the MIP WG did not reply that (1) applications may deal with 
reordering and (2) the HA may deal with reordering.

Also, transport area may be well aware that this kind of per-packet 
splitting across links happens on a routinely at intermediary routers: 
two successive traceroutes rarely show same sequence.

Alex

  But, in any case
>> mostly mobile ip/dmm based solution,

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Nov 2014 19:22:08 +0000

Sure. Applications can deal with it, or they may suffer. Traffic load balancing in internet has always been there. But, there is a fundamental difference between splitting a flow between two redundant paths connected over high-speed links in the internet core, to splitting the same flow across two access two access-links to which a mobile node is attached. Can we split a audio flow on satellite access and DSL link and say its an application problem ? Is it not a network design problem and should it not be avoided ?

> Again, the MIP work with flows has nothing to do with what we try do here.

Please state some technical reasons.

What we did in the past is the following.

Application

Preferred Access Type

Second Preference

Third Preference

HTTP

BLUE

RED

<DROP>

IPSec

RED

BLUE

<DROP>

SSH

<DROP>

 <DROP>

-

SIP / RTP

BLUE

<DROP>

<DROP>

1.) Ability to allow a mobile router to perform connection management;

- Single Access Attach – Attach to the "best" available access network
- Multi Access Attach – Attach to all available access networks

2.) Ability for the mobile router to register multiple care-of address with the anchor (MCOA Work which we did for 3 years)

3.)  Ability to request IPv4 and/or IPv6 mobile network prefixes for the ingress network from the anchor

4.) Ability to establish multiple tunnel paths to the anchor to realize multi-path overlay topology from the mobile network to the anchor; So, to realize a bigger data pipe for the traffic associated with the mobile network prefixes

5.) Ability to negotiate a traffic flow policy on application basis;  Most preferred access to least preferred access on application basis and ability switch the flows based on the path availability

6.) Ability to perform heart-beats for path management and to re-evaluate the flow policy

7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile networks

8.) Ability to perform NAT translation on the "transport" network

9.) The anchor that is here is the HA/LMA/BNG/PGW/ which is used in Wi-Fi, LTE and Cable MSO accounts is the subscriber management function. There is charging, policy, infrastructure that is supported and deployed in todays networks.

Now, if I fix the MR and nail the MR to a wall, what aspects of the above do not work ? Can the MR cannot be a CPE in home with LTE and DOCSIS access ? What is missing here ?  Is it the per-packet load balancing ? Is there any thing more ?

--> If you can summarize your answer for the above 9 points and just state it below it will help.

Regards
Sri

On 11/11/14 8:07 AM, "Alexandru Petrescu" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hui,

That was then.

Alex

  But, in any case

Regards
Sri

On 11/10/14 6:34 PM, "Hui Deng" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sri,

-Hui

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Monday, November 10, 2014 4:23 PM
To: Ted Lemon
Cc: STARK, BARBARA H; Hui Deng; [email-masked]<mailto:[email-masked]>; Brian Haberman; Jouni
Korhonen; [email-masked]<mailto:[email-masked]>; Dapeng Liu
Subject: Re: Follow up with BBF proposal

Hi Ted,

Regards
Sri

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Nov 2014 14:39:34 -0500

Ted Lemon <[email-masked]> wrote:
    mcr> As you say, this is a kind of MIF with multi-provisioning domains, and
    mcr> if the host can decide the right choice of source address, the rest is
    mcr> "solved" by homenet already.

    > Not to rain on your parade, but at the moment with a total of one RFC,
    > homenet isn't solving anything.  Hopefully that will change, but I
    > object to referring to that as a fait accompli.

Well, there is the air-quotes around "solved".

The situation is that the problem of picking the right exit router given
source IP is well explained in homenet, I think that there is running code
that implements if automatically, and we have documents that explain how to
do things in various stages of preperation..  They could probably be WG LC'ed
almost immediately.

So while perhaps homenet is lost; it seems that the AD for Homenet and MIF
ought to be able to clearly say which WG should solve this problem, if it
makes sense that it should be solved only once.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Nov 2014 10:14:14 -1000

On Nov 11, 2014, at 9:22 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> Can we split a audio flow on satellite access and DSL link and say its an application problem ? Is it not a network design problem and should it not be avoided ?

This is precisely why I question whether the proposed architecture is actually the right thing.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Nov 2014 17:32:14 -0600

On Mon, Nov 10, 2014 at 10:08 PM, Margaret Wasserman
<[email-masked]> wrote:
> If you have an ISP today that has two different access networks available,
> such as one 3GPP network and one DSL network, how do(es) the gateway box(es)
> (connected to both networks) decide where it should send each packet it
> receives?  I think there are several possible cases here;
>

This case is not valid because both attached networks belong to the
same operator. Also the hosts do not get separate addresses from the
attached networks, I think.

> some sort of translation from internal to external addresses in the prefix
> of the "right" outgoing link.
>

Yes, I think this is the case.

> (2)  There are two gateways, each attached to a single outbound network.  In
> this case, hosts will always have separate addresses for the two networks,
> and will need to make a decision about which outbound network to use.
>
> Cases 1.1 and 2 are essentially the same from a host standpoint, in that the
> host needs to make a network choice.  This is a problem we have discussed in
> MIF -- What sort of information does/should the host need to make that
> choice, and how is that information communicated to the host?
>
> multi-homing.  The IETF generally prefers to avoid recommending solutions
> that use NAT, but do we have a better answer?
>

This could be the case.

I want to also say here that CPE here is not a mobile router.
There might be mobile routers that are connected to two networks but
not in this case, I think.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Nov 2014 06:12:12 +0100

Le 11/11/2014 21:14, Ted Lemon a écrit :
>> Can we split a audio flow on satellite access and DSL link and say
>> its an application problem ?

HEre we talk DSL and cellular (not satellite).  The link characteristics 
are very different.

>> Is it not a network design problem and should it not be avoided ?

As long as an IP addressing architecture is designed to deal with it ok 
it is not something to be avoided.

Is multihoming something to be avoided?

> is actually the right thing.

Well, I dont know which part of the architecture is under doubt, but the 
presentation tomorrow will clarify maybe some parts of it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Nov 2014 06:32:37 +0100

Le 11/11/2014 20:22, Sri Gundavelli (sgundave) a écrit :
> *Sure. Applications can deal with it, or they may suffer. Traffic load
> balancing in internet has always been there. But, there is a fundamental
> difference between splitting a flow between two redundant paths
> connected over high-speed links in the internet core, to splitting the
> same flow across two access two access-links to which a mobile node is
> attached. Can we split a audio flow on satellite access and DSL link and
> say its an application problem ? Is it not a network design problem and
> should it not be avoided ?*
>
>
> *Please state some technical reasons.*

Where should I start?  Which (P)MIP document should I talk about?
(for reminder, please see our discussion in MIP4 about this a few years 
back)

> *What we did in the past is the following.*

[bitmap diagram of MR and HA skipped]

That figure is good on paper, but it does not augment bandwidth by 
itself.  It's just a way to show that both MR's connections are up at 
the same time.  They are not used to augment bandwidth.  There's only 
one default route that is used and it points to only one tunnel 
interface which in turn is bound to one single physical interface. 
Incoming packets may arrive on both interfaces but outgoing packets only 
go one interface.

I guess transport area will not be happy either to know that for one 
single application the outgoing packets always take a different path 
that incoming packets - assymmetry.

> *1.) Ability to allow a mobile router to perform connection management;*
> *
> *
> *- Single Access Attach – Attach to the "best" available access network*

I agree this is a feature and is highly needed for mobiles.  But 'best' 
means 'best first L2 hop' actually.

Here we talk a different thing.

> *- Multi Access Attach – Attach to all available access networks*

'Attach' is one thing, 'use' is another thing.

A mobile may be attached by many interfaces at the same time (ppp up, 
eth0 up, iwconfig up - all up) but the default route points to only one 
tunnel interface which in turn is linked to only one physical interface. 
  That's where bandwidth augmentation is not present.

> *2.) Ability for the mobile router to register multiple care-of address
> with the anchor (MCOA Work which we did for 3 years) *

Yes, but that's just registering the addresses.  It doesnt tell how to 
augment bandwidth, how to use simultaneously several such interfaces.

> *3.)  Ability to request IPv4 and/or IPv6 mobile network prefixes for
> the ingress network from the anchor*

Yes.

> *4.) Ability to establish multiple tunnel paths to the anchor to realize
> multi-path overlay topology from the mobile network to the anchor; So,
> to realize a bigger data pipe for the traffic associated with the mobile
> network prefixes*

No, that 'so' is your 'so'.  There is no implementation that exhibits 
that bigger data pipe.

> *5.) Ability to negotiate a traffic flow policy on application basis;
>   Most preferred access to least preferred access on application basis
> and ability switch the flows based on the path availability*

No, MIP has no ability to exchange such flow policy.

> *6.) Ability to perform heart-beats for path management and to
> re-evaluate the flow policy*

Sorry - which heartbeats?  There are no heartbeats in MIP.

> *7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile
> networks*

What do you mean by 'mobile network'?

> *8.) Ability to perform NAT translation on the "transport" network*

I dont know what NAT translation means.

> *
> *
> *9.) The anchor that is here is the HA/LMA/BNG/PGW/ which is used in
> Wi-Fi, LTE and Cable MSO accounts is the subscriber management function.
> There is charging, policy, infrastructure that is supported and deployed
> in todays networks.*

Sri - I disagree.  Neither PMIP nor MIP are used in these networks.  I 
dont know why you claim so.

> *Now, if I fix the MR and nail the MR to a wall, what aspects of the
> above do not work ? Can the MR cannot be a CPE in home with LTE and
> DOCSIS access ? **What is missing here ?  Is it the per-packet load
> balancing ? Is there any thing more ?*

Yes.

> *--> If you can summarize your answer for the above 9 points and just
> state it below it will help. *

Sri - you posted a feature list which is vaguely related to a list of 
RFCs.  It is a commercial advertisement for one particular router platform.

We can talk commercial advertisements if you wish, I have another such 
feature list ready to post.

Alex

>
>
>
>
> Regards
> Sri
>
>
>
> On 11/11/14 8:07 AM, "Alexandru Petrescu" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             Cc: STARK, BARBARA H; Hui Deng; [email-masked]
>             <mailto:[email-masked]>; Brian Haberman; Jouni
>             Korhonen; [email-masked]
>             <mailto:[email-masked]>; Dapeng Liu

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 13:19:58 +0000

Hi Alex,

Actually, IMHO, BBF and NEMO use-cases have similar requirements. In “Hybrid Access for Broadband Networks” (quoting the BBF liaison), the CPE is attached to multiple access networks (e.g. DSL, LTE); and the terminal is connected to the CPE via a single interface (i.e. ingress interface), e.g. Wi-Fi . The problem is to distribute the traffic on the different access networks, but we do not touch the terminal; and there should be no specific requirement on the home network. Traffic distribution schemes can be done either on a packet basis or on an IP flow basis, which is typically an IP flow mobility use-case. So, IMU, the "hybrid access" use-case  is a multihomed mobile router scenario, as described in RFC 4980.

Anyway, as you said, it is worth to remind that a lot of work has been done in the past, regarding IP flow management, of course, but even with respect to the BBF use-case: RFC 4908 (Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO)).

BR,
Pierrick

>-----Message d'origine-----
>De : mif [mailto:[email-masked]] De la part de Alexandru Petrescu
>Envoyé : mardi 11 novembre 2014 07:20
>À : Alper Yegin; Hui Deng
>Cc : 'Brian Haberman'; [email-masked]
>Objet : Re: [mif] Follow up with BBF proposal
>
>> interfaces automatically falls under the MIF scope :-) Also, before
>> this work gets on a long journey thru the IETF system, people should
>> be aware that Mobile IP WGs did a lot of work for this space and have
>> solutions.
>
>Actually I'd go as far as to say that MIP WG did in the past a lot of work without
>requirements, including the flow-based management schemes.
>
>Alex
>
>
>>
>> FYI.
>>
>> Alper
>>
>>
>>
>>
>>
>>
>>> *Sent:*Monday, November 10, 2014 5:46 PM *To:*Xueli *Cc:*Brian
>>> Haberman; [email-masked] <mailto:[email-masked]>
>>> *Subject:*Re: [mif] Follow up with BBF proposal Hi Xueli, That's one
>>> of the general statements in the charter. And it covers so many
>>> areas, obviously MIF is not chartered to deal with.
>>> The statements I pulled form the charter pin-points the exact scope
>>> of MIF. Anything else is outside the scope, currently.
>>> Alper
>>> *主题:*Re: [mif] Follow up with BBF proposal MIF focuses on the
>>> following issues, and the issue BBF is bringing up is a totally
>>> separate issue.
>>> the scenario / involved parties, leading to connectivity failure and
>>> / or other undesired consequences.
>>> Alper
>>> interface to another. The group recognizes existing work on
>>> mechanisms that require peer or network support for moving traffic
>>> flows such as RFC 5206, RFC 4980 and the use of multiple care-of
>>> addresses in Mobile IPv6. This group does not work on or impact such
>>> mechanisms. Future work in this area requires rechartering the
>>> working group or asking other, specialized working groups (such as
>>> DHC or 6MAN) to deal with specific issues.* Regards Sri *From:*Hui
>>> Deng <[email-masked] <mailto:[email-masked]>>
>>> *Date:*Friday, October 31, 2014 4:50 AM *To:*Sri Gundavelli
>>> <[email-masked] <mailto:[email-masked]>>, 'Xueli'
>>> <[email-masked] <mailto:[email-masked]>>,
>>> <mailto:[email-masked]>> *Subject:*Follow up with BBF proposal Hi
>>> everybody I am recommending that Xue Li could help to put down the
>>> slide for the problem statement from BBF.
>>> And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly
>>> to meet together during IETF meeting to discuss by adding s thelide
>>> about how today solutions meet the requirement or there are some gap
>>> still, and whether that problem should be solvable in IETF.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 17:26:11 +0000

Hi,

>De : mif [mailto:[email-masked]] De la part de Behcet Sarikaya
>Envoyé : mercredi 12 novembre 2014 00:32
>À : Margaret Wasserman
>Cc : [email-masked] List
>Objet : Re: [mif] Hybrid Access Problem
>
>> If you have an ISP today 

"today" is the keyword here. I'll try to clarify what we can do, today, to meet the BBF requirement on "hybrid access"

that has two different access networks
>> available, such as one 3GPP network and one DSL network, how do(es)
>> the gateway box(es) (connected to both networks) decide where it
>> should send each packet it receives?  I think there are several
>> possible cases here;
>>
>> (1) There is one gateway 

Ok, let's talk about CPE here to avoid confusion with a traffic anchoring gateway (e.g. P-GW, Broadband Network Gateway (BNG), or even, "aggregation gateway", which is sometimes used in some hybrid access architecture)

attached to both outbound networks.  This has
>> two
>> sub-cases:
>>
>> (1.1) Hosts behind the single gateway have separate addresses on the
>> two attached networks.  In that case, the gateway is constrained to
>> send packets over the outgoing network that uses the address prefix
>> that matches the source address, or the packets will be thrown away by
>> ingress filters on the other side.  So, the network choice is made by the
>hosts.
>>
>
>This case is not valid because both attached networks belong to the same
>operator. Also the hosts do not get separate addresses from the attached
>networks, I think.
>

Actually, this is a valid use-case. The point is not to know if access networks are operated but how the addresses, on the egress interface of the CPE, are allocated. Sri has well explained this on a previous email. Taking the example of 4G cellular and DSL egress interfaces, the CPE obtains addresses/prefix on both the cellular and the DSL accesses, respectively topically anchored at the PGW and the BNG. Then these prefixes are delegated to the host, possibly with prefix coloring information.
Then, the host can select the source IP address according the network selected (e.g depending on the application, the host may select a specific egress interface). This behavior should rely on advanced source address selection mechanisms, that are not available today (AFAIK). So, today, most hybrid access implementations are going for the approach described in 1.2.1 case.

>> (1.2) Hosts behind the gateway have only one address each.  This has
>> two
>> sub-cases:
>>

Exactly, this is what we have today with IPv4; NPTv6 would allow same behavior on IPv6 network

>> (1.2.2) The gateway has only one IP address that is somehow shared

Exactly. This scenario has been discussed in 3GPP, relying on PMIP (RFC5213) to share a same IP address, or prefix, across more the egress interfaces of the CPE.

>> (2)  There are two gateways, each attached to a single outbound
>> network.  In this case, hosts will always have separate addresses for
>> the two networks, and will need to make a decision about which outbound
>network to use.
>>

This is a valid use-case, but it does not meet the BBF requirement. Only CPE with more than one outbound interfaces (e.g. LTE, DSL) is in the scope of the BBF liaison, i.e. only case 1).

>> that the host needs to make a network choice.  

Exactly. Basically we have two scenarios regarding traffic steering decision: it is either the host or the CPE which makes the decision to forward the traffic on the most appropriate egress interface. Today, BBF puts the decision making process on the CPE.

This is a problem we
>> need to make that choice, and how is that information communicated to the
>host?
>>

This is what it is implemented with IPv4, and, today, we do not have better answer for IPv6.

>There might be mobile routers that are connected to two networks but not in
>this case, I think.
>

I'm not sure to understand this. Multihomed CPE is a router with more than one egress interfaces and the problem is to distribute the traffic over these interfaces; this is one of the scenarios that NEMO protocol can address...

>> Case 1.2.2 becomes a layer 2 problem and is probably outside the scope

Actually, case 1.2.2 is not necessarily a L2 problem, this is typically a PMIP uses-case where a host (here a CPE) obtains the same IP address/prefix while connecting to different access networks

Pierrick

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2014 13:24:44 -0600

> Then, the host can select the source IP address according the network selected (e.g depending on the application, the host may select a specific egress interface). This behavior should rely on adva…

[behcet] eNodeB sees CPE as a UE. For CPE, the address/prefix it gets
is just another interface for the WAN side.
I don't agree with the delegation part. If that were the case, you
mean that the host must be SHIM-aware?

> Exactly. This scenario has been discussed in 3GPP, relying on PMIP (RFC5213) to share a same IP address, or prefix, across more the egress interfaces of the CPE.

[behcet] Where is 3GPP? To my knowledge BBF hybrid access has not yet
reached 3GPP.

> I'm not sure to understand this. Multihomed CPE is a router with more than one egress interfaces and the problem is to distribute the traffic over these interfaces; this is one of the scenarios tha…

[behcet] Well, this reminds me the hammer and nail story.
Sorry no offence to anyone.

Regards,

Behcet