Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Feb 2012 20:47:13 -0500

Hi Les,
  Thanks for the review. Please find responses inline.

On 02/27/2012 02:28 AM, Les Ginsberg (ginsberg) wrote:
> (Resending w corrected draft address)
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review. The purpose
> of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> 
> Document: draft-ietf-netext-pmip-lr-08
> Reviewer: Les Ginsberg
> Review Date: 26 February 2012
> IETF LC End Date: ???
> Intended Status: Standards Track
> 
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> Comments:
> This document is clearly written and easy to understand.
> This is the first PMIP document I have reviewed, so I went back and read
> some of the previous RFCs. Despite that it may mean that some of my
> comments/questions are naive. Please indulge me.
> 
> Major Issues:
> No major issues found.
> 
> Minor Issues:
> 
> Why are you not using the "MN-CN" terminology from RFC 6279? The fact
> that you use "MN-MN" makes me think that you are only addressing cases
> where both endpoints are MNs. Is this the case? If so, this should be
> explicitly stated. If not, it would seem to be better to use the RFC
> 6279 terminology.

Your understanding is correct. I will add a statement to that effect.

> 
> Section 5
> 
> I assume the lack of requirement for synchronization works because the
> LMA will always forward packets regardless of whether it has sent an
> LRI/received an LRA? This implies that MNs and MAGs may receive
> duplicate packets at times - which presumably should be no problem. I am
> wondering if it would be useful to discuss these points?

In the handover case, the MAG2 will continue sending packets to MAG1
until the LMA establishes new LR state towards nMAG1, and these packets
will be lost. I will add text to this section to make this clear.

> 
> Similarly, in Section 6.1 it is assumed that LMAs always forward
> inter-MN packets regardless of the state of LR?

There will be no inter-LMA forwarding in this case during handover. The
wg decided not to handle this case (A22) because there is no defined
inter-LMA communication mechanism in PMIPv6.

> 
> Nits:
> A number of acronyms are used without definition. For example, in
> Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not
> represent a complete list. Can you please scrub the document for all
> such occurences?

These are inherited from the base PMIP RFC (RFC5213). Would you still
like me to add the expansions here?

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 5 Mar 2012 18:14:44 -0500

Hi Les,
  Addressing 2 open items from your review.

Les Ginsberg (ginsberg) wrote:
> Suresh -
> 
> Replies inline.
> 
>> -----Original Message-----
>> From: Suresh Krishnan [mailto:[email-masked]]
>> Sent: Tuesday, February 28, 2012 5:47 PM
>> To: Les Ginsberg (ginsberg)
>> Cc: [email-masked]; [email-masked]; draft-ietf-netext-pmip-
>> [email-masked]
>> Subject: Re: RtgDir review: draft-ietf-netext-pmip-lr-08.txt
>>
>> Hi Les,
>>> Although these comments are primarily for the use of the Routing
> ADs,
>> it
> Could you also explain why the solutions defined do not work unless both
> nodes are Mobile?
> And, since you say that MN-CN is not addressed, is this something which
> is planned for a future document? RFC 6279 seems to clearly include both
> MN-MN and MN-nonMN (my terminology invention :-)) in the problem space
> to be solved.

RFC6279 only addresses MN-MN communications even though it refers to a
CN. It claims to use RFC3775 terminology for the CN, but it does not. It
assumes that the CN has a MAG and is anchored at an LMA. That makes it
an MN.

>>> duplicate packets at times - which presumably should be no problem.
> I
>> am
> This is not what I was commenting on - though additional clarity in this
> case would be helpful as well.
> I was commenting on the initial setup of LR. I was commenting on the
> statement
> 
> " The protocol does not require any synchronization between the MAGs
>    before local forwarding begins."
> 
> This occurs at the end of Section 5 BEFORE the discussion of handoff in
> Section 5.1.
> Please respond to this comment.

No synchronization between MAGs is required because each MAG initiates
LR in one direction. After the LMA instructs MAG1 to initiate LR,
packets from MN1 to MN2 will take the path MN1->MAG1->MAG2->MN2 while
those from MN2 to MN1 will take the path MN2->MAG2->LMA->MAG1->MN1 until
LMA instructs MAG2 to do so as well. At any instant a MAG will forward a
packet either towards another MAG or its LMA. So there should be no
duplicate packets.

> I am not commenting on A22 - which is discussed in Section 7. My comment
> is regarding what happens during the handover discussed in Section 6.1.
> My concern is regarding what prevents packets from being lost during the
> handover. I assume that no packets are lost because the LMA will always
> forward packets to an MN registered with it even if it currently
> believes that LR is active/enabled - but wanted to confirm and also
> suggest that mention of that point (if correct) might be clarifying.

You are right. I will add some text clarifying this.

Thanks
Suresh