Subject: [netlmm] Some issues with the Routing Considerations section of draft-ietf-netlmm-proxymip6-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 20 May 2007 18:21:00 +0200

Hi Sri,

I have now read in detail the short Routing Considerations section 6.7 
of draft-ietf-netlmm-proxymip6-00.txt.  I think there are several issues
with it.  I'm trying to list them all here (even if we discussed some of
them).

1.  The section describes correctly what happens to packets from MN
     under MAG to a CN outside that MAG.  And from same CN to a MN under
     MAG.

     However, it does not describe what happens to packets between two
     MNs under the same MAG.  I think we should avoid that these packets
     go through the tunnels all the way to LMA (this unoptimal route is
     what happens if "all traffic from the source address MN-HoA... route
     via tunnel0, next-hop LMAA.")

     I have a suggestion about how to write text for this behaviour, but
     I want to see first whether people agree that packets between two
     MNs under same MAG must not travel to LMA.  What do you think?

2.  I don't think this section should describe routing based on the
     additional source address ("policy-based" routing).  There are two
     reasons I think so:

     Source-based routing is very similar to firewall rules, and we
     usually don't specify how to do these.

     Neither MIP6 nor MIP4 specs specify how to do this routing based on
     source address.  I see no reason for PMIPv6 to specify this
     behaviour.

     If implementations are already written with this assumption in mind
     (routing based on the additional source address), I think more
     detail should be described about these particular implementations,
     and maybe in a separate document.

     Finally, if we really need to specify at MAG a certain policy to
     route packets coming from MN  we have much more choice than just
     relying on source address.  These include, but are not limited to,
     flow labels, DSCP in Traffic Class, COPS, MPLS and RSVP.  I do not
     see why restricting the particular MAG policy to just src address.

3. Textual nits:

    "For all traffic from the source address MN-HoA to destination
     0::/0"
     Actually no packet from MN with the unspecified address (::) as dst
     will reach the MAG.  I think you meant traffic to _any_ destination
     address.  Unfortunately there is no textual representation for a
     "any" address (rfc4291 sections 2.2 and 2.3 describe existing
     textual representations of IPv6 addresses and prefixes).

     The phrase above is very confusing also because makes think about a
     default route; but the default route dst prefix (in the routing
     table, not in packets) is 2000::/3 and not 0::/0

     Also the phrase is confusing because IP base header does not contain
     a prefix length, and you seem to say 0::/0.

     "   tunnel0:
         ========
           Source: Proxy-CoA
           Destination: LMAA
           Tunnel Payload: IPv6
           Tunnel Transport: IPv6"
     I think you should say that tunnel0 is on MAG and then picture also
     the corresponding tunnel0 at LMA.

     Also, you seem to be very precise about this tunnel0's parameters.
     Can you say what kind of tunnel is this?  Is it a virtual interface?
     Why the difference Tunnel Payload/Tunnel Transport?

     "All the packets that the mobile access gateway receives from the
      tunnel, after removing the tunnel encapsulation, will forward it to
      the mobile node on the connected interface."
     This surely deserves a better formulation.

Thanks for your consideration,

Alex

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

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 20 May 2007 11:25:31 -0700

Hi Alex:

Please see inline.

Sri

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Sunday, May 20, 2007 9:21 AM
> To: Sri Gundavelli
> Cc: netlmm
> Subject: Some issues with the Routing Considerations section 
> of draft-ietf-netlmm-proxymip6-00.txt
> 
> Hi Sri,
> 

This is a good point. I do agree we should write on the MN to MN
scenario and provide some guidance. But, I do not think the MAG is
allowed to route the traffic directly between two mobile nodes.

Reasons:

- Policy Considerations

The operator may prefer to block MN to MN communications and 
since the LMA is the policy enforcement point, it must tunnel
all the traffic back to the LMA. Policy could be as simple as
an ACL check.

- Accounting

Direct routing will break the accounting for the mobile node's
accounting.

But, we can certainly say, if the operator has configured the
MAG to enable direct routing for MN to MN traffic, the traffic
should not be tunneled back and should be routed locally ...
etc...

>      usually don't specify how to do these.

Source-based routing, aka Policy Routing is an IP layer-3 function.
This is extremely common and is part of  any forwarding function.
Believe me, when the MAG is supporting mobile node's visiting from
two different LMA's, it must select the outgoing tunnel interface
based on the src ip/mac address. That is the key parameter in that
forwarding decision.

RFC-3024 talks on how to add the encap, the destination address from
the recently accepted RRQ for that mobile node. This is the same as
saying, select the outgoing tunnel interface, based on the src
address. We are not introducing any new requirements. There is just
one way for the implementers, on NETBSD or Linux 2.6. 

>      see why restricting the particular MAG policy to just 

May be the phrase "policy routing" is implying too much. When we say,
routing, we implicitly assume its based on destination address. That
was long long back, now routing implies, based on other parameters,
including source address.

>      textual representations of IPv6 addresses and prefixes).

Ok. I agree. We were representing this as a routing rule. But, we can
add the phrase "_any_destination_".

>      Can you say what kind of tunnel is this?  Is it a 

It is a virtual p2p interface.

>      Why the difference Tunnel Payload/Tunnel Transport?

Transport is the outer header. 
Payload is the mobile node's home prefix/home address traffic.

> Thanks for your consideration,

Thanks for the input. This is objective feed back. 

Sri

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Mon, 21 May 2007 11:51:02 +0800

Hi Alex/Sri,

Please see inline.

Thanks,
Mohan

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Sunday, May 20, 2007 11:56 PM
> To: 'Alexandru Petrescu'
> Cc: 'netlmm'
> Subject: [netlmm] RE: Some issues with the Routing Considerations
section
> ofdraft-ietf-netlmm-proxymip6-00.txt
> 
> Hi Alex:
> 
> Please see inline.
> 
> Sri
> 
> 
> 
> 
[Mohan] This is a good point from optimization prespective. I think this
scenario is not there in MIP6 unless route optimization is enabled, this
has to be added as a new feature as part of the PMIPv6 protocol. Also,
this has to be coordinated with the Route Optimization in PMIPv6 as I
think RO will cover this scenario. 

> Direct routing will break the accounting for the mobile node's
[Mohan] I wonder how these aspects are taken into consideration in case
of Route optimization?

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 20 May 2007 21:54:17 -0700

[Mohan] I wonder how these aspects are taken into consideration in
case of Route optimization? 

Hi Mohan:

Note that the home agent can always block RO, by dropping the HoTI
messages from a mobile node. So its always in a position to enforce
that policy.  

In the case of MAG enabling direct routing, the LMA is not in control
of that aspect. So, I do not think we can just look at this as an
optimization and enable it be default. It clearly breaks accounting
and policy enforcement. However, we can certainly state that its a
configuration parameter and deployments may choose to enable this
feature, if needed.

Sri

---

From: "Kandra Mohan-a22098" <[email-masked]>
Date: Mon, 21 May 2007 13:19:27 +0800

Hi Sri,

> Sent: Monday, May 21, 2007 10:24 AM
> To: Kandra Mohan-a22098; 'Alexandru Petrescu'
> Cc: 'netlmm'
> Subject: RE: [netlmm] RE: Some issues with the Routing Considerations
> section ofdraft-ietf-netlmm-proxymip6-00.txt
> 
> 
> 
> 
> 	> Reasons:
> 
> 	>
> 
> 	> - Policy Considerations
> 
> 	>
> 
[Mohan] I am sorry that I didn't find this point in MIPv6 [RFC 3775].
Could you please point me there.

Thanks,
Mohan

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 May 2007 09:34:23 +0300

> case of Route optimization?

Mohan,

in the case of PMIPv6, the decision of whether or not to support route
optimization can and should be with the PMIPv6 operator.  It is a
deployment issue.  The same is true for direct routing of traffic
between mobile nodes on the same MAG.  For either function, the decision
of whether or not to support the function should be left with the
operator, who in turn would decide based on whether the function fits
together with the rest of the system (including the accounting part),
and finally configure MAGs accordingly.

Kind regards,
- Christian

-- 
Fashion is a form of ugliness so intolerable that we have to
alter it every six months.  (Oscar Wilde)

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 May 2007 10:33:26 +0200

Hi Sri, thanks for your email,

>>  under MAG to a CN outside that MAG.  And from same CN to a MN
>> under MAG.
>> 
>>  what happens if "all traffic from the source address MN-HoA...
>> route via tunnel0, next-hop LMAA.")
>> 
> 
> 
> The operator may prefer to block MN to MN communications and since
> the LMA is the policy enforcement point, it must tunnel all the
> traffic back to the LMA. Policy could be as simple as an ACL check.
> 
> - Accounting
> 
> But, we can certainly say, if the operator has configured the MAG to
> enable direct routing for MN to MN traffic, the traffic should not be
> tunneled back and should be routed locally ... etc...

I think I understand the need to develop something that is used by 
operators.  But I am not sure operators like to overload their fixed 
networks (link between MAG and LMA) when they can do the MN-MN 
accounting directly on the covering MAG (instead of LMA).

What you seem to say, IMHO, is that you would like to describe both 
situations: MAG enabled and/or disabled direct routing for MN to MN 
traffic.  Moreover, I think you see the MN-MN communication (under same 
MAG) as an exception that _could_ be described.

I think that should not be the exception but the main method of 
communication between two MNs under the same MAG.  And if operator 
doesn't like it, then we can suggest her/him to do accounting on MAG. 
And if s/he still doesn't like it then we should warn her/him about 
overloading the network; and finally allow probably an exception for 
that particular operator.

> This is extremely common and is part of  any forwarding function.

Yes, it is; and it's like firewalling rules - not specified.

> based on the src ip/mac address. That is the key parameter in that 

I think we go too far trying to address the MNs from different LMAs.  I 
think we should fix first MN from same LMA (MNs belong to the same lmm).

MN from a different LMA, visiting another LMA is too much related to 
global mobility and has too many unknown aspects, security being not the 
least important.  And many possible ways to solve them (not only src 
ip/mac address).

> the recently accepted RRQ for that mobile node. 

I am not sure which paragraph you refer to in rfc3024.  Could you please 
point me to it?  I'm guessing it is in section 5.2.2?

sec 5.2.2 of rfc3024:
>    Packet format forwarded by the foreign agent (Encapsulating Delivery
>    Style):
> 
>       IP fields (encapsulating header):
>         Source Address = foreign agent's care-of address
>         Destination Address = home agent's address
>         Protocol field: 4 (IP in IP)
>       IP fields (original header):
>         Source Address = mobile node's home address
>         Destination Address = correspondent host's address
>       Upper Layer Protocol
> 
>    These fields of the encapsulating IP header MUST be chosen as
>    follows:
> 
>       IP Source Address
> 
>          Copied from the Care-of Address field within the Registration
>          Request.
> 
>       IP Destination Address
> 
>          Copied from the Home Agent field within the most recent
>          successful Registration Reply.

sri:
> This is the same as saying, select the outgoing tunnel interface,
> based on the src address.

I think this is a particular interpretation, and a way of implementing 
it, but it is not what that paragraph says.

Another possible implementation is to follow the spec precisely and copy 
the address from the HA field of RegRep.

Otherwise, if I'm wrong, could you please point to the rfc3024 paragraph 
you refer to, so I can understand what you mean when you say rfc3024 
does src-based routing - thanks.

> We are not introducing any new requirements. There is just one way
> for the implementers, on NETBSD or Linux 2.6.

It's good we discuss implementation.

I think there are at least two ways to start a PMIPv6 implementation on 
linux in particular: from MIPL (MIP6) or from Dynamics (MIP4).  I think 
the behaviour you suggest is more akin to FA behaviour and that is 
probably more Dynamics and that is not in the linux kernel 2.6...

I don't think the MIPL (MIP6) implementation does this src-based routing 
at MN.  That's why I'm not sure why you say there is just one way for 
implementers.

> including source address.

Ok, I understand the novelty aspect of source-based routing.  But I 
insist it shouldn't be specified in PMIPv6.  Because I can't find 
another place where it's already specified.

>> 0::/0" Actually no packet from MN with the unspecified address (::)
>> as dst will reach the MAG.  I think you meant traffic to _any_ 
>> destination address.  Unfortunately there is no textual
>> representation for a "any" address (rfc4291 sections 2.2 and 2.3
>> describe existing textual representations of IPv6 addresses and
>> prefixes).
>> 
> 

Ok, thanks.

> Transport is the outer header. Payload is the mobile node's home
> prefix/home address traffic.

So maybe a similar tunnel description should talk IPv4 as well...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 May 2007 10:45:07 +0200

Kandra Mohan-a22098 wrote:
>>> MNs under the same MAG.  I think we should avoid that
> 
>>> these packets
> 
>>> go through the tunnels all the way to LMA (this
> 
>>> unoptimal route is
> 
>>> what happens if "all traffic from the source address
> 
>>> MN-HoA... route
> 
> [Mohan] This is a good point from optimization prespective. I think 
> this scenario is not there in MIP6 unless route optimization is 
> enabled, this has to be added as a new feature as part of the PMIPv6 
> protocol.

Well, I think the scenario is there in MIP6 because the the MNs can use
their CoAs instead of using their HoAs.  However, in the PMIP6 case the
MNs don't have CoAs so they're forced into using their HoAs always.

> Also, this has to be coordinated with the Route Optimization in 
> PMIPv6 as I think RO will cover this scenario.

I don't think straight MN-to-MN communication (under same MAG) is an
exception or an optimization to be considered later for PMIPv6.  I think
this is the main way communication should happen between the two MNs
under the same MAG (ie don't go to LMA).

But that is just my oppinion.

> case of Route optimization?

I think Sri puts Accounting and Policy-based routing in a same
perspective where we assume that the operator does it in an unspecified
manner.

An operator that doesn't allow straight MN-to-MN communication (forcing
it to an Accounting point) is I believe a thing of the past.  Or at
least something that is not good to encourage.  Accounting is more and
more done with flat fees which means bytes are not counted, but
identification is important.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 May 2007 10:47:24 +0200

Sri Gundavelli wrote:
> and policy enforcement.

Sri, it depends where accounting and policy enforcement are done.

If accounting and policy enforcement are done in the MAG then MN-to-MN
straight communication (without going to LMA) is possible, right?

> However, we can certainly state that its a configuration parameter
> and deployments may choose to enable this feature, if needed.

(I said in a previous mail: this should be the main way of working, not
  knob-enabled optimization).

Alex

---

From: Nicolas DICHTEL <[email-masked]>
Date: Mon, 21 May 2007 14:02:50 +0200

Le 21.05.2007 10:33, Alexandru Petrescu a écrit :
> I think there are at least two ways to start a PMIPv6 implementation 
> on linux in particular: from MIPL (MIP6) or from Dynamics (MIP4).  I 
> think the behaviour you suggest is more akin to FA behaviour and that 
> is probably more Dynamics and that is not in the linux kernel 2.6...
>
> I don't think the MIPL (MIP6) implementation does this src-based 
> routing at MN.  That's why I'm not sure why you say there is just one 
> way for implementers.
MIPL project provides a patch against linux-2.6 which add the src-based 
routing for the MN. This feature will be added soon in linux-2.6.

Rergards,
Nicolas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 May 2007 15:08:30 +0200

> routing for the MN. This feature will be added soon in linux-2.6.

Thanks for the information.  This is good to know.

Could you please point me to a paragraph in rfc3775 (or any other rfc) 
that demands a Mobile IPv6 MN to do src-based routing?  I think there 
may be some but can't seem to figure it out...

Thanks,

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 21 May 2007 18:58:18 -0700

> that particular operator.

We have no problem specifying both the approaches. But, I do think
that the default behaviour is to route the traffic back home for the
two considerations I mentioned. IMO, its a config knob on the MAG
that the operator needs to turn on, if they want to avoid that
reverse tunnel and back . Lets see what other say and we can switch
this behaviour, if others have similar opinion.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 21 May 2007 20:05:15 -0700

Hi Alex,

> >          successful Registration Reply.

Yes. I was referring to this text. Per this text, the foreign agent
must construct the encapsulation header by setting the destination
address of the outer header to the address in the Home Agent field
of a recently received RRP for that mobile. So, for each packet
there is a lookup required for finding the recently accepted RRP.
The lookup can't be based on any other fields in the packet, other
than the source IP address or the MAC address. So, for the
implementers there is no other choice, whether the draft says it or
not, other than doing a source based lookup. This also implicitly
expects the foreign agent to intercept every packet.

The other way of implementing the same is by creating a tunnel
interface, that defines the outer header. Now, a rule that specifies
what packets need to get that header or need to be routed through
that tunnel interface. This source based rule or a PBR, specifies
any packets with the following IP source address or the MAC address
need to be routed through this tunnel. This does not expect the MAG
to intercept every packet. Its a routing rule that goes into the
forwarding process.

So, IMO, we can specify the operation in either of the above two
ways and it will be up to the implementers as how they choose to
implement. After all its the local forwarding behavior and has no
impact on the inter-operability. But, I do think, the latter
approach provides better guidance and proper decoupling between the
control and data plane. But, I will let others comment on this and
express their preference. I'm fine either way and will document
the consensus.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 21 May 2007 20:17:21 -0700

I'm not sure, if its explicitly mentioned. As far as I know, its a
known practice for blocking RO, by the operators. Any case, as I said
before and also as Christian pointed out, we can specify both the
modes. The default being the traffic being routed back to the LMA
and other mode is the MAG doing a local routing, if the configuration
knob is turned on.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 00:02:52 -0500

Hi Sri,

Regards,
Ahmad
 
> Subject: RE: [netlmm] RE: Some issues with the Routing 
> Considerations section ofdraft-ietf-netlmm-proxymip6-00.txt
> 
> 	> 
> 
> 	[Mohan] I wonder how these aspects are taken into 
> consideration in case of Route optimization? 
> 
> Hi Mohan:
> 
> Note that the home agent can always block RO, by dropping the 
> HoTI messages from a mobile node. So its always in a position 
> to enforce that policy.  
> 
> In the case of MAG enabling direct routing, the LMA is not in 
> control of that aspect. So, I do not think we can just look 
> at this as an optimization and enable it be default. It 
> clearly breaks accounting and policy enforcement. However, we 
> can certainly state that its a configuration parameter and 
> deployments may choose to enable this feature, if needed.

[Ahmad]
I agree with Sri on this point. I believe it is the home domain (HA)
which decides if RO is allowed or not. Billing is one of the reasons
here. However, RFC3775 seems to leave it up to the MN as far as route
optimization is concerned. On the other hand, I came across the
following requirement w.r.t Reverse Tunneling which is a little puzzling
me:

"
10.4.5.  Handling Reverse Tunneled Packets

   Unless a binding has been established between the mobile node and a
   correspondent node, traffic from the mobile node to the correspondent
   node goes through a reverse tunnel.
"

IMO, In order for this requirement to be enforced, (It is implicitly
assumed) HA has the power to approve or block RO signaling from the MN
to the CN. Other possibilities is that CN does not support RO but this
is valid if HA approves RO to start with.

Any thoughts here?

. The only requiremnet I did not see any requirement for

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 21 May 2007 23:36:56 -0700

> is valid if HA approves RO to start with.

This is a good point. Now, lets put the CN right on the same link where
the MN is connected. Per 3775, the packet needs to go back in the tunnel.
So, that's the default behaviour. The mobile is not allowed to send
the packets directly unless the RO is in place, and that can be very well
be denied by the home agent. Thanks for this pointer.

Thanks
Sri

---

From: Julien Abeille <[email-masked]>
Date: Tue, 22 May 2007 09:42:42 +0200

Hi,

just one comment about the two MNs attached to the same MAG: the MAG has 
a route to both MNs through a directly connected interface. Therefore 
(still dependent on implementation), receiving a packet from a MN to 
another MN, MAG should use the direct route, not the default one through 
the tunnel (longest match).
Best regards,
Julien

-- 
Julien Abeillé
Research Associate
NEC Europe Ltd.
Network Laboratories
Kurfürsten-Anlage 36
69115 Heidelberg
GERMANY

tel: +49 6221 43421 19
fax: +49 6221 43421 55
eMail: [email-masked]
http://www.netlab.nec.de

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 10:18:25 +0200

Julien Abeille wrote:
> Hi,
> 
> just one comment about the two MNs attached to the same MAG: the MAG
> has a route to both MNs through a directly connected interface.
> Therefore (still dependent on implementation), receiving a packet
> from a MN to another MN, MAG should use the direct route, not the
> default one through the tunnel (longest match).

YEs, this is a behaviour that I'd like to happen (MAG has a route to
both MNs through a directly connected interface, and thus MNs talk
straight to each other).

However, the current Routing Consideration section of the pmipv6 draft
says that all traffic from a certain MN address must go the HA.  This
prevents the behaviour you mention above.

This is so because (1) the longest match mechanism is assumed only on
the dst address (not on the src) or the PMIPv6 draft assumes that the
src address is added to the routing decision and (2) PMIPv6 draft
assumes a point-to-point link between MAG and each MN with a
prefix-per-mobile semantics (ie each ptp link between MAG and MN has a
different prefix) thus no unique connected route for two MNs under same MAG.

Alex

> Best regards, Julien
>>>> HoTI
>> known practice for blocking RO, by the operators. Any case, as I
>> said before and also as Christian pointed out, we can specify both
>> the modes. The default being the traffic being routed back to the
>> LMA and other mode is the MAG doing a local routing, if the
>> configuration knob is turned on.
>> 
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>> 
>> 
> 
> -- Julien Abeillé Research Associate NEC Europe Ltd. Network
> Laboratories Kurfürsten-Anlage 36 69115 Heidelberg GERMANY
> 
> tel: +49 6221 43421 19 fax: +49 6221 43421 55 eMail:
> [email-masked] http://www.netlab.nec.de
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
>

---

From: "Julien Abeille" <[email-masked]>
Date: Tue, 22 May 2007 10:24:20 +0200

Hi Alexandru,

Thanks for your answer. In the end it is just a matter of deciding whether this feature is included in the base spec or as part of a  Route Optimization extension then?
Note that if the routing based on the src address is accepted, I think a route optimization extension should also use this mechanism: if you establish RO for MN1 to a CN, the routing installed on the MAG should be only for MN1 in my opinion. No other MN should take advantage of the RO states and forwarding installed on the MAG for MN1.

Cheers,
Julien

Julien Abeillé
Research Associate
NEC Europe Ltd.
Network Laboratories
Kurfürsten-Anlage 36
69115 Heidelberg
GERMANY

tel: +49 6221 43421 19
fax: +49 6221 43421 55

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, May 22, 2007 10:18 AM
To: Julien Abeille
Cc: Sri Gundavelli; 'Kandra Mohan-a22098'; 'netlmm'
Subject: Re: [netlmm] RE: Some issues with the Routing Considerations section ofdraft-ietf-netlmm-proxymip6-00.txt

Julien Abeille wrote:
> Therefore (still dependent on implementation), receiving a packet from 
> a MN to another MN, MAG should use the direct route, not the default 
> one through the tunnel (longest match).

YEs, this is a behaviour that I'd like to happen (MAG has a route to both MNs through a directly connected interface, and thus MNs talk straight to each other).

However, the current Routing Consideration section of the pmipv6 draft says that all traffic from a certain MN address must go the HA.  This prevents the behaviour you mention above.

This is so because (1) the longest match mechanism is assumed only on the dst address (not on the src) or the PMIPv6 draft assumes that the src address is added to the routing decision and (2) PMIPv6 draft assumes a point-to-point link between MAG and each MN with a prefix-per-mobile semantics (ie each ptp link between MAG and MN has a different prefix) thus no unique connected route for two MNs under same MAG.

Alex

---

From: Christian Vogt <[email-masked]>
Date: Tue, 22 May 2007 12:25:24 +0300

Sri Gundavelli wrote:
> ...

Given that the binding update list on the MAG includes a MN identifier,
the MN's MAC address, and the MN's home address, and given that all of
these values by definition uniquely identify the MN, would it be
possible to leave it up to the MAG which of the values it uses in
identifying the right tunnel for packets from a particular MN?

It seems that this would provide the highest flexibility for operators.

- Christian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 06:30:35 -0500

Hi,
 
That behavior is dependent on the home network policy. Unless MAG is authorized to do so, it should reverse tunnel traffic by default or the MN has established RO with that CN (as per RFC3775). I am not sure why this seems to be an issue here. Home domain is the one who authorizes the MN service to start with. If all other setup and requirements are met, e.g. billing is done by the MAG, for example, there is no problem. BUT all dependent on approval by the home domain. IMO.
 
Regards, 
Ahmad 

________________________________

	From: Julien Abeille [mailto:[email-masked]] 
	Sent: Tuesday, May 22, 2007 2:43 AM
	To: Sri Gundavelli
	Cc: 'netlmm'
	Subject: Re: [netlmm] RE: Some issues with the Routing Considerations section ofdraft-ietf-netlmm-proxymip6-00.txt

	Hi,
	
	just one comment about the two MNs attached to the same MAG: the MAG has a route to both MNs through a directly connected interface. Therefore (still dependent on implementation), receiving a packet from a MN to another MN, MAG should use the direct route, not the default one through the tunnel (longest match).
	Best regards,
	Julien

	
	Sri Gundavelli wrote: 

		Hi Mohan:

		

		

			that policy.

			 

		Sri

		

	-- 
	Julien Abeillé
	Research Associate
	NEC Europe Ltd.
	Network Laboratories
	Kurfürsten-Anlage 36
	69115 Heidelberg
	GERMANY
	
	tel: +49 6221 43421 19
	fax: +49 6221 43421 55

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 06:39:23 -0500

Hi Alex,
Comments inline.

Regards,
Ahmad

> YEs, this is a behaviour that I'd like to happen (MAG has a 
> route to both MNs through a directly connected interface, and 
> thus MNs talk straight to each other).

[Ahmad]
I am sorry, I do not think there is a room for personal taste or preference here. This is policy based. If the home domain authorizes this behaviour, I am fine with that. Otherwise, the default behaviour is for the MAG to reverse tunnel traffic and there should not be an issue here.

> 
> However, the current Routing Consideration section of the 
> pmipv6 draft says that all traffic from a certain MN address 
> must go the HA.  

[Ahmad]
I agree, that should be the default behaviour and I do not see any problem in it. Again, operators is the one who authorizes the mobility service to start with, and it is home domain who needs to authorize this one, if necessary. It is NOT up to the MAG to decide on this. That means the default behaviour of the MAG as per PMIPv6 draft is correct.

> This prevents the behaviour you mention above.
> 
> This is so because (1) the longest match mechanism is assumed 
> only on the dst address (not on the src) or the PMIPv6 draft 
> assumes that the src address is added to the routing decision 
> and (2) PMIPv6 draft assumes a point-to-point link between 
> MAG and each MN with a prefix-per-mobile semantics (ie each 
> ptp link between MAG and MN has a different prefix) thus no 
> unique connected route for two MNs under same MAG.
> 
> Alex
> 
> > Best regards, Julien
> > 
> > 
> > 
> > 
> > Sri Gundavelli wrote:
> >> Hi Mohan:
> >> 
> >> 
> >> 
> >>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 22 May 2007 13:47:36 +0200

On Tuesday 22 May 2007 03:58, Sri Gundavelli wrote:
> Hi Alex:
> > > - Policy Considerations
> > >
> > > The operator may prefer to block MN to MN
> > > communications and since the LMA is the policy
> > > enforcement point, it must tunnel all the
> > > Direct routing will break the accounting for the
> > > mobile node's accounting.
> > >
> > > But, we can certainly say, if the operator has
> > > configured the MAG to enable direct routing for
> > > MN to MN traffic, the traffic
> >
> > should not be
> >
> > I think I understand the need to develop something
> > that is used by operators.  But I am not sure
> > operators like to overload their fixed networks
> > (link between MAG and LMA) when they can do the
> > MN-MN accounting directly on the covering MAG
> > (instead of LMA).
> >
> > What you seem to say, IMHO, is that you would like
> > to describe both situations: MAG enabled and/or
> > disabled direct routing for MN to MN traffic. 
> > Moreover, I think you see the MN-MN communication
> > (under same
> > I think that should not be the exception but the
> > main method of communication between two MNs under
> > the same MAG.  And if operator doesn't like it,
> > then we can suggest her/him to do accounting on
> > MAG. And if s/he still doesn't like it then we
> > should warn her/him about overloading the network;
> > and finally allow probably an exception for that
> > particular operator.
>
> We have no problem specifying both the approaches.
> But, I do think that the default behaviour is to
> route the traffic back home for the two
> considerations I mentioned. IMO, its a config knob
> on the MAG that the operator needs to turn on, if
> they want to avoid that reverse tunnel and back .
> Lets see what other say and we can switch this
> behaviour, if others have similar opinion.

FWIW in the testbed we're using we decided that all 
traffic between MNs under same MAG will travel via the 
LMA. 

In earlier version of the testbed where traffic between 
MNs under same MAG wasn't going through LMA, when a MN 
handed off to a different MAG, MNs would experience a 
drastic change in the end-to-end path characteristics 
(especially RTT).

This was the cause of a dramatic degradation of some 
transport protocols and real time applications 
performance. For example, streaming applications 
computing the size of their buffer based on RTT would 
be hurt a lot. That's why we changed to the solution 
where all traffic goes to LMA.

IMHO routing-via-LMA vs. routing-via-MAG should be left 
as a deployment choice, as Christian suggested.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 13:49:43 +0200

Ahmad Muhanna wrote:
> Hi,
> 
> That behavior is dependent on the home network policy. Unless MAG is 
> authorized to do so, it should reverse tunnel traffic by default or 
> the MN has established RO with that CN (as per RFC3775). I am not 
> sure why this seems to be an issue here.

Because with rfc3775 the MN has the possibility to use its CoA to
communicate to other MN under same AR (if it wants to not go to HA).
Whereas with PMIPv6 this is not an option (there's no CoA).

> Home domain is the one who authorizes the MN service to start with. 
> If all other setup and requirements are met, e.g. billing is done by 
> the MAG, for example, there is no problem. BUT all dependent on 
> approval by the home domain. IMO.

YEs and no.

Typically this is the common gsm/umts handset behaviour (ask home before
any communication).  But it is far from being a laptop behaviour (laptop
can use tunnel to corporate, or direct local communication - as its
owner prefers).

I prefer this latter way of working.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 06:54:01 -0500

Hi Alex,
I do not think we disagree on the merit of the technicality of this
issue here. It is rather obvious. However, IMO, Home domain is the one
to decide on this behavior. I hope we can hear from operators for some
guidance here.

Also, on the case of RFC3775, MN can use its CoA after establishing RO.
However, if that is not established, the default behavior is reverse
tunneling.

Regards,
Ahmad

> Sent: Tuesday, May 22, 2007 6:50 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Julien Abeille; Sri Gundavelli; netlmm
> Subject: Re: [netlmm] RE: Some issues with the Routing 
> > the MN has established RO with that CN (as per RFC3775). I 
> am not sure 
> > why this seems to be an issue here.
> 
> Because with rfc3775 the MN has the possibility to use its 
> CoA to communicate to other MN under same AR (if it wants to 
> not go to HA).
> Typically this is the common gsm/umts handset behaviour (ask 
> home before any communication).  But it is far from being a 
> laptop behaviour (laptop can use tunnel to corporate, or 
> direct local communication - as its owner prefers).
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 06:56:21 -0500

> 
> Sri Gundavelli wrote:
> > ...
> > 
> > So, IMO, we can specify the operation in either of the 
> above two ways 
> > and it will be up to the implementers as how they choose to 
> implement. 
> > After all its the local forwarding behavior and has no 
> impact on the 
> > inter-operability. But, I do think, the latter approach provides 
> > better guidance and proper decoupling between the control and data 
> > plane. But, I will let others comment on this and express their 
> > preference. I'm fine either way and will document the consensus.
> 
> Given that the binding update list on the MAG includes a MN 
> identifier, the MN's MAC address, and the MN's home address, 
> and given that all of these values by definition uniquely 
> identify the MN, would it be possible to leave it up to the 
> MAG which of the values it uses in identifying the right 
> tunnel for packets from a particular MN?
> 

[Ahmad]
I do not see this issue falling under the MAG authorities as a default
behavior. I believe the final decision , IMO, MUST be as per home domain
policy. I understand the optimization issue here, but without home
domain approval, we may end up offering this MN a free service where
operator needs to be informed.

IMO, the question here is: how can Home domain authorizes this service
vs. not authorizing it.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 07:05:36 -0500

> > But, I do think that the default behaviour is to route the traffic 
> > back home for the two considerations I mentioned. IMO, its a config 
> > knob on the MAG that the operator needs to turn on, if they want to 
> > avoid that reverse tunnel and back .
> > Lets see what other say and we can switch this behaviour, if others 
> > have similar opinion.
> 
> FWIW in the testbed we're using we decided that all traffic 
> between MNs under same MAG will travel via the LMA. 

[Ahmad]
Well, does that mean we need to mandate this here without being
authorized by home domain?
> 
> In earlier version of the testbed where traffic between MNs 
> under same MAG wasn't going through LMA, when a MN handed off 
> to a different MAG, MNs would experience a drastic change in 
> the end-to-end path characteristics (especially RTT).

[Ahmad]
Agreed. That is why this service needs to be OFFERED only based on home
domain authorization. What you just said exactly the reason I am trying
to highlight. If the MN has an IRON status and tries to use VoIP, it
should not have the same experience and quality as another MN with a
premium subscription. i.e. one cost more than the other; $$$.

As I said in my response to Christian, probably the question we need to
answer here is: home domain can authorize vs. not authorize this
service?
> transport protocols and real time applications performance. 
> For example, streaming applications computing the size of 
> their buffer based on RTT would be hurt a lot. That's why we 
> changed to the solution where all traffic goes to LMA.

[Ahmad]
Please see comment above.
> 
> IMHO routing-via-LMA vs. routing-via-MAG should be left as a 
> deployment choice, as Christian suggested.

[Ahmad]
I disagree. Any solution needs to preserve the right of the operator,
Home domain.

---

From: <[email-masked]>
Date: Tue, 22 May 2007 14:39:39 +0200

Hi Ahman, et al

> Hi Alex,
> I do not think we disagree on the merit of the technicality 
> of this issue here. It is rather obvious. However, IMO, Home 
> domain is the one to decide on this behavior. I hope we can 
> hear from operators for some guidance here.

<operator hat on>
I want to second what Ahmad said earlier on the list. Both
options should be there, selectable by the home operator
defined policy. Default policy having everything routed via
LMA is a 'safe' choice.

Cheers,
	jouni

> However, if that is not established, the default behavior is 
> reverse tunneling.
> 
> Regards,
> Ahmad
>  
> 
> Considerations 
> > Typically this is the common gsm/umts handset behaviour (ask home 
> > before any communication).  But it is far from being a laptop 
> > behaviour (laptop can use tunnel to corporate, or direct local 
> > communication - as its owner prefers).
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 14:58:37 +0200

Hi Ahmad,

Ahmad Muhanna wrote:
> Hi Alex, Comments inline.
> 
> Regards, Ahmad
> 
> 
>> YEs, this is a behaviour that I'd like to happen (MAG has a route 
>> to both MNs through a directly connected interface, and thus MNs 
>> talk straight to each other).
> 
> [Ahmad] I am sorry, I do not think there is a room for personal taste
>  or preference here. This is policy based.

I'm sorry but we violently disagree :-)  Who defines that policy? - you?

> If the home domain authorizes this behaviour, I am fine with that. 
> Otherwise, the default behaviour is for the MAG to reverse tunnel 
> traffic and there should not be an issue here.

I do agree with MIP principle to reverse tunnel everything but *only*
when that is a MN decision.  I do not agree with MAG to make this
decision on behalf of MN and neither to hardcode that decision in a
protocol.

>> However, the current Routing Consideration section of the pmipv6 
>> draft says that all traffic from a certain MN address must go the 
>> HA.
> 
> [Ahmad] I agree, that should be the default behaviour and I do not 
> see any problem in it. Again, operators is the one who authorizes the
>  mobility service to start with, and it is home domain who needs to 
> authorize this one, if necessary. It is NOT up to the MAG to decide 
> on this. That means the default behaviour of the MAG as per PMIPv6 
> draft is correct.

I think we talk different deployment models here.

I assume the same operator controls both LMA and MAG and thus operator
can account on MAG instead of LMA.  You seem to assume that LMA and MAG
are owned by different operators.

While this balance between responsibility between different operators
should be left open to most innovative deployment and business models I
think the MN should be left the freedom of choice as well (and the
absence of CoA means the mobile is bound to that HoA).

The protocol should _not_ make such a decision based on an assumption of
what a certain operator would do.

There are operators of WiFi networks which do not prefer this MN-MN
communication to go beyond the Access Point, at least because they will
unnecessarily be charged themselves by their DSL operator.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:03:21 +0200

> to decide on this behavior. I hope we can hear from operators for some

If the home domain forces a MN into a restricted Home Address then the 
MN will not use that remote Home Address, it is obvious, at least for 
performance reasons.  The MN will prefer a local address that is less 
restricted to travel to a remote home domain.

> However, if that is not established, the default behavior is reverse

I meant 3775-MN can use its CoA without establishing RO.  It's free to 
do so.  It looses reachability and session continuity at permanent HoA, 
but it can still bypass all communication with its HA.  RFC3775 doesn't 
impose to always go through HA, nor to always do RO.

This should be an option with pmipv6 as well.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:21:16 +0200

Julien Laganier wrote:
>>> I think I understand the need to develop something that is used
>>> by operators.  But I am not sure operators like to overload their
>>> fixed networks (link between MAG and LMA) when they can do the 
>>> MN-MN accounting directly on the covering MAG (instead of LMA).
>>> 
>>> What you seem to say, IMHO, is that you would like to describe
>>> both situations: MAG enabled and/or disabled direct routing for
>>> MN to MN traffic. Moreover, I think you see the MN-MN
>>> communication (under same MAG) as an exception that _could_ be
>>> described.
>>> 
>>> communication between two MNs under the same MAG.  And if
>>> operator doesn't like it, then we can suggest her/him to do
>>> accounting on MAG. And if s/he still doesn't like it then we 
>>> should warn her/him about overloading the network; and finally
>>> allow probably an exception for that particular operator.
>> that the default behaviour is to route the traffic back home for
>> the two considerations I mentioned. IMO, its a config knob on the
>> MAG that the operator needs to turn on, if they want to avoid that
> FWIW in the testbed we're using we decided that all traffic between
> MNs under same MAG will travel via the LMA.
> 
> In earlier version of the testbed where traffic between MNs under
> same MAG wasn't going through LMA, when a MN handed off to a
> different MAG, MNs would experience a drastic change in the
> end-to-end path characteristics (especially RTT).

Could you clarify the difference in RTT?  I wouldn't qualify it as
drastic.  I don't think it is an order of magnitude higher, like 10 vs
100.  I think the difference is a fifth of RTT, which is very small.

[I think that if straight latency between two MNs under same MAG is t
  then latency between two MNs under different MAGs and through LMA is
  less than t+t/5 (wireless latency is usually 10 times more than wired
  latency).  This is very little difference in RTT.]

> This was the cause of a dramatic degradation of some transport
> protocols and real time applications performance. For example,
> streaming applications computing the size of their buffer based on
> RTT would be hurt a lot. That's why we changed to the solution where
> all traffic goes to LMA.
> 
> deployment choice,

I agree.

> as Christian suggested.

I think he suggested only to use several alternative ids in addition to
just src address, but I think he didn't complain about "all packets from
this MN go to HA".

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:26:38 +0200

Julien Abeille wrote:
> Hi Alexandru,
> 
> Thanks for your answer. In the end it is just a matter of deciding 
> whether this feature is included in the base spec or as part of a 
> Route Optimization extension then?

IMHO the PMIPv6 draft largely overspecifies when it says to forward
packets from a certain source address to a certain destination.  BEtter
if it were silent in this respect, IMHO.

> Note that if the routing based on the src address is accepted, I
> think a route optimization extension should also use this mechanism:
> if you establish RO for MN1 to a CN, the routing installed on the MAG
> should be only for MN1 in my opinion. No other MN should take
> advantage of the RO states and forwarding installed on the MAG for
> MN1.

I somehow agree with you, RO done by MAG for MN1 should only be for MN1 
and not for MN.  Sounds as a host-based route and I agree with it.

I have however many more unknowns about how MAG could do a evolved 
3775-RO on behalf of MN...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:33:45 +0200

[email-masked] wrote:
> Hi Ahman, et al
> 
>> Hi Alex, I do not think we disagree on the merit of the 
>> technicality of this issue here. It is rather obvious. However, 
>> IMO, Home domain is the one to decide on this behavior. I hope we 
>> can hear from operators for some guidance here.
> 
> <operator hat on> I want to second what Ahmad said earlier on the 
> list. Both options should be there, selectable by the home operator 
> defined policy. Default policy having everything routed via LMA is a 
> 'safe' choice.

Jouni, what kind of operator is this?

Is it an operator that controls both the access network and the home
network?  Or an operator that controls both of these?

In a gsm operator traditional model, my call to a US mobile won't go to
my home in France if I'm roaming in US.  So a safe assumption with a
traditional operator is to not route everything back to home.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 22 May 2007 15:41:43 +0200

Alex:

On Tuesday 22 May 2007 15:21, Alexandru Petrescu wrote:
> Julien Laganier wrote:
> >
> > FWIW in the testbed we're using we decided that
> > all traffic between MNs under same MAG will travel
> > via the LMA.
> >
> > In earlier version of the testbed where traffic
> > between MNs under same MAG wasn't going through
> > LMA, when a MN handed off to a different MAG, MNs
> > would experience a drastic change in the
> Could you clarify the difference in RTT?  I wouldn't
> qualify it as drastic.  I don't think it is an order
> of magnitude higher, like 10 vs 100.  I think the
> difference is a fifth of RTT, which is very small.
>
> [I think that if straight latency between two MNs
> under same MAG is t then latency between two MNs
> under different MAGs and through LMA is less than
> t+t/5 (wireless latency is usually 10 times more
> than wired latency).  This is very little difference
> in RTT.]

The difference in RTT depends entirely on the 
deployment (that's why I'm saying that routing via LMA 
or not should be left as a deployment matter). 

Our testbed has an 802.11 radio access network where 
RTT between two nodes can be as low as 0.2ms, i.e. RTT 
between two MNs through MAG around 0.4ms. The core 
network we're using to connect LMA with MAGs has 50ms 
RTT. 

In that case the difference is dramatic (x125), but of 
course in a different deployment YMMV.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 08:44:25 -0500

Hi Alex,

> I'm sorry but we violently disagree :-)  Who defines that 

[Ahmad]
Absolutely NOT. OPERATOR IS the one who decides.
We so far heard from one operator. I hope we hear from more operators.
> I do agree with MIP principle to reverse tunnel everything 
> but *only* when that is a MN decision.  I do not agree with 
> MAG to make this decision on behalf of MN and neither to 
> hardcode that decision in a protocol.

[Ahmad]
Alex, it is meaningless to turn this into a religious debate. It is very
simple. 
I agree with you, the MN is the one to decide on this; however, UNDER
ONE CONDITION: "This MN has its own operator SLA agreement with the
visiting network (MAG & LMA) and that agreement authorize the behaviour
you just mentioned.
> >> draft says that all traffic from a certain MN address must 
> go the HA.
> > 
> > [Ahmad] I agree, that should be the default behaviour and I 
> do not see 
> > any problem in it. Again, operators is the one who authorizes the  
> > authorize this one, if necessary. It is NOT up to the MAG 
> to decide on 
> > this. That means the default behaviour of the MAG as per 
> PMIPv6 draft 
> > is correct.
> 

[Ahmad]
Absolutely. I just would like to rephrase what you just said. In other
words, what you just said is: different home domain deployment/policies
models. 
First: Home domain deployment/policy is a blank check to the visiting
domain (MAG) to allow RO by default.
Second: Home domain deployment/policy is to allow this service on a case
by case bases.

i.e. default behavior for the MAG where the policy is not communicated
to the MAG from the home domain IS: REVERSE TUNNEL EVERYTHING.

> 
> I assume the same operator controls both LMA and MAG and thus 
> operator can account on MAG instead of LMA.  You seem to 
> assume that LMA and MAG are owned by different operators.

[Ahmad]
Please see the above comment. It does not contradict with what you just
said.
> 
> While this balance between responsibility between different 
> operators should be left open to most innovative deployment 
> and business models I think the MN should be left the freedom 
> of choice as well (and the absence of CoA means the mobile is 
> bound to that HoA).

[Ahmad]
Agreed, the MN SHOULD have the freedom of choice as long as it is within
the home domain authorization and policy. Let us face it, if this MN is
authorized to receive this service, it is FREE to do whatever it needs
to do. Hey, the MN has already paid for the service anyway. IMO: the MN
should not receive a service that it did not pay for.

> 
> The protocol should _not_ make such a decision based on an 
> assumption of what a certain operator would do.
> 
> There are operators of WiFi networks which do not prefer this 
> MN-MN communication to go beyond the Access Point, at least 
> because they will unnecessarily be charged themselves by 
> their DSL operator.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:57:09 +0200

Sri, see below.

As a separate issue, why do you think there should be several LMAs (in
different subnets) for a MAG?  If there is only one LMA per lmm then
this src-based lookup is not needed at all.  The LMA address can be
hard-coded in every MAG.  DHCP Relays and Server work this way.

Alex

Sri Gundavelli wrote:
>> I am not sure which paragraph you refer to in rfc3024.  Could you 
>> please point me to it?  I'm guessing it is in section 5.2.2?
>> 
>> sec 5.2.2 of rfc3024:
>>> IP fields (encapsulating header): Source Address = foreign 
>>> agent's care-of address Destination Address = home agent's 
>>> address Protocol field: 4 (IP in IP) IP fields (original header):
>>>  Source Address = mobile node's home address Destination Address 
>>> = correspondent host's address Upper Layer Protocol
>>> 
> address of the outer header to the address in the Home Agent field of
>  a recently received RRP for that mobile. So, for each packet there 
> is a lookup required for finding the recently accepted RRP. The 
> lookup can't be based on any other fields in the packet, other than 
> the source IP address or the MAC address.
[...]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 15:57:20 +0200

Sri, see below.

> the source IP address or the MAC address.

Ok, so FA writes in dst the address it received in the src of a RRP
corresponding to a MN HoA.  And there is a lookup keyed by that HoA to
find that src address.

But this does not mean that the packet is routed based on its source
address.  Encapsulating a packet maybe yes.  But the routing happens on
the dst address.  I think this is a misunderstanding of interpretation
of that RFC.

> So, for the implementers there is no other choice, whether the draft 
> says it or not, other than doing a source based lookup.

YEs, there is a source based lookup to find which HA corresponds to that
MN.  But once the encapsulated packet is constructed it's going to be
routed based on the dst address...

> This also implicitly expects the foreign agent to intercept every 
> packet.

Yes, and it is the case for MAG as well - it must intercept every packet
to MN.

> that tunnel interface.

Yes, that _may_ be a way of implementing it, using such a tunnel
interface.  But why not writing the PMIPv6 spec like the rfc3024 is
written, saying where to find the various src and dst addresses and how
to encapsulated - and not saying to use tunnel interface and to route
based on src address.

> This source based rule or a PBR, specifies any packets with the 
> following IP source address or the MAC address need to be routed 
> through this tunnel. This does not expect the MAG to intercept every 
> packet. Its a routing rule that goes into the forwarding process.

Disagree to bring this into the forwarding process.  Disagree to make
this a policy rule.

> So, IMO, we can specify the operation in either of the above two ways
> impact on the inter-operability. But, I do think, the latter approach
>  provides better guidance and proper decoupling between the control 
> and data plane. But, I will let others comment on this and express 
> their preference. I'm fine either way and will document the 
> consensus.

Ok.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 16:06:11 +0200

Julien Laganier wrote:
>> drastic.  I don't think it is an order of magnitude higher, like 10
>> vs 100.  I think the difference is a fifth of RTT, which is very
>> small.
>> 
>> [I think that if straight latency between two MNs under same MAG is
>> t then latency between two MNs under different MAGs and through LMA
>> is less than t+t/5 (wireless latency is usually 10 times more than
>> wired latency).  This is very little difference in RTT.]
> 
> The difference in RTT depends entirely on the deployment (that's why
> I'm saying that routing via LMA or not should be left as a deployment
> matter).
> 
> Our testbed has an 802.11 radio access network where RTT between two
> nodes can be as low as 0.2ms, i.e. RTT between two MNs through MAG
> around 0.4ms. The core network we're using to connect LMA with MAGs
> has 50ms RTT.

50ms RTT for a core network?  This is surprising.  I think there is an 
old and loaded 10mbps between MAG and LMA, or maybe many routers in between.

It is surprising _if_ you used 0.2ms on wireless (a relatively recent 
wifi, maybe 802.11g or n) and an old 10mbps in the core, or a very 
distanced LMA-MAG connection.

> In that case the difference is dramatic (x125), but of course in a
> different deployment YMMV.

YEs.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 16:18:51 +0200

Ahmad Muhanna wrote:
>>>>> has a route to both MNs through a directly connected
>>>>> interface. Therefore (still dependent on implementation),
>>>>> receiving a
>>>> packet from
>>>> both MNs through a directly connected interface, and thus MNs
> [Ahmad] Absolutely NOT. OPERATOR IS the one who decides.

I'm sorry, we're not under contract with operators here.

> We so far heard from one operator. I hope we hear from more

I think operators have other places to meet.

>>> If the home domain authorizes this behaviour, I am fine with
>>> that. Otherwise, the default behaviour is for the MAG to reverse
>>> tunnel traffic and there should not be an issue here.
>> I do agree with MIP principle to reverse tunnel everything but
>> *only* when that is a MN decision.  I do not agree with MAG to make
>> this decision on behalf of MN and neither to hardcode that decision
>> in a protocol.
> 
> [Ahmad] Alex, it is meaningless to turn this into a religious debate.
> It is very simple. I agree with you, the MN is the one to decide on
> this; however, UNDER ONE CONDITION: "This MN has its own operator SLA
> agreement with the visiting network (MAG & LMA) and that agreement
> authorize the behaviour you just mentioned.

Yes, but these kinds of agreements are not like the monthly subscription
an end user pays to a cell operator, and even less like a yearly SLA
signed between operators and business sites.

These can be very ephemeral 1-hour agreements that come and go as we
speak.  In such conditions it's difficult to decide for 'knob' behaviour
at MAG.

>>>> must
>>>  mobility service to start with, and it is home domain who needs
>>> to authorize this one, if necessary. It is NOT up to the MAG
>> to decide on
> [Ahmad] Absolutely. I just would like to rephrase what you just said.
> In other words, what you just said is: different home domain
> deployment/policies models.

YEs.

>  domain (MAG) to allow RO by default. Second: Home domain
> deployment/policy is to allow this service on a case by case bases.
> 
> i.e. default behavior for the MAG where the policy is not
> communicated to the MAG from the home domain IS: REVERSE TUNNEL
> EVERYTHING.

I think this is completely wrong.

I think the home domain should just authorize the MN and then leave all
communication to be managed by the foreign domain.

One reason why MIP4 and MIP6 reverse tunnel everything (when not doing 
RO) is technical: avoid asymmetrical or triangular paths.  I think there 
is no operator reasoning used to motivate MIP4 and MIP6 reverse tunelling.

>> operator can account on MAG instead of LMA.  You seem to assume
>> that LMA and MAG are owned by different operators.
> 
> [Ahmad] Please see the above comment. It does not contradict with
> what you just said.
>> operators should be left open to most innovative deployment and
>> business models I think the MN should be left the freedom of choice
>> as well (and the absence of CoA means the mobile is bound to that
>> HoA).
> 
> [Ahmad] Agreed, the MN SHOULD have the freedom of choice as long as
> it is within the home domain authorization and policy. Let us face
> it, if this MN is authorized to receive this service, it is FREE to
> do whatever it needs to do. Hey, the MN has already paid for the
> service anyway. IMO: the MN should not receive a service that it did
> not pay for.

Sounds sane to me.

But there are business models where a flat fee means that some consumers
consume much more than others (but overall operator still gains), and in
some cases one can say that somebody does more than what s/he paid for...

We go into economy models...

What's the sense of forcing one's understanding of how to make money
into a protocol?

Alex

>> communication to go beyond the Access Point, at least because they
>> will unnecessarily be charged themselves by their DSL operator.
>> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 May 2007 09:48:40 -0500

> I'm sorry, we're not under contract with operators here.

[Ahmad]
If we are in disconnect, then we are designing something in vacuum which
probably would never be deployed. In that case, we may stop arguing and
go back to do something else!

> I think operators have other places to meet.

[Ahmad]
I am sorry; I disagree. 
Operators are members here like you and me and their voices make a
difference. I may say BIG difference.

> Yes, but these kinds of agreements are not like the monthly 
> subscription an end user pays to a cell operator, and even 
> less like a yearly SLA signed between operators and business sites.
> 
> These can be very ephemeral 1-hour agreements that come and 
> go as we speak.  In such conditions it's difficult to decide 
> for 'knob' behaviour at MAG.

[Ahmad]
FINE. Then you agree that this is a policy based decision NOT a granted
behaviour by default.

> >>>> pmipv6 draft says that all traffic from a certain MN address must
> >> go the HA.

[Ahmad]
Good. We are converging then.

> communicated 

[Ahmad]
Ok, I guess we are not converging!:(
> 
> I think the home domain should just authorize the MN and then 
> leave all communication to be managed by the foreign domain.

[Ahmad]
Good. We are converging but using different words. Authorization means a
lot of things, one of the services that the MN needs to be authorized
for, RO which include the case we are discussing here. I hope and pray
that we are not going to diverge again!:)
> RO) is technical: avoid asymmetrical or triangular paths.  I 
> think there is no operator reasoning used to motivate MIP4 
> and MIP6 reverse tunelling.

[Ahmad]
Alex, I can debate this with you for as long as you want, however, it
should be either offlist or on a different thread not linked to PMIPv6.
But very simply I would like to say the following:

In order for any Mobile Node to receive IP mobility service when travels
away from home, it needs to have an IP address anchored at a router
beyond the very immediate access link attachment that it is visiting.
Long time ago, people called this ROUTER, Home Agent.

In all non roaming scenarios, i.e. the MN is at home, the home domain
can enforce its own policies on the MN via home domain Router(s).
However, when the MN departs from its home domain and travels abroad,
the MN needs to keep its parents involved as if it never left home
(otherwise they will unplug the wire!:). 

In all cases, it is still the parents/home domain who give the
authorization to what service the traveling MN can receive.

Even in MIPv4, HA always have the right to reject RRQ if the HA policy
mandates reverse tunneling and the RRQ does not have the RT bit set.

Although, Reverse tunneling has a technical merit as you said but its
enforcement is based on home domain POLICY.

> assume that 
> >> LMA and MAG are owned by different operators.
> > 
> > [Ahmad] Please see the above comment. It does not 
> contradict with what 
> > you just said.
> >> should be left open to most innovative deployment and 
> business models 
> >> I think the MN should be left the freedom of choice as 
> well (and the 
> > [Ahmad] Agreed, the MN SHOULD have the freedom of choice as 
> long as it 
> > is within the home domain authorization and policy. Let us 
> face it, if 
> > this MN is authorized to receive this service, it is FREE to do 
> > whatever it needs to do. Hey, the MN has already paid for 
> the service 
> > anyway. IMO: the MN should not receive a service that it 
> did not pay 
> > for.
> 
> Sounds sane to me.
> 
> But there are business models where a flat fee means that 
> some consumers consume much more than others (but overall 
> operator still gains), and in some cases one can say that 
> somebody does more than what s/he paid for...
> 
> What's the sense of forcing one's understanding of how to 
> make money into a protocol?
> 
> Alex
> 
> _____________________________________________________________________
> >> _  This email has been scanned by the MessageLabs Email Security

---

From: "SEITE Pierrick RD-RESA-REN" <[email-masked]>
Date: Tue, 22 May 2007 16:50:01 +0200

Hi,

<also with operator hat on>

I agree with Jouni, in the home domain, the default can be to route data via the LMA.

Of course, PMIP should allow route optimization (I think we all agree...). But the choice to run optimization or not should be left to the operator, it is "just" a matter of deployment choice (as suggested many times on the list)

Pierrick

-----Message d'origine-----
De : Alexandru Petrescu [mailto:[email-masked]] 
Envoyé : mardi 22 mai 2007 15:34
À : [email-masked]
Cc : [email-masked]
Objet : Re: Kinds of operators and their policies (was: [netlmm] RE: Someissues with the Routing Considerationssectionofdraft-ietf-netlmm-proxymip6-00.txt)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 May 2007 17:21:39 +0200

Hi Pierrick,

Thanks for the message.

I also wanted to say that although my previous mail may have made it 
look contentious with respect to operators - my fault - I completely 
agree that different operators have different needs and in many cases we 
need to develop something not in a vacuum (to cite Ahmad) and which is 
needed by operators.

Alex

SEITE Pierrick RD-RESA-REN wrote:
> Of course, PMIP should allow route optimization (I think we all 
> agree...). But the choice to run optimization or not should be left 
> to the operator, it is "just" a matter of deployment choice (as 
> suggested many times on the list)
> 
> Pierrick
> 
> -----Message d'origine----- De : Alexandru Petrescu 
> [mailto:[email-masked]] Envoyé : mardi 22 mai 2007 
> 15:34 À : [email-masked] Cc : [email-masked] Objet :
>  Re: Kinds of operators and their policies (was: [netlmm] RE: 
> Someissues with the Routing 
> Considerationssectionofdraft-ietf-netlmm-proxymip6-00.txt)
> 
>>  defined policy. Default policy having everything routed via LMA is
>>  a 'safe' choice.
> 
> In a gsm operator traditional model, my call to a US mobile won't go 
> to my home in France if I'm roaming in US.  So a safe assumption with
>  a traditional operator is to not route everything back to home.
> 
> Alex
> 
>

---

From: <[email-masked]>
Date: Tue, 22 May 2007 19:37:25 +0200

Alex,

> technicality 
> >> of this issue here. It is rather obvious. However, IMO, 
> Home domain 
> >> is the one to decide on this behavior. I hope we can hear from 
> >> operators for some guidance here.
> > 
> LMA is a 
> Is it an operator that controls both the access network and 
> the home network?  Or an operator that controls both of these?
> 
> In a gsm operator traditional model, my call to a US mobile 
> won't go to my home in France if I'm roaming in US.  So a 

Can be true for your outgoing calls while roaming.. most
probably not for your incoming calls ;-)

Anyway, data roaming is slightly different than cs voice roaming.
Don't recall e.g. too many GPRS operators that allow use of
visited network GGSNs today. These things change gradually..
hopefully.

> safe assumption with a traditional operator is to not route 
> everything back to home.

Things like route optimization (between MNs under the same MAG
or between MNs under different MAGs - these cases are slightly
different) are definitely on the wish list, it is not question
about that. But there must to be ways to configure those
dynamically e.g. based on policies and roaming contracts.

/Jouni

---

From: Sebastian Thalanany <[email-masked]>
Date: Tue, 22 May 2007 15:08:30 -0500

Hi, Jouni,
                      Yes, I would support the notion of a home domain 
policy driven behavior for the routing of bearer traffic (localized at 
the MAG, or reverse tunneled via the LMA).

                       Thanks.

Regards,
     Sebastian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 May 2007 13:27:37 -0700

Alex:

>From the below text its clear, 3775 does not permit the MN
to send the traffic bypassing the MN-HA tunnel, unless RO
is in place. Given the reasons related to accounting, policy
enforcement, also from the operator input provided by Jouni,
Pierrick and also feed back from Ahmad and others, I think
we should default the mechanism of MAG routing the traffic
back to the LMA. Offcourse, we can also specify the method
of enabling direct routing when the config knob is turned
on. Can we close this issue now  ?

Thanks
Sri

> Sent: Monday, May 21, 2007 11:37 PM
> To: 'Ahmad Muhanna'; 'Kandra Mohan-a22098'; 'Alexandru Petrescu'
> Cc: 'netlmm'
> Considerationssection ofdraft-ietf-netlmm-proxymip6-00.txt
> 
> > "

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 22 May 2007 14:29:32 -0700

<WG Chair Hat Off>

Just a quick comment on the text below from Section 10.4.5 of RFC3775 -
the text is referring to the fact that unless RO is performed with the
CN, the CN will not have the necessary binding to process the Home
Address destination option on a packet that would be sent directly from
the MN to the CN.  And, conversely, the CN will not send packets using
the Type2 Routing Header and hence, the packets will not be sent
directly to the MN.  This is also referring to packets meant to be
sourced from/to the HoA, but are sent from/to the CoA to be
sourcing/receiving on a topologically correct address.  This means that
without RO, the MN cannot send packets from its HoA to the CN and expect
those to be processed and hence, those packets will have to be reverse
tunneled through the HA. 

As far as I know, this (or any other part of RFC3775) makes no
assumptions on the HA authorizing RO for MNs. I can see how it is
possible to have an HA configured to disallow RO, but, RFC3775 does not
address those aspects. 

Also, an MN can always choose to use its CoA to communicate with any
node and that is outside the scope of Mobile IP at that point.  It is
just regular IP communication, with no mobility support for the address
in use. 

That aside, the current discussion seems to be around whether direct
routing at a MAG should be permitted for MNs that are directly attached
to it at a given time.  The The MN's IP prefixes and addresses are
rooted at the LMA and hence, by default, the MAG would route that to the
LMA (I would think this would be analogous to MIP4 Foreign Agent
behavior).  The routing entry for the MN, when created from a PBU/PBA
exchange, would point to the LMA, I would imagine.  If the MAG had to
perform direct routing, it must be keeping track of all the MNs attached
to it and perform more specific routing for those.  Since it is not a
simple case of MAG acting as a generic router (i.e., the MN's prefixes
are not local to the MAG), it does seem like this constitutes a case of
RO in PMIP.  

</WG Chair Hat Off>

<WG Chair Hat On>

Route optimization is currently out of scope in our charter for the base
protocol.  We will get a chance to discuss the importance of it and add
it to the charter upon re-chartering if there is sufficient interest.
But, as far as the base document goes, we should  leave RO out. 

</WG Chair Hat On>

Regards,
Vidya

> Sent: Tuesday, May 22, 2007 1:28 PM
> To: 'Alexandru Petrescu'
> Cc: 'netlmm'
> Subject: RE: [netlmm] RE: Some issues with the 
> RoutingConsiderationssection ofdraft-ietf-netlmm-proxymip6-00.txt
> 
> 
> Alex:
> 
> to send the traffic bypassing the MN-HA tunnel, unless RO is 
> in place. Given the reasons related to accounting, policy 
> Pierrick and also feed back from Ahmad and others, I think we 
> should default the mechanism of MAG routing the traffic back 
> to the LMA. Offcourse, we can also specify the method of 
> enabling direct routing when the config knob is turned on. 
> Can we close this issue now  ?
> 
> Thanks
> Sri
> 
>  
> 
> > This is a good point. Now, lets put the CN right on the same link 
> > where the MN is connected. Per 3775, the packet needs to go back in 
> > the tunnel.
> > the packets directly unless the RO is in place, and that 
> can be very 
> > well be denied by the home agent. Thanks for this pointer.
> > 
> > Thanks
> > Sri
> >
> 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 22 May 2007 16:27:07 -0700

Agree with Vidya.

> are not local to the MAG), it does seem like this constitutes a case of

In fact I would say there is nothing to standardize here. Supporting
this can be done in an implementation specific manner on the MAG. 

I also agree that the LMA should be able to disable this behavior on 
the MAG if it wants to. But this becomes a deployment issue. However,
we could standardize a mobility option that can carried in the Proxy 
BU/Proxy BAck if required. The LMA would be able to tell the MAG what
to do using the mobility option.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 May 2007 21:59:55 -0700

Local routing on the MAG cannot be completely equated to the
RO procedure defined in 3775. Reasons:

- CN is not establishing a relation between HoA and CoA.
- MN is not sending the traffic using CoA, nor its asking
  the CN to create a relation between the two.

However, it is a path optimization, the end result of a
successful RO procedure in 3775. IMO, since there is no
security implications, we should allow this as a non-default
behavior, enabled using a config knob. Or, atleast we should
not have explicit text disallowing this case. Leave it to
the implementation/deployments. Because, reverse tunneling is
not mandatory in MIP4 either, if that guidance helps.

W.r.t routing, the MAG would have a directly connected route
for each of the attached mobile node's home prefixes. So,
its indeed just a longest prefix match rule that gives the
shorter path. When this enabled, the tunnel default route
should be bypassed for connected destination prefixes.

Bottom line, IMO, we should have the tunnel route as the
default and the local routing as an optimization than is
determined by the local MAG policy.

Sri

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, May 22, 2007 4:27 PM

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 May 2007 22:07:56 -0700

Hi Christian,

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Tuesday, May 22, 2007 2:25 AM
> To: Sri Gundavelli; 'Alexandru Petrescu'
> Cc: 'netlmm'
> Considerations section of draft-ietf-netlmm-proxymip6-00.txt
> 
> Sri Gundavelli wrote:
> > ...
> > 
> identifier,

Sure, from the parameters in the packet, either the MAC address or
the home address can be used by the MAG to select outgoing tunnel.
Other keys could be the ingress interface identifier (p2p link
between the MAG and the MN), as a possible selector. We can make
this flexible for the implementers to use any of these parameters
for selecting the outgoing tunnel. The text can be generally more
as a suggestive text as supposed to forcing a certain implementation
method.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 May 2007 00:47:38 -0500

Hi Vidya,

Please see comment inline.

Regards,
Ahmad
 
> 
> 
> <WG Chair Hat Off>
> 
> Just a quick comment on the text below from Section 10.4.5 of 
> RFC3775 - the text is referring to the fact that unless RO is 
> performed with the CN, the CN will not have the necessary 
> binding to process the Home Address destination option on a 
> packet that would be sent directly from the MN to the CN.

[Ahmad]
Hi Vidya,
I am not a big fan of this text and I do not want to have a debate here,
however, I would like to comment as follows:

1. This text is under subsection 10.4.5, which is under section "10.
Home Agent Operation"

2. RFC3775 mandates that the MN reverse tunnel traffics to the home
agent, UNLESS a binding has been established with the CN. Only when the
MN establishes a binding with the CN, the MN is able to send traffic
directly to the CN. 

3. RFC3775 did not elaborate what the reasons behind the MN not been
able to establish a binding with the CN, however, what you mentioned
here is one interpretation/reason. Another possible reasons is that the
correspondent node is not able to obtain reasonable assurance that the
mobile node is in fact addressable at its home address. [Possibly due
Home domain policy enforced by the HA].

4. If I would draw a simple comparison between RFC3775 and RFC3344
handling for reverse tunneling, I would say that, as per RFC3344, the HA
is always allowed to reject a request by the MN for not to reverse
tunnel its traffic to the HA. Although, RFC3775 does not address this
explicitly, but, in my mind, RFC3775 specifies one specific mechanism to
allow Direct Delivery, if I may call it that, i.e. return routability
procedure or RO.

5. Having made that comparison, I believe the HA has the right to reject
MN request for "Direct Delivery" based on home domain policy. I agree,
RFC3775 did not offer a clear mechanism for how the HA can do that, but
on the other hand, it did not prohibit it.

> And, conversely, the CN will not send packets using the Type2 
> Routing Header and hence, the packets will not be sent 
> directly to the MN.  This is also referring to packets meant 
> to be sourced from/to the HoA, but are sent from/to the CoA 
> to be sourcing/receiving on a topologically correct address.  
> This means that without RO, the MN cannot send packets from 
> its HoA to the CN and expect those to be processed and hence, 
> those packets will have to be reverse tunneled through the HA. 
> 
> As far as I know, this (or any other part of RFC3775) makes 
> no assumptions on the HA authorizing RO for MNs. I can see 
> how it is possible to have an HA configured to disallow RO, 
> but, RFC3775 does not address those aspects. 
> 
> Also, an MN can always choose to use its CoA to communicate 
> with any node and that is outside the scope of Mobile IP at 
> that point.  It is just regular IP communication, with no 
> mobility support for the address in use. 
> 
> That aside, the current discussion seems to be around whether 
> direct routing at a MAG should be permitted for MNs that are 
> directly attached to it at a given time.  The The MN's IP 
> prefixes and addresses are rooted at the LMA and hence, by 
> default, the MAG would route that to the LMA (I would think 
> this would be analogous to MIP4 Foreign Agent behavior).  The 
> routing entry for the MN, when created from a PBU/PBA 
> exchange, would point to the LMA, I would imagine.  If the 
> MAG had to perform direct routing, it must be keeping track 
> of all the MNs attached to it and perform more specific 
> routing for those.  Since it is not a simple case of MAG 
> acting as a generic router (i.e., the MN's prefixes are not 
> local to the MAG), it does seem like this constitutes a case 
> of RO in PMIP.  
> 
> </WG Chair Hat Off>
> 
> <WG Chair Hat On>
> 
> Route optimization is currently out of scope in our charter 
> for the base protocol.  We will get a chance to discuss the 
> importance of it and add it to the charter upon re-chartering 
> if there is sufficient interest.
> is in place. 
> > Given the reasons related to accounting, policy 
> enforcement, also from 
> > the operator input provided by Jouni, Pierrick and also 
> feed back from 
> > Ahmad and others, I think we should default the mechanism of MAG 
> > routing the traffic back to the LMA. Offcourse, we can also specify 
> > the method of enabling direct routing when the config knob 
> is turned 
> > on.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 May 2007 01:27:51 -0500

Hi Sri,

Please see one comment inline.

Regards,
Ahmad

> theRoutingConsiderationssection ofdraft-ietf-netlmm-proxymip6-00.txt)
> 
> not have explicit text disallowing this case. Leave it to the 
> implementation/deployments. Because, reverse tunneling is not 
> mandatory in MIP4 either, if that guidance helps.
> 
> for each of the attached mobile node's home prefixes. So, its 
> indeed just a longest prefix match rule that gives the 

[Ahmad]
Let me clarify what you meant here. You just said that supporting this
functionality globally, i.e. per the whole box, is a MAG local policy.
However, enforcing this functionality is a per-session based on home
domain policy. The way home domain communicates this policy to the MAG
is out of the scope of PMIP base protocol.

Is that a fair understanding?

Thanks.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 May 2007 23:39:16 -0700

> Is that a fair understanding?

Since, this behavior has an impact on the accounting, I do think
the LMA/Home Domain Policy should have control on this aspect. I
should rather add "determined by the local MAG policy, but
enforced by the home domain policy", as you correctly described.
The enforcement semantics or the messaging is beyond the scope
of the base doc, again, as you emphasized.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 May 2007 01:44:35 -0500

Hi Sri,

> Since, this behavior has an impact on the accounting, I do 
> think the LMA/Home Domain Policy should have control on this 
> aspect. I should rather add "determined by the local MAG 
> policy, but enforced by the home domain policy", as you 
> correctly described.

[Ahmad]
Excellent, you nicely captured my 5 lines in few words!:)

> The enforcement semantics or the messaging is beyond the 
> scope of the base doc, again, as you emphasized.
> 
> Thanks
> Sri
>

---

From: <[email-masked]>
Date: Wed, 23 May 2007 08:54:29 +0200

Sri,

>   the CN to create a relation between the two.

Agree.

> mandatory in MIP4 either, if that guidance helps.

Agree.

Just to be more explicit I think we should mention these two
different optimization cases and their characteristics:

 o MNs anchored to the same MAG. Does not need explicit RO
   procedure, just a config knob.

 o MNs anchored to two different MAGs under the same LMA. This
   would need some explicit RO procedure.

I see good usecases for both... (e.g. to offload traffic away
from the LMA).

Details are for future work anyway.

Cheers,
	Jouni

---

From: "Christian Vogt" <[email-masked]>
Date: Wed, 23 May 2007 13:24:06 +0300 (EEST)

> IMO, the question here is: how can Home domain authorizes this service

Ahmad,

my comment refers to how the MAG identifies a mobile node.  Authorization
comes afterwards based on that identification and, certainly, has to be
in-line with home domain policies.

- Christian

---

From: "Christian Vogt" <[email-masked]>
Date: Wed, 23 May 2007 13:28:08 +0300 (EEST)

>> [Christian]  Given that the binding update list on the MAG includes a
>> MN identifier,
> [Sri]  Sure, from the parameters in the packet, either the MAC address
> or the home address can be used by the MAG to select outgoing tunnel.

Excellent, that would be most appropriate IMO.

Thanks,
- Christian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 May 2007 06:46:44 -0500

Hi Christian,
I agree. I am sorry for overlooking this. It was a long day:)

Regards,
Ahmad

> Sent: Wednesday, May 23, 2007 5:24 AM
> Cc: Sri Gundavelli; Alexandru Petrescu; netlmm
> > behavior. I believe the final decision , IMO, MUST be as per home 
> > domain policy. I understand the optimization issue here, 
> but without 
> > home domain approval, we may end up offering this MN a free service 
> > where operator needs to be informed.
> >
> my comment refers to how the MAG identifies a mobile node.  
> Authorization comes afterwards based on that identification 
> and, certainly, has to be in-line with home domain policies.
> 
> - Christian
> 
> 
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 May 2007 14:59:53 +0300

> I agree. I am sorry for overlooking this. It was a long day:)

Oh, don't worry about it.  Not a problem at all. :-)

- Christian

---

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

Hi Jouni,

I agree.

I think, these two cases clearly identify where explicit RO
is required and where local routing can be applied with no
security implications.

Thanks
Sri