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

From: George Tsirtsis <[email-masked]>
Date: Sat, 25 Apr 2009 11:38:49 +0100

Behcet/Yungui,

As you can see there is significant push-back in what you are
proposing for this draft and I believe for good reasons.
Maybe then, all this time and energy can be directed to something a
bit more constructive.

What you are talking about is not about protocol definition but about
implementation, deployment choices etc.
Since Marcelo, on behalf of the WG, is eager to get significant
reviews on a number of upcoming documents why don't you take a look at
draft-ietf-monami6-mipv6-analysis-05 which is about to enter WGLC, and
which IMO is a much more appropriate document for this discussion.
There are many possible configurations, that we should not attempt to
capture in the MCoA spec (we never do that!)....but one could try to
capture such examples in an info document like the analysis draft.

A node with multiple interfaces attached to the same or different
links, prior to initiation of MIPv6 session, is simply a node with
multiple interfaces, each of which has its own IP address. The node
has to make an explicit decision to turn one of these address, or
maybe a different one (in case of a remote HA), into a MIPv6 home
address,
The node can even turn multiple of its addresses into HoAs...resulting
in multiple independent MIPv6 session, possibly with different HAs. Or
the MN may keep one HoA and turn all the others into CoAs....or any
combination of the above.... and i am not even discussing NEMO, DSMIP
etc...As I said there are many possible configurations ...which if we
really want to discuss they should go in documents like that analysis
doc.

George

On Sat, Apr 25, 2009 at 1:50 AM, Yungui Wang <[email-masked]> wrote:
> 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,
>
> On 4/23/09 8:54 PM, "Yungui Wang" 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.
>>>
>>> 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.
>
> That would be out of scope. As far as the current MCoA draft is concerned,
> there is no tunneling from the home link.
>
>
> 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
>
>> Otherwise, it seems the HA
>> has to initiate flow handover to another interface.
>> Therefore, I think, Behcet's statement makes sense.
>>
>> B.R.
>> Yungui
>>
>>> Does the above make sense?
>>>
>>> Vijay
>>>
>>>> -----Original Message-----
>>>> From: Behcet Sarikaya [mailto:[email-masked]]
>>>> Sent: Thursday, April 23, 2009 8:54 AM
>>>> To: Vijay Devarapalli; marcelo bagnulo braun
>>>> Cc: mext
>>>> Subject: Re: [MEXT] [Fwd: I-D
>>>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>
>>>> 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,
>>>>
>>>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote:
>>>>
>>>>> 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.
>>>>
>>>> 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
>>>>
>>>>> Regards,
>>>>>
>>>>> Behcet
>>>>>
>>>>> From: marcelo bagnulo braun <[email-masked]>
>>>>> To: Behcet Sarikaya <[email-masked]>
>>>>> Cc: Ryuji Wakikawa <[email-masked]>; mext
>>> <[email-masked]>
>>>>> Sent: Wednesday, April 22, 2009 4:59:50 PM
>>>>> Subject: Re: [MEXT] [Fwd: I-D
>>>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>
>>>>> 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
>>>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>
>>>>>> Hi Behcet,
>>>>>>
>>>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: George Tsirtsis <[email-masked]
>>>>>>> <mailto:[email-masked]>>
>>>>>>> To: Behcet Sarikaya <[email-masked]
>>> <mailto:[email-masked]>>
>>>>>>> Cc: mext <[email-masked] <mailto:[email-masked]>>
>>>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM
>>>>>>> Subject: Re: [MEXT] [Fwd: I-D
>>>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>>
>>>>>>> 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.
>>>>>>> [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 Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
>>>>>>> <[email-masked]
>>>> <mailto:[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
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>> 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]>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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]
>>>>>>>> <mailto:[email-masked]>>
>>>>>>>> wrote:
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> This has been discussed for a long time in MEXT.
>>>>>>>>>> who is familiar with which discussions? I don't know
>>>> your concern here.
>>>>>>>>>>  *[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?*
>>>>>>>>>>
>>>>>>>>>> **
>>>>>>>>>>
>>>>>>>>>>>  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..
>>>>>>>>>>
>>>>>>>>>> sure, but please explain your issue more precisely.
>>>>>>>>>>
>>>>>>>>>> thanks!
>>>>>>>>>> ryuji
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Behcet
>>>>>>>>>>> From: marcelo bagnulo braun <[email-masked]
>>>>>>>>>>> <mailto:[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
>>>>>>>>>> <jari.arkko@piuha..net <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]
>>>> <
> mailto:jari.arkko@piuha..net >
>>>>>>>>>> <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]>
>>>>>>>>>>> <mailto:[email-masked]
>>>> <mailto:[email-masked]>>
>>>>>>>>>>> Para:    [email-masked]
>>> <mailto:[email-masked]>
>>>>>>>>>>> <mailto:[email-masked]
>>> <mailto:[email-masked]>>
>>>>>>>>>>> CC:    [email-masked] <mailto:mext@ietf..org
>>>> <mailto:[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-multipl
>>> ecoa-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]> <mailto:[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> --------------------------------------------------------------
>>>> ----------
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> MEXT mailing list
>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> MEXT mailing list
>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MEXT mailing list
>>>>>>> [email-masked] <
> mailto:[email-masked] > >
>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>
>>>>>>
>>>>>>
>>>> --------------------------------------------------------------
>>>> ----------
>>>>>>
>>>>>> _______________________________________________
>>>>>> MEXT mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: Yungui Wang <[email-masked]>
Date: Mon, 27 Apr 2009 10:04:18 +0800

Hello 

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Saturday, April 25, 2009 6:39 PM
> To: [email-masked]
> Cc: Vijay Devarapalli; Behcet Sarikaya; marcelo bagnulo braun; mext
> Subject: a suggestion ...Re: [MEXT] [Fwd: I-D 

I wouldn't want to delay this document. Please move forward if necessary.

However, home binding is a little controversial new feature which was 
recently added from -11. Well, I am only interesting with its operation. 
Maybe it is more appropriate to clarify it offline. You are appreciated to 
do that. :)

> capture such examples in an info document like the analysis draft.

See blow.

> maybe a different one (in case of a remote HA), into a MIPv6 home

Agree.

> combination of the above.... 

Actually, I were commenting home binding operation of MCoA in case of 
multiple interfaces of MN returning home. I am not conerned of you stated 
how to configure address(es) on the MN, but how the HA to process the 
multiple home binding registration at home link under different situation.

Thanks.
Yungui

> and i am not even discussing NEMO, DSMIP
> > 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,
> > 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
> >>>>?? I understand your concerns.
> >>>>
> >>>> The other? interfaces may later on become active and connect
> >>>> the? interface MN originally used to connect to the home link
> >>>>>? How about this little paragraph?
> >>>>>
> >>>>>>? I checked your draft. Again, I could not understand how
> >>>> you are sending a
> >>>>>>? As I mentioned to you, we discussed this related to
> >>>> draft-premec-homelink
> >>>>>>? Regards,
> >>>>>>? Behcet
> >>>>>>>>? It seems in my previous reply I replied to this mail of
> >>>> yours which was
> >>>>>>>>? Now regarding home link registration, what is the
> >>>> mechanism MCoA draft
> >>>>>>>>? My suggestion was building on this, i.e. I suggested
> >>>> that whatever you
> >>>>>>>> Informational documents,? they should not require
> >>>> normative changes to
> >>>>>>>>>>>? Also I have a question to Ryuji: does this draft send a
> >>>>>>>>>>? *[behcet] So your answer is yes the draft sends a
> >>>> non-deregistration BU
> >>>>>>>>>>>? Sorry if I am too? much confused
> >>>>>>>>>>> Asunto:??? [MEXT] I-D
> >>>>>>>>>>> Fecha:??? Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
> >>>>>>>>>>> De:??? [email-masked]
> >>>>>>>>>>> Para:??? [email-masked]
> >>>>>>>>>>> CC:??? [email-masked] <mailto:mext@ietf..org
> >>>> <mailto:[email-masked]> >
> >>>>>>>>>>> <
> > mailto:[email-masked] >>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>??? 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
> >>>>>>>>>>>
> >>>>>>>>>>> correspondent nodes.? However, for matters of cost,
> >>>> bandwidth, delay,
> >>>> addresses.? This
> >>>>>>>>>>> and use multiple care-of addresses.? The extensions
> >>>> proposed in this

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 26 Apr 2009 20:43:58 -0700 (PDT)

> Maybe it is more appropriate to clarify it offline. You are appreciated to

I agree with this assessment. I dont want to delay this doc either, you
can go ahead. But, I just dont know how to implement the mobile node's
home link attachment with non-NDP mode. The mobile node can use its home
address, but cannot participate in NDP. It can use HoA on the home link,
and can only send and receive packets with its home agent. This requires
special semantics, or even driver layer interface, not a socket layer
interface.

Atleast in Cisco IOS, where there is some programming constructs, I do
not know how to configure the HoA on the home link, disable NDP, still use
HoA for sending packets with the link-layer header and for receiving
packets to HoA, while its not defending that address. Or, I dont know how
to make the mobile node's IPv6 interface to believe that the prefix is an
off-link prefix, while the RA's carry the prefixes as onlink prefixes, for
it to send all packets to destinations through the router. And for the
home agent to disable the REDIRECT semantic on the home interface for
supporting this through router indirection. This requires some changes as
how IPv6 is confiugred on interfaces and how ND is enabled or how
applications see it. Its possible with hacks. I assume some one
implemented this on Linux, using standard socket layer interface
per 4584 or 3542.

Also, we are generally so worried about the integrity of the host, the
programming layers, specially the interface integrity and the any changes
to it, but for supporting this mode, we are going out of our way and the
implications are hardly ever analyzed, like the home interface
designation, multiple hoa generation, or the implementation complexity.
But I guess, its CMIP with a free check to rewrite the host stack.

Page 22, last paragraph:
"If the home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises
with respect to how the home agent discovers the mobile node's
link local address. "

Is it link local or link-layer ?

Regards
Sri

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 27 Apr 2009 11:30:40 +0100

Hi Sri,

I think the authors appreciate that the non-NDP home link operation is
not straightforward, but as you say this is client MIP and changing
the end node is part of the game.

Also, the home link operation was the subject of lengthy discussion a
few months back though and the draft captures the result of this
discussion, so, I am not sure it is fair to say that the implications
were not discussed..

Regards
George

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 27 Apr 2009 08:00:10 -0700 (PDT)

Hi George,
  Your points well taken.
That said, is this doc draft-ietf-monami6-mipv6-analysis-05 in the charter? 
My suggestion was to include the crust of the analysis and basic assumptions into your doc in a single paragraph and you could replace that with the reference to this analysis draft.
  It seems like you guys are pretty reluctant for any progressive suggestions.
  Lastly, I looked at the draft again, as Vijay said this draft does not talk about any packet forwarding to any of CoAs for which the BIDs were given. I don't think this draft is a prerequisite for any flow binding work. 
  I would have proposed spending the time and energy that went  to this draft (13 possibly more revisions) on better causes.

Regards,

Behcet  

________________________________
From: George Tsirtsis <[email-masked]>
To: [email-masked]
Cc: Vijay Devarapalli <[email-masked]>; Behcet Sarikaya <[email-masked]>; marcelo bagnulo braun <[email-masked]>; mext <[email-masked]>
Sent: Saturday, April 25, 2009 5:38:49 AM
Subject: a suggestion ...Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

Behcet/Yungui,

etc....As I said there are many possible configurations ...which if we

George

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 27 Apr 2009 16:03:00 +0100

> That said, is this doc draft-ietf-monami6-mipv6-analysis-05 in the charter?

GT> This is one of the documents Marcelo identified as being ready for
WGLC, and as such reviews would be much appreciated.

George

> My suggestion was to include the crust of the analysis and basic assumptions
> into your doc in a single paragraph and you could replace that with the
> reference to this analysis draft.
>   Lastly, I looked at the draft again, as Vijay said this draft does not
> talk about any packet forwarding to any of CoAs for which the BIDs were
> given. I don't think this draft is a prerequisite for any flow binding work.
>   I would have proposed spending the time and energy that went  to this
> draft (13 possibly more revisions) on better causes.
>
> Regards,
>
> Behcet
>
>
> Cc: Vijay Devarapalli <[email-masked]>; Behcet Sarikaya
> <[email-masked]>; marcelo bagnulo braun <[email-masked]>; mext
> <[email-masked]>
> etc...As I said there are many possible configurations ....which if we

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Apr 2009 14:07:38 -0700

Hi Sri,

The "Home Binding" operation is not straight forward to implement on an 
ethernet-like link. I agree. However, it is not so hard when the mobile 
node has a tunnel (GTP,  PMI, IPsec, etc..) as the link layer to the 
home agent.

Note that the mobile node node is not required to support this. It can 
always have all the flows over the interface with which it is attached 
to the home link.

For the scenario, where the mobile node wants to receive packets both 
over the home link and the visited link, the solution in the draft is 
the best we could come up with.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Apr 2009 14:40:20 -0700 (PDT)

Hi George,

> the end node is part of the game.

Its not complex alone, it makes some fundamental assumptions on
the IPv6 link model. I assumed you will argue, its does not require
a endhost stack re-write, but you are a saying, its client MIP and so
its a right to rewrite :) Not sure, about that.

> discussion, so, I am not sure it is fair to say that the implications

This was not a day-1 feature, it was added fairly recently,
given the long history of MCOA draft. Even if there were
lots of discussions, given the complexity and the fact
that there are still lots of questions, I'm not sure why
this cant be split to a different doc and taken on a slower
path. As I said, I'm not arguing to block this, but I dont
think any one can be compliant to this.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Apr 2009 14:40:29 -0700 (PDT)

Hi Vijay,

Implementation complexity is one thing. But, the spec
largely ignores the link model or the assumptions that
all the ND specs make.

On a given IPv6 link, there is only one node that can
use an IPv6 address. The node or a proxy on its behalf.
But, this draft introduces a new model, the proxy
defends the node's address, it can receive packets,
while the node can still send and receive the packets.
What is this link model ? Where is it specified ? What
are the implementations to the IPv6 stack on the host.

The draft very simple terms states this requirement.
I dont know how this can be achieved, IPv6 interface
configuration or the ND mgmt is not a module owned by the
mobile ip stack. There is some level of modularity on any
platform. Like we dont make all the IPsec handling as a MIP
decision. If the given feature requires the fundamental
assumption change there is an issue. If one has to implement
this on a open source platform such as Linux, with a kernel
stack tighly controlled, how does one implement this ? As I
said, I cant implement this on IOS and so we will always
non-compliant to this spec.

Generally, you insist on feature control, I say the same
thing, why dont we do this later when we need it ? There
are so many issues as the WG pointed out, in the current
form no one can implement this any ways, even if you rush
and publish the doc. But, its your call, as it cleared all
reviews and surprisingly this was not caught in IESG reviews.

Sri

On Mon, 27 Apr 2009, Vijay Devarapalli wrote:

> ethernet-like link. I agree. However, it is not so hard when the mobile node 
> has a tunnel (GTP,  PMI, IPsec, etc..) as the link layer to the home agent.
>
> Note that the mobile node node is not required to support this. It can always 
> have all the flows over the interface with which it is attached to the home 
> link.
>
> For the scenario, where the mobile node wants to receive packets both over 
> the home link and the visited link, the solution in the draft is the best we 
> could come up with.
>
> Vijay
>
> Sri Gundavelli wrote:
>>
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Apr 2009 15:02:07 -0700

> are the implementations to the IPv6 stack on the host.

I guess you missed parts of my earlier email on this. I expect this 
"home binding" feature to be mostly used when there is a tunnel (GTP, 
etc..) emulating the home link. The mobile node is unlikely to receive 
any neighbor solicitations for the home address. The home agent would 
continue proxying for the home address.

> non-compliant to this spec.

Not implementing the "home binding" feature would not make you 
non-compliant to the spec.

Vijay

>> The "Home Binding" operation is not straight forward to implement on 
>> an ethernet-like link. I agree. However, it is not so hard when the 
>> mobile node has a tunnel (GTP,  PMI, IPsec, etc..) as the link layer 
>> to the home agent.
>>
>>> >  Maybe it is more appropriate to clarify it offline. You are 
>>> appreciated >  to
>>> >  do that. :)
>>> > >
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Apr 2009 15:10:16 -0700 (PDT)

Hi Vijay,

On Mon, 27 Apr 2009, Vijay Devarapalli wrote:

> I guess you missed parts of my earlier email on this. I expect this "home 
> binding" feature to be mostly used when there is a tunnel (GTP, etc..) 
> emulating the home link. The mobile node is unlikely to receive any neighbor 
> solicitations for the home address. The home agent would continue proxying 
> for the home address.
>

But, its still an IETF document. I'm not sure we can
ignore the above considerations. If the home attachment
solution is a generic requirement, I assume the solution
needs to work for a generic mobile client.

> Not implementing the "home binding" feature would not make you non-compliant 
> to the spec.

Why is that ? You mean, it will be partially compliant ?

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Apr 2009 17:46:56 -0700

Hello Yungui,

On 4/26/09 7:04 PM, "Yungui Wang" wrote:

> recently added from -11.

This is not correct. Simultaneous attachment to the home and visited link
was added to the specification in version 07. It was submitted in April
2008. See section 5.6.3 of
http://tools.ietf.org/id/draft-ietf-monami6-multiplecoa-07.txt

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 27 Apr 2009 18:30:37 -0700

Hi Sri,

On 2009/04/26, at 20:43, Sri Gundavelli wrote:

>> appreciated to

In MCoA document, we have following texts in the home binding no NDP  
operation.

This
        operation is similar to Mobile IPv6 [RFC-3775] when a mobile  
node
        sends a deregistration binding update to the home agent's link-
        layer address in the operation for returning home.

We follow the RFC3775 which MN does not react to NS for HoA.

We don't introduce any new semantics here.
Cisco has already had some codes for returning home, don't you?

> implemented this on Linux, using standard socket layer interface

Yes, we need some hack to work HoA without NDP.
However, this is what I have implemented for Mobile IPv6's returning  
home.

> But I guess, its CMIP with a free check to rewrite the host stack.

HA can tell the MN how to behave on the home link.
If there is no routers on the home link other than HA, there is no  
reason to use this mode.

> Is it link local or link-layer ?

Yes, this is typo.
Thanks!

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 27 Apr 2009 18:37:01 -0700

Hi Sri,

> think any one can be compliant to this.

It's not recently added feature.
Common, We added this feature more than 1 years ago.
http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05#section-5.6.3

We did a lot of discussion whether we exclude or include this feature  
(simultaneous home and foreign links) in MCoA.
We had consensus to keep it at the MEXT WG.

regards,
ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Apr 2009 19:33:00 -0700 (PDT)

Hi Ryuji,

Please see inline.

On Mon, 27 Apr 2009, Ryuji Wakikawa wrote:

>       operation is similar to Mobile IPv6 [RFC-3775] when a mobile node

There are special ND considerations for the MN on returning home
as how it takes over the home address from the HA. Those are
general Proxy-ND considerations on unsolicited NA usage. This
requires lot more hacks on complete ND disabling on the MN,
and redirect disable on the HA, You cant equate these changes to
MN returning home.

> However, this is what I have implemented for Mobile IPv6's returning home.
>

Ok. But, I hope you implemented this for MCOA with home/roam simultanous
support.

> If there is no routers on the home link other than HA, there is no reason to 
> use this mode.
>

This configuration is another challenge.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Apr 2009 19:34:32 -0700 (PDT)

Hi Ryuji,

> We had consensus to keep it at the MEXT WG.

Ok, fine. I will let this go as we talked.

Regards
Sri