Re: [netlmm] Local routing at the MAG

["Koodli, Rajeev" <[e-mail]>]

Hi Vijay,

> I looked at draft-koodli-netlmm-local-forwarding. I think it is a good
> idea.

[RKo:>] Thanks.

> 
> The PMIPv6 base specification already allows a MAG to optimize the
> traffic when it figures out that both mobile nodes are attached to it.
> See section 6.10.3 of draft-ietf-netlmm-proxymip6-18.txt. However,
this
> decision is based on local policy on the MAG. 

[RKo:>] Yes.
 
>The base PMIPv6 document
> also says
> 
>    This decision of path optimization SHOULD be based on the policy
>    configured on the mobile access gateway, but enforced by the mobile
>    node's local mobility anchor.  The specific details on how this is
>    achieved are beyond of the scope of this document.
> 
> I think draft-koodli-netlmm-local-forwarding could be the out-of-scope
> mechanism referred to in the base document. Also,
> draft-koodli-netlmm-local-forwarding should refer to section 6.10.3 of
> the base spec.

[RKo:>] Okay.

> 
> I have a few questions on the draft.
> 
> Why does the LMA have to authorize local routing per-pair of mobile
> nodes? Can't it tell the MAG to apply local routing whenever possible?

[RKo:>] Because all routing, by default, is through the LMA. The
scenario you refer to is a local policy issue, which may be captured by
setting a special field in LFRQ (something like wildcard auth for a pair
mobiles). On the other hand, we would like to have as much fine-grained
control as possible in enabling this - for instance, it should be
possible to allow local forwarding on a per application session basis.
Usually, such a control rests at the LMA (which has hooks to policy
servers).

> 
> Would it make sense to also allow the MAG to request the LMA for local
> routing authorization when it detects a flow between two mobile nodes
> attached to it? Does the local forwarding have to be triggered by the
> LMA always?

[RKo:>] I guess this depends on where the flow detection for local
forwarding is implemented. MAG could request it (i.e., LFRQ could
originate from the MAG) when deployments allow such a scenario. Since,
as a default, all routing goes through the LMA, that's the natural place
to have this control.

> 
> Section 5.1 says
> 
>       MAY contain
>       the remote MAG IPv6 address option, which is identical to the
HNP
>       option except for Prefix Length equal to 128 bits.
> 
> What indicates the presence of the remote (or peer) MAG IP address in
> the LFRQ message? You might need a flag in the reserved field.
> 


[RKo:>] You keep parsing until the Total Length matches your current
pointer value :-)

> Finally, have you guys considered using the Generic Signaling message
> (or the generic notification message as it was called before) instead
of
> defining a new mobility header message?
> 

[RKo:>] It might be a possibility, but the semantics has to work. We are
asking for one Type assignment.

Thanks again.

-Rajeev

 
> Vijay
_______________________________________________
netlmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netlmm