Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Apr 2009 18:03:05 +0200

We have this new version of the MCOA document that addresses the 
comments received, including IESG review comments.
To the best of my knowledge, the IESG is ok with the doc and ready for 
publication.
I am planning to ask our AD to move forward in a week or so, so, if you 
have comments on the document please provide them before the 1st of may.

Regards, marcelo
(mcoa doc shepherd)

-------- Mensaje original --------
Asunto: 	[MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
Fecha: 	Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
De: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Multiple Care-of Addresses Registration
	Author(s)       : R. Wakikawa, et al.
	Filename        : draft-ietf-monami6-multiplecoa-13.txt
	Pages           : 44
	Date            : 2009-04-20

According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the
correspondent nodes.  However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through
multiple accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses.  This
document proposes extensions to the Mobile IPv6 protocol to register
and use multiple care-of addresses.  The extensions proposed in this
document can be used by Mobile Routers using the NEMO (Network
Mobility) Basic Support protocol as well.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Apr 2009 09:18:12 -0700 (PDT)

Hi Marcelo,
  Do you consider the issue raised on the prefixes which affects Figures 1, 2 and 3 and possibly some other text closed?
  If yes, how is it closed? I for one is still confused especially with George's reply that talks about virtual interfaces.
  Also I have a question to Ryuji: does this draft send a non-deregistration BU at the home link? If yes, is he familiar with the discussion going on on this subject? This is another point of confusion for me.
  Sorry if I am too  much confused 
Please don't get me wrong, I am not trying to slow down the progress of this document.

Regards,

Behcet

________________________________
From: marcelo bagnulo braun <[email-masked]>
To: mext <[email-masked]>; Julien Laganier <[email-masked]>; Jari Arkko <[email-masked]>
Sent: Tuesday, April 21, 2009 11:03:05 AM
Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

We have this new version of the MCOA document that addresses the comments received, including IESG review comments.
To the best of my knowledge, the IESG is ok with the doc and ready for publication.
I am planning to ask our AD to move forward in a week or so, so, if you have comments on the document please provide them before the 1st of may.

Regards, marcelo
(mcoa doc shepherd)

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Apr 2009 13:02:56 -0400

Hi Behcet,

On 2009/04/21, at 12:18, Behcet Sarikaya wrote:

> Hi Marcelo,
>   Do you consider the issue raised on the prefixes which affects  
> Figures 1, 2 and 3 and possibly some other text closed?
>   If yes, how is it closed? I for one is still confused especially  
> with George's reply that talks about virtual interfaces.

I don't get your point. This document is about binding a home address  
to multiple CoAs.
Why you bring up with prefix here.
I think you are confused something.

>   Also I have a question to Ryuji: does this draft send a non- 
> deregistration BU at the home link? If yes, is he familiar with the  
> discussion going on on this subject? This is another point of  
> confusion for me.

This has been discussed for a long time in MEXT.
who is familiar with which discussions? I don't know your concern here.

> Please don't get me wrong, I am not trying to slow down the progress  

sure, but please explain your issue more precisely.

thanks!
ryuji

> To: mext <[email-masked]>; Julien Laganier <[email-masked] 
> >; Jari Arkko <[email-masked]>
> I am planning to ask our AD to move forward in a week or so, so, if  
> you have comments on the document please provide them before the 1st  
> of may.
>
> Regards, marcelo
> (mcoa doc shepherd)
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Apr 2009 11:43:15 -0700 (PDT)

Hi Ryuji,

  Please see inline.

Regards,

Behcet

From: Ryuji Wakikawa <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>; mext <[email-masked]>; Julien Laganier <[email-masked]>; Jari Arkko <[email-masked]>
Sent: Tuesday, April 21, 2009 12:02:56 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

[behcet] Yes but each interface will appear to HA as a different device and HA needs to assign a different HoA. Then MCoA problem disappears.
So George is saying that this is avoided by some virtual interfaces so that HA does not see each interface separately. 
Is this explained anywhere in the draft?
If yes then I am OK.

[behcet] So your answer is yes the draft sends a non-deregistration BU (kind of bulk registration) at the home link.
The discussion I mentioned was related to draft-premec-mext-extended-home-link. This draft also sends non-deregistration BU at the home link. So does a few more drafts likedraft-devarapalli-mext-mipv6-home-link.
 
[behcet] You mentioned some bit is set but I could not understand which. One idea is since so many drafts need this, why not factor this out and define whatever the mechanism to enable sending non-deregistration BU in 3775bis. What do you think about that?
 >  Sorry if I am too  much confused

thanks!
ryuji

Hi Behcet,

>  If yes, how is it closed? I for one is still confused especially with George's reply that talks about virtual interfaces.

I don't get your point. This document is about binding a home address to multiple CoAs.
Why you bring up with prefix here.
I think you are confused something.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Apr 2009 11:58:07 -0700

Behcet,

Behcet Sarikaya wrote:
> *[behcet] Yes but each interface will appear to HA as a different device 
> and HA needs to assign a different HoA. Then MCoA problem disappears.*
> *So George is saying that this is avoided by some virtual interfaces so 
> that HA does not see each interface separately. *
> *Is this explained anywhere in the draft?*
> *If yes then I am OK.*

The home agent does not care about the multiple interfaces on the mobile 
node. It only sees the mobile node as one entity and allocates a home 
address to it. The multiple care-of addresses that the mobile node has 
will be used by the home agent as tunnel end points. That is all. So 
there is no issue.

Vijay

>  >  Also I have a question to Ryuji: does this draft send a 
> non-deregistration BU at the home link? If yes, is he familiar with the 
> discussion going on on this subject? This is another point of confusion 
> for me.
> 
> *[behcet] So your answer is yes the draft sends a non-deregistration BU 
> (kind of bulk registration) at the home link.*
> *The discussion I mentioned was related to 
> draft-premec-mext-extended-home-link. This draft also sends 
> non-deregistration BU at the home link. So does a few more drafts like 
> **draft-devarapalli-mext-mipv6-home-link.*
> 
> ** 
> 
> *[behcet] You mentioned some bit is set but I could not understand 
> which. One idea is since so many drafts need this, why not factor this 
> out and define whatever the mechanism to enable sending 
> non-deregistration BU in 3775bis. What do you think about that?*
> 
> ** 
> 
> 
>  > Please don't get me wrong, I am not trying to slow down the progress 
> of this document..
> 
>  > From: marcelo bagnulo braun <[email-masked] 
> <mailto:[email-masked]>>
>  > To: mext <[email-masked] <mailto:[email-masked]>>; Julien Laganier 
> <[email-masked] 
> <mailto:[email-masked]>>; Jari Arkko 
> <[email-masked] <mailto:[email-masked]>>
> you have comments on the document please provide them before the 1st of may.
>  >
>  > Regards, marcelo
>  > (mcoa doc shepherd)
>  >
>  > De:    [email-masked] <mailto:[email-masked]>
>  > Para:    [email-masked] <mailto:[email-masked]>
>  > CC:    [email-masked] <mailto:[email-masked]>
>  >
>  >
>  >
>  >    Filename        : draft-ietf-monami6-multiplecoa-13..txt
>  >    Pages          : 44
>  >    Date            : 2009-04-20
>  >
>  > [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Apr 2009 12:04:24 -0700 (PDT)

So you are saying that there could be a single HA?

Regards,

Behcet

________________________________
From: Vijay Devarapalli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Ryuji Wakikawa <[email-masked]>; mext <[email-masked]>
Sent: Tuesday, April 21, 2009 1:58:07 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Behcet,

Behcet Sarikaya wrote:
> *[behcet] Yes but each interface will appear to HA as a different device and HA needs to assign a different HoA. Then MCoA problem disappears.*
> *So George is saying that this is avoided by some virtual interfaces so that HA does not see each interface separately. *

The home agent does not care about the multiple interfaces on the mobile node. It only sees the mobile node as one entity and allocates a home address to it. The multiple care-of addresses that the mobile node has will be used by the home agent as tunnel end points. That is all. So there is no issue.

Vijay

>  >  Also I have a question to Ryuji: does this draft send a non-deregistration BU at the home link? If yes, is he familiar with the discussion going on on this subject? This is another point of confusion for me.
> 
>  *[behcet] So your answer is yes the draft sends a non-deregistration BU (kind of bulk registration) at the home link.*
> *The discussion I mentioned was related to draft-premec-mext-extended-home-link. This draft also sends non-deregistration BU at the home link. So does a few more drafts like **draft-devarapalli-mext-mipv6-home-link.*
> 
> ** 
> *[behcet] You mentioned some bit is set but I could not understand which. One idea is since so many drafts need this, why not factor this out and define whatever the mechanism to enable sending non-deregistration BU in 3775bis. What do you think about that?*
> 
> ** 
> 
>  > Please don't get me wrong, I am not trying to slow down the progress of this document..
> 
>  >
>  > Regards,
>  >
>  > Behcet
>  > From: marcelo bagnulo braun <[email-masked] <mailto:[email-masked]>>
>  > To: mext <[email-masked] <mailto:[email-masked]>>; Julien Laganier <[email-masked] <mailto:[email-masked]>>; Jari Arkko <[email-masked] <mailto:[email-masked]>>
>  > Sent: Tuesday, April 21, 2009 11:03:05 AM
>  > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>  >
>  > We have this new version of the MCOA document that addresses the comments received, including IESG review comments.
>  > To the best of my knowledge, the IESG is ok with the doc and ready for publication.
>  > I am planning to ask our AD to move forward in a week or so, so, if you have comments on the document please provide them before the 1st of may.
>  >
>  > Regards, marcelo
>  > (mcoa doc shepherd)
>  >
>  > -------- Mensaje original --------
>  > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>  > Fecha:    Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
>  > De:    [email-masked] <mailto:[email-masked]>
>  > Para:    [email-masked] <mailto:[email-masked]>
>  > CC:    [email-masked] <mailto:[email-masked]>
>  >
>  >
>  >
>  > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.
>  >
>  >
>  >    Title          : Multiple Care-of Addresses Registration
>  >    Author(s)      : R. Wakikawa, et al.
>  >    Filename        : draft-ietf-monami6-multiplecoa-13..txt
>  >    Pages          : 44
>  >    Date            : 2009-04-20
>  >
>  > According to the current Mobile IPv6 specification, a mobile node may
>  > have several care-of addresses, but only one, called the primary
>  > care-of address, that can be registered with its home agent and the
>  > correspondent nodes.  However, for matters of cost, bandwidth, delay,
>  > etc, it is useful for the mobile node to get Internet access through
>  > multiple accesses simultaneously, in which case the mobile node would
>  > be configured with multiple active IPv6 care-of addresses.  This
>  > document proposes extensions to the Mobile IPv6 protocol to register
>  > and use multiple care-of addresses.  The extensions proposed in this
>  > document can be used by Mobile Routers using the NEMO (Network
>  > Mobility) Basic Support protocol as well.
>  >
>  > A URL for this Internet-Draft is:
>  > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
>  >
>  > Internet-Drafts are also available by anonymous FTP at:
>  > ftp://ftp.ietf.org/internet-drafts/
>  >
>  > Below is the data which will enable a MIME compliant mail reader
>  > implementation to automatically retrieve the ASCII version of the
>  > Internet-Draft.
>  >
>  >
>  >
>  > _______________________________________________
>  > MEXT mailing list
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/mext
> 
> 
>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 21 Apr 2009 20:14:55 +0100

...also wrt the home link registration, I do not think what you
suggest is necessary.

As far as I see the other documents are informational, and they do not
yet have a formal standing in the WG. If and when they do, as
Informational documents,  they should not require normative changes to
anything. They should make sure what they describe (mostly
implementation options in this case) are compatible not only with
RFC3775 but also with extensions to it, including Flow Bindings. .

Regards
George

On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <[email-masked]> wrote:
> address to it. The multiple care-of addresses that the mobile node has will
> be used by the home agent as tunnel end points. That is all. So there is no
> issue.
>
> Vijay
>
>>  >  Also I have a question to Ryuji: does this draft send a
>> discussion going on on this subject? This is another point of confusion for
>> me.
>>
>> *[behcet] You mentioned some bit is set but I could not understand which.
>> One idea is since so many drafts need this, why not factor this out and
>> define whatever the mechanism to enable sending non-deregistration BU in
>> 3775bis. What do you think about that?*
>>
>> **
>>
>>  > To: mext <[email-masked] <mailto:[email-masked]>>; Julien Laganier
>>  > We have this new version of the MCOA document that addresses the
>>  > I am planning to ask our AD to move forward in a week or so, so, if you

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 21 Apr 2009 20:39:08 +0100

Behcet,

I do not understand your latest question, but that's OK.  I am going
to try to read between the lines to see if I can help with this.

Based on your last e-mail, I think you now understand that according
to the MCoA draft the HA must treat all tunnels to the different CoAs
of an MN as indeed belonging to the same MN, and not as interfaces to
different MNs  (which would indeed require different prefixis) as you
originally thought.

This has always been clear, however, since all CoAs are registered
using the MNs home address as the MN identifier, and are secured by
the same MN-HA security association. So there can be no doubt that a
given set of CoAs belong to a given MN.

I hope this helps.

George

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 07:49:27 -0700 (PDT)

Why not?
Each interface having a different HA is a viable scenario IMHO.

I think this is where MCoA assumptions start to crack.

________________________________
From: Vijay Devarapalli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Sent: Tuesday, April 21, 2009 2:09:57 PM
Subject: RE: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

How is that relevant?

________________________________
From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo..com] 
Sent: Tuesday, April 21, 2009 12:09 PM
To: Vijay Devarapalli; Behcet Sarikaya
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Per MN.

Regards,

Behcet

________________________________
From: Vijay Devarapalli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Sent: Tuesday, April 21, 2009 2:06:42 PM
Subject: RE: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hi Behcet,
 
What do  you mean by single home agent?
 
Vijay

________________________________
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, April 21, 2009 12:04 PM
To: Vijay Devarapalli
Cc: mext
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Regards,

Behcet

Behcet,

> *Is this explained anywhere in the draft?*

The home agent does not care about the multiple interfaces on the mobile node. It only sees the mobile node as one entity and allocates a home address to it. The multiple care-of addresses that the mobile node has will be used by the home agent as tunnel end points.. That is all. So there is no issue.

Vijay

>  >    Author(s)      : R. Wakikawa, et al..

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 07:59:13 -0700 (PDT)

Hi George,
  It seems like now you are telling the truth 
Basically MCoA draft wishes to establish some hierarchy of the interfaces. There is one which is the main interface (Vijay calls this main entity but as we ALL know addresses as Layer 3 identities are assigned to the interfaces not the the entities). There are other interfaces which are the lowest level interfaces.
MN does INE using the main interface. Uses IKEv2 and gets HoA assigned establishes secure tunnel with the HA on this interface.

Somewhat magically the lowest level interfaces become active and connect to some other domains and get CoA1 then MCoA draft kicks in and starts assigning these BIDs.

My suggestion is that the draft should explain this clearly in textual form.

Regards,

Behcet

________________________________
From: George Tsirtsis <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; mext <[email-masked]>
Sent: Tuesday, April 21, 2009 2:14:55 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

....also wrt the home link registration, I do not think what you
suggest is necessary.

Regards
George

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 08:06:06 -0700 (PDT)

Hi George,
  It seems in my previous reply I replied to this mail of yours which was unrelated to the other mail you sent to which I was really replying, apologies.
  Now regarding home link registration, what is the mechanism MCoA draft uses? Ryuji mentioned some H bit but I read the draft and couldn't confirm it.

  My suggestion was building on this, i.e.. I suggested that whatever you came up with can be moved to 3775bis so that other people would not have to make normative references to your draft.

That's all.

Regards,

Behcet

Regards
George

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 22 Apr 2009 16:06:18 +0100

>   It seems like now you are telling the truth

GT> I always try :-)

> Basically MCoA draft wishes to establish some hierarchy of the interfaces.
> There is one which is the main interface (Vijay calls this main entity but
> as we ALL know addresses as Layer 3 identities are assigned to the
> interfaces not the the entities). There are other interfaces which are the
> lowest level interfaces.
> MN does INE using the main interface. Uses IKEv2 and gets HoA assigned
> establishes secure tunnel with the HA on this interface.
>

GT> Not sure what INE is

> Somewhat magically the lowest level interfaces become active and connect to
> some other domains and get CoA1 then MCoA draft kicks in and starts
> assigning these BIDs..
>

GT> You are missing the fact that the lowest interface can actually
come up first so that the MN gets a CoA, which is then using to
bootstrap with the HA.

> My suggestion is that the draft should explain this clearly in textual form.

GT> Behcet, all this is already known and obvious. We can add any
number of obvious things to every document but I do not think it is
useful. RFCs are not tutorials. The reader is expected to be familiar
with the subject, especially when looking at an extension of a base
protocol like MCoA is to MIP.

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 22 Apr 2009 16:10:08 +0100

I do not think that adding home link registration to RFC3775bis is feasible.
This requires logic in the MN and HA that is not directly compatible
to RFC3775. The aim of RFC3775bis is to make minimal changes for
clarification reasons and to correct errors. Home Link Registration as
defined in MCoA is neither.

On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
<[email-masked]> wrote:
> Hi George,
>   It seems in my previous reply I replied to this mail of yours which was
> unrelated to the other mail you sent to which I was really replying,
> apologies.
>   Now regarding home link registration, what is the mechanism MCoA draft
> uses? Ryuji mentioned some H bit but I read the draft and couldn't confirm
> it.
>
>   My suggestion was building on this, i.e. I suggested that whatever you
> came up with can be moved to 3775bis so that other people would not have to
> make normative references to your draft.
>
> That's all.
>
> Regards,
>
> Behcet
>
>> will
>>> for
>>>  > Please don't get me wrong, I am not trying to slow down the progress
>>> of
>>> this document..
>>>
>>>  > Subject: [MEXT] [Fwd: I-D
>>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>  >
>>>  > To the best of my knowledge, the IESG is ok with the doc and ready for
>>> publication..

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 08:25:58 -0700 (PDT)

So the first interface that does INE (initial network entry, SDO terminology) becomes the main interface and grabs the HoA.
I don't think stating this basic assumption is not good. Many people including Vijay had some different thoughts.

--behcet

Cc: mext <[email-masked]>
Sent: Wednesday, April 22, 2009 10:06:18 AM

GT> I always try :-)

GT> Not sure what INE is

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 22 Apr 2009 16:29:08 +0100

sigh... this is not what I said....
Also Vijay has the same thoughts with me on the subject...this does
not happen often, but it does happen!

On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya
<[email-masked]> wrote:
> So the first interface that does INE (initial network entry, SDO
> terminology) becomes the main interface and grabs the HoA.
> I don't think stating this basic assumption is not good. Many people
> including Vijay had some different thoughts.
>
> --behcet
>
>> Subject: Re: [MEXT] [Fwd: I-D

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 08:31:17 -0700 (PDT)

From: George Tsirtsis <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: mext <[email-masked]>
Sent: Wednesday, April 22, 2009 10:10:08 AM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

[behcet] Why not? If it is needed in so many instances, that qualifies it to become a base protocol feature, at least to me.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 13:02:47 -0700 (PDT)

George, 

   I checked 3775, 
Home Address A unicast routable address assigned to a mobile node, used as the
      permanent address of the mobile node.

HoA can be used as source addresses in IP packets and it is not Host
             Identity Tag (HIT) of HIP, as Vijay may possibly wish to identify.

RFC 5026 defines how HoA can be configured from the prefix and IID just like any IPv6 address. This address is assigned to the interface with which MN connects to the home link.

HIT on the other hand is also of the same length but it is generated from HI using hashed encoding. It is not an IPv6 address.

BR,

Behcet 

Sent: Wednesday, April 22, 2009 10:29:08 AM

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 22 Apr 2009 17:18:28 -0400

Hi Behcet,

On 2009/04/22, at 11:31, Behcet Sarikaya wrote:

> [behcet] Why not? If it is needed in so many instances, that  
> qualifies it to become a base protocol feature, at least to me.

We cannot add a new feature to 3775. That is the ground rule of -bis.  
The chairs can clarify this.

regards,
ryuji

> > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <[email-masked] 
> >
> > wrote:
> >> Behcet,
> >>
> >> Behcet Sarikaya wrote:
> >>>
> >> be used by the home agent as tunnel end points. That is all. So  
> there is
> >> no
> >> issue.
> >>
> >> Vijay
> >>
> confusion
> >>> <mailto:[email-masked]>>; Jari Arkko
> >>>  > Subject: [MEXT] [Fwd: I-D
> >>> you
> >>>  > De:    [email-masked] <mailto:[email-masked] 
> >
> >>>  > A New Internet-Draft is available from the on-line Internet- 
> Drafts
> >>> directories.
> >>>  > This draft is a work item of the Mobility EXTensions for IPv6  
> Working
> >>> Group of the IETF.
> >>>  >
> >>>  >

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 22 Apr 2009 17:22:43 -0400

Hi Behet.

We don't treat HoA as HIT in MCoA, but just follows how RFC3775  
defines HoA.

regards,
ryuji

On 2009/04/22, at 16:02, Behcet Sarikaya wrote:

> RFC 5026 defines how HoA can be configured from the prefix and IID  
> just like any IPv6 address. This address is assigned to the  
> interface with which MN connects to the home link.
>
> HIT on the other hand is also of the same length but it is generated  
> from HI using hashed encoding. It is not an IPv6 address.
>
>
> BR,
>
> Behcet
> >> Somewhat magically the lowest level interfaces become active and  
> connect
> >> to
> >> My suggestion is that the draft should explain this clearly in  
> textual
> >> form.
> >>
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 14:41:30 -0700 (PDT)

Hi Ryuji,
  So you agree that a clarification is needed regarding the main interface and other or auxiliary interfaces that I was trying to express in my previous mails. 

Regards,

Behcet

________________________________
From: Ryuji Wakikawa <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: George Tsirtsis <[email-masked]>; mext <[email-masked]>
Sent: Wednesday, April 22, 2009 4:22:43 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hi Behet.

We don't treat HoA as HIT in MCoA, but just follows how RFC3775 defines HoA.

regards,
ryuji

On 2009/04/22, at 16:02, Behcet Sarikaya wrote:

> >> Cc: Behcet Sarikaya <[email-masked]>; mext <mext@ietf..org>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 14:45:53 -0700 (PDT)

Hi Ryuji,
  I checked your draft. Again, I could not understand how you are sending a registration BU at the home link as only an O-flag is defined in your draft which is used for something else.
  As I mentioned to you, we discussed this related to draft-premec-homelink and it seems like HA will reject such a BU unless something is done, I thought you were familiar with the discussions as it relates to your draft too. I am surprised.

Regards,

Behcet

Sent: Wednesday, April 22, 2009 4:18:28 PM

Hi Behcet,

> [behcet] Why not? If it is needed in so many instances, that qualifies it to become a base protocol feature, at least to me.

We cannot add a new feature to 3775. That is the ground rule of -bis. The chairs can clarify this.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 22 Apr 2009 17:52:15 -0400

Hi Behcet,

On 2009/04/22, at 17:41, Behcet Sarikaya wrote:

> Hi Ryuji,
>   So you agree that a clarification is needed regarding the main  
> interface and other or auxiliary interfaces that I was trying to  
> express in my previous mails.

I don't agree with you...

We don't have the definition of neither main or auxiliary interfaces.
Multiple CoAs are described in RFC3775.

    care-of address
       A unicast routable address associated with a mobile node while
       visiting a foreign link; the subnet prefix of this IP address  
is a
       foreign subnet prefix.  Among the multiple care-of addresses that
       a mobile node may have at any given time (e.g., with different
       subnet prefixes), the one registered with the mobile node's home
       agent for a given home address is called its "primary" care-of
       address.

MCoA is just extension how to register multiple COAs to HA.
We don't need any special clarification in MCoA,
because we didn't change anything here.

regards,
ryuji

> > HIT on the other hand is also of the same length but it is  
> generated from HI using hashed encoding. It is not an IPv6 address.
> >
> >
> > BR,
> >
> > Behcet
> > sigh.... this is not what I said....
> > >> Somewhat magically the lowest level interfaces become active  
> and connect
> > >> to

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 23:59:50 +0200

Hi Bechet,

could you send exactly what text do you think needs to be changed in the 
MCOA draft, so the WG can evaluate and figure out if the changes are 
needed? (i.e. please send OLD text NEW text)

Please note that at this point in the life of the document, we only take 
changes that fix errors in the document, rather than  getting more 
features in.

Regards, marcelo

Behcet Sarikaya escribió:
> Hi Ryuji,
>   I checked your draft. Again, I could not understand how you are 
> sending a registration BU at the home link as only an O-flag is 
> defined in your draft which is used for something else.
>   As I mentioned to you, we discussed this related to 
> draft-premec-homelink and it seems like HA will reject such a BU 
> unless something is done, I thought you were familiar with the 
> discussions as it relates to your draft too. I am surprised.
>  
> Regards,
>  
> Behcet
>
> *From:* Ryuji Wakikawa <[email-masked]>
> *To:* Behcet Sarikaya <[email-masked]>
> *Cc:* George Tsirtsis <[email-masked]>; mext <[email-masked]>
> *Sent:* Wednesday, April 22, 2009 4:18:28 PM
> *Subject:* Re: [MEXT] [Fwd: I-D 
> > From: George Tsirtsis <[email-masked] 
> <mailto:[email-masked]>>
> > To: Behcet Sarikaya <[email-masked] <mailto:[email-masked]>>
> > Cc: mext <[email-masked] <mailto:[email-masked]>>
> > <[email-masked] <mailto:[email-masked]>> wrote:
> > > Hi George,
> > > From: George Tsirtsis <[email-masked] 
> <mailto:[email-masked]>>
> > > To: Vijay Devarapalli <[email-masked] <mailto:[email-masked]>>
> > > Cc: Behcet Sarikaya <[email-masked] 
> <mailto:[email-masked]>>; mext <[email-masked] <mailto:[email-masked]>>
> > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli 
> <[email-masked] <mailto:[email-masked]>>
> > > wrote:
> > >> Behcet,
> > >>
> > >> Behcet Sarikaya wrote:
> > >>>
> <mailto:[email-masked]>
> > >>> <mailto:[email-masked] <mailto:[email-masked]>>>
> > >>>  > To: mext <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>; Julien Laganier
> <mailto:[email-masked]>
> > >>> <mailto:[email-masked] 
> <mailto:[email-masked]>>>; Jari Arkko
> > >>> <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> > >>>  > Asunto:    [MEXT] I-D 
> Action:draft-ietf-monami6-multiplecoa-13.txt
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>
> > >>>  >
> > >>>  >
> > >>>  >
> > >>>  > A New Internet-Draft is available from the on-line 
> Internet-Drafts
> > >>> directories.
> > >>>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 22 Apr 2009 18:02:09 -0400

Hi Behcet,

> defined in your draft which is used for something else.

Please see section 5.6.3

>   As I mentioned to you, we discussed this related to draft-premec- 
> homelink and it seems like HA will reject such a BU unless something  
> is done, I thought you were familiar with the discussions as it  
> relates to your draft too. I am surprised.

yes, I follow that discussion.
RFC3775-bis should not include any additional features like sending BU  
from the home link.
We should define this in MCoA. Only if needed, draft-homelink can  
refer to MCoA for this feature.

regards,
ryuji

> > >>>  > This draft is a work item of the Mobility EXTensions for  
> IPv6 Working
> > >>> Group of the IETF.
> > >>>  >
> > >>>  >

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 15:54:19 -0700 (PDT)

Hi Ryuji,
  So you are going to define a C-Flag?
I am OK with it. But I don't understand why the only right place is your draft. My idea is that the right place for such a thing is 3775bis as this would avoid people with drafts not related to MCoA having to refer to MCoA draft.

Regards,

Behcet

Sent: Wednesday, April 22, 2009 5:02:09 PM

Hi Behcet,

Please see section 5.6.3

yes, I follow that discussion.
RFC3775-bis should not include any additional features like sending BU from the home link.
We should define this in MCoA. Only if needed, draft-homelink can refer to MCoA for this feature.

regards,
ryuji

> > > it..
> > >>> publication...

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Apr 2009 16:07:50 -0700 (PDT)

Hi Marcelo,
  How about this little paragraph?

In this document it is assumed that a multi-homed MN connects to the home link using only one interface. Therefore this interface is considered as the main interface as identified by the home address assigned by the home agent.  The other or auxiliary interfaces may later on become active and connect to some other networks and get their care-of addresses and then the procedures defined in this document allow such care-of addresses to be registered with the home agent apart from the registration of the care-of addresses assigned to the main interface which is already defined in RFC 3775.

Regards,

Behcet

Sent: Wednesday, April 22, 2009 4:59:50 PM

Hi Bechet,

could you send exactly what text do you think needs to be changed in the MCOA draft, so the WG can evaluate and figure out if the changes are needed? (i.e. please send OLD text NEW text)

Please note that at this point in the life of the document, we only take changes that fix errors in the document, rather than  getting more features in.

Regards, marcelo

Behcet Sarikaya escribió:
> *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> 
> Hi Behcet,
> 
> > From: George Tsirtsis <[email-masked] <mailto:[email-masked]>>
> > > From: George Tsirtsis <[email-masked] <mailto:[email-masked]>>
> > > Cc: Behcet Sarikaya <[email-masked] <mailto:[email-masked]>>; mext <[email-masked] <mailto:[email-masked]>>
> > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <[email-masked] <mailto:[email-masked]>>
> > > wrote:
> > >> Behcet,
> > >>
> > >> Behcet Sarikaya wrote:
> > >>>
> > >>>  > From: marcelo bagnulo braun <[email-masked] <mailto:[email-masked]>
> > >>>  > To: mext <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>; Julien Laganier
> > >>> <[email-masked] <mailto:[email-masked]>
> > >>> <mailto:[email-masked] <mailto:[email-masked]>>>; Jari Arkko
> > >>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> > >>>  > De:    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > >>>  > Para:    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > >>>  > CC:    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > >>>  >
> > >>>  >
> > >>>  >
> > >>>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Apr 2009 16:43:13 -0700

Hi Bechet,

On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote:

> In this document it is assumed that a multi-homed MN connects to the home link
> using only one interface. Therefore this interface is considered as the main
> interface as identified by the home address assigned by the home agent.

I disagree with this. The mobile node can connect to the home link through
any one of its interfaces.

> The 
> other or auxiliary interfaces may later on become active and connect to some
> other networks and get their care-of addresses and then the procedures defined
> in this document allow such care-of addresses to be registered with the home
> agent apart from the registration of the care-of addresses assigned to the
> main interface which is already defined in RFC 3775.

There is no need for the home agent to identify one of the interfaces as a
"main" interface.

Vijay

> could you send exactly what text do you think needs to be changed in the MCOA
> draft, so the WG can evaluate and figure out if the changes are needed? (i.e.
> please send OLD text NEW text)
> 
> changes that fix errors in the document, rather than  getting more features
> in.
> 
> Regards, marcelo
> 
> 
> 
>>  I checked your draft. Again, I could not understand how you are sending a
>> registration BU at the home link as only an O-flag is defined in your draft
>> which is used for something else.
>>  As I mentioned to you, we discussed this related to draft-premec-homelink
>> and it seems like HA will reject such a BU unless something is done, I
>> thought you were familiar with the discussions as it relates to your draft
>> too. I am surprised.
>>  Regards,
>>  Behcet
>> 
>>> [behcet] Why not? If it is needed in so many instances, that qualifies it to
>>> become a base protocol feature, at least to me.
>> 
>>>> <mailto:[email-masked]>>
>>>> wrote:
>>>>> Behcet,
>>>>> 
>>>>> Behcet Sarikaya wrote:
>>>>>> 
>>>>> be used by the home agent as tunnel end points. That is all.. So there is
>>>>> no
>>>>> issue.
>>>>> 
>>>>> Vijay
>>>>> 
>>>>>>> To: mext <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>>>>>> <mailto:[email-masked]>>>; Julien Laganier
>>>>>> <mailto:[email-masked] <mailto:jari.arkko@piuha..net
>>>>>> <mailto:[email-masked]> >>>
>>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>> CC:    [email-masked] <mailto:mext@ietf..org <mailto:[email-masked]> >
>>> [email-masked] <mailto:[email-masked] <mailto:MEXT@ietf..org> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Apr 2009 08:54:17 +0200

To be placed where in the document?
All the rest of the document stays the same?

Behcet Sarikaya escribió:
> In this document it is assumed that a multi-homed MN connects to the 
> home link using only one interface. Therefore this interface 
> is considered as the main interface as identified by the home address 
> assigned by the home agent.  The other or auxiliary interfaces may 
> later on become active and connect to some other networks and get 
> their care-of addresses and then the procedures defined in this 
> document allow such care-of addresses to be registered with the home 
> agent apart from the registration of the care-of addresses assigned to 
> the main interface which is already defined in RFC 3775.
> Regards,
>  
> Behcet
> *From:* marcelo bagnulo braun <[email-masked]>
> *Cc:* Ryuji Wakikawa <[email-masked]>; mext <[email-masked]>
> *Sent:* Wednesday, April 22, 2009 4:59:50 PM
> could you send exactly what text do you think needs to be changed in 
> the MCOA draft, so the WG can evaluate and figure out if the changes 
> are needed? (i.e. please send OLD text NEW text)
>
> Please note that at this point in the life of the document, we only 
> take changes that fix errors in the document, rather than  getting 
> more features in.
>
> Regards, marcelo
>
>
>
> > *From:* Ryuji Wakikawa <[email-masked] 
> <mailto:[email-masked]>>
> > *To:* Behcet Sarikaya <[email-masked] <mailto:[email-masked]>>
> > *Cc:* George Tsirtsis <[email-masked] 
> <mailto:[email-masked]>>; mext <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> > > To: Behcet Sarikaya <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> > > Cc: mext <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> > > <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>> 
> wrote:
> > > > Hi George,
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> > > > To: Vijay Devarapalli <[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>; mext <[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> > > > wrote:
> > > >> Behcet,
> > > >>
> > > >> Behcet Sarikaya wrote:
> > > >>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> > > >>> <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>>
> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>>; Julien Laganier
> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]> 
> <mailto:[email-masked]>>>>; Jari Arkko
> <mailto:[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:jari.arkko@piuha..net <mailto:[email-masked]>>>>
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:mext@ietf..org <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> > > >>>  >
> > > >>>  >
> > > >>>  >
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:MEXT@ietf..org>>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 23 Apr 2009 09:41:27 +0100

I also disagree... there is not such thing as a 'main' interface and
there is no restriction on how many interfaces are connected to the
home link, or whether aninterface connected on the home link then goes
ahead is moved from the home link to a foreign link.

George

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Apr 2009 20:17:59 +1000

Such restriction makes no sense for the document. The MN has to be able to
use any interface. 

Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Apr 2009 08:45:12 -0700 (PDT)

Hesham, I don't think the text imposes on which interface you connect to the home link, so MN is able to use any interface.

What the text says, the interface used to connect to the home interface is considered as the main interface as far as this document is concerned. 

Maybe we can clarify the main and auxiliary with "as far as this document is concerned".

Regards,

Behcet

________________________________
From: Hesham Soliman <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: mext <[email-masked]>
Sent: Thursday, April 23, 2009 5:17:59 AM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Apr 2009 08:47:53 -0700 (PDT)

Hi George,
  The problem was exactly many interfaces connecting to the home link.
If that happens you agreed that a different prefix has to be assigned to each prefix and this requires many changes in MCoA draft.

You want to go ahead with this or with the proposed text?

Regards,

Behcet

________________________________
From: George Tsirtsis <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; marcelo bagnulo braun <[email-masked]>; mext <[email-masked]>
Sent: Thursday, April 23, 2009 3:41:27 AM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

George

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Apr 2009 08:53:39 -0700 (PDT)

Hi Vijay,
  I understand your concerns.

Here is slightly revised version removing main and auxiliary:

In this document it is assumed that a multi-homed MN connects to the home link using only one interface. This interface is identified by the home address assigned by the home agent.  The other  interfaces may later on become active and connect to some other networks and get their care-of addresses and then the procedures defined in this document allow such care-of addresses to be registered with the home agent apart from the registration of the care-of addresses assigned to the  interface MN originally used to connect to the home link which is already defined in RFC 3775.

Regards,

Behcet

________________________________
From: Vijay Devarapalli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; marcelo bagnulo braun <[email-masked]>
Cc: mext <[email-masked]>
Sent: Wednesday, April 22, 2009 6:43:13 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hi Bechet,

Vijay

>>>> That's all..
>>>>>>> <mailto:Internet-Drafts@ietf..org <mailto:[email-masked]>>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 23 Apr 2009 13:28:54 -0400

I kind of understand what you are saying now. You are concerned about the mobile node attaching to the home link via multiple interfaces (since it has multiple interfaces) and the result of assigning the home address to those interfaces.

As far as RFC 3775 and the MCoA draft is concerned, the home address is assigned to first interface with which the mobile node attaches to the home link. This may require the mobile node to "move" the home address from a MIPv6 virtual interface to the physical interface with which it attaches to the home link. This is implementation specific. 

If the mobile node attaches to the home link via a second interface, I think the mobile node should get a new home address for that interface. Not the same home address. 

Does the above make sense?

Vijay 

> -----Original Message-----
> Sent: Thursday, April 23, 2009 8:54 AM
> To: Vijay Devarapalli; marcelo bagnulo braun
> Cc: mext
> In this document it is assumed that a multi-homed MN connects 
> to the home link using only one interface. This interface is 
> identified by the home address assigned by the home agent.  
> The other  interfaces may later on become active and connect 
> to some other networks and get their care-of addresses and 
> then the procedures defined in this document allow such 
> care-of addresses to be registered with the home agent apart 
> from the registration of the care-of addresses assigned to 
> the  interface MN originally used to connect to the home link 
> which is already defined in RFC 3775.
> 
> 
> Regards,
>  
> Behcet
> 
> draft-premec-homelink
> >> We cannot add a new feature to 3775. That is the ground 
> rule of -bis. The
> >> chairs can clarify this.
> >> 
> >> regards,
> >> ryuji
> >> 
> >> 
> >> 
> >>> 
> >>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >>>> Hi George,
> <mailto:[email-masked]
> >>>>>> <jari.arkko@piuha..net <mailto:[email-masked]>  
> <mailto:[email-masked]>
> >>>>>> <mailto:[email-masked] 
> <mailto:jari.arkko@piuha..net <mailto:jari..arkko@piuha..net> 
> >>>>>>> This draft is a work item of the Mobility EXTensions 
> for IPv6 Working
> >>>>>> Group of the IETF..
> >>>>>>> 
> >>>>>>>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 23 Apr 2009 18:59:31 +0100

> If the mobile node attaches to the home link via a second interface, I think the mobile node should get a new home address for that interface. Not the same home address.

GT> The MN would not be able to get the same home address even if it
tried. At the time a node attaches an interface on a link, the Access
Routers do not have any clue to what node this interface belongs or
whether this node has other interfaces on or off link. All interfaces
are assumed to have different IP addresses at that level. It is only
after that, the MN communicates with the HA function in the local AR (
assuming that is where its HA is) establishes ONE of its addresses as
home address.

GT> Again I do not think there is anything to define here.

---

From: Yungui Wang <[email-masked]>
Date: Fri, 24 Apr 2009 11:54:25 +0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Friday, April 24, 2009 1:29 AM
> To: Behcet Sarikaya; marcelo bagnulo braun
> Cc: mext
> I kind of understand what you are saying now. You are 
> concerned about the mobile node attaching to the home link 
> via multiple interfaces (since it has multiple interfaces) 
> and the result of assigning the home address to those interfaces.
> 
> As far as RFC 3775 and the MCoA draft is concerned, the home 
> address is assigned to first interface with which the mobile 
> node attaches to the home link. This may require the mobile 
> node to "move" the home address from a MIPv6 virtual 
> interface to the physical interface with which it attaches to 
> the home link. This is implementation specific. 
> 
> If the mobile node attaches to the home link via a second 
> interface, I think the mobile node should get a new home 
> address for that interface. Not the same home address. 
> 
[Yungui] In this case, in my mind, the question is, could we treat
this new HoA as a (home) CoA binding to the primary HoA?
If so, the service continuity could be guaranteed because this 
interface is using the primary HoA. Otherwise, it seems the HA 
has to initiate flow handover to another interface.
Therefore, I think, Behcet's statement makes sense.

B.R.
Yungui

> <mailto:[email-masked]>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Apr 2009 22:32:18 -0700

Hello,

On 4/23/09 8:54 PM, "Yungui Wang" wrote:

> interface is using the primary HoA.

That would be out of scope. As far as the current MCoA draft is concerned,
there is no tunneling from the home link.

Vijay

> Otherwise, it seems the HA

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 24 Apr 2009 15:34:40 -0700 (PDT)

[behcet] Yes I agree but which ONE? I think that's where we need clarification. As Vijay says MN may connect the home link over multiple interfaces, etc.
The text I proposed has the purpose of clarifying these. It is probably suggesting some restrictions and maybe that's why you are not happy 
We are saying that you should not be at the home link and roaming at the same time. I think this is a fair assumption to make.
 
What do you think?

Regards,
 
Behcet
 
I removed the rest as it was getting so big.

---

From: Yungui Wang <[email-masked]>
Date: Sat, 25 Apr 2009 08:50:19 +0800

Hello

  _____  

From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 1:32 PM
To: [email-masked]; Behcet Sarikaya; marcelo bagnulo braun
Cc: mext
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hello,

 
As MCoA I-D described, when MN is located in foreign link 
and home link in parallel, its interface returning home may 
register a home binding with its (HoA, CoA). Here CoA is 
set to HoA. Due to there are two HoA in above situation, 
maybe it needs to be clarified something, such as 
'what's the just HoA set to CoA in home binding for the 
second interface'; or 

'the second interface returning home is not supported'; or
'the second interface returning home is implicitly de-registered 
from MCoA registration'; etc.
If it is out of scope, obviously some ambiguous operation is left.
 
In addition, tunneling may be not necessary for the second 
interface at home link. It need also register its Link-layer 
Address Option for packet forwarding. The I-D can give a 
note that HA shall use link-layer address to forward downlink
packet once it is presented.
 
B.R.
Yungui

Vijay

>>>>>>>>> <mailto:[email-masked]  <mailto:[email-masked]
<mailto:[email-masked]> >>>
>>> <mailto:jari.arkko@piuha..net  <mailto:jari.arkko@piuha..net
<mailto:jari..arkko@piuha..net> >
>>>>>>>>>> <mailto:[email-masked]  <mailto:[email-masked]
<mailto:[email-masked]> >>
>>>>>> [email-masked] <mailto:[email-masked]  <mailto:[email-masked]
<mailto:MEXT@ietf..org> > >

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 25 Apr 2009 01:32:14 -0700

Hi Behcet, Vijay and George,

On 2009/04/23, at 13:59, George Tsirtsis wrote:

>> I kind of understand what you are saying now. You are concerned  
>> about the mobile node attaching to the home link via multiple  
>> interfaces (since it has multiple interfaces) and the result of  
>> assigning the home address to those interfaces.
>>
>> address is assigned to first interface with which the mobile node  
>> attaches to the home link. This may require the mobile node to  
>> "move" the home address from a MIPv6 virtual interface to the  
>> physical interface with which it attaches to the home link. This is  
>> implementation specific.
>>
>> interface, I think the mobile node should get a new home address  
>> for that interface. Not the same home address.
>>
>

 From IPv6 point of view, a node cannot assign the same address to  
multiple interfaces on the same link.
Thus, as Vijay and George mentioned, we don't have the configuration  
which you concerned in MCoA.

> GT> Again I do not think there is anything to define here.

I don't think this clarification is necessary.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 25 Apr 2009 01:32:33 -0700

Hi Behcet,

>   So you are going to define a C-Flag?

MCoA does not have such flag. What are you referring to?

regards,
ryuji

> I am OK with it. But I don't understand why the only right place is  
> your draft. My idea is that the right place for such a thing is  
> 3775bis as this would avoid people with drafts not related to MCoA  
> having to refer to MCoA draft.
>
> Regards,
>
> Behcet
>
> > From: Ryuji Wakikawa <ryuji.wakikawa@gmail..com>
> > > To: Behcet Sarikaya <sarikaya@ieee..org>
> > > Cc: mext <[email-masked]>
> > > >> be used by the home agent as tunnel end points. That is all.  
> So there is
> > > >> no
> > > >> issue.
> > > >>
> > > >> Vijay
> > > >>
> > > >>>  > To: mext <mext@ietf..org <mailto:[email-masked]>>; Julien  
> Laganier
> > > >>> <julien.laganier.ietf@googlemail..com
> > > >>> comments received, including IESG review comments..
> > > >>>  > Para:    [email-masked] <mailto:[email-masked] 
> >
> > > >>>  > be configured with multiple active IPv6 care-of  
> addresses..  This

---

From: jouni korhonen <[email-masked]>
Date: Wed, 29 Apr 2009 15:39:44 +0300

Hi,

I had a quick re-read of this I-D based on the recent interest on  
it ;)  And found several placed to comment. Mainly editorials but some  
other stuff as well.

o Section 5.7 second bullet:

   "o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
       mobile node needs to stop using bulk registrations with the node
       that sent the Binding Acknowledgement.  It should assume that  
none
       of the attempted registrations were successful."

   Why "should"? I think "It MUST assume" works better here as the CN  
MUST reject the BU anyway according to Section 6.2. third bullet.
o Section 5.7 second & third bullets
   Where "MCOA BULK REGISTRATION NOT SUPPORT" and its value is  
actually defined? It is not listed in IANA considerations nor in  
Section 4.4.
o Section 5.7 third bullet:
   s/corruption. ./corruption.

o Section 5.7 fourth bullet

   s/replced/replaced

o Section 5.7 fifth bullet:

   s/care-off/care-of

o Section 5.7 fifth bullet:

   "...
    indicated.  If the mobile node is trying to deregister a BID, it
    NEED NOT do anything further."

   There is no such requirement language term as "NEED NOT" in rfc2119.

o Section 5.9

   "..If old bindings still exists at.."

   s/exists/exist

o Section 6.2 sixth bullet, first sub-bullet

   "..is 20, the care-of address is copied the IPv6 address from the.."

   should probably say

   "..is 20, the care-of address is the IPv6 address copied from the.."

o Section 8.1 first paragraph

   "..even if some of the care-of addresses are IPv4 address."

   s/are/is

Cheers,
	Jouni

On Apr 21, 2009, at 7:03 PM, marcelo bagnulo braun wrote:

> Working Group of the IETF.
>
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 29 Apr 2009 14:39:29 +0100

Hi Jouni,

We will provide these comments to the RFC Editor to clean them up, so
no problem.

Below I only comment on a few of them that need clarification.

Thanks
George

On Wed, Apr 29, 2009 at 1:39 PM, jouni korhonen <[email-masked]> wrote:
> Hi,
>
> I had a quick re-read of this I-D based on the recent interest on it ;)  And
> found several placed to comment. Mainly editorials but some other stuff as
> well.
>
>      that sent the Binding Acknowledgement.  It should assume that none
>  Why "should"? I think "It MUST assume" works better here as the CN MUST
> reject the BU anyway according to Section 6.2. third bullet.

GT> I am not sure MUST in necessary. SHOULD means that you better have
a good reason to do otherwise  (e.g., in this case say the MN rebooted
and forgot that bulk reg is not supported). In any case what is the HA
going to do if the MN sends bulk registration for 2nd time? it will
simply have to reject it again....so MUST/SHOULD make no difference in
practice.
As you say we already indicate that when talking to a CN bulk
registration MUST NOT be used.

>  Where "MCOA BULK REGISTRATION NOT SUPPORT" and its value is actually
> defined? It is not listed in IANA considerations nor in Section 4.4.

GT> It should be "MCOA BULK REGISTRATION PROHIBITED" which is included.

>  There is no such requirement language term as "NEED NOT" in rfc2119.

GT> You are right :-) it should simply be lower case "need not"

>> We have this new version of the MCOA document that addresses the comments
>> received, including IESG review comments.