Re: [Dime] Diameter extension for PMIPv6 localized routing

[Qin Wu <[e-mail]>]

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. 

>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.

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. This capability should also get aligned with
LOCAL_MAG_ROUTING_SUPPORTED capability defined in RFC5779.

> - 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.

> - 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.

> - 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