Subject: FW: [offline] [netlmm] Conclusion of the discussion so far... Multihoming withPMIP

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Oct 2007 20:30:13 -0500

Hi George,
Please see some question/comment inline.

Regards,
Ahmad
 
> 
> I agree there has been significant progress and the two solutions on 
> the table are in fact fairly close to each other. At this point IMO 
> the two solutions have one issue that creates some uncertainty and one

> important difference.
> 
> 1) The Issue generating uncertainty:
> 
> 	- Editing team's solution requires the LMA to know via "policy"
> whether the same prefix can be allocated to two different access 
> technology interfaces.
> 
> 	- Christian's solution requires the MAG to somehow know the
Interface 
> ID of a Virtual Interface.
> 
> It is clear that how such thing can be known is outside the scope of 
> the base specification and at this point in time there is some 
> uncertainty about whether and when the IETF will provide solutions to 
> these issues.
> It is, however, reasonable and realistic that other organizations 
> (3GPP,
> 3GPP2 etc) can define how these issues can be solved within their own 
> systems.
> 
> IMHO, the two solutions require equivalent amount of work outside the 
> base specification to make PMIP work for inter-technology handoffs.
> 
> 2) The important difference
> 
> 	- Editing team's solution differentiates between access
technologies.
> 	- Christian's solution differentiates between Interfaces.
> 
> The difference between the two can be seen as a granularity 
> difference.
> 
> The Interface model normally recognizes individual physical 
> interfaces.
> It then allows for such physical interfaces to be explicitly grouped 
> under a Virtual Interface, for the purposes of inter-technology 
> handoff.
> 
> The access technology model, only recognizes access type. The obvious 
> and undeniable issue with this approach is that two physical 
> interfaces of the same access type can not be differentiated between 
> and are recognized as the same thing.
> 
> So, a host with two interfaces of the same type, attached to the same 
> PMIP domain is guarantied to face the multi-homing issues we are 
> trying to resolve with this discussion. This is clearly not the case 
> in the interface model, and for this reason the interface model is a 
> superior and more generic solution.

[Ahmad]
What kind of access technology we are talking about here?

Do you have an example of certain deployment where (a generic and an
existing IPv6 host) has more than one interface using the same access
technology?

If that example exist what is the possibility for this host to use the
same PMIPv6 domain and land on the same LMA using two different MAGs?

A real example may help me understand the issue you are trying to solve.

> 
> 
> Conclusion
> ----------
> Given the clear advantage of the per interface model and the fact that

> both solutions have similar level of uncertainty and work to be done, 
> either in IETF or other SDOs, I do not understand how the Editing 
> team's solution can be justified.

[Ahmad]
We can talk about the conclusion after understanding the real example
you will provide me.
I mean, of course, your assumption leads to your above conclusion.

Many thanks in advance.

Regards,
Ahmad

> 
> Best Regards
> George
> -----Original Message-----
> From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]]
> Sent: Friday, October 12, 2007 6:50 AM
> To: 'NetLMM Mailing List'
> Subject: [netlmm] Conclusion of the discussion so far... 
> Multihoming withPMIP
> 
> <Chair hat on>
> Everybody,
> 
> We have come a long way since last week. Last week our discussion was 
> about deciding if we should handle the issue of multihoming by leaving

> it out of scope or not. However, this week we have concentrated on the

> discussion, how to solve the issue in the document. So, I believe that

> we are in a totally different situation than we were a week ago: We 
> have reached consensus to solve the multihoming issue in the document 
> - now the discussion is just about what is the technical solution to 
> solve the issue.
> 
> It seems that the solution has converged into two solutions:
> 
> (These solutions are listed in the order of proposal)
> 
> 1) The editing team of the PMIP base spec have proposed text to the 
> document for a way forward 
> (http://www1.ietf.org/mail-archive/web/netlmm/current/msg03756.html),
> and
> further modified it with (
> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03863.html).
> 
> 2) Christian proposed a different solution 
> (http://www1.ietf.org/mail-archive/web/netlmm/current/msg03764.html),
> which
> has also gotten support on the list.
> 
> On both solutions pros and cons have been stated, and it is clear that

> through e-mail discussion a consensus cannot be reached anymore.
> 
> We have to now find a way forward as this seems to be one of the few 
> remaining issues on the draft. I will talk to the people involved to 
> find out if a solution can be found, or if we would have to go to a 
> consensus call on the topic.
> 
> I will get back to the list with a way forward on Friday evening.
> 
> I hope this helps.
> 
> Cheers,
> 
> Jonne.  
> --
> Jonne Soininen
> Nokia Siemens Networks
> 
> Tel: +358 40 527 46 34
> E-mail: [email-masked]
> 
> 
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 12 Oct 2007 22:54:16 +1000

Hi Ahmad, 

George might have a different opinion, but I think his analysis was solid
and I want to comment on your comment below. 

 > A real example may help me understand the issue you are 

=> I think it's a valid question. Of course we know that load sharing is
common in ethernet-type networks for busy servers ...etc. So the concept of
having two interfaces of the same technology is not really science fiction.
A more realistic example could be a busy mobile router on a plane or train.
One cellular technology, one identity, but two interfaces. 
But there is a much more important issue here. Your question of giving an
example to justify a scenario, while valid, is really only relevant when you
have several approaches that require different amounts of cost/effort to
deploy and you're trying to narrow down scenarios to choose the cheapest
one. But when you have two approaches, that cost the same, but one is more
generic and cleaner (cleansiness comes from being able to abstract the
problem and therefore solve more scenarios), the question becomes
irrelevant. In other words, nothing is gained by giving such example, which
after all, only represents what we know at this very second and does not
allow for new products/ideas that may come up two hours from now :). Does
that make sense? 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Oct 2007 19:11:57 -0700

Hesham Soliman wrote:

> common in ethernet-type networks for busy servers ...etc. 

How is this relevant?

> So the concept of

This is not an unmodified host. Typically this is done by binding
the two interfaces together into one interface, using concepts
like Linux port bonding. The IP stacks see only one interface.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Oct 2007 21:24:05 -0500

Hi Hesham,

Thanks! makes a lot of sense, but please take a look below.

Regards,
Ahmad

> 
> Hi Ahmad, 
> 
> George might have a different opinion, but I think his 
> analysis was solid and I want to comment on your comment below. 
> 
> 
> 
>  > > So, a host with two interfaces of the same type, 
> attached  > to the same  > > PMIP domain is guarantied to 
> face the multi-homing issues we are  > > trying to resolve 
> with this discussion. This is clearly  > not the case  > > in 
> the interface model, and for this reason the interface  > 
> model is a  > > superior and more generic solution.
>  >
>  >
>  > [Ahmad]
>  > Do you have an example of certain deployment where (a 
> generic and an  > existing IPv6 host) has more than one 
> interface using the same access  > technology?
>  >
>  > If that example exist what is the possibility for this 
> host  > to use the  > same PMIPv6 domain and land on the same 
> LMA using two different MAGs?
>  >
>  > A real example may help me understand the issue you are  > 
> trying to solve.
> 
> => I think it's a valid question. Of course we know that load 
> sharing is common in ethernet-type networks for busy servers 
> ...etc. So the concept of having two interfaces of the same 
> technology is not really science fiction.

[Ahmad]
Sure, but we need to have a real example that is applicable to the case
at hand.

> One cellular technology, one identity, but two interfaces.

[Ahmad]
Although, I do not want to argue otherwise, but how does this is used in
connection with PMIPv6?
As a matter of fact, I would imagine that each of these interfaces
should work as a separate MAG or separate routers rather than a single
interface. In other words, which more realistic? to design PMIPv6 to
adopt to this scenario or to configure this Airplane with separate
MN-IDs per interface? 
 
> But there is a much more important issue here. Your question 
> of giving an example to justify a scenario, while valid, is 
> really only relevant when you have several approaches that 
> require different amounts of cost/effort to deploy and you're 
> trying to narrow down scenarios to choose the cheapest one. 
> But when you have two approaches, that cost the same, but one 
> is more generic and cleaner (cleansiness comes from being 
> able to abstract the problem and therefore solve more 
> scenarios), the question becomes irrelevant. In other words, 
> nothing is gained by giving such example, 

[Ahmad]
Sorry Hesham; I have to disagree here. No one claimed that we are going
to design a protocol that will fits every imagination of every single
person on the face of the earth. Right? That may work in the ART world
but in real stuff, we are always limited. If we would like to do that,
guess what we will be discussing a similar issue for PMIPv6 two years
from today?

> which after all, 
> only represents what we know at this very second and does not 
> allow for new products/ideas that may come up two hours from 
> now :). Does that make sense? 

[Ahmad]
Absolutely makes a lot of sense. Now my question is why do you think
that the provided solution is limited and is not forward compatible to
address the scenario you have in mind. I believe there are multiple ways
to extend the protocol to address the train scenario, the simplest one
is to configure each interface with different IDs. Makes sense?

> 
> Hesham
> 
>  > 
>  >   
>  > >
>  > >
>  > > Conclusion
>  > > ----------
>  > > Given the clear advantage of the per interface model and 
>  > the fact that  >  > > both solutions have similar level of 
> uncertainty and work  > to be done,  > > either in IETF or 
> other SDOs, I do not understand how the Editing  > > team's 
> solution can be justified.
>  >
>  > [Ahmad]
>  > We can talk about the conclusion after understanding the 
> real example  > you will provide me.0
>  > > From: Soininen Jonne (NSN FI/Espoo) 
> [mailto:[email-masked]]  > > Sent: Friday, October 
> 12, 2007 6:50 AM  > > To: 'NetLMM Mailing List'
>  > > We have come a long way since last week. Last week our  
> > discussion was  > > about deciding if we should handle the 
> issue of  > multihoming by leaving  >  > > it out of scope or 
> not. However, this week we have  > concentrated on the  >  > 
> > discussion, how to solve the issue in the document. So, I  
> > believe that  >  > > we are in a totally different 
> situation than we were a  > week ago: We  > > have reached 
> consensus to solve the multihoming issue in  > the document  
> > > - now the discussion is just about what is the technical  
> > solution to  > > solve the issue.
>  > >
>  > > (These solutions are listed in the order of proposal)  > 
> >  > > 1) The editing team of the PMIP base spec have 
> proposed  > text to the  > > document for a way forward  > >  
> > 
>  > > 2) Christian proposed a different solution  > >  > 
>  > > On both solutions pros and cons have been stated, and it 
>  > is clear that  >  > > through e-mail discussion a 
> consensus cannot be reached anymore.
>  > >
>  > > We have to now find a way forward as this seems to be 
> one  > of the few  > > remaining issues on the draft. I will 
> talk to the people  > involved to  > > find out if a solution 
> can be found, or if we would have  > to go to a  > >

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 12 Oct 2007 23:25:35 +1000

> > common in ethernet-type networks for busy servers ...etc. 

=> If you read the whole paragraph you see the relevance.

 > like Linux port bonding. The IP stacks see only one interface.

=> This is an implementation choice. It's a v4 legacy that some people
choose to use a loopback interface to implement this type of multihoming.
But again, since we moved into v6, where multihoming is there by default,
this isn't needed. I think a lot of people are confused about what they want
because they think v4. I'll say it again, the real question, which you
avoided in my paragrpah is whether one should choose the more flexible
solution or not. I know if I have the option of buying one of two routers,
same brand, cost, but one of them supports more features then I'll buy that
one. It seems to me like you'd buy the one with less features because you
and Sri think you'll never need the extra features. Of course once you
realise you might need the extra feature you'll be sorry for that choice. 

Hesham

 > >  > the fact that
 > [mailto:[email-masked]]
 > >  > discussion was 
 > >  > believe that
 > >  > solution to 
 > >  > is clear that

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 12 Oct 2007 23:37:17 +1000

> Sure, but we need to have a real example that is applicable 

=> Only if it saves money or effort. Otherwise, the time we spend making up
examples, which can always be refuted is a waste. 

 > adopt to this scenario or to configure this Airplane with separate

=> I don't want to get to what you prefer Vs what I prefer because we just
can't limit people to deploy or develop products to our preferred
configuration. My personal preference is to use MIPv6, but I realise that
some people want PMIP6. Anyway, the question about connecting to different
MAGs is not correct, typically you only have access to one BS due to
physical/geographic deployment restrictions. Multiple interfaces does not
mean multiple access routers. 

 > guess what we will be discussing a similar issue for PMIPv6 two years

=> You're taking my comment to an extreme, which distorts what I'm saying.
I'm talking about this single issue. We have two options, one supports more
scenarios for no extra cost, why should we even consider the other one? You
have 10000 dollars to buy a car, and you have a choice between a 1990 BMW
and a 2005 BMW same condition, which one will you get? Will you buy the 1990
one because you think you can't think of a use case for a fancy car? If
that's your choice then I have a car to sell you :) 

 > address the scenario you have in mind. 

=> Becuase it's more abstract. In protocol design and SW development, if you
abstract the problem, for the same cost, then you've done something really
useful. It's pretty straight forward. The only reasons people restrict the
problem is cost and complexity. 

Hesham

I believe there are 
 > multiple ways

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Oct 2007 22:23:25 -0500

Hi Hesham,
Please see comments inline.

>  >
>  > [Ahmad]
>  > Sure, but we need to have a real example that is 
> applicable  > to the case  > at hand.
> 
> => Only if it saves money or effort. Otherwise, the time we 
> spend making up examples, which can always be refuted is a waste. 

[Ahmad]
>From business prospective, I disagree. 
I would call that a valuable and real investment:-) That is why billions
of $$$ spent every year on R&D. right?
We are eventually supposed to make money by applying such solution on
these scenarios. No?

> 
>  >
>  > > A more realistic example could be a busy mobile router 
> on a  > > plane or train.
>  > Although, I do not want to argue otherwise, but how does  
> > this is used in  > connection with PMIPv6?
>  > As a matter of fact, I would imagine that each of these 
> interfaces  > should work as a separate MAG or separate 
> routers rather  > than a single  > interface. In other words, 
> which more realistic? to design PMIPv6 to  > adopt to this 
> scenario or to configure this Airplane with separate  > 
> MN-IDs per interface? 
> 
> => I don't want to get to what you prefer Vs what I prefer 
> because we just can't limit people to deploy or develop 
> products to our preferred configuration. My personal 
> preference is to use MIPv6, but I realise that some people 
> want PMIP6.
 
[Ahmad]
Excellent, from business fairness prospective, let those who prefer MIP6
to deploy MIP6 and those who would like to deploy PMIP6 deploy PMIP6. I
do not see why the MIP6 camp would like to complicate the PMIP6 solution
to address unknown scenarios?

> Anyway, the question about connecting to 
> different MAGs is not correct, typically you only have access 
> to one BS due to physical/geographic deployment restrictions. 
> Multiple interfaces does not mean multiple access routers.

[Ahmad]
Further information to prove that this scenario is not applicable to
PMIP6. right? I thought that we are talking about P-to-P link. No?
 
> 
>  > > But there is a much more important issue here. Your 
> question  > > of giving an example to justify a scenario, 
> while valid, is  > > really only relevant when you have 
> several approaches that  > > require different amounts of 
> cost/effort to deploy and you're  > > trying to narrow down 
> scenarios to choose the cheapest one. 
>  > > But when you have two approaches, that cost the same, 
> but one  > > is more generic and cleaner (cleansiness comes 
> from being  > > able to abstract the problem and therefore 
> solve more  > > scenarios), the question becomes irrelevant. 
> In other words,  > > nothing is gained by giving such 
> example,  >  > [Ahmad]  > Sorry Hesham; I have to disagree 
> here. No one claimed that  > we are going  > to design a 
> protocol that will fits every imagination of every single  > 
> person on the face of the earth. Right? That may work in the  
> > ART world  > but in real stuff, we are always limited. If 
> we would like  > to do that,  > guess what we will be 
> discussing a similar issue for PMIPv6 two years  > from today?
> 

[Ahmad]
My apologies Hesham, I did not mean that.

> I'm talking about this single issue. We have two options, one 
> supports more scenarios for no extra cost, why should we even 
> consider the other one? You have 10000 dollars to buy a car, 
> and you have a choice between a 1990 BMW and a 2005 BMW same 
> condition, which one will you get? Will you buy the 1990 one 
> because you think you can't think of a use case for a fancy 
> car? If that's your choice then I have a car to sell you :)

[Ahmad]
Hesham, I just would like to modify your above example slightly to be
applicable to the case we have at hand.

Sure you have the 2005 BMW BUT what I have is a 2007 RAMSEES which looks
like a 1990 BMW and function as your 2005 BMW. However, the 2005 BMW is
a high maintenance car with very limited spare parts that only available
at the corner store:-), on the other hand, the 2007 RAMSEES is very
reliable and brings you money day-in-and-day-out by NOT spending your
money on that high maintenance 2005.

Which one do you think I should BUY, I am getting the 2007 RAMSEES with
the 2005 performance:-))))
Now, I realized that it is 5:15 am here in Munich and tomorrow is EID
day here; Eid Mubarak Hesham:-)

> 
>  > > which after all,
>  > > only represents what we know at this very second and 
> does not  > > allow for new products/ideas that may come up 
> two hours from  > > now :). Does that make sense? 
>  >
>  > [Ahmad]
>  > Absolutely makes a lot of sense. Now my question is why do 
> you think  > that the provided solution is limited and is not 
> forward  > compatible to  > address the scenario you have in mind. 
> 
> => Becuase it's more abstract. In protocol design and SW 
> development, if you abstract the problem, for the same cost, 
> then you've done something really useful. It's pretty 
> straight forward. The only reasons people restrict the 

[Ahmad]
No one is restricting the solution, on the contrary, we would like to
have a solution that is forward compatible which can address all Mobile
Nodes, I mean ,MNs, deployments. In case we need to address mobile
routers, we may as well address it as an extension later on. Is there
any of these airplane routers SDOs who are waiting for PMIP6?
 
> 
> Hesham
> 
> I believe there are
>  > multiple ways
>  > to extend the protocol to address the train scenario, the  
> > simplest one  > is to configure each interface with 
> different IDs. Makes sense?
>  >
>  >
>  > >
>  > > Hesham
>  > >
>  > >  > 
>  > >  >   
>  > >  > >
>  > >  > >
>  > >  > > Conclusion
>  > >  > > ----------
>  > >  > > Given the clear advantage of the per interface 
> model and  > >  > the fact that  >  > > both solutions have 
> similar level of  > > uncertainty and work  > to be done,  > 
> > either in IETF or  > > other SDOs, I do not understand how 
> the Editing  > > team's  > > solution can be justified.
>  > >  >
>  > >  > [Ahmad]
>  > >  > We can talk about the conclusion after understanding 
> the  > > real example  > you will provide me.0  > >  > I 
> mean, of course, your assumption leads to your above  > conclusion.
>  > >  >
>  > >  > Many thanks in advance.
>  > >  >
>  > >  > Regards,
>  > >  > Ahmad
>  > >  >
>  > >  > >
>  > >  > > Best Regards
>  > >  > > George
>  > >  > > From: Soininen Jonne (NSN FI/Espoo)  > > 
> [mailto:[email-masked]]  > > Sent: Friday, October  > 
>  > >  > > We have come a long way since last week. Last week 
> our  > > > discussion was  > > about deciding if we should 
> handle the  > > issue of  > multihoming by leaving  >  > > it 
> out of scope or  > > not. However, this week we have  > 
> concentrated on the  >  >  > > > discussion, how to solve the 
> issue in the document. So, I  > > > believe that  >  > > we 
> are in a totally different  > > situation than we were a  > 
> week ago: We  > > have reached  > > consensus to solve the 
> multihoming issue in  > the document  > > > > - now the 
> discussion is just about what is the technical  > > > 
>  > >  > > (These solutions are listed in the order of 
> proposal)  >  > > >  > > 1) The editing team of the PMIP base 
> spec have  > > proposed  > text to the  > > document for a 
> way forward  > >  > > >  > >  > 
>  > >  > > On both solutions pros and cons have been stated, 
> and it  > >  > is clear that  >  > > through e-mail 
> discussion a  > > consensus cannot be reached anymore.
>  > >  > >
>  > >  > > We have to now find a way forward as this seems to 
> be  > > one  > of the few  > > remaining issues on the draft. 
> I will  > > talk to the people  > involved to  > > find out 
> if a solution  > > can be found, or if we would have  > to go 
> to a  > >  > > consensus call on the topic.
>  > >  > >
>  > >  > > E-mail: [email-masked]  > >  > >  > >  > >  
> > >  > >  > >  > >  > >  > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Oct 2007 21:12:11 -0700

> realise you might need the extra feature you'll be sorry for that choice. 

This discussion needs some beer. Not in the mood otherwise. :)

Vijay

>  > question of giving an
>  > the real example