Subject: [netlmm] PMIPv6: Draft

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Wed, 16 May 2007 18:31:22 +0800

Hi,

This is with respect to the draft "draft-ietf-netlmm-proxymip6-00.txt".

I have a doubt on the default route setup at the MAG. 

The protocol says "The mobile access gateway on receiving this Proxy
Binding Acknowledgment message sets up a tunnel to the local mobility
anchor and adds a default route over the tunnel to the local mobility
anchor.  All traffic from the mobile node gets routed to the mobile
node's local mobility anchor over the tunnel." (section 3)

According to my understanding default route means all the traffic will
be deliverd to that destination (which here is the tunnel and finally to
the LMA). 

1. My point is how this works in case of multiple LMAs working with the
same MAG (as mentioned in the Figure 1 of the draft), how the correct
LMA is selected for the specific MN? 

2. what about the other traffic (MIP6 MN etc..)

3. How about the signalling messages in case of existance of the tunnel
(created earlier for a existing MN) when a new MN attaches. Will these
be tunneled.

Please correct if I was misunderstood.

Thanks,

Mohan

 

________________________________

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 May 2007 15:07:25 +0200

Hi Mohan,

On Wednesday 16 May 2007 12:31, Kandra Mohan-a22098 
wrote:
> The protocol says "The mobile access gateway on
> receiving this Proxy Binding Acknowledgment message
> sets up a tunnel to the local mobility anchor and
> adds a default route over the tunnel to the local
> mobility anchor.  All traffic from the mobile node
> gets routed to the mobile node's local mobility
> anchor over the tunnel." (section 3)
>
> According to my understanding default route means
> all the traffic will be deliverd to that destination
> (which here is the tunnel and finally to the LMA).

That's correct.

> 1. My point is how this works in case of multiple
> LMAs working with the same MAG (as mentioned in the
> Figure 1 of the draft), how the correct LMA is
> selected for the specific MN?

You're right that when multiple LMAs are present, a 
default route isn't sufficient. 

What would be required is 1) multiple default route to 
the different LMAs, and 2) policy routing to select 
the appropriate default route (to correct LMA) based 
on packet source address (i.e. the MN's address). 
Policy routing should be set so that packet from MN_i 
address goes into tunnel to LMA of MN_i, whatever the 
destination of the packet is (that's why it's still a 
default route). 

> 2. what about the other traffic (MIP6 MN etc..)

These should just use a regular default route to the 
domain's backbone (i.e. not to a specific LMA).

> 3. How about the signalling messages in case of
> existance of the tunnel (created earlier for a
> existing MN) when a new MN attaches. Will these be
> tunneled.

If you are referring to pMIP6 proxy, those shall not be 
tunneled are they do not originate from the MN but 
from the MAG.

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 16 May 2007 08:39:42 -0700

Hi Mohan:
 
Please see inline.

  _____  

From: Kandra Mohan-a22098 [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 3:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: PMIPv6: Draft

Hi,

The protocol says "The mobile access gateway on receiving this Proxy Binding
Acknowledgment message sets up a tunnel to the local mobility anchor and
adds a default route over the tunnel to the local mobility anchor.  All
traffic from the mobile node gets routed to the mobile node's local mobility
anchor over the tunnel." (section 3)

According to my understanding default route means all the traffic will be
deliverd to that destination (which here is the tunnel and finally to the
LMA). 

1. My point is how this works in case of multiple LMAs working with the same
MAG (as mentioned in the Figure 1 of the draft), how the correct LMA is
selected for the specific MN? 

[Sri] The default-route is on a node basis. Please see Section 6.7, Routing
Considerations.

"

 Mobile Node's IPv6 traffic:
  ===========================
  For all traffic from the source address MN-HoA to destination 0::/0
  route via tunnel0, next-hop LMAA.

  MN-HoA::/64 is reachable via the directly connected interface.

  tunnel0:
  ========
      Source: Proxy-CoA
      Destination: LMAA
      Tunnel Payload: IPv6
      Tunnel Transport: IPv6
"

This is more PBR, as Julien pointed out. We do this today in MIP4 on the FA
as well. 

But, we will make a point to add about PBR in the above lines your pointed
out.

[Sri] Router normally and not in a tunnel, as Julien pointed out.

3. How about the signalling messages in case of existance of the tunnel
(created earlier for a existing MN) when a new MN attaches. Will these be
tunneled.

[Sri] I assume this is about the rereg messags for a given node ? These are
routed directly.

 

Thanks,

Mohan

 

  _____

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 21:03:30 +0200

Sri Gundavelli wrote:
>     [Sri] The default-route is on a node basis. Please see Section 6.7,
>     Routing Considerations.

I'm sorry but how is the default route implemented "on a node basis"? 
Router implementation doesn't look at source address...

Alex

>     This is more PBR, as Julien pointed out. We do this today in MIP4 on
>     the FA as well.
> 
>     But, we will make a point to add about PBR in the above lines your
>     pointed out.
> 
>      
> 
>      
> 
>     3. How about the signalling messages in case of existance of the
>     tunnel (created earlier for a existing MN) when a new MN attaches.
>     Will these be tunneled.
> 
>      
> 
>      
> 
>     [Sri] I assume this is about the rereg messags for a given node ?
>     These are routed directly.
> 
>      
> 
>      
> 
>     ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 May 2007 13:34:05 -0700 (PDT)

On Wed, 16 May 2007, Alexandru Petrescu wrote:

> I'm sorry but how is the default route implemented "on a node basis"? Router 
> implementation doesn't look at source address...

How do you support reverse tunneling today in MIP4 on the
FA ? Same logic. Use the source address/Mac Address of the
packet for the route selection.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 23:40:46 +0200

Sri Gundavelli wrote:
>>> [Sri] The default-route is on a node basis. Please see Section
>>> 6.7, Routing Considerations.
>> 
>> I'm sorry but how is the default route implemented "on a node
>> basis"? Router implementation doesn't look at source address...
> 
> 
> How do you support reverse tunneling today in MIP4 on the FA ? Same
> logic. Use the source address/Mac Address of the packet for the route
> selection.

MIP4 on MN doesn't need src address of packet for route selection, it 
reverse tunnels every outgoing packet.  I think it's the same for FA but 
can't confirm.

For MIP6 it's also the case (don't use src address to select routes).

I'm not quite sure what are the security aspects of routing in this way 
(using src address to select routes).

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 May 2007 15:07:40 -0700 (PDT)

Alex:

> reverse tunnels every outgoing packet.  I think it's the same for FA but 

I'm not talking about MN in CCOA mode. Reverse tunneling in the FA-COA
mode. Please see my earlier comment above.

FA may have tunnels to different HA's. The FA may also be serving
mobile node's visiting from multiple HA's. Now, when the FA sends
a packet to any CN, if reverse tunneling is enabled, the route
decision is based on the source address of the packet. This is Policy
based routing, as Julien as pointed out. So, all the FA implementations
do this today.

The same logic is used here for selecting the MAG-LMA tunnel for
outgoing packets.

Sri

> (using src address to select routes).

Think of some and let me know, if this mode of routing violates
3344 and any security. But, I cant think of any thing. This is
quite normal.

Sri

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Thu, 17 May 2007 14:21:02 +0800

Hi Sri,

RFC 3024 talks about the security considerations of using reverse
tunneling and the need for a SA between nodes (FA - MN). As you pointed
out the usage of these, I doubt, is it required any such security
Associations here in this case.

Thanks,
Mohan

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, May 17, 2007 3:38 AM
To: Alexandru Petrescu
Cc: Kandra Mohan-a22098; [email-masked]
Subject: Re: [netlmm] RE: PMIPv6: Draft

Alex:

Sri

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 16 May 2007 23:42:21 -0700

Hi Mohan, 

> Sent: Wednesday, May 16, 2007 11:21 PM
> To: Sri Gundavelli; Alexandru Petrescu
> Cc: [email-masked]
> Subject: RE: [netlmm] RE: PMIPv6: Draft
> 
> Hi Sri,
> 

Yes. The MN-AR trust relation is the stated assumption. So, the
considerations from 3024 when applied to this document at a
high level, is the requirement of the access authentication, as
mentioned in Section 6.3. On the routing aspect, there is no
difference. 

Thanks for highlighting the reverse tunneling aspect. In addition
to the text in Section 6.7, we will add few lines on the PBR
specifics, even thought the routing in general is very well
covered.

Regards
Sri

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Thu, 17 May 2007 17:12:21 +0800

Hi,

>From section 5.7 of draft-ietf-netlmm-proxymip6-00.txt:

How can a MAG will come to know that there is a change in the MN prefix
and thus it can advertise the ICMP Mobile Prefix Advertisement message
to that MN?

Is it that an interface with relevant messages is required between
policy store and the MAG?

Thanks,
Mohan

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Thu, 17 May 2007 19:57:15 +0800

Hi,

After going thru the draft, I am stuck up with few doubts which I need
some clarifications.

1.	what is the order of messages: is it RA and then PBU/PBACK or
first PBU/PBACK and then RA? Bacause in case of LMA denies it was
mentioned that the MAG MUST NOT advertise the home network prefix on the
access link.
2.	Section 6.11 - 4th point. "The mobile access gateway on
receiving a Router Solicitation message from a mobile node MUST send a
Router Advertisement message containing the mobile node's home network
prefix." I think it should be mentioned that the MAG should advertise
the relevant prefix based on the network-based mobility service is
offered or not (in line to the 3rd point).
3.	Section 6.5 - last Para: "This is further assured with the
currently supported per-mn-prefix model, as there are two mobile nodes
that share the same home network prefix." I think this should be a no
statement.
4.	In some places it is mentioned "direct registration". I think
these are MIPv6 (RFC 3775) registrations. 
a.	If so, in section 5.8 point 6: As direct registration won't have
the MN-Identifier data, how can we check the Binding cache while
processing PBU? I doubt even the care-of addresses in both cases (MIPv6
registration and PBU registration) will be same.
b.	Same section, point 7: I wonder why the direct deregistration
will be received on a tunnel between LMA and MAG. If we think of the
source based routing, the source address of the direct BU will be CoA
and not the HoA.
5.	Is it possible to replace the home network prefix with home
network address itself? Also, will the LMA and MAG will be worried just
about the MN's Home prefix or the entire MN's Home address is required.

These are a few till now.

Thanks,
Mohan

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 May 2007 08:35:28 -0500

IMO, I do not think that is necessary. The advertised prefix has a
lifetime and that should suffice. No?

Regards,
Ahmad

> Sent: Thursday, May 17, 2007 2:12 AM
> Subject: [netlmm] PMIPv6: Mobile Prefix Discovery
> 
> Hi,
> 
> How can a MAG will come to know that there is a change in the 
> MN prefix and thus it can advertise the ICMP Mobile Prefix 
> Advertisement message to that MN?
> 
> Is it that an interface with relevant messages is required 
> between policy store and the MAG?
> 
> Thanks,
> Mohan
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 May 2007 18:51:44 +0200

Sri Gundavelli wrote:
>> reverse tunnels every outgoing packet.  I think it's the same for FA 
>> but can't confirm.
>>
> 

Care to explain to me (and to this Working Group) what is Policy-Based 
routing?  What are the protocols?  Who defines that policy?

I think doing policy-based routing in PMIPv6 completely out of the blue, 
ie without any reference to existing policy-based routing standards, is 
not the way to go.

Also, doing policy profile and identification of the mobile node (from a 
AAA database or some other unknown means) is again not the way to go.

Because, answering "this is policy" whenever some issue is raised about 
PMIPv6 is not the way to go.

Alex

>> I'm not quite sure what are the security aspects of routing in this 
>> way (using src address to select routes).
>>
>

---

From: Frank Xia <[email-masked]>
Date: Thu, 17 May 2007 12:12:15 -0500

This is IPv6 address renumbering problem. 
General solution is 
  1)advertised prefix has a lifetime
  2)MAG SHOULD has mechanism to renew the lifetime or request another prefix.
    As to specific mechanisms, MAG can use PBU to piggyback the renew,  or MAG can tunnel DHCPv6 message
    It depends on the prefix delegation methods which are described in http://tools.ietf.org/wg/netlmm/draft-sarikaya-netlmm-prefix-delegation-00.txt.
    
Regards,
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Kandra Mohan-a22098" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; "Alexandru Petrescu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 17, 2007 8:35 AM
Subject: RE: [netlmm] PMIPv6: Mobile Prefix Discovery

Regards,
Ahmad

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 May 2007 10:16:53 -0700

Alex:

Section 6.7, explains how the MAG needs to handle the mobile node's
out going traffic. Do you have any issue with it ? Implementation
issue or a routing issue, that you see ? Also, this is exactly how
the foreign agent handles the MN traffic, for the out going tunnel
selection. 

"

Now, the draft did not use the phrase PBR. Generally, when routing
is based on parameters other than destination address, the phrase PBR
is used to define that. Refer to: 

http://en.wikipedia.org/wiki/Policy_based_routing

So, the policy here is the route entry in Section 6.7. But, I'm really
not sure, why you ask these questions. Its done in MIP4, exactly the
same way. You authored one or more drafts on MIP4-MR. 

Please do state, if this is incorrect, or if you want this to be done
differently. That will really help.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 May 2007 10:29:02 -0700

> Subject: PMIPv6: Mobile Prefix Discovery 
> 
> Hi,
> 
> MN prefix

The interface between LMA/MAG and the policy store, is outside the scope
of the base document. Its also an implementation detail, how often
the entities should query the policy store ..etc. That can enforced in
one or more ways, but, out of scope for the base doc. 

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 May 2007 23:44:57 +0200

> Mobile Node's IPv6 traffic:

YEs I have two issues with this paragraph.

This is not how routing works ("for all traffic from somewhere go to 
somewhere").  This spec can not specify such a large departure from how 
routing works, can it.

Also, the destination address is rarely :: (ie the 'unspecified 
address', or 128 0 bits).  I think you meant for traffic to _any_ 
destination.

> http://en.wikipedia.org/wiki/Policy_based_routing

Ha ha, laughing out loud :-)  We're not wikipedia here are we :-)

Seriously, I understand what you say with policy based routing, and I 
also know there are several protocols related to policy-based routing: 
MPLS, RSVP and probably some BGP policies.

But being silent in a PMIP6 spec about that is not good, it implies that 
somehow the policy is something defined outside the spec and that solves 
some issues this spec may have.

> same way. You authored one or more drafts on MIP4-MR. 

(The one MIP4-MR draft I'm authoring is only about the CCoA mode, not FA
  extensions for MR, so it has not this issue.)

MIP4 implementation I'm working with does not look at src address when 
doing reverse tunnelling.

> differently. That will really help.

Yes, IMHO, it is incorrect to impose routing based on src address, 
unless it specifies which protocol it uses.

I think it should work without routing based on src address.  It is 
sufficient for AR to encapsulate all traffic to the HA, instead of 
routing it.  Ie AR's default route will point to a tunnel interface, and 
the tunnel interface has a static route to HA.

Otherwise, could you please point me to the right text in MIP4 spec that 
says that FA will route packets from MN based on its src address?

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 May 2007 18:50:47 -0700

> some issues this spec may have.

Policy Routing is not about any specific protocol. Its just about
a forwarding decision based on parameters other than just a destination
address. Its just another routing rule and supported by all forwarding
engines, including in Linux. Simple user package such as IPRoute2 has
the options to insert these routing rules that use the source address
for the route selection. Check the RPD section. 

http://www.policyrouting.org/iproute2.doc.html#ss9.6

So, the routing requirement for this spec, is nothing special, just
as in MIP4. I'm not sure, if we should add any more text on this. Its
too obvious. Hope this helps.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 May 2007 18:50:47 -0700

> says that FA will route packets from MN based on its src address?

No. MAG's default route will not point to the tunnel interface.
The MAG may have established tunnels to multiple LMA's. There may
be more than one tunnel. Your logic works, if there is only one
LMA in the PMIP domain. So, the forwarding decision must be based
on the source address, that determines the tunnel interface and
the next hop gateway (the respective LMA).

Refer to, RFC 3024, Section 5.1.2. The destination address in
the outer header is the home agent's address in the recently
accepted RRQ for that mobile node. Same thing here ..the same
encap logic applies here.

See the below illustration, From 3024, A.2, its an overlapping
private address case, but, there are multiple HA's and that's the
relevant point here. FA has two tunnels to HA1 and HA2. Where does
the FA route the packet ? It must see the src/mac address and
select the tunnel interface, towards HA1 or HA2. That's the
forwarding decision, its based on src address/mac address.

      10.10.1.2
       +----+                IF1=COA1+-------+    HAA2 +-----+
       | MN1|------------------------|  FA   |---------| HA2 |
       +----+           +------------|       |         +-----+
                        |    IF2=COA2+-------+
                    +---+               |
                    |                   |
                 +-----+                |
                 | MN2 |                |
                 +-----+                |
                  10.10.1.2             |
                                        | HAA1
                                    +------+
                                    | HA1  |
                                    +------+

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 May 2007 19:09:26 -0700

Mohan:
 
Please see inline.

Sri

  _____  

From: Kandra Mohan-a22098 [mailto:[email-masked]] 
Sent: Thursday, May 17, 2007 4:57 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: clarifications in draft-ietf-netlmm-proxymip6-00

Hi,

After going thru the draft, I am stuck up with few doubts which I need some
clarifications.

1.      what is the order of messages: is it RA and then PBU/PBACK or first
PBU/PBACK and then RA? Bacause in case of LMA denies it was mentioned that
the MAG MUST NOT advertise the home network prefix on the access link .

[Sri] This is tracked in issue#55. We have discussed this at length with
JinHyeock. 

    2.      Section 6.11 - 4th point. "The mobile access gateway on
receiving a Router Solicitation message from a mobile node MUST send a
Router Advertisement message containing the mobile node's home network
prefix." I think it should be mentioned that the MAG should advertise the
relevant prefix based on the network-based mobility service is offered or
not (in line to the 3rd point) .

[Sri] That's covered in the prev bullet, as you mentioned. Why should that
be stated again ?

 3.      Section 6.5 - last Para: "This is further assured with the
currently supported per-mn-prefix model, as there are two mobile nodes that
share the same home network prefix." I think this should be a no statement. 

[Sri] Yes. Editorial. This is fixed.

4.      In some places it is mentioned "direct registration". I think these
are MIPv6 (RFC 3775) registrations. 
a.      If so, in section 5.8 point 6: As direct registration won't have the
MN-Identifier data, how can we check the Binding cache while processing PBU?
I doubt even the care-of addresses in both cases (MIPv6 registration and PBU
registration) will be same . 

[Sri] CMIP/PMIP integration scenario will not be in the base doc. See the
<http://draft-devarapalli-netlmm-pmipv6-mipv6-01.txt>
draft-devarapalli-netlmm-pmipv6-mipv6-01.txt or merged doc soon ...

b.      Same section, point 7: I wonder why the direct deregistration will
be received on a tunnel between LMA and MAG. If we think of the source based
routing, the source address of the direct BU will be CoA and not the HoA . 

[Sri] Same as above. But, note that from the mobile's perspective, its on
its home link. There is no COA, its HoA.

 5.      Is it possible to replace the home network prefix with home network
address itself? Also, will the LMA and MAG will be worried just about the
MN's Home prefix or the entire MN's Home address is required. 

[Sri] Currently, we support only Per-MN-Prefix model in the base spec. The
route is for the whole prefix.

[Sri] Ok. Shoot, when you have more comments.

Thanks,

Mohan

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Fri, 18 May 2007 12:02:34 +0800

Hi Sri,

Thanks for your explanations.

Please see inline.

Regards,

Mohan

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Friday, May 18, 2007 7:39 AM
To: Kandra Mohan-a22098
Cc: [email-masked]
Subject: RE: clarifications in draft-ietf-netlmm-proxymip6-00

Mohan:

Please see inline.

Sri

	Hi,

	After going thru the draft, I am stuck up with few doubts which
I need some clarifications.

	1.      what is the order of messages: is it RA and then
PBU/PBACK or first PBU/PBACK and then RA? Bacause in case of LMA denies
it was mentioned that the MAG MUST NOT advertise the home network prefix
on the access link .

	[Sri] This is tracked in issue#55. We have discussed this at
length with JinHyeock. 

	    2.      Section 6.11 - 4th point. "The mobile access gateway
on receiving a Router Solicitation message from a mobile node MUST send
a Router Advertisement message containing the mobile node's home network
prefix." I think it should be mentioned that the MAG should advertise
the relevant prefix based on the network-based mobility service is
offered or not (in line to the 3rd point) .

	[Sri] That's covered in the prev bullet, as you mentioned. Why
should that be stated again ?

	[Mohan] I mean this point is saying that MAG MUST respond to RS
with RA containing home network prefix in all the cases, which won't
happen, right?

	 3.      Section 6.5 - last Para: "This is further assured with
the currently supported per-mn-prefix model, as there are two mobile
nodes that share the same home network prefix." I think this should be a
no statement. 

	4.      In some places it is mentioned "direct registration". I
think these are MIPv6 (RFC 3775) registrations. 
	a.      If so, in section 5.8 point 6: As direct registration
won't have the MN-Identifier data, how can we check the Binding cache
while processing PBU? I doubt even the care-of addresses in both cases
(MIPv6 registration and PBU registration) will be same . 

	[Sri] CMIP/PMIP integration scenario will not be in the base
doc. See the draft-devarapalli-netlmm-pmipv6-mipv6-01.txt
<http://draft-devarapalli-netlmm-pmipv6-mipv6-01.txt>  or merged doc
soon ...

	b.      Same section, point 7: I wonder why the direct
deregistration will be received on a tunnel between LMA and MAG. If we
think of the source based routing, the source address of the direct BU
will be CoA and not the HoA . 

	[Sri] Same as above. But, note that from the mobile's
perspective, its on its home link. There is no COA, its HoA.

	 5.      Is it possible to replace the home network prefix with
home network address itself? Also, will the LMA and MAG will be worried
just about the MN's Home prefix or the entire MN's Home address is
required. 

	[Sri] Currently, we support only Per-MN-Prefix model in the base
spec. The route is for the whole prefix.

	Thanks,

	Mohan

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 18 May 2007 00:26:40 -0500

Hi Sri/Mohan,
 
please see one comment inline. Thanks.

Regards, 
Ahmad 

		From: Kandra Mohan-a22098
[mailto:[email-masked]] 
		Sent: Thursday, May 17, 2007 4:57 AM
		To: Sri Gundavelli
		Cc: [email-masked]
		Subject: clarifications in
draft-ietf-netlmm-proxymip6-00

		Hi,

		After going thru the draft, I am stuck up with few
doubts which I need some clarifications.

		[Sri] This is tracked in issue#55. We have discussed
this at length with JinHyeock. 

		    2.      Section 6.11 - 4th point. "The mobile access
gateway on receiving a Router Solicitation message from a mobile node
MUST send a Router Advertisement message containing the mobile node's
home network prefix." I think it should be mentioned that the MAG should
advertise the relevant prefix based on the network-based mobility
service is offered or not (in line to the 3rd point) .

		[Sri] That's covered in the prev bullet, as you
mentioned. Why should that be stated again ?

		[Mohan] I mean this point is saying that MAG MUST
respond to RS with RA containing home network prefix in all the cases,
which won't happen, right? 

		[Ahmad]

		Good catch. However, I would suggest reordering the
bullets. and leaving the text as is would suffice.  i.e. bullet No. 4 to
be moved to become No. 3 and bullet No. 3 to become No. 4. 

		 3.      Section 6.5 - last Para: "This is further
assured with the currently supported per-mn-prefix model, as there are
two mobile nodes that share the same home network prefix." I think this
should be a no statement. 

		4.      In some places it is mentioned "direct
registration". I think these are MIPv6 (RFC 3775) registrations. 
		a.      If so, in section 5.8 point 6: As direct
registration won't have the MN-Identifier data, how can we check the
Binding cache while processing PBU? I doubt even the care-of addresses
in both cases (MIPv6 registration and PBU registration) will be same . 

		[Sri] CMIP/PMIP integration scenario will not be in the
base doc. See the draft-devarapalli-netlmm-pmipv6-mipv6-01.txt
<http://draft-devarapalli-netlmm-pmipv6-mipv6-01.txt>  or merged doc
soon ...

		 5.      Is it possible to replace the home network
prefix with home network address itself? Also, will the LMA and MAG will
be worried just about the MN's Home prefix or the entire MN's Home
address is required. 

		[Sri] Currently, we support only Per-MN-Prefix model in
the base spec. The route is for the whole prefix.

		Thanks,

		Mohan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 May 2007 10:44:19 +0200

Sri Gundavelli wrote:
>>> Section 6.7, explains how the MAG needs to handle the mobile
>>> node's out going traffic. Do you have any issue with it ?
>>> Implementation issue or a routing issue, that you see ? Also,
>>> this is exactly how the foreign agent handles the MN traffic, for
>>> the out going tunnel selection.
>>> 
>>> 
>> Seriously, I understand what you say with policy based routing, and
>> I also know there are several protocols related to policy-based 
>> routing: MPLS, RSVP and probably some BGP policies.
>> 
>> But being silent in a PMIP6 spec about that is not good, it implies
>> that somehow the policy is something defined outside the spec and 
>> that solves some issues this spec may have.
>> 
> 
> Policy Routing is not about any specific protocol. Its just about a
> forwarding decision based on parameters other than just a destination
>  address.

That's why it's not specified at IETF, then.

> Its just another routing rule and supported by all forwarding 
>  the options to insert these routing rules that use the source
> address for the route selection. Check the RPD section.
> 

Could you please point me to an _IETF_ spec about how policy routing is
done, thanks.

> as in MIP4.

Could you please point me to where in the MIP4 spec this policy routing
based on src address is specified?

> I'm not sure, if we should add any more text on this. Its too
> obvious. Hope this helps.

Ok.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 May 2007 10:57:21 +0200

Sri Gundavelli wrote:
>>  routing it.  Ie AR's default route will point to a tunnel 
>> interface, and the tunnel interface has a static route to HA.
>> 
>> Otherwise, could you please point me to the right text in MIP4 spec
>> that says that FA will route packets from MN based on its src
>> address?
>> 
>> Alex
>> 
> 

That's because you want to implement it that way.

> The MAG may have established tunnels to multiple LMA's.

If you mean redundant HAs on the home link then in IPv6 this effect is
achieved by using one anycast HA IPv6 address, so still only one default 
route at MAG but several HAs.

Otherwise I am not sure why you require MAG to have established tunnels
to multiple LMAs?  All the MNs in a lmm belong to the same HA, right?

> There may be more than one tunnel.  Your logic works, if there is only
> one LMA in the PMIP domain. So, the forwarding decision must be based
>  on the source address, that determines the tunnel interface and the
> next hop gateway (the respective LMA).

I think you mean there may be more than one tunnel interface.

> Refer to, RFC 3024, Section 5.1.2. The destination address in the
> outer header is the home agent's address in the recently accepted RRQ
> for that mobile node. Same thing here ..the same encap logic applies
> here.
> 
> the FA route the packet ? It must see the src/mac address and select
> the tunnel interface, towards HA1 or HA2. That's the forwarding
> decision, its based on src address/mac address.
> 
> 
> 
> <figure in previous post>

Again, I think this is your interpretation, that section in that RFC 
doesn't talk at all about overlapping address spaces neither about using 
the src address (nor the mac address) to select the tunnel interface.

But, from your explanation, I understand you have a good understanding 
about how MIP4 FA - and you prefer to replicate that behaviour in 
PMIPv6.  However, all these aspects are particular to MIP4 and don't 
exist in MIP6.

I really think it is not a good idea to replicate the MIP4 FA behaviour 
in MIP6.

An alternative is to extend MIP4 (and not MIP6) to obtain PMIPv4 and 
then extend DS-MIPv4 to obtain PMIPv6.  But I've said this already many 
times.

Alex

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 18 May 2007 11:49:31 +0200

Hi Sri,

> Mobile Node's IPv6 traffic:

I would think that the first occurrence of MN-HoA should be replaced with MN-HoA::/64. Is it only editorial or did you intentionaly use just MN-HoA without /64 at this place?

regards
domagoj

> Sent: 17. svibanj 2007 19:17
> To: 'Alexandru Petrescu'
> Cc: [email-masked]
> > > mobile node's visiting from multiple HA's. Now, when the 
> FA sends a 
> > > packet to any CN, if reverse tunneling is enabled, the route 
> > I think doing policy-based routing in PMIPv6 completely out of the 
> > blue, ie without any reference to existing policy-based routing 
> > standards, is not the way to go.
> > 
> > Also, doing policy profile and identification of the mobile 
> node (from 
> > a AAA database or some other unknown means) is again not the way to 
> > go.
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 18 May 2007 17:49:05 -0700

Hi Domagoj,

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Friday, May 18, 2007 2:50 AM
> To: Sri Gundavelli
> Cc: [email-masked]; Alexandru Petrescu
> I would think that the first occurrence of MN-HoA should be 
> replaced with MN-HoA::/64. Is it only editorial or did you 
> intentionaly use just MN-HoA without /64 at this place?
> 

Yes. Since we support per-mn-prefix route, this must be
MN-HoA::/64. The tunnel route is for the whole prefix.
Will change it.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 18 May 2007 17:49:05 -0700

HI Ahmad:

[Mohan] I mean this point is saying that MAG MUST respond to RS with RA
containing home network prefix in all the cases, which won't happen, right? 

[Ahmad]

Good catch. However, I would suggest reordering the bullets. and leaving the
text as is would suffice.  i.e. bullet No. 4 to be moved to become No. 3 and
bullet No. 3 to become No. 4. 

This sounds ok. Thanks

Sri