Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-lr-ps-05.txt

From: <[email-masked]>
Date: Tue, 22 Feb 2011 22:29:00 +0000

Hello,

The Netext WG I-D mentioned below is ready to be progressed to the
IESG for review and approval. Attached is the document shepherd
writeup for this I-D.

I-D: PMIPv6 Localized Routing Problem Statement
     <draft-ietf-netext-pmip6-lr-ps-05.txt>

-Raj

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Document shepherd: Basavaraj Patil
Yes, I have reviewed this version of the document and believe it is
ready for IESG review and publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had adequate reviews by key WG members.
I do not have any concerns regarding the depth or breadth of the
reviews received.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns regarding the reviews so far and do not believe additional
reviews are needed.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I do not have any specific concerns at this time regarding this
document. The problem statement has been presented and discussed at
length in previous WG meetings and on the mailing list. I am not aware
of any IPR disclosures related to this I-D.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is solid WG consensus behind this document. I believe the
majority of WG members understand and agree with the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No threats of appeal or extreme discontent have been expressed
regarding this I-D.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes. I have run the I-D through the ID nits tool and found no issues.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative sections.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

This document does not require any IANA action. It is a problem state
description. 

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not applicable.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Proxy Mobile IPv6 is the IETF standard for network-based mobility
management.  In Proxy Mobile IPv6, mobile nodes are topologically
anchored at a Local Mobility Anchor, which forwards all data
for registered mobile nodes.  The setup and maintenance of localized
routing, which allows forwarding of data packets between mobile nodes
and correspondent nodes directly without involvement of the Local
Mobility Anchor in forwarding, is not considered.  This document
describes the problem space of localized routing in Proxy Mobile
IPv6. 

There is strong WG consensus regarding the problem statement and the
need for a solution to deal with localized routing.
The document describes the localized routing problem in Proxy Mobile
IPv6 deployments and hence not relevant from an implementation
perspective.

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 23 Feb 2011 09:45:10 +0800

Hi Raj,

I'm not sure I have understood this well, because in my mind, there are some
comments not completely addressed, I mean
http://www.ietf.org/mail-archive/web/netext/current/msg01483.html.
Would you please check them, or make sure those comments are negligible? 
If I was wrong, please let me know my mistake.

Thanks,
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Wednesday, February 23, 2011 6:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [netext] Request to progress Netext WG I-D:
> draft-ietf-netext-pmip6-lr-ps-05.txt
> 
> 
> Hello,
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 23 Feb 2011 10:51:10 +0100

Hi Xiangsong,
all your comments have been addressed in version 4 and 5.
W.r.t. the remaining two paragraphs you refer to in msg-1483,
let me clarify again by copying your last reply:

Xiangsong wrote:

>The first sentence of section 5,
>Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs,
>MAGs) tied by MN and CN may be distributed between different provider
>domains (i.e., domain A, B, C) and MN and/or CN moves from    one provider
>domain to another one.
>Let me try to simplify this sentence, it is describing the roaming case
>which is showed in Figure 2,
>The front half of the subordinate clause says, "PMIPv6 components (e.g.,
>LMAs, MAGs) tied by MN and CN may be distributed between different provider
>domains" does this mean MAGs may be in different provider domain?
>The end half of the subordinate clause says, "MN and/or CN moves from one
>provider domain to another one". Does the *or* means that the nodes may roam
>one by one? So even MAGs are in same provider domain, it would be changed
>when one node is roaming (to a new MAG in another provider domain).

Marco: The first sentence you refer to in section 5 is related to 
general roaming use cases.
So, both is possible, MN and/or CN move. This has nothing to do yet with 
localized routing.
Only in the second sentence we indicate that NetExt covers only use 
cases for localized
routing where both MAGs (MN's and CN's) share the same provider domain. 
This is also
independent of their LMA's location

Xiangsong wrote:

>Do you mean MN and CN are roaming exactly simultaneously? From MAG1/MAG2
>pair to MAG1'/MAG2' pair?
>In my impression, when MN (or CN) moves to a new provider domain, it would
>lie in a different provider domain with CN (or MN), so the localized routing
>should be released, right?
>If you say they are exactly simultaneously roaming, supposed they are
>registered in the same LMA, the LMA would receive PBU from MAG1' and MAG2'
>respectively, I think here should be a single thread program, so it is
>impossible for the LMA to receive exactly simultaneous message, do you mean
>the LMA should hold one PBU for some time (not destroy localized routing
>immediately although "different provider domain") and wait for the other PBU
>(to continue the localized routing on new MAG pair)? This is of course
>purely implementation issue, here my point is just to check the case.

Marco: This is not about maintenance of localized routing when MN/CN 
step from a
non-roaming into a roaming situation. It only mandates (according to 
NetExt scope
and requirements) that both MAGs share the same provider domain in a 
steady state
situation, which means localized routing is set up when MN and CN start 
a communication
and both MAGs are within the same provider domain. Further, this section 
indicates that
MN's as well as CN's LMA may be located in the same provider domain as 
the MN's/CN's
MAG or in a different one (roaming).

I hope that clarifies your concerns and we can proceed with version 5.

Marco

---

From: <[email-masked]>
Date: Wed, 23 Feb 2011 15:45:13 +0000

Hi Xiansong,

IMO your comments have been addressed in this revision of the I-D.
Marco has provided the details in another email.

It should be noted that the scope of the problem statement includes
aspects which will not be considered in the solution space itself. It is
simply considering all aspects of localized routing.

-Raj

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 24 Feb 2011 10:40:54 +0800

Hi Marco, 

Please see my comments below.

Of
> Marco Liebsch
> Sent: Wednesday, February 23, 2011 5:51 PM
> To: Xiangsong Cui
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [netext] Request to progress Netext WG I-D:

I see, thanks for your kind explanation.

> MAG or in a different one (roaming).

Do you mean this section is about the situations before and after "roaming",
but not about the procedure of "roaming"?

Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 24 Feb 2011 11:00:40 +0100

Hi Xiangsong,

please find my reply inline.

Xiangsong Cui wrote:
>>> Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g.,
>>>       
>> LMAs,
>>     
>>> domains (i.e., domain A, B, C) and MN and/or CN moves from    one
>>>       
>> provider
>>     
>>> domain to another one.
>>> LMAs, MAGs) tied by MN and CN may be distributed between different
>>>       
>> provider
>>     
>>> provider domain to another one". Does the *or* means that the nodes may
>>>       
>> roam
>>     
>>> Do you mean MN and CN are roaming exactly simultaneously? From
>>>       
>> MAG1/MAG2
>>     
>>> In my impression, when MN (or CN) moves to a new provider domain, it
>>>       
> would
>   
>>> lie in a different provider domain with CN (or MN), so the localized
>>>       
> routing
>   
>>> registered in the same LMA, the LMA would receive PBU from MAG1' and
>>>       
>> MAG2'
>>     
>>> impossible for the LMA to receive exactly simultaneous message, do you
>>>       
>> mean
>>     
>>> immediately although "different provider domain") and wait for the other
>>>       
> PBU
>   
yes.

marco

>>> I'm not sure I have understood this well, because in my mind, there are
>>>       
> some
>   
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>         
> Behalf
>   
>>> Of
>>>       
>>>>    (1.b) Has the document had adequate review both from key WG
>>>>         
>> members
>>     
>>>>          and from key non-WG members? Does the Document Shepherd
>>>>         
>> have
>>     
>>>>          document satisfies all ID nits? (See the Internet-Drafts
>>>>         
> Checklist
>   
>>>>          and http://tools.ietf.org/tools/idnits/). Boilerplate checks
>>>>         
> are
>   
> Received: from smtp0.neclab.eu (192.168.23.16) by METHONE.office.hd
>  (192.168.24.54) with Microsoft SMTP Server id 14.1.270.1; Thu, 24 Feb 2011
>  03:41:07 +0100
> Received: by smtp0.neclab.eu (Postfix)	id 7F6052C000205; Thu, 24 Feb 2011
>  03:41:55 +0100 (CET)
> Delivered-To: [email-masked]
> Received: from localhost (localhost.localdomain [127.0.0.1])	by
>  smtp0.neclab.eu (Postfix) with ESMTP id 7450C2C0001DE	for
>  <[email-masked]>; Thu, 24 Feb 2011 03:41:55 +0100 (CET)
> X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
> Received: from smtp0.neclab.eu ([127.0.0.1])	by localhost (atlas2.office.hd
>  [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id qH1ppQF8hxGR for
>  <[email-masked]>;	Thu, 24 Feb 2011 03:41:55 +0100 (CET)
> Received: by smtp0.neclab.eu (Postfix, from userid 1001)	id 4D5F52C000203;
>  Thu, 24 Feb 2011 03:41:55 +0100 (CET)
> X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on atlas2.office.hd
> X-Spam-Level:
> X-Spam-Status: No, score=-106.6 required=4.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
> 	USER_IN_WHITELIST autolearn=ham version=3.2.5
> Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66])
> 	by smtp0.neclab.eu (Postfix) with ESMTP id 4BA8F2C0001DE	for
>  <[email-masked]>; Thu, 24 Feb 2011 03:41:47 +0100 (CET)
> Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com
>  (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id
>  <[email-masked]> for [email-masked]; Thu, 24
>  Feb 2011 10:40:54 +0800 (CST)
> Received: from c00111037 ([10.111.16.128]) by szxga03-in.huawei.com (iPlanet
>  Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id
>  <[email-masked]> for [email-masked]; Thu, 24
>  Feb 2011 10:40:54 +0800 (CST)
> Date: Thu, 24 Feb 2011 10:40:54 +0800
> From: Xiangsong Cui <[email-masked]>
> Subject: RE: [netext] Request to progress Netext WG I-D:
> In-Reply-To: <[email-masked]>
> To: 'Marco Liebsch' <[email-masked]>
> CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Message-ID: <[email-masked]>
> X-Mailer: Microsoft Office Outlook 12.0
> Content-Type: text/plain; charset="us-ascii"
> Content-Language: zh-cn
> Content-Transfer-Encoding: 7BIT
> Thread-index: AcvTP2O+M2RwQl1oRi6Jpl+hf6PggwAi74VA
> References: <[email-masked]>
>  <[email-masked]> <[email-masked]>
> Return-Path: [email-masked]
> X-MS-Exchange-Organization-AuthSource: METHONE.office.hd
> X-MS-Exchange-Organization-AuthAs: Anonymous
> MIME-Version: 1.0
>
> Hi Marco, 
>
>>> Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g.,
>>>       
>> LMAs,
>>     
>>> domains (i.e., domain A, B, C) and MN and/or CN moves from    one
>>>       
>> provider
>>     
>>> domain to another one.
>>> LMAs, MAGs) tied by MN and CN may be distributed between different
>>>       
>> provider
>>     
>>> provider domain to another one". Does the *or* means that the nodes may
>>>       
>> roam
>>     
>>> Do you mean MN and CN are roaming exactly simultaneously? From
>>>       
>> MAG1/MAG2
>>     
>>> In my impression, when MN (or CN) moves to a new provider domain, it
>>>       
> would
>   
>>> lie in a different provider domain with CN (or MN), so the localized
>>>       
> routing
>   
>>> registered in the same LMA, the LMA would receive PBU from MAG1' and
>>>       
>> MAG2'
>>     
>>> impossible for the LMA to receive exactly simultaneous message, do you
>>>       
>> mean
>>     
>>> immediately although "different provider domain") and wait for the other
>>>       
> PBU
>   
>>> I'm not sure I have understood this well, because in my mind, there are
>>>       
> some
>   
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>         
> Behalf
>   
>>> Of
>>>       
>>>>    (1.b) Has the document had adequate review both from key WG
>>>>         
>> members
>>     
>>>>          and from key non-WG members? Does the Document Shepherd
>>>>         
>> have
>>     
>>>>          document satisfies all ID nits? (See the Internet-Drafts
>>>>         
> Checklist
>   
>>>>          and http://tools.ietf.org/tools/idnits/). Boilerplate checks
>>>>         
> are
>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 25 Feb 2011 10:13:45 +0800

> > but not about the procedure of "roaming"?

So it seems a bit strange to me.
Roaming action does not happen before "roaming" or after "roaming". In the section which is named "Roaming Considerations", it happens that description of "roaming" is absent.

Anyway, this is not an objection, but just a minor comment. 

Best regards,
Xiangsong

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 25 Feb 2011 10:56:52 +0100

Hi Xiangsong,

Xiangsong Cui wrote:
>>> Do you mean this section is about the situations before and 
>>>       
>> after "roaming",
>>     
well, roaming covers both, maintaining a session during the the actual 
movement
from an access network of a home provider to a visited provider as well 
as the
set up of a session while being attached already to a visited provider. 
I think stating
the requirement to set up localized routing only when MN's and CN's MAGs 
share the
same provider domain is sufficient and rules out one possible dynamic 
roaming scenario
for the following reason: Assume MN and CN being attached to MAGs in 
provider domain A
and set up a data session. MN moves to provider domain B, which turns 
the situation into
an out of scope use case, as MN's and CN's MAG do not share the same 
provider domain.
Another scenario you refer to is rather rare, I'd say, which is the 
simultaneous movement
of MN and CN from domain A to domain B while having the intention to 
maintain a
localized route between their MAGs.

As for the problem statement, I think the current problem analysis and 
conclusion is
sufficient to cover both of the dynamic use cases as well.

> Anyway, this is not an objection, but just a minor comment. 
Agree and it's good to have such comments and discussion. If we really find
out that something needs to be added to the PS, we may get the chance to do
this. So far I do not see the need.

Thanks for your comments.

Best regards,
marco

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 25 Feb 2011 18:37:21 +0800

OK, thanks for your clarification.

Best regards,
Xiangsong

Of
> Marco Liebsch
> Sent: Friday, February 25, 2011 5:57 PM
> To: Xiangsong Cui
> Cc: [email-masked]; [email-masked]
> > Roaming action does not happen before "roaming" or after "roaming". In
the
> section which is named "Roaming Considerations", it happens that
description
> of "roaming" is absent.