Subject: Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00

From: Marco Liebsch <[email-masked]>
Date: Thu, 15 Oct 2009 18:27:50 +0200

Hi Raj,

looks like you propose to remove the complete IPv4 section. The comment
to address IPv4 in the PS has been brought up during SF meeting and
there was support for that comment as far as we understood. That was the
reason to include such section in the individual draft. For the WG draft, we
shortened this section according to the feedback we received in Stockholm
and our understanding how this fits into the revised PS structure. Now you
propose to remove IPv4 entirely.

I (personally) still think that the PS can refer to a potential problem 
if it's
valid and I see this independent of whether or not the solution will address
all these problems. If the concern is that a particular issue described 
in the
PS needs more time for discussion and that this may delay starting with the
solution work, well, I don't see this problem as work on solution can start
in parallel.

I really don't persist in keeping the related text and if there is a 
good reason to
remove some text or the complete IPv4 section, I am ok. But I think there
are more opinions needed.

marco

[email-masked] schrieb:
> Hello,
>
> Regarding the scope of localized routing for PMIP6, I believe the
> current PS I-D has some issues w.r.t the following:
>
> 1. Localized routing for IPv4 HoA (Sec 3.3.1)
> I do not believe we should work on supporting LR for IPv4 HoA at this
> time. Given the possibility of multiple MNs with the same IPv4 HoA
> (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this
> capability. Lets just worry about LR for only the IPv6
> prefix/address. 
>
> 2. Transport network between the MAGs (Sec 3.3.2)
> Rather than making assumptions about the capability of MAGs in a PMIP6
> domain, and defining negotiation mechanisms, we can make an assumption
> that MAGs support IPv6 transport. Keeping the scope constrained will
> ensure we get something done here.
>
> So I would recommend (with chair hat on) that we delete secs 3.3,
> 3.3.1 and 3.3.2. 
>
> -Chairs
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: <[email-masked]>
Date: Fri, 16 Oct 2009 22:19:49 +0200

Hi Marco,

> propose to remove IPv4 entirely.

That was my originla suggestion in order to keep it simple. However Rajeev
said that maybe it is okay to still allow localized routing for the assigned
IPv4 HoA for the MN. But I think we should definitely not include the part
about MAGs being assigned private IPv4 addresses and the mechanisms to deal
with NATs etc.

> all these problems.

Well, the PS is going to act as the reference for the solution I-D and hence
it is better to keep the PS scope limited to what we think is reasonable.

> If the concern is that a particular issue described
> in the

We could always have a separate I-D to discuss the aspects which do not have
consensus at the moment as well, right?

> are more opinions needed.

Sure. WG members should express opinion and feeback. We will go with
whatever the WG believes is in the best interest.

>From a chair perspective, I believe we should not chew off more than
necessary; Rather focus on getting something done quickly that can be
implemented and used.

-Raj

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 19 Oct 2009 10:30:49 +0200

Hi Raj,

> about MAGs being assigned private IPv4 addresses and the mechanisms to deal
Ok.
> consensus at the moment as well, right?
What about having the "in scope" items in the core part of the PS, but 
to have a short reference
to further possible issues, which we just summarize in the appendix 
without digging into detail.
So, we don't lose time with discussing them, but future documents can 
take this PS as a hook
to analyze associated issues in detail. Advantage would also be to show 
that we did not ignore
such issues, but just left them aside as they are not conidered yet for 
the NetExt protocol solution.
What do you think?

> necessary; Rather focus on getting something done quickly that can be
Yes, I think my proposal above lets us proceed quickly.

marco