[netext] Review of I-D: draft-ietf-netext-pmip-lr-04

[<[e-mail]>]

Hello,

Below is the chair review of this I-D following the completion of WG
last call.

-Basavaraj

1.
s/mobile access gateways to exchange traffic/mobile access gateways to
route traffic

2.
s/This document proposes initiation, utilization and termination
   mechanisms for localized routing/This document proposes initiation,
   utilization and termination mechanisms for localized routing
   between mobile access gateways within a proxy mobile IPv6 domain.

3. The reference I-D.ietf-netext-pmip6-lr-ps can be updated to RFC6279

4. In the terminology section (3), it would be useful to reference the
   terminology captured in RFC6279

5. Please number the figures in the I-D

6. Would be good to explain what are the flags Opt1: R=0,S=0, U=0 from
   a readability standpoint

7. The terms LRI and LRA are used in Sec 4, Scenario A11 without
   having previously expanded the acronym or for that matter
   explaining the basic set of new messages that have been defined for
   the purpose or localized routing.

8.
s/The MAG (MAG1) starts by verifying that the two MNs are indeed
   attached to it./The MAG (MAG1) verifies via the binding cache the
   existence/attachment status of the two MNs locally.

9. Question:
>   The MAG (MAG1) starts by verifying that the two MNs are indeed
>   attached to it.  It then verifies if the EnableMAGLocalRouting flag
>   is set to 1.  If it is not, the MAG has not been configured to allow
>   localized routing and it will reject the LRI and send an LRA with
>   status code "Localized Routing Not Allowed".

This scenario and message flow suggests the usage of LRI/LRA to setup
localized routing at the MAG. Does this update the behavior specified
in RFC5213? If so, it would be good to state it.

10. Sec 5:
>  As earlier, the LMA initiates LR as a response to some trigger
>  mechanism.

What trigger mechanism? Can you provide at least some examples?

11.
>   The tunnel between the MAGs is assumed to be established by means
>   outside the scope of this document.

It would be useful to at least provide some examples of the tunnel
establishment between MAGs from a completeness perspective. It looks
like handwaving at the moment.

12.
>   As before, each MAG responds to the LRI with an LRA message.

What exactly are you referencing by "As before"?

13.
> 6.  Scenario A12: Two MNs attached to the same MAG with different
> LMAs

It would be good to mention that the LMAs in this case are in the
scope of the same PMIP6 domain.

14. Explain the flow diagram in section 6. I would recommend numbering
    the message flows and explaining the sequence.

15.
s/Scenario A22: Two MNs attached to the different MAGs with different
    LMAs/Scenario A22: Two MNs attached to different MAGs with different
    LMAs

You can also state that this case is not covered even if the LMAs are
in the same PMIP6 domain.

16. Question:
> 8.  IPv4 support in Localized Routing

Are we supporting LR for IPv4 traffic? I thought that we had agreed to
do LR for IPv6 traffic only and avoid the issues related to
overlapping IPv4 addresses etc. Can you clarify why this section
exists?
Maybe it would be useful to state that LR is only for IPv6 traffic.

17. 11.  Security Considerations

You do not mention anything about the security requirements between
MAGs when traffic is routed between MAG1 and MAG2 via some tunnelling
mechanism. This should be clearly captured.

18. The IANA considerations section is poorly written and does not
    provide sufficient information to IANA regarding the actions
    needed from them. I would recommend revisiting this section.