Subject: [netext] Fw: New Version Notification for draft-cui-netext-lma-redirection-solution-00

From: Xiangsong Cui <[email-masked]>
Date: Mon, 27 Jul 2009 15:55:57 +0800

Hi all,

I have just submitted a draft about the LMA Redirection solution.
You  may find the draft by the link:
http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00

Please take a look and any comment is welcomed.

Thanks and regards

Xiangsong

----- Original Message ----- 
From: "IETF I-D Submission Tool" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 27, 2009 3:31 PM
Subject: New Version Notification for 
draft-cui-netext-lma-redirection-solution-00

>
> A new version of I-D, draft-cui-netext-lma-redirection-solution-00.txt has 
> been successfuly submitted by Xiangsong Cui and posted to the IETF 
> repository.
>
> Filename: draft-cui-netext-lma-redirection-solution
> Revision: 00
> Title: LMA Redirection Solution
> Creation_date: 2009-07-27
> WG ID: Independent Submission
> Number_of_pages: 8
>
> Abstract:
> In network-based mobility management domain, LMA is used to manage
> the mobility of IP node attached to MAG. LMA discovery and LMA
> redirection mechanism are used to improve the network flexibility.
> This document is used to introduce a recommended solution for this
> purpose. In this solution Redirect Agent function is adopted to
> accomplish the requirement.
>
> Conventions used in this document
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
>
>
> The IETF Secretariat.
>
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 Jul 2009 11:59:04 -0700

Hi Xiangsong,

As Jouni pointed, this mechanism was already there in version 00 of
draft-korhonen-netext-redirect. The normal IETF practice is to send comments
saying that you prefer the mechanism in the original draft compared to the
new mechanism. You can suggest enhancements too. There might be some minor
differences between what is in your draft and
draft-korhonen-netext-redirect-00.txt, but writing yet another draft is not
the right approach.

Vijay

On 7/27/09 12:55 AM, "Xiangsong Cui" wrote:

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

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 31 Jul 2009 10:12:24 +0800

Hi Vijay,

Thank you for your response, and I think we should do more
discussion on the issue.

> draft-korhonen-netext-redirect.

I have to say I can't agree that.
Because I didn't read the early version (i.e. draft-00) in the past,
I check the document just now.

In my understanding, the version 00 is similar with version 02, but
different with my draft.

The key points are: who send the first PBA to MAG?
When the old LMA decide to do redirection,  whom does the
old LMA send message to?

In my draft, it is the old LMA sends PBA to MAG, indicating
the redirection procedure and the new LMA information.
When the old LMA decide to do redirection, it sends message
to the MAG, but not the new LMA.

In the drafts of Jouni, it is the new LMA sends PBA, it is the new LMA
sends the option to MAG, indicating the redirection procedure and with
the old LMA information attached.
I get this conclusion, because of the following text (copied from draft 00):

Section 3:
 " The Redirect mobility option in the PBA MUST contain the
   IPv6 address (unicast or anycast) of the rfLMA and MAY contain the
   IPv4 address of the rfLMA.  The PBA containing the Redirect mobility
   option MUST be sent from the r2LMA.  After receiving the PBA
   containing the Redirect mobility option from the r2LMA, the MAG MUST
   send subsequent PBUs and user traffic to the r2LMA that concern the
   redirected mobility session."

The draft says the PBA MUST be sent from the r2LMA, which is the new
one.

Section 5.1:
 " If the MAG receives a PBA that contains the Redirect mobility option
   from a LMA without first including the Redirect mobility option in
   the corresponding PBU, the MAG MUST treat the PBA as if the binding
   update failed and log the event.  If the MAG receives a PBA that
   contains the Redirect mobility option and the MAG had included the
   Redirect mobility option in the corresponding PBU, then the MAG MUST
   perform the following steps in addition to the normal RFC 5213 PBA
   processing:

   o  Check if the Redirect mobility option contains the IP address of
      the LMA to whom the MAG originally sent the PBU (i.e. the rfLMA).
      If the check fails, then the MAG MUST treat the PBA as if the
      binding update failed and log the event.

   o  Update the Binding Update List to correspond to the LMA Address
      where the newly received PBA came from."

Notice the last sentence, I believe the LMA is the new LMA, so the MAG
need update the binding update list, isn't it?

Section 5.2:
 " In
   the case of redirection, the r2LMA MUST always include the IPv6
   address (unicast or anycast) of the rfLMA in the Redirect mobility
   option in the PBA."

The draft says r2LMA MUST include the information of the old LMA,
while in my draft, it is the old LMA indicates the new LMA.

Vijay, would you like to read the draft-00 of Jouni and check my
conclusion?

> The normal IETF practice is to send comments
> new mechanism. You can suggest enhancements too.

I agree the mechanism in my draft is widely used in other protocols, but
I don't think it is introduced in the drafts of Jouni.

> There might be some minor

Because my draft is different from the drafts of Jouni, I think I can submit
it to the WG. We just discussed several drafts on the topic of RO, IMO,
two drafts on the Redirection is reasonable.

Regards

Xiangsong