Re: [Dime] Diameter extension for PMIPv6 localized routing

[Qin Wu <[e-mail]>]

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


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


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


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

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

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

[Qin]: Yes, exactly.

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

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

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


[Qin]: Good suggestions.


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

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

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