Subject: [netext] review of draft-ietf-netext-pmip6-lr-ps-04

From: Jouni <[email-masked]>
Date: Thu, 13 Jan 2011 15:58:08 +0200

Hi,

Here's my initial quick review of the "PMIPv6 Localized Routing Problem Statement" based on the recent -04 version.

- Jouni

--------------------------------

Nits:

 o The document seems to lack the IANA considerations section.
   Even if it is not needed, having a dummy section stating
   "This document has no IANA considerations" would be good.

 o Shouldn't the I-D reference to RFC3775bis instead of RFC3775?
   The bis is already in IESG.

Semi-substantial:

Section 1:

 o Propose rephrasing
   "..  maintenance of a forwarding tunnel between an MN's Mobile Access.."
   as
   "..  maintenance of a tunnel between an MN's Mobile Access.."

Section 3.1:

 o It is stated
   "Localized routing is understood in [RFC5213] as optimization of
   traffic between an MN and a CN under the same access router, whereas
   the MN connects to the MAG function of this access router and is
   registered with an LMA, but the CN is a regular IPv6 node without
   getting PMIPv6 service.  In such case, the MAG forwards traffic.."

  I do not agree with the above conclusion of CN's role. In RFC5213
  Section 6.10.3 says "..correspondent node that is locally attached
  to an access link connected to the mobile access gateway, .."
  To me this does not imply CN is not getting PMIPv6 service. I would
  propose rephrasing the text as:

  "Localized routing is understood in [RFC5213] as optimization of
   traffic between an MN and a CN that are attached to an access
   link connected to a same MAG. In such case, the MAG forwards
   traffic.."

 o The third paragraph listing localized routing benefits I think one
   additional benefit should be listed. Localized routing allows
   bypassing the LMA, which may help scaling of the LMA. The LMA is
   anyway aggregating traffic from a number of MAGs thus becoming a
   bottleneck more easily than a MAG.

Section 3.2:

 o What actually is a "provider domain"? A composition of PMIPv6
   domains? This should be clarified. Maybe even in the terminology
   section.

Section 3.3.1:

 o This section should at least mention that MN and CN should have
   IPv4 home addresses of the same scope. I know e.g. NAT is scoped
   away (which is good) but having more explicit statement here
   would add clarity imho.

 o In case of RFC1918 IPv4 home addresses CN's and MN's addresses
   must not overlap.

Section 3.3.2:

 o I would also add here that addressing used across all MAGs 
   should be of the same scope (for both IPv4 and IPv6). That
   would make life a bit easier.

Section 5:

 o The last paragraph and the last sentence says "CN should stay
   with MN within the same domain." I did not get where this
   requirement is coming from.

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 13 Jan 2011 16:43:47 +0100

Hi Jouni,

thanks for your comments. Please see inline.

> Here's my initial quick review of the "PMIPv6 Localized Routing Problem Statement" based on the recent -04 version.
very good point. I'll add it.

>     The bis is already in IESG.
Hmm, as long as it's not approved and published? I think in case we get the
PS to the RFC Editor state, by that time RFC3775bis may be public and
will be updated in the PS anyhow before publication. I'll check if it's
appropriate to refer to the bis now. Thanks for the hint.

>     "..  maintenance of a tunnel between an MN's Mobile Access.."
ok

>     link connected to a same MAG. In such case, the MAG forwards
Reading RFC5213, both can be understood. Carlos mentioned the interpretation
of having regular IPv6 nodes below a MAG in Feb 2009. But this shows 
that RFC5213
is really not clear about which use cases are addressed and in 
particular how to achieve
and signal localized routing. At that time we agreed to refer to regular 
IPv6 nodes.
I don't think it's too relevant for the PS if it's a regular IPv6 node 
or a mobile node,
as mechanisms are obviously not completely covered in RFC5213. That means
there is still a problem and that's what the PS is about. So, if Carlos 
and others are
fine, I am also ok with taking over your shortened text.

>     bottleneck more easily than a MAG.
Ok, I'll add an item about LMA scalability. thanks.

>     domains? This should be clarified. Maybe even in the terminology
Let's add some description to the Terms section.

'Provider domain: A network domain in which network components
are administered by a single authority, e.g. the mobile operator.'

Does this sound ok?

Btw, we tried to propose text for such definition some time ago, folks
complained if we want to re-invent the wheel and re-define well
known terms ;-)

>   o In case of RFC1918 IPv4 home addresses CN's and MN's addresses
Do you propose to write this as a requirement? We cannot assume this, as
we identify problems in this document.
Conflicts when using private address spaces can still happen. We covered 
this
in early versions of the PS, but had to take it out. Please clarify the 
last two
bullets. Thanks.

>     would make life a bit easier.
as requirement or as problem?

>     requirement is coming from.
Good point. This is really not clear.
I guess it should be said that in both cases, roaming or non-roaming, MN 
and CN
must attached to MAGs of the same provider domain to receive localized 
routing
service (meeting the NetExt scope). What about the following revision:

'During mobility, CN and MN should remain attached to MAGs of the same
provider domain to ensure efficient routing of traffic between their MAGs.'

Is this clear enough?

Thanks,
marco

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

---

From: jouni korhonen <[email-masked]>
Date: Fri, 14 Jan 2011 13:15:51 +0200

Hi Marco,

See inline.

> appropriate to refer to the bis now. Thanks for the hint.

Ok.

> of having regular IPv6 nodes below a MAG in Feb 2009. But this shows that RFC5213
> is really not clear about which use cases are addressed and in particular how to achieve
> and signal localized routing. At that time we agreed to refer to regular IPv6 nodes.
> I don't think it's too relevant for the PS if it's a regular IPv6 node or a mobile node,
> there is still a problem and that's what the PS is about. So, if Carlos and others are

Just to mention that the "shortened" interpretation was used e.g. when RFC5779 was done.

> are administered by a single authority, e.g. the mobile operator.'

Sounds ok.

> complained if we want to re-invent the wheel and re-define well

Wasn't ambiguous to me.. and I even used to work for a provider.

> we identify problems in this document.

You could state that as a problem or a known constraint.

> Conflicts when using private address spaces can still happen. We covered this
> in early versions of the PS, but had to take it out. Please clarify the last two
> bullets. Thanks.

I find it odd, of someone would even try to directly integrate domains that are known to have overlapping address issues. That would be plain dump.

> as requirement or as problem?

Would state that as a problem/known constraint.

> I guess it should be said that in both cases, roaming or non-roaming, MN and CN
> must attached to MAGs of the same provider domain to receive localized routing

Yes.

- JOuni