Subject: RE: [Monami6] MCoA vs Flow Bindings: Solvingsame problem?

From: Ken Nagami <[email-masked]>
Date: Tue, 04 Jul 2006 00:03:43 +0900

Hi Hesham,

>  > The MCoA draft has the BID between a CoA and a flowID as you
>  > mentioned.
>
>=> I don't understand this statement. There are no flow IDs in the 
>MCOA draft and there should not be.

The MCoA draft doesn't have flowIDs. The MCoA draft only defines relationship
between CoAs and BID.
Other draft will define mapping betwenn BID and flow ID.
"draft-mitsuya-monami6-flow-distribution-policy-00.txt" is one 
definition for this.

This approach is separation of binding registration and flow distribution.

MCoA :
         CoA1 <-> BID1               : This binding is defined by the MCoA draft.

                  BID1 <-> FlowID1   :
                       <-> FlowID2
                            ....

>  > One advantage of the MCoA draft is as follow.
>  > Many flowIDs bind to one CoA as following figure.
>  > When the CoA1 changes to other CoA, in the MCoA case, only one
>  > re-binding between CoA and BID is needed.
>  > But in flow binding case, many re-binding between CoA and
>  > FlowID is needed.
>
>=> That's not true at all. Only one BU would be needed in the flow 
>binding draft. One BU would list all the FID (not the whole option 
>just the indices).

What I want to say is not a comparison of the numbers of BU messages.
We should care the number of relations between CoA and flowIDs that 
should be changed
when the CoA changes, because routers need to change a relation table
between CoA and flowID.

Regards,

Ken Nagami

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 3 Jul 2006 09:34:23 -0700

> The MCoA draft doesn't have flowIDs. The MCoA draft only 

=> Right, so I still don't understand your earlier statement above.

 > defined by the MCoA draft.

=> Yes we tried to do the same thing in draft-soliman. However, as I said before to Gabor, in this case the BID is redundant. 

 > What I want to say is not a comparison of the numbers of BU messages.

=> Well, please re-read your statement above, it's exactly a comparison of the numbers of BUs.

 > when the CoA changes, because routers need to change a relation table

=> Sure, but in this comparison criterion there is no difference between the two. Please show an example to tell us what the difference is. 

Hesham

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 04 Jul 2006 18:24:30 +0300

Soliman, Hesham wrote:

> => Yes we tried to do the same thing in draft-soliman. However, as I said before 
> to Gabor, in this case the BID is redundant.

I find the current situation of the WG to be a little bit odd. It has
become clear that draft-soliman doesn't utilize the BID option because
it's redundant for draft-soliman. However, the draft that specifies the
BID option is already accepted as a WG document. If draft-soliman would
eventually be accepted with as a WG draft, there would be two drafts
that do not complete each other; draft-ietf-monami6-multiplecoa-00.txt
would just be a mechanism to allow multiple bindings and pretty much
nothing else whereas draft-soliman would provide the same functionality
and a bit more. Does anyone else think that this would be somewhat strange?

The same remark has been sent to the list earlier but I didn't notice
any reactions...

-- 
Tero

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 4 Jul 2006 09:16:01 -0700

Tero,

I want to make some comments on your statement then make a more general
point on your remarks, which have been raised a few times now in
different ways. I think your comment is definitely important and should
be discussed. See my responses below.

 > it's redundant for draft-soliman. 

=> That's true, however, I've tried to highlight the more general point
a few times before. It's true that it's redundant in draft-soliman, but
that's not because draft-soliman has some special features that makes
the BID redundant. The point here is that there are two concepts being
introduced in parallel, a super set of features (in draft-soliman) where
multiple CoAs and the associated forwarding policies are defined, and a
subset of features in the MCOA draft where multiple COAs are enabled. It
is difficult to require the former to utilise a larger granularity
binding for a more granular binding. I.e. It's difficult to require flow
bindings to utilise CoA bindings as an add-on. In theory it sounds good
to do that because it sounds modular ...etc. However, given the way the
MCOA is designed (to be used in isolation or potentially with some
policies associated with an address), putting the flow binding as an
add-on is quite inefficient. Furthermore, it's redundant as I mentioned
before because we *must* define flow identifiers in the flow binding
draft to make it work. Since flow ids cover a more granular template,
the BID naturally becomes redundant. 

   However, the draft that 
 > specifies the
 > that do not complete each other; 

=> I don't think all drafts in a WG should complement each other, but
unfortunately we had that expectation from the beginning and it seems
that some people expect this to happen. However, we need to let reality
get in the way I think.

 > draft-ietf-monami6-multiplecoa-00.txt

=> I can't comment on whether it's strange because that depends on the
applicability of the drafts. The MCOA draft would be useful if we can
think of a good application for it. The problem I see with that draft is
that it's quite abstract so it's not clear what can be done with the
MCOA feature. For instance if you were thinking about a solution for
bicasting you could consider it, but since there are no rules associated
with each binding you'd have to define new options for those rules, and
you would end up with the flow binding draft or something very similar. 
So my opinion is that we can progress the MCOA draft if someone sees or
writes an applicability statement for it. Absent that, I don't
understand what it will be used for. We did try to use it as a basis for
the flow binding draft as I said in Dallas, but it made no sense
technically or from an efficiency point of view. 

I think it's not strange to revisit decisions based on changes in
designs and further investigations. We should probably do that in the
next meeting before more confusion is spread within the WG. 

Hesham

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 5 Jul 2006 01:22:24 +0200

Hi Tero,

On 4 juil. 06, at 18:16, Soliman, Hesham wrote:

>> BID option is already accepted as a WG document.

The fact that the MCoA is accepted as a Working Group document does  
not mean that it will be published RFC as it is written today. There  
is still lot of work to be done.

>> If
>> draft-soliman would

Agree.

>> and a bit more. Does anyone else think that this would be

It is, and this is why we have these discussions.

> next meeting before more confusion is spread within the WG.

I fully agree here.
This is an ongoing work, and we never pretended to have all solutions  
in mind. Any opinion is welcome to make progress in the working  
group, even if we have to change initial goals.

Nicolas

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 4 Jul 2006 17:10:00 -0700 (PDT)

Hi all,
  I agree with Tero and Hesham. The BID draft (firstly it should be BUI not BID) is kind of redundant, I thought that originally RFC 3775 did allow registration of multiple CoAs anyways. BUI draft does not do more than that, IMHO.
  If you read the literature that goes way back to 1998, the motivation is the concept of flow and that's what the WG should concentrate on.

  Regards,

--behcet

----- Original Message ----
From: "Soliman, Hesham" <[email-masked]>
To: Monami6 WG <[email-masked]>
Sent: Tuesday, July 4, 2006 11:16:01 AM
Subject: [Monami6] Coordination between drafts in monami6

Tero,

   However, the draft that 

Hesham

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 5 Jul 2006 10:25:15 +0800

Hi Behcet,
 
I believe you are refering to section 11.5.3 of RFC 3775 when mentioning
about multiple CoAs. But IMHO, I don't think that section mention anything
about how you can register multiple CoAs which is what
draft-ietf-monami6-multiplecoa-00 (the BUI draft u mention) is covering.
 
Regards,
Benjamin Lim

  _____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 8:10 AM
To: Monami6 WG
Subject: Re: [Monami6] Coordination between drafts in monami6

Hi all,
  I agree with Tero and Hesham. The BID draft (firstly it should be BUI not
BID) is kind of redundant, I thought that originally RFC 3775 did allow
registration of multiple CoAs anyways. BUI draft does not do more than that,
IMHO.
  If you read the literature that goes way back to 1998, the motivation is
the concept of flow and that's what the WG should concentrate on.

  Regards,

--behcet

----- Original Message ----
From: "Soliman, Hesham" <[email-masked]>
To: Monami6 WG <[email-masked]>
Sent: Tuesday, July 4, 2006 11:16:01 AM
Subject: [Monami6] Coordination between drafts in monami6

Tero,

   However, the draft that 

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 14:48:50 +0900

On 2006/07/05, at 11:25, Benjamin Lim wrote:

> Hi Behcet,
>
> I believe you are refering to section 11.5.3 of RFC 3775 when  
> mentioning about multiple CoAs. But IMHO, I don't think that  
> section mention anything about how you can register multiple CoAs  
> which is what draft-ietf-monami6-multiplecoa-00 (the BUI draft u  
> mention) is covering.

Right
Thanks for clarifying this.

regards,
ryuji

>   I agree with Tero and Hesham. The BID draft (firstly it should be  
> BUI not BID) is kind of redundant, I thought that originally RFC  
> 3775 did allow registration of multiple CoAs anyways. BUI draft  
> does not do more than that, IMHO.
>   If you read the literature that goes way back to 1998, the  
> motivation is the concept of flow and that's what the WG should  
> concentrate on.
>
>   Regards,
>
> --behcet
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 14:48:58 +0900

Your statement is wrong.
RFC3775 does not allow multiple CoA registration.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 14:49:02 +0900

Hesham

> the BID naturally becomes redundant.

There is advantage to separate multiple CoA registration and policy  
exchange.
Your draft just force to carry policy information only in BU.

Our draft can be extended to carry policy in BU or in other signals.  
It is more flexible.
At least there are drafts to specify carrying policies in upper layer.

Policy routing can be operated in IP, but policy management is not an  
original feature of IP/MIP.
We should be able to separate these two things.

> think of a good application for it. The problem I see with that  

What do you mean application?? MCOA is a solution for end multihoming.

> with each binding you'd have to define new options for those rules,  

Bicasting is nothing to do with MCoA. MCoA take care of multiple path  
(tunnels) setup.
How to distribute flow can be decided by policy.

> you would end up with the flow binding draft or something very  

not only. For example, we can use existing IP filtering scheme with  
other policy exchange scheme.

> technically or from an efficiency point of view.

Can you list up the limitation of MCoA to flow iD?

If your concern of BID definition, we may update this term to  
interpret as flow ID, too.
BID is originally designed to binding CoAs to HoA.
If BU which CoA is same but BID is different, a home agent can accept  
it as distinct binding.

You are saying that you consider to build flow binding on MCoA,
but non of MCoA DT didn't get any feedback from flow binding DT.

> next meeting before more confusion is spread within the WG.

agree
ryuji

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 05 Jul 2006 09:22:58 +0300

Ryuji Wakikawa wrote:
>> draft to make it work. 

Nod.

>> Since flow ids cover a more granular template, the BID naturally becomes redundant.

I would say it depends on which level the flow binding information is 
carried. I mean if the information is included in BUs, the BID becomes 
easily redundant. However, what if a BU would carry some information 
that would create a relation between BID and flow binding information? 
The actual flow binding information (i.e. those parameters that are seen 
for example in draft-soliman) would be transferred by other means, let 
me call them now as rules. BUs would be used to transfer only 
identifiers to these rules, and thus creating an association between 
BIDs and flow bindings. This way there would be no need to pack the 
rules into BUs, and the flow binding management could be implemented in 
a mobility management protocol independent way. 
draft-mitsuya-monami6-flow-distribution-policy-01.txt is a step to this 
direction. However, we are also trying work on this idea but 
unfortunately it's not possible for us to produce a draft before the 
next IETF meeting.

> Your draft just force to carry policy information only in BU.

I think Hesham has already tried to point this one out, but actually 
draft-hesham is not carrying policy information in BUs. It's carrying 
flow binding information which is not the same as a policy, IMHO. I 
would think that one policy can contain more than one flow binding 
entities (let me just call it for an entity), and basing on some logic 
these flow binding entities are (or could be) created from a policy. 
However, this is out of the scope of draft-hesham. Please correct me if 
I'm wrong, Hesham.

-- 
Tero

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 4 Jul 2006 23:55:40 -0700

> > introduced in parallel, a super set of features (in 
 > draft-soliman)  
 > > where
 > > binding for a more granular binding. I.e. It's difficult 
 > to require  
 > > flow
 > > bindings to utilise CoA bindings as an add-on. In theory 
 > it sounds  
 > > good
 > > to do that because it sounds modular ...etc. However, 
 > given the way  
 > > the

=> What is the advantage?

 > Your draft just force to carry policy information only in BU.

=> The draft is based on MIPv6 yes.

 > At least there are drafts to specify carrying policies in 

=> I think I've mentioned about 4 times already that the source of
policy is out of our scope. I'm not interested in making this a
discussion about "your draft" and "my draft" so stick to the technical
merits or you can continue this discussion with someone else.

 > We should be able to separate these two things.

=> Again, what's the advantage??? We should be able to do lots of
things....

 > What do you mean application?? MCOA is a solution for end 

=> What's the application of it? Can you give a complete scenario and
show how it will be used? I mean some people mentioned redundancy, can
you show a start to end scenario of how it will help with redundancy? I
don't see it. 

 > other policy exchange scheme.

=> Show a scneario please.

 > Can you list up the limitation of MCoA to flow iD?

=> Please see previous messages to Gabor. I've mentioned them at least
twice.

 > interpret as flow ID, too.

=> No that's not my concern, see below.

 > If BU which CoA is same but BID is different, a home agent 

=> Exactly. The binding of CoAs to HoAs is inherently different from
binding flows to a CoA. The BID is correctly defined but it's not useful
to build anything on top of it. It's an inherent issue with the concept,
not with some definition that can be changed.

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 00:05:33 -0700

> easily redundant. 

=> Exactly. 

   However, what if a BU would carry some information 
 > a mobility management protocol independent way. 

=> I think you're describing something very similar to what we already
do. I had this discussion with Henrik some time ago. We send the rule
*once*. After that we only send an index to that rule. I hope many
people are reading this because I get the impression that a lot of
people think we send the full option in every BU. That's *not true*. 

Now the second point you mention is also interesting. You're suggesting
that there can be a relationship between the BID and the FID. But the
point here is that since the FID already "includes" the BID if you like
(it's the super set), and since the option is not sent in full, I think
we already have the most granular definition we can have and I don't see
what we will gain from relating a FID to the BID. If you write down the
formats of messages I think you'll find that in your cae you'll pack
everything in the BID option, i.e. you're adding another level of
abstraction. Now if you take away that additional level of abstraction
you'll find that you lost no features. That means your additional level
was redundant. 

 > flow binding information which is not the same as a policy, IMHO. 

=> Correct.

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 17:11:57 +0900

> => What is the advantage?

MIP6 does not need to concern flow management.

> merits or you can continue this discussion with someone else.

I am not interested in drafts, but I want to make sure the scope of  
draft-soliman.

> => Again, what's the advantage??? We should be able to do lots of

MIP6 establish tunnel, that's all.
Which flow is sent to which tunnel is outside of MIP functions.

> you show a start to end scenario of how it will help with  

If there are multiple tunnels setup, both MN and HA can star using  
active tunnel as soon as they detect tunnel failure.
If you follow RFC3775, MN must wait for a new CoA and register it to  
HA. HA also wait for BU from MN.
In this case, we don't need any flow information involve.

> => Show a scneario please.

please read draft-mitsuya

> not with some definition that can be changed.

I cannot agree it's not useful to build anything on top of it.
If flow-id can be built on top of BID, the whole architecture gets  
more flexible and extensible.

ryuji

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 05 Jul 2006 11:26:15 +0300

> people think we send the full option in every BU. That's *not true*.

I think your "fear" is valid because IMHO it's easy to get that 
impression from the draft, i.e. it was not clear at first glance.

> what we will gain from relating a FID to the BID. 

I'm just thinking that if this flow binding information would not be 
sent in the BU, the same mechanism would be usable by other mobility 
management protocols. You are right, I'm not sure that even in the case 
that the flow binding information (rule) and association (sent in BU) 
are sent separately it would not turn out that BID would be redundant.
-- 
Tero

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Jul 2006 16:31:58 +0900

On 2006/07/05, at 15:22, Tero Kauppinen (JO/LMF) wrote:

> I would say it depends on which level the flow binding information  
> is carried. I mean if the information is included in BUs, the BID  
> becomes easily redundant. However, what if a BU would carry some  
> information that would create a relation between BID and flow  
> binding information? The actual flow binding information (i.e.  
> those parameters that are seen for example in draft-soliman) would  
> be transferred by other means, let me call them now as rules. BUs  
> would be used to transfer only identifiers to these rules, and thus  
> creating an association between BIDs and flow bindings. This way  
> there would be no need to pack the rules into BUs, and the flow  
> binding management could be implemented in a mobility management  
> protocol independent way. draft-mitsuya-monami6-flow-distribution- 
> policy-01.txt is a step to this direction. However, we are also  
> trying work on this idea but unfortunately it's not possible for us  
> to produce a draft before the next IETF meeting.

Flow binding may be useful in some scenario, but it cannot be a super  
solution which cover all scenarios.
Therefore, always using flow binding to setup multiple path should be  
avoided.
To me, there can be several flow management schemes depending on  
operational policy.
But we should have consistent scheme to setup multiple tunnels  
between MN/MR-HA.

>> There is advantage to separate multiple CoA registration and  
>> policy exchange.
> I think Hesham has already tried to point this one out, but  
> actually draft-hesham is not carrying policy information in BUs.  
> It's carrying flow binding information which is not the same as a  
> policy, IMHO. I would think that one policy can contain more than  
> one flow binding entities (let me just call it for an entity), and  
> basing on some logic these flow binding entities are (or could be)  
> created from a policy. However, this is out of the scope of draft- 
> hesham. Please correct me if I'm wrong, Hesham.

yes, I saw the messages.
thanks
ryuji

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 01:45:50 -0700

> management protocols. 

=> In theory I agree, but this is IMO the so called "kitchen sink"
approach where we tend to make things so open for anything to use it. I
prefer to make things concrete and clear for what we know. If we do
things independently we will end up building a new mobility management
protocol. For example we need to make sure it's secure, no flooding or
address stealing ...etc. I don't see a need to re-invent the wheel here.
If on the other hand there is another mobilility management protocol
that needs this feature, it's easy to incorporate the same ideas in that
protocol. I think this is the cleanest way to go. This is especially
true if you consider that two mobility management protocols will most
likely not co-exist so why build something for both of them?
    
   You are right, I'm not sure that even 
 > in the case 

=> Exactly. I completely agree with this comment. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 02:03:52 -0700

> MIP6 does not need to concern flow management.

=> So?? Someone else does, why is this any better?

 > Which flow is sent to which tunnel is outside of MIP functions.

=> Oh ok! I guess we should follow these words without
explanation....sigh

 > active tunnel as soon as they detect tunnel failure.

=> How do they do that? You keep avoiding putting down the whole
scenario.
So there are two CoAs registered in the HA. One interface goes down on
the MN, how does the HA know to switch to the other one? Does the MN
signal that? If so, then how is this different from sending a new BU.

 > HA. HA also wait for BU from MN.

=> So how do we avoid the BU from the MN when MCoA is used? 

 > In this case, we don't need any flow information involve.

=> I think you're confusing separate issues here. We're discussing the
utility of the MCoA draft without adding rules. 

 > please read draft-mitsuya

=> I did. 

 > more flexible and extensible.

=> Without explaining your opinions it is very difficult to consider
them. You need to explain what "flexible" and "extensible" means and how
we can get that. 

Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Jul 2006 10:17:31 -0700 (PDT)

Well, what I meant it is straightforward, just use the alternate care of address option in Sec. 6.2.5. If you have more, set the length accordingly (RFC 3775 does not state the length MUST be set to 16?). What is wrong with that?
The rules on the alternate care of address option sent to CNs, aren't they exactly like those in the BUI draft?

----- Original Message ----
From: Ryuji Wakikawa <[email-masked]>
To: [email-masked]; Monami6 WG <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>
Sent: Wednesday, July 5, 2006 12:48:50 AM
Subject: Re: [Monami6] Coordination between drafts in monami6

Right

regards,
ryuji

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 6 Jul 2006 10:04:18 +0800

Hi Behcet,
 
My comment inline.

  _____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, July 06, 2006 1:18 AM
To: Ryuji Wakikawa; [email-masked]; Monami6 WG
Subject: Re: [Monami6] Coordination between drafts in monami6

Well, what I meant it is straightforward, just use the alternate care of
address option in Sec. 6.2.5. If you have more, set the length accordingly
(RFC 3775 does not state the length MUST be set to 16?). What is wrong with
that? 
 
The rules on the alternate care of address option sent to CNs, aren't they
exactly like those in the BUI draft? 
 
[Benjamin] IMHO, draft-ietf-monami6-multiplecoa-00 is trying to introduce
the BID for purpose of identifying multiple bindings. I'll illustrate a
scenario. MN has 2 CoAs (CoA1, CoA2) bind to HoA. It wishes to update the
binding for CoA2. If you are implementing draft-ietf-monami6-multiplecoa-00,
CoA1 <--> BID1, CoA2 <--> BID2. So MN sends the BU with the BID sub options
with BID2 and the updated CoA.
 
However, if you were to use your suggested method (Alt CoA option), there is
no way for you identify the different bindings. Thus MN would have to send
BU with all the CoAs in the Alt CoA options field just to update the binding
for CoA2. This is not very efficient IMHO.

Reagrds,
Benjamin Lim

----- Original Message ----
From: Ryuji Wakikawa <[email-masked]>
To: [email-masked]; Monami6 WG <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>
Sent: Wednesday, July 5, 2006 12:48:50 AM
Subject: Re: [Monami6] Coordination between drafts in monami6

Right

regards,
ryuji

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Jul 2006 20:03:07 -0700 (PDT)

Hi Benjamin,
  BID or BUI is just a syntactic sugar, don't be misled by things like that.

--behcet

----- Original Message ----
From: Benjamin Lim <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Monami6 WG <[email-masked]>
Cc: Ryuji Wakikawa <[email-masked]>
Sent: Wednesday, July 5, 2006 9:04:18 PM
Subject: RE: [Monami6] Coordination between drafts in monami6

    DIV { MARGIN:0px;}   Hi  Behcet,
  
 My  comment inline.

   

   [Benjamin] IMHO, draft-ietf-monami6-multiplecoa-00 is trying to introduce the BID    for purpose of identifying multiple bindings. I'll illustrate a scenario. MN    has 2 CoAs (CoA1, CoA2) bind to HoA. It wishes to update the binding    for CoA2. If you are implementing    draft-ietf-monami6-multiplecoa-00, CoA1 <--> BID1, CoA2 <-->    BID2. So MN sends the BU with the BID sub options with BID2 and the updated    CoA.
    
   However, if you were to use your suggested method    (Alt CoA option), there is no way for you identify the different    bindings. Thus MN would have to send BU with all the CoAs in the Alt CoA    options field just to update the binding for CoA2. This is not very efficient    IMHO.

    Reagrds,
   Benjamin    Lim

   -----    Original Message ----
From: Ryuji Wakikawa    <[email-masked]>
To: [email-masked]; Monami6    WG <[email-masked]>
Cc: Behcet Sarikaya    <[email-masked]>
Sent: Wednesday, July 5, 2006 12:48:50    AM
Subject: Re: [Monami6] Coordination between drafts in monami6

Right

regards,
ryuji

---

From: Keigo Aso <[email-masked]>
Date: Thu, 06 Jul 2006 15:55:02 +0900

Hi,

> signal that? If so, then how is this different from sending a new BU.
IMO, this case could be divided to three steps.
(1)the necessity to change a CoA is detected by MN,
(2)the MN signal to HA in order to change the CoA. (This signal may
be for registering new CoA or de-registering old CoA.)
After receiving its signal,
(3)the HA changes the forwarding destination from the CoA to other one.

When (1) is done by MN, MN may perform (2) as above if it want to
change the interface to receive packets.(I think this is your scenario)
But when (1) is done by HA, (2) is skipped because the HA does not 
need to signal to MN on changing a CoA. 
In this case, HA may perform (1) based on the policy registered by MN
or not.

These could be called MN-initiate change and HA-initiate change.
I think both are a benefit of multiple CoAs registration.

Regards,
Keigo

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 6 Jul 2006 00:03:02 -0700

> change the interface to receive packets.(I think this is 

=> Yes.

 > need to signal to MN on changing a CoA. 

=> If (1) is done by the HA you will have one way connectivity. I don't
think one way connectivity is useful. But before we discuss all this,
you seem to indicate that there are policies in the HA that tells it
what to do when one interface failed and that it *assumes* that this is
the intention of the MCOA registration. Unless these intentions are
signalled and agreed upon by the MN and HA I don't think we should make
implicit assumptions about the intention of the MCOA registration. There
are several scenarios where this assumption is very unhelpful to the MN.

Hesham

---

From: Keigo Aso <[email-masked]>
Date: Thu, 06 Jul 2006 19:47:17 +0900

Hi Hesham,

On Thu, 06 Jul 2006 00:03:02 -0700

> are several scenarios where this assumption is very unhelpful to the MN.

The detection of the necessity to change a CoA is caused by various
kinds of reasons. And I think there is not only MN side reason but
also HA side reason. 
Regarding the policy on how to select next CoA to use after 
the detection also, I think there is not only MN side policy
but also HA side policy, for example selecting a optimized path to MN
from HA point of view.

Regards,
Keigo

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 6 Jul 2006 04:36:24 -0700

> kinds of reasons. And I think there is not only MN side reason but

=> I'm not saying it has to be done by the MN exclusively, I'm saying
that in the example you mentioned above you'd have one way connectivity
until the MN is aware of that change.

 > but also HA side policy, for example selecting a optimized path to MN

=> Again, I didn't say it has to be done by the MN only, I said that in
the example you mentioned above you assume the merely registering MCOA
means there is an implicit policy associated with it. I don't think
that's a good assumption to make.

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 11 Jul 2006 03:50:51 +0900

Hi Hesham

> that's a good assumption to make.

The goal of MCoA is not policy setup.
The draft focus on only multiple care-of address registration.

This is because we were asked to limit protocol extensions.
We also believe the separation of policy management and binding  
registration is better approach.

MCoA is open for any types of flow management scheme on top of it.

ryuji