Subject: Re: [Dime] Diameter extension for PMIPv6 localized routing

From: Marco Liebsch <[email-masked]>
Date: Tue, 21 Jun 2011 16:38:21 +0200

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).
>
> - 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"
>
> - 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. Besides, from a conceptual
> viewpoint, do we need authorization for LR for a given pair of MNs or
> for a given pair of MAGs?
>
> - 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.
>
> - 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"
>
> - Page 8: "is LMA2. MAG1 or LMA may solicit" -->  "is LMA2. MAG1 or LMA1
> may solicit"
>
> - 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.
>
> - 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?
>
> Thanks,
>
> Carlos
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 23 Jun 2011 15:48:36 +0800

Hi, Carlos
Thank for your valuable comments, please see my reply belows.

Regards!
-Qin
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 21, 2011 10:38 PM
Subject: Re: [Dime] Diameter extension for PMIPv6 localized routing

marco

> address of LMA1? if so, it seems awkward).

[Qin]: Okay, that makes sense.

> interaction between LMA1 and the AAA server should"

[Qin]: Good catch, Thanks.

> 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

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

> shown (but only on LMA1/MAG1). I think it'd help to show the whole

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

> packet from MN2 to MN1 and requesting"

[Qin]: Corret.

> - Page 8: "is LMA2. MAG1 or LMA may solicit" -->  "is LMA2. MAG1 or LMA1

[Qin]: Correct, Thanks.

> the other. There is also missing the arrow head for the LRA(MAG2)

[Qin]: Good suggestion, will fix this in the new version.

> to be covered by both this document and draft-ietf-netext-pmip-lr,

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

> Carlos

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 27 Jun 2011 14:19:30 +0200

Hi Qin,

please find a few minor comments inline.

Am 23.06.2011 09:48, schrieb Qin Wu:
> From: "Marco Liebsch"<[email-masked]>
> To:<[email-masked]>
> Cc:<[email-masked]>
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.

> to resolve LMA2 based on MN2 and return LMA2 address which will be used to
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..

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

> each figure. Combine these figure, you can  see the whole picture.
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.

>> packet from MN2 to MN1 and requesting"
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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 28 Jun 2011 01:23:21 +0200

Hi Qin, Marco,

Thanks for your comments and responses. I agree with your points, Marco.

Kind Regards,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Jun 2011 10:06:57 +0800

Hi, all:
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 27, 2011 8:19 PM
Subject: Re: [Dime] Diameter extension for PMIPv6 localized routing

> enforcement of LR according to RFC5213 is solely up to PMIPv6.

[Qin]: Correct. I agree these are two separate issues and can't be mixed up.

> depend on the tuple MN1 and MN2, but on each MN's authorization result.

[Qin]: Yes, the descison on useful of LR is not part of authorization. The counterexample I gave here 
may be not appropriate.

Also I agree if only MN1 is  carried in the Diameter AAA message to the server, the server only
can check if MN1 is allowed to use LR.

> Only authorization to set up localized routing for MN1 and for MN2 is 

[Qin]: Yes, exactly.

> operator's decision to establish LR for a particular MN. This is in line 

[Qin]: Not sure this flag is Per MAG based.
 RFC5779 said
 "
The MAG SHOULD support this policy
 feature on a per-MN and per-subscription basis
"

> added with a note that this belongs to the initial pahse of LR setup.

[Qin]: Good suggestions.

> and take traffic from MN1 to MN2 as trigger, assuming MN1 is the initiator

[Qin]: I agree. Thank for your clarification.