Subject: Re: [Monami6] draft-ietf-monami6-multiplecoa-00.txt

From: Gábor Fekete <[email-masked]>
Date: Wed, 14 Jun 2006 14:11:52 +0300

Hi everyone,

Then how do you like this? :)

     1.  A mobile node uses several physical network interfaces and
         configures __one__ Care-of Address on each of its interfaces.
 
     2.  The mobile configures one or more Care-of Addresses on an interface
         for each available prefix on the link of that interface.

And I still think that using the word "global" instead of "CoA" is not
good since a site-local address can also be a CoA.

Regards,
Gabor

On Wednesday 14 June 2006 12:55, Tero Kauppinen (JO/LMF) wrote:
> Gábor Fekete wrote:
> > Hi Benjamin,
> > 
> > Combining your clarification and my previous reasoning, I say that both
> > 1 and 2 should be modified as follows:
> > 
> >      1.  A mobile node uses several physical network interfaces and
> >          acquires __one__ Care-of Address on each of its interfaces.
> > 
> >      2.  The mobile node is attached to a link on an interface where multiple
> >          prefixes are announced.  Several Care-of Addresses are configured
> >          on this interface for each of the announced prefixes.
> 
> What about the case when the node configures several addresses from one 
> prefix?
> 

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 14 Jun 2006 15:18:53 +0300

>          for each available prefix on the link of that interface.

I can live with this ;)

> good since a site-local address can also be a CoA.

Agreed. I was merely referring to the original terminology in the draft.

-- 
Tero

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Thu, 15 Jun 2006 09:06:15 +0800

Hi!

I would suggest:

1.  A mobile node uses several physical network interfaces and
configures __a__ Care-of Address on each of its interfaces.

This would better express the idea that the multiple Care-of Addresses
may come from multiple physical interfaces (1) or multiple configured
Care-of Addresses (2).

Using __one__ in (1) seems to convey an unneccessary sense of
restriction to me.

Regards,
Ben

-- 
/<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\
| Benjamin Koh Tien-Ming                   |
| R & D Engineer                           |
| Panasonic Singapore Laboratories Pte Ltd |
| Tel: (65)6550 5481  Fax: (65)6550 5459   |
| E-mail: [email-masked]  |
\>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<<</

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 15 Jun 2006 17:33:54 +0200

Hi all

Since this text is not clear enough, another choice is removing this  
text.
The important point here is that the number of IF is not matter for  
this protocol.

ryuji

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 16 Jun 2006 09:32:35 +0900

On 2006/06/16 0:33, Ryuji Wakikawa wrote:
> Hi all
> 
> Since this text is not clear enough, another choice is removing this text.
> The important point here is that the number of IF is not matter for this 
> protocol.

I agree.  It could be written something like, "a mobile node configures
multiple CoAs on its physical network interface(s)."

regards,
watari

>> --/<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Fri, 16 Jun 2006 08:46:09 +0800

Hi!

> multiple CoAs on its physical network interface(s)."

Works for me.

Regards,
Ben

---

From: Gábor Fekete <[email-masked]>
Date: Fri, 16 Jun 2006 11:39:26 +0300

Hi Ryuji,

> The important point here is that the number of IF is not matter for  
Fine for me.

Also, I have one more comment.
Section 5.1. says:
  "A mobile node assigns a BID to each Care-of Address when it wants to
   simultaneously register with its Home Address.  ..."
And also the BID definition in Section 2 says:

     "The BID can be assigned to either a Care-of Address or an
      interface depending on implementation choices so as to keep using
      the same BID for the same binding even when the status of the
      binding is changed.  More details can be found in Section 5.1."

I think both these explanations are a bit misleading. As I see, the BID
identifies a binding of a specific HoA (either a BUL entry or a BC entry).
I don't see it necessary (or appropriate) to say that the BID is/can be
assigned to CoA or interface. It is assigned to a Binding. Or am I lost?
So, I suggest to drop all the "BID is assigned to CoA" text and just say
something like:

"The BID is assigned to the binding, so implementations can keep using the
same BID for identifying the binding in BUs (e.g. when the CoA changes in
the binding)."

Regards,
Gabor Fekete

---

From: Ken Nagami <[email-masked]>
Date: Mon, 19 Jun 2006 16:32:38 +0900

Hi Gabor,

>same BID for identifying the binding in BUs (e.g. when the CoA changes in

"The BID is assigned to the binding" is ok for me.

But, the current text
"The BID can be assigned to either a Care-of Address or an interface"
is an example for implementation.
I think it is easy to understand to have an example.
So, I think a text for an example needs to remain.
How do you think?

Regards,

Ken Nagami

> > >> G〓bor Fekete wrote:

---

From: Gábor Fekete <[email-masked]>
Date: Mon, 19 Jun 2006 11:04:19 +0300

Hi Ken,

> Hi Gabor,

snip

> So, I think a text for an example needs to remain.
I think it is a bad example. It may cause more confusion than help.
For example, these things come to mind when reading such things:

1. If the BID is assigned to a CoA then this assignment will last
   only until the next CoA change (i.e. next handover). So why is
   this useful to do explicitly?
   The BID is assigned to a binding and that binding has a CoA. So,
   the BID is already implicitly assigned to the CoA of the binding.

2. If the BID is assigned to an interface then it causes confusion when
   the interface has two different CoAs and both are bound to the same
   HoA. In this case two bindings would have the same BID.

So, both of the above two examples, if implemented, would/may restrict the
capabilities of the implementation.
I understand what you mean, but I think it is better just not to
advise any of the above two to implementers. And implementers can decide
on their own if they want to restrict their code, but I would not help
them in how to do so by giving them hints.

Regards,
Gabor Fekete

---

From: Ken Nagami <[email-masked]>
Date: Tue, 20 Jun 2006 23:47:16 +0900

Hi Gabor,

>them in how to do so by giving them hints.

I agree to have to write for readers not to misunderstand.

A simple example to use BID is:
  the BID is assinged to an interface AND
  the MN registers only one CoA per interface

I think you understand this situation.
This is simple example but this is one of typical case.

But if the example confuses the reader, this sentence will be remove 
from section 5.1.

Regards,

Ken Nagami

---

From: qinxia <[email-masked]>
Date: Wed, 21 Jun 2006 09:47:35 +0800

Hello all,

  Maybe, this example could lead to a misunderstanding. I have an idea, if
we need examples indeed, we may show several examples more than one single
instance.

[snipped]
> But if the example confuses the reader, this sentence will be 
> remove from section 5.1.
> 

> -----Original Message-----
> From: Ken Nagami [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 10:47 PM
> To: G 畸 or Fekete; Monami6 WG
> Subject: Re: [Monami6] BID assignment in 
> draft-ietf-monami6-multiplecoa (was Re: 
> draft-ietf-monami6-multiplecoa-00.txt)
> 
> Hi Gabor,
> 
>  > >
> > > >"The BID is assigned to the binding, so implementations can keep 
> > > >using the same BID for identifying the binding in BUs (e.g. when 
> > > >the CoA changes in the binding)."
> > >
> >So, both of the above two examples, if implemented, 
> would/may restrict 
> >the capabilities of the implementation.
> >I understand what you mean, but I think it is better just 
> not to advise 
> >any of the above two to implementers. And implementers can decide on 
> >their own if they want to restrict their code, but I would not help 

> But if the example confuses the reader, this sentence will be 
> remove from section 5.1.
> 
> Regards,
> 
> Ken Nagami
> 
> 
> 
>