Subject: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 5 Nov 2008 18:27:49 -0800

All,
The consensus call for the open issue of PMIP6-MIP6 interactions for the colocated LMA-HA scenario (Scenario C in draft-ietf-netlmm-mip-interactions-00) has concluded.  Jonne and I have reviewed all the emails from both attempts of the consensus call on the list.  Taking the Dublin discussions and the emails into account, we do have rough consensus to move forward with logically separate BCEs for PMIP6 and MIP6 bindings and forwarding always using the MIP6 BCE and only using the PMIP6 BCE when there is no MIP6 BCE.  

Authors, please submit a revised draft to reflect this.  We can discuss any other open topics at Minneapolis and get further reviews on the document to move forward. 

Thanks,
Vidya
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 6 Nov 2008 11:29:26 -0500

Vidya, Jonne,

I object to this. There was absolutely no consensus on this for you guys
to decide. There were clarifying questions that people had on what
exactly you meant by multi-homing. You didn't respond to any of those
emails.

There are also some unanswered questions on single radio handovers and
the mobile node having to indicate to the HA that it would like to be
connected via the home link and the visited link using the MCoA
questions. 

This is not acceptable.

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Wednesday, November 05, 2008 6:28 PM
> To: [email-masked]
> Subject: [netlmm] Conclusion and way forward for PMIP6-MIP6 
> interactions
> 
> All,
> The consensus call for the open issue of PMIP6-MIP6 
> interactions for the colocated LMA-HA scenario (Scenario C in 
> draft-ietf-netlmm-mip-interactions-00) has concluded.  Jonne 
> and I have reviewed all the emails from both attempts of the 
> consensus call on the list.  Taking the Dublin discussions 
> and the emails into account, we do have rough consensus to 
> move forward with logically separate BCEs for PMIP6 and MIP6 
> bindings and forwarding always using the MIP6 BCE and only 
> using the PMIP6 BCE when there is no MIP6 BCE.  
> 
> Authors, please submit a revised draft to reflect this.  We 
> can discuss any other open topics at Minneapolis and get 
> further reviews on the document to move forward. 
> 
> Thanks,
> Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 13:30:58 -0600

Hi Vidya,

Just a clarification question:

On 11/5/08 8:27 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> All,
> The consensus call for the open issue of PMIP6-MIP6 interactions for the
> colocated LMA-HA scenario (Scenario C in
> draft-ietf-netlmm-mip-interactions-00) has concluded.  Jonne and I have
> reviewed all the emails from both attempts of the consensus call on the list.
> Taking the Dublin discussions and the emails into account, we do have rough
> consensus to move forward with logically separate BCEs for PMIP6 and MIP6
> bindings and forwarding always using the MIP6 BCE and only using the PMIP6 BCE
> when there is no MIP6 BCE.

If the MIP6 BCE and the PMIP6 BCE exist for an MN, the DL packet sent to the
MN is processed by the MIP6 BCE first and forwarded thru the corresponding
CoA only if the destination address matches the /128 address. If it does not
match the PMIP6 BCE is used to forward the packet to the MN. Do you agree?

-Raj

> 
> Authors, please submit a revised draft to reflect this.  We can discuss any
> other open topics at Minneapolis and get further reviews on the document to
> move forward. 
> 
> Thanks,
> Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 6 Nov 2008 11:39:01 -0800

Hi Raj,

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 11:31 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] Conclusion and way forward for 
> PMIP6-MIP6 interactions
> 
> 
> Hi Vidya,
> 
> interactions for 
> > the colocated LMA-HA scenario (Scenario C in
> > draft-ietf-netlmm-mip-interactions-00) has concluded.  Jonne and I 
> > have reviewed all the emails from both attempts of the 
> consensus call on the list.
> > Taking the Dublin discussions and the emails into account, 
> we do have 
> > rough consensus to move forward with logically separate 
> BCEs for PMIP6 
> > and MIP6 bindings and forwarding always using the MIP6 BCE and only 
> If the MIP6 BCE and the PMIP6 BCE exist for an MN, the DL 
> packet sent to the MN is processed by the MIP6 BCE first and 
> forwarded thru the corresponding CoA only if the destination 
> address matches the /128 address. If it does not match the 
> PMIP6 BCE is used to forward the packet to the MN. Do you agree?
> 

Yes, I believe this is true, unless the MN was using NEMO and had the 'R' bit set in the MIP6 BU, in which case, the match for the MIP6 BCE is not just on the /128 address. 

Thanks,
Vidya

> -Raj
> 
> > 
> > Authors, please submit a revised draft to reflect this.  We can 
> > discuss any other open topics at Minneapolis and get 
> further reviews

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 6 Nov 2008 12:07:36 -0800

Vijay,
There have been clarifications already on the list that any and all multihoming scenarios that are feasible without PMIP6 should be feasible with PMIP6.  So, there is no need to explicitly define all possibilities here.  We already went through that exercise during the multihoming discussions on the base PMIP6 document.  

We have also clarified that we cannot assume SDO-specific scenarios or solutions in making our decisions here.  So, we cannot design specifically for single radio handovers and such.  

Again, we have reviewed all the technical points raised and followed all the discussion.  Technically, it seems to need workarounds and new functionality to allow normal multihoming scenarios to work with keeping a singe BCE and forwarding using the most recently updated BCE.  We also have many people believing that the shortcomings raised about keeping separate BCEs and forwarding using the MIP6 BCE first, followed by the PMIP6 BCE are less problematic and it natively allows any kind of multihoming to be done. 

Overall, in our judgment, we do have rough consensus to move on here.  I am hoping that you can work with WG consensus and move forward.    

Thanks,
Vidya 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 8:29 AM
> Cc: Jari Arkko
> Subject: RE: [netlmm] Conclusion and way forward for 
> PMIP6-MIP6 interactions
> 
> Vidya, Jonne,
> 
> I object to this. There was absolutely no consensus on this 
> for you guys to decide. There were clarifying questions that 
> people had on what exactly you meant by multi-homing. You 
> didn't respond to any of those emails.
> 
> There are also some unanswered questions on single radio 
> handovers and the mobile node having to indicate to the HA 
> that it would like to be connected via the home link and the 
> visited link using the MCoA questions. 
> 
> This is not acceptable.
> 
> Vijay
> 
> 
> consensus call 
> > on the list.  Taking the Dublin discussions and the emails into 
> > account, we do have rough consensus to move forward with logically 
> > separate BCEs for PMIP6 and MIP6 bindings and forwarding 
> always using 
> > the MIP6 BCE and only using the PMIP6 BCE when there is no MIP6 BCE.
> >

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 07 Nov 2008 17:39:18 +0200

Vijay and everybody else,

Just for the record, this decision was done by the chairs together, and this
was our reading both during the discussion in the meeting in Dublin, and at
this discussion here.

Remember, rough consensus does not mean that everybody has to agree. It
means roughly the WG agrees. I agree the decision is not based on unanimous
agreement in the WG. However, we do believe rough consensus is there.

Cheers,

Jonne.

On 11/6/08 10:07 PM, "Vidya Narayanan" <[email-masked]> wrote:

> Vijay,
> There have been clarifications already on the list that any and all
> multihoming scenarios that are feasible without PMIP6 should be feasible with
> PMIP6.  So, there is no need to explicitly define all possibilities here.  We
> already went through that exercise during the multihoming discussions on the
> base PMIP6 document.
> 
> We have also clarified that we cannot assume SDO-specific scenarios or
> solutions in making our decisions here.  So, we cannot design specifically for
> single radio handovers and such.
> 
> Again, we have reviewed all the technical points raised and followed all the
> discussion.  Technically, it seems to need workarounds and new functionality
> to allow normal multihoming scenarios to work with keeping a singe BCE and
> forwarding using the most recently updated BCE.  We also have many people
> believing that the shortcomings raised about keeping separate BCEs and
> forwarding using the MIP6 BCE first, followed by the PMIP6 BCE are less
> problematic and it natively allows any kind of multihoming to be done.
> 
> Overall, in our judgment, we do have rough consensus to move on here.  I am
> hoping that you can work with WG consensus and move forward.
> 
> Thanks,
> Vidya 
> 

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 7 Nov 2008 13:22:59 -0500

Raj,

The destination address on the DL packet would be a 128-bit address. So
it will always hit the MIPv6 BCE. There won't be a case where the MIPv6
BCE is skipped and the PMIPv6 BCE is used, if the MIPv6 BCE is given the
preference.

Even though the MIPv6 BCE has the 128-bit address and the PMIPv6 BCE has
the 64-bit HNP, the home address used by the mobile node is the same
irrespective of whether it is attached to the PMIPv6 domain or outside
the PMIPv6 domain.

Vijay

[email-masked] wrote:
>> The consensus call for the open issue of PMIP6-MIP6 interactions for
>> have reviewed all the emails from both attempts of the consensus
>> call on the list. Taking the Dublin discussions and the emails into
>> separate BCEs for PMIP6 and MIP6 bindings and forwarding always
>> using the MIP6 BCE and only using the PMIP6 BCE when there is no
>> MIP6 BCE. 
> 
> If the MIP6 BCE and the PMIP6 BCE exist for an MN, the DL packet sent
> to the MN is processed by the MIP6 BCE first and forwarded thru the
> corresponding CoA only if the destination address matches the /128
> address. If it does not match the PMIP6 BCE is used to forward the
> packet to the MN. Do you agree? 
> 
> -Raj
> 
>> 
>> discuss any other open topics at Minneapolis and get further reviews
>> on the document to move forward. 
>> 
>> Thanks,
>> Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 12:37:59 -0600

Vijay,

An MN which is assigned a /64 HNP can use essentially any address that it
may configure from that prefix via the PMIP6 domain. However the MN will use
only the HoA registered with the HA for the interface which is using MIP6.
So there could be multiple sessions, some which use the /128 HoA that is in
the BCE of the HA and others that fall within the HNP assigned by the LMA.
Hence it is not the case that all traffic is only via the MIP6 HoA in such a
scenario. 

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 7 Nov 2008 13:42:32 -0500

Basavaraj Patil wrote:
> Vijay,
> 
> An MN which is assigned a /64 HNP can use essentially any address
> that it may configure from that prefix via the PMIP6 domain. 

If the MN is using different 128-bit address while in the PMIPv6 domain
and outside the PMIPv6 domain, then we are *NOT* talking about scenario
C at all. There is no session continuity for the mobile node anymore.

> However
> the MN will use only the HoA registered with the HA for the interface
> which is using MIP6. So there could be multiple sessions, some which
> use the /128 HoA that is in the BCE of the HA and others that fall
> within the HNP assigned by the LMA. Hence it is not the case that all
> traffic is only via the MIP6 HoA in such a scenario.

Please take a look at Scenario C description in section 3 in
draft-ietf-netlmm-mip-interactions-00.txt. 

Vijay

>> The destination address on the DL packet would be a 128-bit address.
>> So it will always hit the MIPv6 BCE. There won't be a case where the
>> MIPv6 BCE is skipped and the PMIPv6 BCE is used, if the MIPv6 BCE is
>> given the preference. 
>> 
>> Even though the MIPv6 BCE has the 128-bit address and the PMIPv6 BCE
>> has the 64-bit HNP, the home address used by the mobile node is the
>> same irrespective of whether it is attached to the PMIPv6 domain or
>> outside the PMIPv6 domain. 
>> 
>> Vijay
>> 
>>>> The consensus call for the open issue of PMIP6-MIP6 interactions
>>>> for the colocated LMA-HA scenario (Scenario C in
>>> If the MIP6 BCE and the PMIP6 BCE exist for an MN, the DL packet
>>> sent to the MN is processed by the MIP6 BCE first and forwarded
>>> thru the corresponding CoA only if the destination address matches
>>> the /128 address. If it does not match the PMIP6 BCE is used to
>>> forward the packet to the MN. Do you agree?
>>> 
>>> -Raj
>>> 
>>>> 
>>>> discuss any other open topics at Minneapolis and get further
>>>> reviews on the document to move forward.
>>>> 
>>>> Thanks,
>>>> Vidya

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 7 Nov 2008 10:47:28 -0800

This is valid for plain MIPv6. If NEMO extensions are used and implicit mode is assumed, the MIPv6/NEMO BCE may not be only for the /128 but for the entire HNP.

However in general I agree with Raj and these two cases will be captured in the I-D.

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Basavaraj Patil
> Sent: Friday, November 07, 2008 10:38 AM
> To: ext Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions
> 
> 
> Vijay,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 12:56:21 -0600

My comment was not specific to Scenario C. It was for the general case where
we have two BCEs. 

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 07 Nov 2008 11:38:25 -0800

Hi Vidya, Jonne,

For a mobile node that has two interfaces and wants to use both 
interfaces, while using the same home address across the two interfaces, 
we need some extensions. Mobile IPv6 [RFC 3775] does not allow a mobile 
node to use both the home link and the visited link simultaneously when 
the mobile node has only one home address.

For the home agent to allow the mobile node to use both the home link 
and the visited link, we need the MCoA extensions. Specifically, the 
mobile node must indicate to the home agent that it wants to do so.

It doesn't matter if the home link is provided by PMIPv6, GTP or direct 
attachment to the home link, the above is valid.

Instead, what I see being designed is a solution where the GTP/PMIPv6 
process on the GGSN/LMA/HA entity maintains state that is independent of 
the HA process on the same GGSN/LMA/HA entity. In fact what you are 
trying to force through consensus here, i.e., keep the MIPv6 and PMIPv6 
BCE separate is actually influenced by an SDO-specific scenario. I 
believe there is a scenario in 3GPP where folks wanted the mobile node 
to be able to keep its GPRS/UMTS interface up, while using another 
interface like WiFi, so that it can quickly fall back to the GRPS/UMTS 
interface, when it loses WiFi access. And you are saying, we shouldn't 
consider SDO-specific scenarios. When you said that, my initial reaction 
was "you gotta be kidding me". :)

I am not saying the above is not a valid scenario. Lets support it, but 
in the right away, by an explicit indication from the mobile node to the 
home agent that it does want to use the home link and the visited link 
at the same time. This would allow the GGSN/LMA/HA entity maintain 
forwarding state for both the home link and the visited link at the same 
time. This would work irrespective of how the home link is created.

As for the consensus call that you and Jonne started last week, I 
maintain that were was absolutely no consensus. I think four people 
spoke in favor of keeping the binding cache entries separate. There were 
lot more people, either asking for clarifications, or opposing it. I 
would like to know how you arrived at the consensus.

Lastly, we do need to consider the single radio handover in the 
PMIPv6-MIPv6 interactions document. I don't understand how you can 
declare that out-of-scope.

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 7 Nov 2008 14:48:21 -0500

Hello Vidya,

I am sorry, but I thought the discussion was either incomplete or did
not steer towards one particular way or the other. For instance, I
didn't get a clear answer for my question on why there would be a single
BCE when two different interfaces are in use. Could you please clarify? 

Thanks,

-Rajeev

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Narayanan, Vidya
interactions
> The consensus call for the open issue of PMIP6-MIP6 interactions for
the
> colocated LMA-HA scenario (Scenario C in draft-ietf-netlmm-mip-
> interactions-00) has concluded.  Jonne and I have reviewed all the
emails
> from both attempts of the consensus call on the list.  Taking the
Dublin
> discussions and the emails into account, we do have rough consensus to
> move forward with logically separate BCEs for PMIP6 and MIP6 bindings
and
> forwarding always using the MIP6 BCE and only using the PMIP6 BCE when
> there is no MIP6 BCE.
> 
discuss
> any other open topics at Minneapolis and get further reviews on the
> document to move forward.
> 
> Thanks,
> Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 11:50:24 -0800 (PST)

I agree. We need to discuss this further. I dont think
we have consensus either way. As some one says, 5 to 4
or 5 to 3 does not reflect consensus. Lets keep the
discussion open. Lets attempt to resolve this and not
rush either way.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 15:35:10 -0600

<ccing MEXT because I think the MCoA discussion has relevance there>

Hi Vijay,

On 11/7/08 1:38 PM, "ext Vijay Devarapalli" <[email-masked]> wrote:

> and the visited link, we need the MCoA extensions.

The MCoA extension allows the MN to register multiple CoAs associated with
the same HoA. The scenario where the MN is on its home link as a virtue of
PMIP6 on one interface and continues to be on a foreign link on another IMO
are not captured. Sec 5.6.  Returning Home: Simultaneous Home and Visited
Link Operation of I-D: draft-ietf-monami6-multiplecoa does provide some
guidelines but given that the PMIP6 aspect is not covered, it may be
worthwhile to revisit the issue.

> Specifically, the

Agree. But this is specified in the MCoA I-D, right?

> attachment to the home link, the above is valid.

In the case of PMIP6, there is a BCE for the MN in the LMA, unlike the MIP6
case where the MN returns home and the BCE is deleted.

> BCE separate is actually influenced by an SDO-specific scenario.

While an SDO has an interest in keeping the BCEs separate, why would the
same not apply in general as well? Given the scenario, I do think that
having separate BCEs is the correct approach.

> I 

And what is wrong with such a scenario and for the WG to address it. Because
the scenario is not SDO specific.

> time. This would work irrespective of how the home link is created.

Good. As I said it may be worthwhile to add the PMIP6 created home link
scenario to the MCoA I-D.

> declare that out-of-scope.

The concept of single radio is not applicable in the context of IETF IMO. A
host may be able to use multiple interfaces simultaneously. If we go down
the path where we start discussing why the host may not be able to do so, we
are essentially getting down in to the details of PHY/MAC issues,
interference, spectrums that the interfaces may be operating in, and many
other issues. This is not in the domain of the IETF WGs. It is better to
define optimizations for handovers which do not necessarily assume too much
about whether the underlying interfaces operate (connect/attach)
simultaneously or otherwise.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 7 Nov 2008 13:45:27 -0800

Hi Rajeev,

> From: Koodli, Rajeev [mailto:[email-masked]] 
> Sent: Friday, November 07, 2008 11:48 AM
> I am sorry, but I thought the discussion was either 
> incomplete or did not steer towards one particular way or the 
> other. 

<WG Chair hat on>
Sorry, in taking all the emails and the Dublin discussions into account, the chairs do see rough consensus.  Also, we cannot indefinitely keep an issue open.  As I said in my second call for consensus, if this call did not result in rough consensus, Jonne and I would have had to discuss with Jari and come up with a way forward based on the technical points.  It so happens that we do have rough consensus when considering all the input received.  As Jonne said, rough consensus does not amount to unanimous consensus and unfortunately, we still have a few people that disagree.  But, we do believe we have enough to move forward here. 
</WG Chair hat on>

> For instance, I didn't get a clear answer for my 
> question on why there would be a single BCE when two 
> different interfaces are in use. Could you please clarify? 

<no hats on>

The discussion has been generally on PMIP6-MIP6 interworking, regardless of the actual interfaces involved.  As some have pointed out, it also doesn't even matter if we are dealing with virtual or physical interfaces, etc.  When using MIP6, an MN may decide to use MCoAs to keep multiple interfaces active.  However, the addition of one of the interfaces may trigger a PMIP6 BCE, since that interface attached to a PMIP6 domain that happens to be the MN's MIP6 home network.  Hence, this does still map to the discussion of handling PMIP6 and MIP6 with logically the same vs. separate BCEs.  In such a case, with the logically same BCE, it is possible that the PBU replaces the existing MIP6 binding, where, the MN's BU is to imply registration of an additional interface.   

Regards,
Vidya

> This email and any attachments may contain legally privileged 
> and/or confidential information of Starent Networks, Corp. 
> and is intended only for the individual or entity named in 
> the message.  The information transmitted may not be used to 
> create or change any contractual obligations of Starent 
> Networks, Corp.  Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon this 
> e-mail and its attachments by persons or entities other than 
> the intended recipient is prohibited. If you are not the 
> intended recipient, please notify the sender immediately -- 
> by replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 07 Nov 2008 13:48:09 -0800

> worthwhile to revisit the issue.

This was brought up during the AD review of the MCoA draft. It shouldn't 
matter if the home link is created by the MN attaching directly to the 
home agent or by GTP or PMIPv6. The MCoA extensions can be used. The 
plan is to add some text on this.

> case where the MN returns home and the BCE is deleted.

In the simultaneous home and visited link attachment, there is a binding 
for the home link too.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 07 Nov 2008 13:52:18 -0800

> simultaneously or otherwise.

Disagree. If you have an inter-access technology handover between two 
interfaces that use similar radio technology, then it is very important 
to consider a single radio handover. And this is the case in some of the 
deployments being considered in the near time.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 15:58:59 -0600

Vijay,

On 11/7/08 3:52 PM, "ext Vijay Devarapalli" <[email-masked]> wrote:

> to consider a single radio handover.

Not true. Similar radio technology has no implication on whether both radios
can work simultaneously. There are other factors but not because two
radios/interfaces use the same radio technology. But the point is that the
issues related to what radios can work simultaneously or not is outside the
scope of the IETF. 

-Raj

> And this is the case in some of the

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2008 14:46:19 -0800 (PST)

Dear Vidya,
  I reallly don't know if there was consensus, rough or strong. What I would like to point out is if we can come up with any IOT test case which would enable us to test one way or another. How would you design a test case to see if some LMA is sharing BCE with HA? How would you design a test case to see which BCE is used first?
  Otherwise I think we should not care.

Regards,

Behcet

________________________________
From: "Narayanan, Vidya" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, November 6, 2008 2:07:36 PM
Subject: Re: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions

Vijay,

Thanks,
Vidya

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Nov 2008 17:33:29 -0600

Hi Gerardo,
Just as a clarification. Please see inline.

Regards,
Ahmad
 
> This is valid for plain MIPv6. 
[Ahmad]
What is a plain MIPv6?

> If NEMO extensions are used 
> and implicit mode is assumed, the MIPv6/NEMO BCE may not be 
> only for the /128 but for the entire HNP.

[Ahmad]
I have a hard time following the logic here. What does it mean for the
entire HNP? And how that differs from the case of MIP6/PMIPv6 BCE for
example?

> > Behalf Of Basavaraj Patil
> > An MN which is assigned a /64 HNP can use essentially any 
> address that 
> > it may configure from that prefix via the PMIP6 domain. 
> However the MN 
> > will use only the HoA registered with the HA for the 
> interface which is using MIP6.
> > So there could be multiple sessions, some which use the 
> /128 HoA that 
> > is in the BCE of the HA and others that fall within the HNP 
> assigned by the LMA.
> > Hence it is not the case that all traffic is only via the 
> MIP6 HoA in 
> > such a scenario.
> > 
> > -Raj
> > 
> > 
> consensus 
> > >>> call on the list. Taking the Dublin discussions and the emails 
> > >>> into account, we do have rough consensus to move forward with 
> > >>> logically separate BCEs for PMIP6 and MIP6 bindings and 
> forwarding 
> > >>> always using the MIP6 BCE and only using the PMIP6 BCE 
> when there 
> > >>> is no
> > >>> MIP6 BCE.
> > >>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 7 Nov 2008 16:23:35 -0800

Hi Ahmad,

the point is the following:

- if MIPv6 per RFC3775 is used, the BCE will contain routing state for the HoA only (/128). The BCE created by PMIPv6 will contain routing state for the entire /64 HNP. Therefore a packet destined to the HoA will match both BCE; the consensus is to process the packet based on the MIPv6 BCE. Packets which match the PMIPv6 BCE but not the MIPv6 BCE will be processed based on the PMIPv6 BCE. This is Raj's point.

- if NEMO extensions are used as per RFC 3963 and the implicit mode is used, the MIPv6/NEMO BCE will contian routing state for the /64 HNP in case the HA is configured in that way for the implicit mode. In this case the overlapping between the MIPv6/NEMO and PMIPv6 BCEs is complete. All packets destined to any address of the HNP will be processed based on the MIPv6/NEMO BCE.

I hope this clarifies.

Thanks
Gerardo

________________________________________
From: Ahmad Muhanna [[email-masked]]
Sent: Friday, November 07, 2008 3:33 PM
To: Giaretta, Gerardo; Basavaraj Patil; ext Vijay Devarapalli
Cc: [email-masked]
Subject: RE: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions

Hi Gerardo,

Regards,
Ahmad

[Ahmad]
What is a plain MIPv6?

[Ahmad]

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 7 Nov 2008 16:28:39 -0800

I fully agree with Raj on this aspect. The solution must be independent if the MN has one or more radio technology as this may not be known by the IP layer. This is a basic principle of IETF protocols. 

A part form that, there is still not any technical motivation described in this list why the solution for which we have consensus is not good enough for single radio devices. 

Please let's move on.

Gerardo

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Basavaraj Patil [[email-masked]]
Sent: Friday, November 07, 2008 1:58 PM
To: ext Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions

Vijay,

-Raj