Re: [Dime] Diameter extension for PMIPv6 localized routing

[Marco Liebsch <[e-mail]>]

Hi Qin,

please find a few minor comments inline.

Am 23.06.2011 09:48, schrieb Qin Wu:
> Hi, Carlos
> Thank for your valuable comments, please see my reply belows.
>
> Regards!
> -Qin
> ----- Original Message -----
> From: "Marco Liebsch"<[e-mail]>
> To:<[e-mail]>
> Cc:<[e-mail]>
> Sent: Tuesday, June 21, 2011 10:38 PM
> Subject: Re: [Dime] Diameter extension for PMIPv6 localized routing
>
>
> Please find below a review from Carlos about draft-ietf-dime-pmip6-lr-04.
> I forwarded this eMail to the DIME list. If you reply, please maintain
> Carlos' eMail address in the recipients list.
>
> marco
>
>
> Am 21.06.2011 10:39, schrieb Carlos Jesús Bernardos Cano:
>> Hi Marco,
>>
>> Here are my comments (apologies for the delay):
>>
>> I think the document is well written and I didn't find any major issue
>> with the solution itself (although I'm not a security expert). I have
>> some minor comments/questions:
>>
>> - I think Figure 1 would benefit from some redesign, as to me it's a bit
>> misleading. It is not clear what the arrows mean and the IP addresses
>> 'a' and 'b' are also unclear (is 'a' the address of LMA2 and 'b' the
>> address of LMA1? if so, it seems awkward).
> [Qin]: Okay, that makes sense.
>
>> - Page 5: "but share the same LMA the interaction between LMA1
>> interaction and the AAA server should" -->   "but share the same LMA, the
>> interaction between LMA1 and the AAA server should"
> [Qin]: Good catch, Thanks.
>
>> - Page 6: "The Diameter server checks if localized routing is allowed
>> between MAG1 and MAG2" -->   does the server checks that or that LR is
>> allowed between MN1 and MN2? because the signaling does not explicitly
>> includes MAGs' addresses, but MNs' ones.
> [Qin]: Agree. This should be per MN basis. Since MAG2's address can not be known to the server
> before MN2's LMA2 is resolved through AAA mechanism.
Good point and text may be more precise about this. The Diameter server 
authorizes
LR for each MN, as the result depends on the MN's profile and the 
operator's policy.
Capability of MAGs to support LR (local flag EnableMAGLocalRouting) and
enforcement of LR according to RFC5213 is solely up to PMIPv6.


>> Besides, from a conceptual
>> viewpoint, do we need authorization for LR for a given pair of MNs or
>> for a given pair of MAGs?
> [Qin]: Yes, we need authorization for LR for a given pair of MNs.
> becos if LR is not allowed between MNs, it does not make sense for the server
> to resolve LMA2 based on MN2 and return LMA2 address which will be used to
> address A22.
Authorization does not include a decision if it's useful to set up a 
localized
path. Its result is positive simply when MN1 is allowed to use localized 
routing
and the same applies to MNs. For this decision, IMHO, the result does not
depend on the tuple MN1 and MN2, but on each MN's authorization result.
Maybe a minor detail..

> Another reason is Localized routing is per MN based capability, only when both
> MN1 and MN2 support localized routing capability, then LR path between MAG1
> and MAG2 can be allowed to setup.
no support or particular capability on MN1 and MN2 is needed for 
localized routing.
Only authorization to set up localized routing for MN1 and for MN2 is 
needed.


>   This capability should also get aligned with
> LOCAL_MAG_ROUTING_SUPPORTED capability defined in RFC5779.
I think this flag is solely a static flag on each MAG, which is 
administratively set per
MAG and not per MN. Authorization of LR for an MN depends on its profile 
and the
operator's decision to establish LR for a particular MN. This is in line 
with RFC6279.

>> - In Figures 2 and 3, the LR signaling on the LMA2/MAG2 side is not
>> shown (but only on LMA1/MAG1). I think it'd help to show the whole
>> picture.
> [Qin]: We simplify the figure 2 and 3 by cutting off LR signaling since
> we got the comments on the list in the past that this document should
> focus how Diameter AAA is used for LR rather than LR signaling.
>
> On the other hand, the detailed signaling on the LMA2/MAG2 is
> described in Figure 5, which is not necessary to be repeated in
> each figure. Combine these figure, you can  see the whole picture.
>   Hope it clarifies.
Not sure why Fig 5 shows details at all whereas the others do not. Anyway,
if the draft includes such details, it should be noted that this is 
exemplary for
explanation and, even more important, the meaning of a message must be
described. The message LRI is not expanded in the text and should be
added with a note that this belongs to the initial pahse of LR setup.


>> - Page 7: "the data packet from MN1 to MN2 and requesting" -->   I think
>> is the other way around (to be also consistant with Figure 3): "the data
>> packet from MN2 to MN1 and requesting"
> [Qin]: Corret.
Also here it may make sense to point to the exemplary nature of the sequence
chart, as it depends on where localized routing is detected and initiated.
So far it has been considered that the source MN's PMIP components
(MAG or LMA) detect and initiate LR. But for explanation in the DIME
spec it should not matter too much. Otherwise and for ease of reading I'd
propose making this consistent throughout all message sequence charts
and take traffic from MN1 to MN2 as trigger, assuming MN1 is the initiator
of the communication.

marco

>> - Page 8: "is LMA2. MAG1 or LMA may solicit" -->   "is LMA2. MAG1 or LMA1
>> may solicit"
> [Qin]: Correct, Thanks.
>
>> - In Figure 5, both cases of MAG1 or LMA1 soliciting the LR (i.e.,
>> sending the LRI and receiving the LRA message) are shown, but it might
>> lead to confusion if the reader just looks at the picture. Maybe
>> something can be added to the Figure to mention that it is one case or
>> the other. There is also missing the arrow head for the LRA(MAG2)
>> message.
> [Qin]: Good suggestion, will fix this in the new version.

>> - I think it might be necessary to make more explicit that this document
>> addresses Scenario A22 of draft-ietf-netext-pmip6-lr-ps (which is not
>> cover in draft-ietf-netext-pmip-lr). What about Scenario A21? this seems
>> to be covered by both this document and draft-ietf-netext-pmip-lr,
>> right?
> [Qin]: Sure, that make sense. Actually the document should cover
> both A22 and A21.
> As described in the section 2 of this document, it said:
> "
>      This reference architecture assumes
>
>     o  MN1 and MN2 belong to different LMAs or the same LMA.
>
> "
> however we lack one more use case to explain how LR authorization works in A21.
> we will fix this in the new version, thank for your suggestion.
>
>> Thanks,
>>
>> Carlos
>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime