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

From: <[email-masked]>
Date: Tue, 19 Apr 2011 14:25:27 +0000

Hello,

Consider this as the working group last call for the I-D:
Localized Routing for Proxy Mobile IPv6  <draft-ietf-netext-pmip-lr-01>.

Please review and submit your comments to the ML or authors by April 30th,
2011.

-Chairs

---

From: <[email-masked]>
Date: Fri, 29 Apr 2011 10:45:58 +0200

Dear all,
I think the draft provides a simple but efficient solution to the problem described in "PMIPv6 Localized Routing Problem Statement" and is written concisely. Some comments beyond the nits detected by the tool following (although done on vers. -01, sorry for that!):

Abstract:
be suboptimal, localized routing(LR) => be suboptimal, localized routing (LR)

P.3:
according to [RFC5213]. => according to [RFC5213].  The protocol builds on the scenarios defined        
    in [I-D.ietf-netext-pmip6-lr-ps].

P.4:
The MAG MUST Initiate => The MAG MUST initiate   
The LMA MUST Initiate => The LMA MUST initiate 

Some more nits e.g. on p.7:
Localized Routing Entries(LREs) => Localized Routing Entries (LREs) 
address of the next- hop).  => address of the next hop).  

P.8:
a Local Routing Acknowledgment (LRA) => a Localized Routing Acknowledgment (LRA)
another MAG(say nMAG) => another MAG (say nMAG) 

Not sure about LRE or (new?) LFE on P.8/9:
corresponding LFE entries MUST be removed. =>  corresponding LRE entries MUST be removed.

MAG IP Address option is present, each MAG MUST create a local forwarding entry => MAG IP Address option is present, each MAG MUST create an LRE  _or_ local forwarding entry (LFE)

P.12:
it.  Hence the local routing  => it.  Hence the localized routing 
 
p.17:
 'S' flag: When set to 1, indicates a request to stop local =>  'S' flag: When set to 1, indicates a request to stop localized

P.20:
association between the LMA and the MAG to protect the LRI and LRA => association as defined in [RFC5213] for use between the LMA and the MAG to protect the LRI and LRA 

P.21
Local Routing Acknowledgment, => Localized Routing Acknowledgment, 

So far my minor suggestions.
Thanks!

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Dienstag, 19. April 2011 16:25
An: [email-masked]
Betreff: [netext] WG LC: draft-ietf-netext-pmip-lr

Hello,

-Chairs

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 29 Apr 2011 20:27:08 +0200

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".
- 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.
- 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).
- 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.
- Why do the MAGs check EnableMAGLocalRouting flag in A11 but not in
A12?
- 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?

Editorial:
- Abstract: "localized routing(LR)" --> "localized routing (LR)"
- Abstract: "This document proposes an initiation mechanism for
localized routing". Well, the document does something more than that,
right? it is not just about how to initiate the process, but also some
details (not all of them) about how to actually do it (e.g., tunnel
packets between MAGs in some scenarios).
- Section 2 (page 4): LR is expanded in the abstract. I'd suggest
expanding it also at least the first time it appears in the text.
- Sections 2.1 and 2.2 (page 4): "MUST Initiate LR if" --> "MUST
initiate LR if"
- Section 2.2 (page 4): "MNs are anchored to it" --> "MNs are anchored
at it" ??
- Section 4 (page 7): "Localized Routing Entries(LREs)" --> "Localized
Routing Entries (LREs)"
- Section 4 (page 7): "the next- hop" --> "the next-hop"
- Section 4 (page 5): "The MAG may refresh" --> is that "may" normative
or not?
- Section 4.1 (page 7): "MAG(say nMAG)" --> "MAG (say nMAG)"
- Section 4.1. The use of "MAG" to refer to a particular MAG in the
scenario is a bit misleading, e.g. in "and update the LR state of MAG",
the reader may think of the MAG as network entity, while in this case it
is referring to the particular MAG where MN1 was previously attached to
(MN2 remains attached there). I'd suggest always number the elements in
the pictures, so there is MAG1, even for the case of an scenario with a
single MAG.
- Section 5 (page 9): "As earlier, the LMA initiates LRI as a response"
--> I'd say "As earlier, the LMA initiates LR as a response"
- draft-ietf-netlmm-pmip6-ipv4-support is already RFC5844

Hope this helps, and again apologies if part of my comments have been
already raised and tackled.

Carlos

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