Re: [netext] WG LC: draft-ietf-netext-pmip-lr

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

Hi Suresh,

Thanks Suresh. Some comments inline below.

On Fri, 2011-06-03 at 18:52 -0400, Suresh Krishnan wrote:
> Hi Carlos,
>     Thanks for your comments. Please find responses inline.
> 
> Carlos Jesús Bernardos Cano wrote:
> > Hi,
> > 
> > This is, as I promised in Prague, my review of the document. Sorry for
> > being a bit late.
> > 
> > Overall, I think it is a good document. I have some comments/questions.
> > Disclaimer: I might have missed some previous discussion on this
> > document, so I may ask questions that have been already addressed. Sorry
> > about that.
> > 
> > BTW, I've reviewed -02, though the WGLC was issued on -01.
> > 
> > Technical:
> > - Section 4. "The LMA initiates a localized routing session by detecting
> > a flow between two MNs attached to the same MAG." It seems (also by what
> > the rest of the section says) that the LR could be done per-flow, while
> > the signaling defined in the document clearly does not allow that, but
> > just on HNP level (which I'm fine with it). I'd suggest to clarify the
> > text there, and maybe not mention "flow", but rather "traffic".
> 
> OK. Sounds reasonable.
> 
> > - Section 4. The example provided about an application-layer signaling
> > entity notifying the LMA about the possibility of LR and the end-points
> > does not seem very realistic to me. In this scenario (A11), I think
> > either MAG or LMA can easily detect this.
> 
> The idea of the leaving that text in there was that there are some
> classes of applications that would need LR and they could request
> initiation of LR if needed. There was some interest to allow this kind 
> of triggering but to leave it as an implementation detail. The spec does 
> not cover application based triggering. Would you object to leave this 
> text in there?

No strong objection. I just think that application based trigggering is
not very realistic, but it's mainly a personal opinion. If there was
interest to allow it, I'm fine with that.

> 
> > - Section 4 (page 5). What is the rationale behind the U-LRA message? To
> > me it is not clear and I see that it complicates the protocol (as
> > introduces unsolicited messages that impact on the state machine).
> > Besides, the draft should IMHO clearly state if the LRI message sent in
> > response to the U-LRA needs to be acknowledged with another LRA (so the
> > sequence is U-LRA (from MAG to LMA), LRI (from LMA to MAG) and the LRA
> > (from MAG to LMA).
> 
> OK. I have removed the U-LRA as it adds complexity for no reason.
> 
> > - Why do the MAGs need to ask the LMA for authorization to perform LR
> > even when the MNs are both attached to the same MAG? I'm fine with that,
> > but it should be clear why that decision was taken, IMHO.
> 
> The intent was to centralize the policy decision and minimize 
> configuration, but I am open to suggestions.

I'd remove the need for authorization in that case.

> 
> > - Why do the MAGs check EnableMAGLocalRouting flag in A11 but not in
> > A12?
> 
> In the A11 scenario we are still within the bounds of RFC5213 that
> requires checking the flag. RFC5213 does not cover the 1 MAG 2 LMA case.

In my reading of RFC5213, the flag is not restricted to one single LMA
case. It just talks about visiting mobile node and correspondent node
locally attached to the same MAG.

> 
> > - Using LRI in both MAG-to-LMA and LMA-to-MAG makes the protocol a bit
> > complex, because they are not used exactly for the same thing (they are
> > more than just initiators, as I understand them).
> > - Section 7. Why cannot just the MAG stop performing LR when detects
> > that one of the MNs is no longer attached/delivery to one of the MNs
> > fails?
> > - Section 8. Isn't in the scope the case the MAG has an IPv4-only
> > address? I guess for that case it is needed to define also a MAG IPv4
> > address, right?
> > - Section 9.1 (page 17). In the LRI message, couldn't a lifetime value
> > set to 0 used instead of the S=1 flag?
> > 

What about the previous four comments?

Thanks,

Carlos

> > Editorial:
> 
> I have fixed all your editorial comments in -03.
> 
> Thanks
> Suresh
> 
> 

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