Re: [Dime] Diameter extension for PMIPv6 localized routing

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Qin, Marco,

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

Kind Regards,

Carlos

On Mon, 2011-06-27 at 14:19 +0200, Marco Liebsch wrote:
> 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
> 

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