Subject: [MEXT] draft-ng-intarea-tunnel-loop

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Nov 2008 07:31:08 -0800 (PST)

Dear all,
  This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext.
  Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link.
  MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching  HAs sequentially. MCoA draft also assumes a single HA serving all interfaces.
  MN should not send BUs at the home link. The problem here is how does MN know it is at the home link? I think this was discussed when mext was first formed. I don't remember the conclusion.
  I found a typo: D in PDN and PDG should stand for Data.

Regards,

Behcet

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

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 14 Nov 2008 11:05:31 +0800

Hi Behcet,
 
Thanks for reading draft. Please see reply in-line.
 
BR,
Mohana

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Behcet Sarikaya
	Sent: Thursday, November 13, 2008 11:31 PM
	To: [email-masked]
	Subject: [MEXT] draft-ng-intarea-tunnel-loop

	Dear all,
	  This draft will be presented in Mext next week. Although the
solution is int-area issue but the PS belongs to mext.
	  Two example scenarios are presented in Sec. 1.2 which make up
the problem statement. In the first scenario, there is the issue of two
HAs simultaneously serving MN and MN sending BUs at the home link. In
the second scenario, the issue is MN sending BU at the home link. 
	In both the scenarios decsribed in the draft, the MN is not
attached to its home link. If it is attached to home-link then it will
not send binding updates. In the first scenario the tunnel loop is
created betwee two of its HAs and in the second scenario, more of a 3GPP
scenario
	where tunnel loop is created between ePDG and P-GW/HA.  
	  MIPv6 and DSMIPv6 are not designed to handle multiple HAs
serving simultaneously. RFC 5142 handles MN switching  HAs sequentially.
MCoA draft also assumes a single HA serving all interfaces.
	  MN should not send BUs at the home link. The problem here is
how does MN know it is at the home link? 
	  I am not sure why you want to verify that this is home-link.
The UE sees an address that is not its home address. Thus, it will know
that 
	this is not home-link and can send BU. 
	  I think this was discussed when mext was first formed. I don't
remember the conclusion.
	  I found a typo: D in PDN and PDG should stand for Data. 
	Thanks for pointing out. Yes we will make the relevant changes
in future revisions. 
	
	Regards,
	
	Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Nov 2008 07:28:23 -0800 (PST)

Hi Mohana,

  Please see inline.

Regards,

Behcet

________________________________
From: Mohana Jeyatharan <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; [email-masked]
Sent: Thursday, November 13, 2008 9:05:31 PM
Subject: RE: [MEXT] draft-ng-intarea-tunnel-loop

Hi Behcet,
 
Thanks for reading draft. Please see reply 
in-line.
 
BR,
Mohana

________________________________
 From: [email-masked]  [mailto:[email-masked]] On Behalf Of Behcet  Sarikaya
Sent: Thursday, November 13, 2008 11:31 PM
To: [email-masked]
Subject: [MEXT]  draft-ng-intarea-tunnel-loop

Dear all,
  This draft will be presented in Mext next week.  Although the solution is int-area issue but the PS belongs to mext.
   Two example scenarios are presented in Sec. 1.2 which make up the problem  statement. In the first scenario, there is the issue of two HAs simultaneously  serving MN and MN sending BUs at the home link. In the second scenario, the  issue is MN sending BU at the home link. 
In  both the scenarios decsribed in the draft, the MN is not attached to its home  link. If it is attached to home-link then it will not send binding  updates. In the first scenario the tunnel loop is created betwee  two of its HAs and in the second scenario, more of a 3GPP  scenario
where tunnel loop is created between ePDG and P-GW/HA.  
  MIPv6 and DSMIPv6 are not designed to handle  multiple HAs serving simultaneously. RFC 5142 handles MN switching  HAs  sequentially. MCoA draft also assumes a single HA serving all  interfaces.
  MN should not send BUs at the home link. The problem  here is how does MN know it is at the home link? 
  I am not sure why you want to verify that this is home-link. The  UE sees an address that is not its home address. Thus, it will know that 
this  is not home-link and can send BU.

[behcet] Yes UE sees an address and this address is from the new PDN if you are talking about multiple PDN connectivity. And this new PDN is supposed to be acting as another HA and therefore UE is at its home-link with the new HA.

  I think this was discussed  when mext was first formed. I don't remember the conclusion.
  I found  a typo: D in PDN and PDG should stand for Data. 
Thanks for pointing out. Yes we will make the relevant changes in  future  revisions. 

Regards,

Behcet

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Sat, 15 Nov 2008 14:11:15 +0800

Hi Behcet,
 
Please see reply in-line.
 
BR,
Mohana

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Friday, November 14, 2008 11:28 PM
	To: Mohana Jeyatharan
	Cc: [email-masked]
	Subject: Re: [MEXT] draft-ng-intarea-tunnel-loop

	Hi Mohana,
	
	  Please see inline.
	
	Regards,
	
	Behcet

	Hi Behcet,

	BR,
	Mohana

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Behcet Sarikaya
		Sent: Thursday, November 13, 2008 11:31 PM
		To: [email-masked]
		Subject: [MEXT] draft-ng-intarea-tunnel-loop

		Dear all,
		  This draft will be presented in Mext next week.
Although the solution is int-area issue but the PS belongs to mext.
		  Two example scenarios are presented in Sec. 1.2 which
make up the problem statement. In the first scenario, there is the issue
of two HAs simultaneously serving MN and MN sending BUs at the home
link. In the second scenario, the issue is MN sending BU at the home
link. 
		In both the scenarios decsribed in the draft, the MN is
not attached to its home link. If it is attached to home-link then it
will not send binding updates. In the first scenario the tunnel loop is
created betwee two of its HAs and in the second scenario, more of a 3GPP
scenario
		where tunnel loop is created between ePDG and P-GW/HA.  
		  MIPv6 and DSMIPv6 are not designed to handle multiple
HAs serving simultaneously. RFC 5142 handles MN switching  HAs
sequentially. MCoA draft also assumes a single HA serving all
interfaces.
		  MN should not send BUs at the home link. The problem
here is how does MN know it is at the home link? 
		  I am not sure why you want to verify that this is
home-link. The UE sees an address that is not its home address. Thus, it
will know that 
		this is not home-link and can send BU.
		
		[behcet] Yes UE sees an address and this address is from
the new PDN if you are talking about multiple PDN connectivity. And this
new PDN is supposed to be acting as another HA and therefore UE is at
its home-link with the new HA.
		 [Mohana] UE has configured two home addresses from two
different P-GW/HAs. HoA1 from HA1/P-GW1 and HoA2/P-GW2. Now the address
UE sees is from the local access network and not the home address from
HA2 for example. Again it depends on the type of access network. If it
is assigned by the e-PDG, then this address with be the DSMIPv6 CoA.
		 It will not see the home address given by the second
HA. Here the assumption is, that this is a malicious UE and it knows its
home addresses obtained from different HAs and it is deliberately
creating loop. Hope this helps!
		
		  I think this was discussed when mext was first formed.
I don't remember the conclusion.
		  I found a typo: D in PDN and PDG should stand for
Data. 
		Thanks for pointing out. Yes we will make the relevant
changes in future revisions. 
		
		Regards,
		
		Behcet