Subject: [MEXT] RFC3775 update

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 02 Jun 2008 10:58:54 +0200

Hi,

In last IETF we said that we will accept input for RFC3775 changes for 
about 3 months and then try to wrap up this issues.

This is reminder of that plan and that proposals for changes for RFC3775 
are accepted till the 15 of june.

After that we will go through the proposed changes and try to reach 
consensus on each of the proposed changes (including the text to be 
included and removed) in the ml.

After that we will ask the authors of rfc3775 to submit a 3775bis 
including the accepted changes and go to WGLC.

Regards, Julien and marcelo

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Jun 2008 11:44:36 +0200

Hi Marcelo, I'm not sure whether this has been discussed or not.

rfc3775 is silent about HA copying or ignoring the Trafic Class and Flow 
Label fields when de/encapsulating from/to MN.  It can prove to be an 
issue when using that field.  In some implementations the field _is_ 
copied, which is a good thing IMHO.

On this topic, rfc3775 points to rfc2473 ("Generic Packet Tunneling in 
IPv6") which further says "Depending on the entry-point node tunnel 
configuration, the [flow label]/traffic class can be set to that of 
either the original packet or a pre-configured value."

In practice however, many implementations of rfc2473 don't have a means 
to set a pre-configured value for the traffic class/flow label.  This is 
something relatively difficult to implement because it's difficult to 
link a set of parameters into a pre-configured traffic class/flow label: 
What does a pre-configured traffic class/flow label correspond to: a 
pair of IP addresses?  port numbers?  etc.

On this reasoning, I prefer 3775 to say that the HA must either copy the 
traffic class/flow label, or set it to 0.

Just say a good recommendation instead of relying on rfc2473 
unimplemented means of this behaviour.

Alex

> Regards, Julien and marcelo

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Jun 2008 14:59:33 -0400

I'm not sure copying text from already normatively referenced documents 
is going to change the situation.

Jari

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 2 Jun 2008 13:46:31 -0400

Alex,

I think this should be addressed as part of updating RFC 2473. (there
was some discussion on the INT Area mailing list on updating RFC 2473).

PMIPv6, FMIPv6, HMIPv6, all use tunneling. They all refer to RFC 2473.
What you bring up below would be applicable to all these protocols as
well. So we shouldn't make changes to how encapsulation/decapsulation is
done in 3775bis.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 2 Jun 2008 19:58:22 -0700 (PDT)

Just one comment.

> well. So we shouldn't make changes to how encapsulation/decapsulation is

The transport AD did not agree with this stand and we ended up
specifying the ECN handling for the PMIP tunnels. But, thats a
new spec. If we make the tunnel normative to 3168 specification,
we can just state on the ECN copying and leave it there. DSMIP
spec also seems to have done that. Unless you see an issue with
this addition of what is missing in 2473, we can probably specify
this. In any case, the same will get added to 2473-bis, normative
to 3168. But again, 3775-bis is a simple update, some what an
error correction.

Sri

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Mon, 2 Jun 2008 20:36:52 -0700

On Mon, Jun 2, 2008 at 7:58 PM, Sri Gundavelli <[email-masked]> wrote:
> new spec.

It was more of a procedural issue. I am sure you didn't want PMIPv6
approval held up until 2473bis was done. :)

Vijay

If we make the tunnel normative to 3168 specification,

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Jun 2008 23:52:30 -0400

Sri,

> specifying the ECN handling for the PMIP tunnels.

I think there are several different cases:

1) The referenced spec does have the needed words
2) The referenced spec does not have the needed words
3) The referenced spec has the words, but the referring spec needs 
further details
4) The referenced spec has the words, but its important to highlight the 
issue for some reason
5) ...

I don't think its necessary to add any explanation for case 1. In other 
cases, it may be needed. Like Netlmm, I think we were mostly in items 2 
and 3. But what I understood from Alex we had case 1 here. I have not 
checked the RFC recently, however...

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 10:31:53 +0200

> checked the RFC recently, however...

YEs, it was item 1: referenced spec (rfc2473) does have the words about 
the possibility to copy the TC/Flow labels or insert pre-configured 
values.  However, at least one widespread implementation doesn't 
implement the latter feature.

I think if some implementers realize there may be some issue in which 
qos is used with mip6 then we may need to clarify 3775.  Otherwise, if 
in practice this  aspect was not identified by some implementers then we 
may continue as now until the need becomes apparent.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jun 2008 07:06:46 -0400

Alex,

> YEs, it was item 1: referenced spec (rfc2473) does have the words 
> about the possibility to copy the TC/Flow labels or insert 
> pre-configured values.  However, at least one widespread 
> implementation doesn't implement the latter feature.
>
> in practice this  aspect was not identified by some implementers then 
> we may continue as now until the need becomes apparent.

I understand what you want to do. But if our situation is that 
implementors are ignoring IETF RFCs, its not going to be helped by 
publishing more RFCs. And including things in category 1 would be a 
never-ending task. Lets focus on the other categories where we can 
actually add some value. And hopefully because of you raising this issue 
now here on the list some implementors are now going back to fix their 
code :-)

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 13:53:22 +0200

Jari Arkko wrote:
>> I think if some implementers realize there may be some issue in
>> which qos is used with mip6 then we may need to clarify 3775.
>> Otherwise, if in practice this  aspect was not identified by some
>> implementers then we may continue as now until the need becomes
>> apparent.
> 
> actually add some value. And hopefully because of you raising this
> issue now here on the list some implementors are now going back to
> fix their code :-)

I agree on the value adding part and I somehow disagree suggesting stuff
to implementers.  I am here to suggest back stuff to specifiers.

I often notice differences between what's being specified and what's
getting widely implemented.  Protocols don't make it to even a WG item
yet get deployed, and Proposed Standards protocols whose implementation 
is still to happen - but I disgress.

Let me stop commenting on this and come back to Chair's reminder on 
3775bis next steps.

Alex

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 15 Jun 2008 08:29:41 -0400

> Regards, Julien and marcelo

Hi Marcelo,

	I would like to request to consider looking into this issue as part of 
the effort for the proposed changes to RFC 3775.

Regards
Ashutosh

-------- Original Message --------
Subject: Re: [MEXT] simultaneous mobility
Date: Sat, 29 Mar 2008 10:02:37 +0100
From: marcelo bagnulo <[email-masked]>
To: Ashutosh Dutta <[email-masked]>
CC: Dr. Daniel Wong <[email-masked]>, [email-masked]
References: 
<[email-masked]> 	 
<[email-masked]> <[email-masked]>

Hi Ashutosh,

i would suggest you to suggest what text need to be changed in rfc3775
to solve this issue and send it to the list so people can comment

regards, marcelo

Ashutosh Dutta escribió:
 > Marcelo,
 >         As per your suggestion and brief discussion during IETF
 > meeting, I looked at RFC 3775. However, I have not seen anywhere about
 > the fall back option if the mobile is already operating in RO mode.
 > Section 11.8 in RFC 3775 discusses about the re-transmission of
 > Care-of Test Init messages and Binding Update that may go on
 > indefinitely.
 >
 > "The retransmissions by the mobile node MUST use an exponential back-
 > off process in which the timeout period is doubled upon each
 > retransmission, until either the node receives a response or the
 > timeout period reaches the value MAX_BINDACK_TIMEOUT.  The mobile
 > node MAY continue to send these messages at this slower rate
 > indefinitely."
 >
 >
 > However, if the retransmission goes on for indefinitely due to
 > simultaneous mobility and there is no fall back option, it might
 > affect the real-time communication because of the delayed RO. Thus, we
 > will probably need to find some solution either by specifying it as
 > part of RFC 3775bis or some other solution.
 >
 > It would be good to have some discussion on how to take care of this
 > specific problem.
 >
 > Regards
 > Ashutosh
 >
 > marcelo bagnulo wrote:
 >>> b) it was suggested that it is not a problem when route optimization
 >>> signaling is lost, because it will then fall back to bidirectional
 >>> tunneling. However, once the communication session has been started
 >>> and route optimization is in use, there is no mechanism specified in
 >>> RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh
 >>> comment more on this point). Perhaps the introduction of such a
 >>> fallback mechanism could be considered a candidate solution.
 >>>
 >> FWIW, imho this is how i would expect RFC3775 should behave, so imho
 >> this is simply something that was not fully specified in rfc3775.
 >> I would treat it as an update in rfc3775bis
 >>
 >> regards, marcelo
 >>
 >>
 >>
 >>> thanks
 >>> Daniel
 >>>
 >>> --
 >>> Dr. Daniel Wong
 >>> Assistant Professor
 >>> Malaysia University of Science and Technology
 >>> ** check out my book on wireless IP at
 >>> http://www.must.edu.my/~dwong/book.html
 >>> <http://www.must.edu.my/%7Edwong/book.html> **
 >>> 
------------------------------------------------------------------------

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sun, 15 Jun 2008 16:44:21 +0200

Hi Ashutosh,

in order to consider that input, you should submit it in the folllwing format:

- OLD TEXT in rfc 3775 that you want to change
- NEW TEXT that you want to include in rfc3775bis replacing the old text
- motivations for the change

I would ask you to do this soon, cause we are closing the window for 
submitting changes

regards, marcelo

Ashutosh Dutta <[email-masked]> dijo:

> 	I would like to request to consider looking into this issue as part 
> of the effort for the proposed changes to RFC 3775.
>
> Regards
> Ashutosh
>
> <[email-masked]> 
> <[email-masked]>
>
> Hi Ashutosh,
>

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 15 Jun 2008 23:03:46 -0400

Marcelo,
          Daniel Wong and I suggest to add the following new Text to RFC 
3775. We do not want to change any existing old text, but would like to 
add the following text in section 11.8 after second paragraph in page 137.

/new
In certain scenarios such as in case of simultaneous mobility where
both correspondent host and mobile host move at the same time, route
optimization may not complete because of failed return routability
procedures or failed binding updates. In such cases, the mobile SHOULD
have the fall back option to resume bidirectional tunneling in order
to avoid long delays in communication. Such an option could occur
after a suitable timeout period. new/

Motivation: The simultaneous mobility problem statement draft
http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt 
that was presented in 71 IETF at Philadelphia describes how return 
routability and binding update may get affected due to simultaneous 
mobility of the communicating hosts. Currently, RFC 3775 does not 
provide any guidelines regarding how to take care of the simultaneous 
mobility problem. During the draft presentation in IETF it was suggested 
to investigate RFC 3775 and propose alternative solutions to take care 
of this problem. One suggested solution was to add some provision for 
fall back option in 3775 and other approach would be to provide some 
extension. Since there is an attempt to produce the 3775-bis draft, this 
proposed text may be considered.

Regards
Ashutosh

MARCELO BAGNULO BRAUN wrote:
>>     I would like to request to consider looking into this issue as 
>> part of the effort for the proposed changes to RFC 3775.
>>
>> Regards
>> Ashutosh
>>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 16 Jun 2008 13:17:54 +1000

I think the text is not clear enough for specification language. Comments
inline

> procedures or failed binding updates. In such cases, the mobile SHOULD
=>                                                               ^^ node
> have the fall back option to resume bidirectional tunneling in order

=> Need to reword this, perhaps remove "have the" and "option"

> after a suitable timeout period. new/

=> What's the timeout period? Do you retry RO in parallel? Or retry RO once
before falling back to bidirectional tunnelling? There are several
variations that can be done. I think falling back permanently to
bidirectional tunnelling should be the last resort.

Hesham

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 16 Jun 2008 19:56:14 -0400

Hesham, thanks for the useful feedback. Please find the revised text 
taking into account your suggestions. Even with the inclusion of similar 
text that defines the provision of fall back to bidirectional tunneling 
mode, we still need to have a mechanism in place that will allow the 
mobile to start the bi-directional tunneling in parallel when the mobile 
has started the session with RO mode.

Also, what is the expected behavior of the mobile node and correspondent 
node when both bi-directional tunneling and RO procedures run in parallel?

Thanks
Ashutosh

/new
In certain scenarios such as in case of simultaneous mobility where
both correspondent host and mobile host move at the same time, route
optimization may not complete because of failed return routability
procedures or failed binding updates. In such cases, the mobile node 
SHOULD fall back to resume normal bidirectional tunneling in order
to avoid long delays in communication. The mobile node may run the 
bidirectional tunneling in parallel with the route optimization 
procedure until the RO procedure is successful. Bidirectional tunneling 
will start after RO procedure is not successful within a timeout period 
of MAX_RO_FAILURE (needs to be defined) and may continue to be the 
dafault option for that session if the RO procedure does not complete 
within the specified final timeout value of MAX_BINDACK_TIMEOUT. new/

---

From: "Daniel Wong" <[email-masked]>
Date: Mon, 16 Jun 2008 23:30:29 -0700

Thanks, Hesham, for your insightful comments. Indeed, when Ashutosh
and I were discussing about how this type of fallback solution
(fallback from route optimization to reverse tunneling in cases where
route optimization messages are getting lost due to simultaneous
mobility or other reasons), it seems there are a number of possible
ways to proceed, and they have their various pros and cons.

For example, continuing to retry RO while falling back on reverse
tunneling in parallel might be faster, but might have some new tricky
protocol and timing issues that need to be carefully thought through.
We would need to specify the correspondent host, home agent and mobile
host behaviors carefully.

If it is not done in parallel (say, it stops trying RO after one
retry, and just falls back to reverse tunneling), then it may or may
not have to use reverse tunneling for the rest of the session. maybe
it could try RO again the next time it moves or something.

Daniel

On Mon, Jun 16, 2008 at 4:56 PM, Ashutosh Dutta
<[email-masked]> wrote:
> Hesham, thanks for the useful feedback. Please find the revised text taking
> into account your suggestions. Even with the inclusion of similar text that
> defines the provision of fall back to bidirectional tunneling mode, we still
> need to have a mechanism in place that will allow the mobile to start the
> bi-directional tunneling in parallel when the mobile has started the session
> with RO mode.
>
> procedures or failed binding updates. In such cases, the mobile node SHOULD
> fall back to resume normal bidirectional tunneling in order
> bidirectional tunneling in parallel with the route optimization procedure
> until the RO procedure is successful. Bidirectional tunneling will start
> after RO procedure is not successful within a timeout period of
> MAX_RO_FAILURE (needs to be defined) and may continue to be the dafault
> option for that session if the RO procedure does not complete within the
> specified final timeout value of MAX_BINDACK_TIMEOUT. new/
>
>
> Hesham Soliman wrote:
>>
>>>>>> This is reminder of that plan and that proposals for changes for
>>>>>
>>>>> RFC3775
>>>>>>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Jun 2008 23:18:57 +0300

Ashutosh,

I think something may need to be done with respect to this issue, but I 
agree with Hesham that we are far from having the right text for it yet. 
I'm still struggling with the definition of the problem, actually.

There are a couple of issues that interact:

1) Mobile nodes cannot send traffic from their new care-of address 
directly to a correspondent node before they have sent the RO BU to the 
it (Section 11.3.1). This cannot happen before they have executed the 
full return routability procedure. From this we can conclude that if 
there is any data traffic to the correspondent node, it will have to go 
through the correspondent node's home address and home agent.

2) What is the reaction of the correspondent node when it receives 
tunneled traffic? See Section 11.7.2. But return routability packets are 
exempt from this rule.

3) Whether the usual RO rules for the destination apply to RR packets or 
not; as far as I know there are no special rules for them.

Did I miss anything? Based on the above, I have a few questions:

- If we need to specify something new action on this, should this action 
be triggered by (a) data traffic or (b) lack of response to RR packets?

- Or is it simply wrong to attempt to do the signaling to the peer's 
care-of address, maybe we should require doing it via the home address 
instead?

- Why is this issue specific to simultaneous movement? Wouldn't it 
happen also if the peer rebooted and got a new address, as well?

Jari

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 18 Jun 2008 09:34:36 -0400

Hi Jari,
         Thanks for your clarifications and questions.

Some of these were discussed in the mailing list after we posted the 
initial (00) draft on February 18. We took into consideration some of 
the comments from Killien and others and updated the draft just before 
the IETF in PA. However, the revised version was not submitted to IETF. 
You can still find the revised draft that has taken into account some of 
those comments and slides at the following location.

http://argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt
http://argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt

Daniel and I discussed your questions and suggestions. Please see the 
answers inline.

> through the correspondent node's home address and home agent.

Ans: We are describing a scenario where the mobile is already in a 
session using Route Optimized mode and then it moves. In this case RR 
(or BU) messages may not complete for reasons such as simultaneous 
mobility giving rise to data loss as the data will be sent to the old 
destination address.

> tunneled traffic? See Section 11.7.2. But return routability packets are 

Ans> We are referring to unsuccessful RR procedure here not the data
traffic.

> not; as far as I know there are no special rules for them.

Ans> RR signaling is sent to the home agent of the destination (home 
address of the destination), rather than directly to the destination 
address (as applied for data traffic). This reduces the likelihood of 
lost messages due to simultaneous mobility, for instance, but does not 
eliminate the possibility. Killien actually raised this good point 
during the mailing list discussion and we addressed that in the revised 
version of the draft. I am just quoting some sentences from the draft here.

"In reality, as a Mobility Header message, the binding update MUST NOT 
be sent to any care-of address that the Mobile Host might have for a 
mobile Correspondent Host, but must be sent to the permanent home 
address of the mobile Correspondent Host.  This binding update can then 
be forwarded by the mobile Correspondent Host's home agent to its 
current location. Similarly, Care-of-Test Init (CTI) and Home-Test Init 
(HTI), when sent to a Correspondent Host that is also mobile, MUST NOT 
be sent to the care-of address for that Correspondent Host, but both go 
to the home address, and thus, are forwarded to the Correspondent Host 
by the home agent of the Correspondent Host.  Thus, this serves as an 
in-built defense against the simultaneous mobility problem, since the 
home agent of the receiving host is involved.  The defense, however, is 
only partial, because it needs the Home Agent registration of the 
receiving host to be successfully completed before the control message 
can be properly forwarded to the receiving host.  Therefore, the 
interval of time in which the receiving Mobile Host is vulnerable to the 
simultaneous mobility problem is from when it transitions to interrupted 
state, until it can obtain a care-of address and complete
successful home registration."

The draft has a picture showing the occurrence of this specific scenario.

> be triggered by (a) data traffic or (b) lack of response to RR packets?

Ans> It should be triggered by lack of response to RR packets.

> care-of address, maybe we should require doing it via the home address 

Ans> Yes, it is better to do it via the home address. This reduces the
likelihood of lost messages due to simultaneous mobility, for instance, 
but does not eliminate the possibility, as we had discussed in the MEXT 
meeting in IETF 71 and illustrated in the revised draft. Please see the 
excerpt from the draft on this issue described above.

> happen also if the peer rebooted and got a new address, as well?

Ans> I think this problem could be applied to other scenarios that you 
have described as well. Also, it is a matter of timing.

Regards
Ashutosh