Subject: [Monami6] review of problem statement draft

From: Nicolas Montavont <[email-masked]>
Date: Mon, 25 Sep 2006 16:11:53 +0200

Folks,

Authors of the following draft

"Analysis of Multihoming in Mobile IPv6"
URL: 
http://ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-01.txt

believe that the document is now ready for in-deep review from the 
working group. We thus encourage the WG to carefully review the document 
and provide (any) comment to enhance it.

Any comments will be greatly appreciated.

Thank you for your effort.

Nicolas

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 26 Sep 2006 23:34:27 -0700

Folks, 

Please note that a new revision has been submitted based on our
discussions 
in Montreal. Until it apperas on the IETF site, you can find it here:

http://www-r2.u-strasbg.fr/~montavont/draft-soliman-monami6-flow-binding
-02.txt

We made significant changes in this revision, here are the main ones:

- Combine the use of the flow id with the BID for aggregation and 
  n-casting benefits. 
- Modified the Flow id option to include the BID (as a sub-option)
- Defined a new BID sub-option for the purpose above
- Added a new field (CLS) to the option in order to allow other ways of
definining a flow. 
This issue was brought up in the last meeting. We can now have 15
different mechanisms
(or languages) to define a flow. 

We look forward to your comments. 

Hesham

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 27 Sep 2006 10:08:56 +0300

> We look forward to your comments. 

Hello Hesham,

One quick question. What is the benefit of storing flow identification 
information in the BC/BUL instead of storing it in a database shared by 
possibly other mobility management protocols? Yes, BC and BUL are 
already defined entities whereas "a common database" is not, but still 
in my opinion BC and BUL are not the place to store such information 
unless there is a good argument for it.

-- 
Tero

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 27 Sep 2006 00:16:25 -0700

Hi Tero, 

 > unless there is a good argument for it.

=> The spec talks about managing and storing this information
conceptually just like 
3775 discusses the BC and BUL conceptually and just like 2461 discusses
a NC. You could choose to implement things differently in anyway you
want as long as the external behavious is consistent with the spec.
Similarly You could choose to implement a BC in your NC, or a routing
table in the NC. There is no point in mandating anything here. For
clarity though we describe conceptual data.

Hesham

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 27 Sep 2006 12:16:30 +0300

> clarity though we describe conceptual data.

Okay, I see. I guess that "conceptually" was just then too easy to miss 
for me.

-- 
Tero