Subject: Re: [nemo] About Test Specification in IPv6 Ready Logo

From: Keiichi SHIMA <[email-masked]>
Date: Sat, 4 Nov 2006 14:42:58 -0800

Hello,

I'm sorry for my very delayed response.

On 2006/10/30, at 17:00, K.Kawaguchi wrote:
>
> We have already gotten some opinions. We hope to obtain the conclusion
> at the meeting. We want to examine only the conclusion at the meeting,
> because the meeting have not much time.
> If you have an additional opinion, please send it to ML before the
> meeting.

I'm personally fine with the direction that Kawaguchi-san suggested.

Our team implemented NEMO BS on top of the BSD operating system.   
Right now, we only support the basic case (a HoA from a home network)  
due to our implementation design.  So, making it as a basic logo  
requirement and taking a HoA from MNP as an advanced requirement is  
OK for us :-).

However I have one concern.  The Logo program intends to produce many  
interoperable implementations.  But if we have two levels of the logo  
program (basic and advanced), and everyone can get the basic logo by  
implementing only some parts of the specification, what does motivate  
vendors to implement advanced features?

So, the question is, how is it important for NEMO deployment that  
taking a HoA from a mobile network prefix.  If it is not very  
important, then the feature can be in the advanced logo requirement  
only.  But if it is important, we should not have two logo programs.

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

On 2006/10/30, at 17:00, K.Kawaguchi wrote:

> Hi all and Vijay-san,
>
> Thank you for answer.
> # I'm sorry the delay.
>
> To our regret, The IPv6 Logo Committee NEMO staffs cannot  
> participate in
> the next meeting. Instead of participation, I made text for the next
> IETF meeting.
>
> We have already gotten some opinions. We hope to obtain the conclusion
> at the meeting. We want to examine only the conclusion at the meeting,
> because the meeting have not much time.
> If you have an additional opinion, please send it to ML before the
> meeting.
>
>
> Best regards
> ---
> Kiyoaki KAWAGUCHI
>
>
>
> "Re: [nemo] About Test Specification in IPv6 Ready Logo"
> "Vijay Devarapalli <[email-masked]>" wrote:
>
>> K.Kawaguchi wrote:
>>
>>>> - HA (Home Agent)
>>>>  - Router functions defined in "Test Specifications for the IPv6  
>>>> Core
>>>>    Protocols" MUST be supported.
>>>>  - Mobile network prefix registration supporting all of explicit  
>>>> mode,
>>>>    implicit mode, home address derived from the Mobile Network  
>>>> Prefix, and
>>>>                    
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>    home address derived from the Home Network Prefix is a Basic  
>>>> Function (A1).
>>>>     
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>>>> ^^^^^^^^
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> * supplementation) keywords
>>>>   Basic Function (Priority A1)  : It is defined as indispensable  
>>>> function.
>>>>                                   It is always to be tested in  
>>>> Logo.
>>>>   Advance Function (Priority A2): It is defined as enhanced  
>>>> feature.
>>>>                                   It is tested by selection in  
>>>> Logo.
>>>>
>>>>
>>>> RFC3963 has not described which method is a 'MUST'. Therefore,
>>>> we had equally treated both. However, the operation is possible
>>>> by either one.  And a lot of venders might implement only one
>>>> of methods. Now, we think that it is too rich to demand both from
>>>> all products.
>>>> We will put the bias. Two alternatives without mandating either
>>>> make non-interoperable world. So, mandating one is very reasonable.
>>>> We think naturally that home Address be configured from Home Link
>>>> Prefix is basic method same as MIPv6.
>>
>> sounds good to me.
>>
>> Vijay
>>
>>
>> <Logo_NENO_IETF_68th.txt>

---

From: Thierry Ernst <[email-masked]>
Date: Sun, 5 Nov 2006 17:44:04 +0100

Dear Shima-san,

You raised an interesting point and I totally agree with the rationale. 

As a WG, we should make sure that all functionalities are actually
implemented by at least a few implementors, otherwise the
functionalities would have to be removed in a later revision of the RFC.

It there could only be one level of the ready logo program, this would
rather mean that all features should be part of the ready logo program
in order for an implementation to qualify for it. Otherwise, yes, we
take the risk that some features are not implemented. If that happens,
we would wonder what was the reason behind all the work we make to add
more features.

I think it would be nice if all implementors would make their point
about what is needed to deploy RFC 3963 (this is linked with another
discussion, then), and what has been implemented / is under going on
their side.

Thierry.

On Sat, 4 Nov 2006 14:42:58 -0800

--

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Nov 2006 09:08:27 -0800

Hi Thierry,

> functionalities would have to be removed in a later revision of the RFC.

its ok if some features don't get implemented
and we eventually remove them.

> in order for an implementation to qualify for it. 

I don't think we should force the IPv6 ready logo
program to include all features.

Otherwise, yes, we
> we would wonder what was the reason behind all the work we make to add

thats normal. when a WG develops a solution on the
IETF, it is hard to say what will get implemented
and deployed.

> discussion, then), and what has been implemented / is under going on

as the Basic NEMO spec moves from a Proposed
Standard to Draft Standard, this happens
automatically. any feature in the RFC that does not
have multiple interoperable implementations is
removed.

Vijay

---

From: "K.Kawaguchi" <[email-masked]>
Date: Wed, 8 Nov 2006 15:13:33 +0900

Hi Chairs and all,

I explain the selection and the classification of test item on the Logo
test specification in section 7 more. And I add the Idea-5 in section 5.

We want the evidence of the consensus/Idea that IETF NEMO WG agreed.
If possible, please consolidate it at the meeting.

---
7.  Supplementary explanation

   The Logo test specification doesn't take all the descriptions of RFC.
   The functions with strong demand in RFC are included in the Logo
   test. (i.e. 'MUST','SHOULD' and an affirmative sentence in RFC. )
   Not only 'MUST' but also 'SHOULD' is contained because the Logo
   standard was set to a high-quality interoperability. (Logo such as
   IPv6 Core and IPsec is similar too.)

   Logo is classified from the necessity of the function into the Basic
   Function and the Advanced Function. The Basic Function takes a
   function necessary to ensure a minimum interoperability. The Advanced
   Function is necessary for securing the interoperability of a higher
   function. The Advanced Function of Logo is proof of a higher
   function.

   In the Logo test specification of RFC3775(MIP6), the home
   registration and the payloads packet tunneling were assumed to be the
   Basic Function. The dynamic home agents address discovery, the mobile
   prefix discovery, the return routabiliuty, and the returning home
   were assumed to be the Advanced Function. (This function is the same
   classification into NEMO.)

   How is the Home Address setting classified in NEMO basic?
   - MUST/SHOULD MR be able to configure home address from home network
     prefix?
   - MUST/SHOULD MR be able to configure home address from mobile
     network prefix?
   - Is it necessary for securing a minimum interconnectivity?

   Some opinions seem to support the home address configuring from home
   network prefix. On the other hand, no opinion supports the home
   address configuring from mobile network prefix. The following ideas
   are added.

   Idea-5) Although home address configured from home network prefix is
           the Basic Function, home address configured from mobile
           network prefix is out of the Logo. In this case, Logo
           candidates are required to support at least the Basic
           Function. We can certificate interoperability among all the
           NEMO products with the Basic Function.

   The Logo test will be renewed if the RFC is renewed in the future.
   That is, if the demand rises in the future, it will be added to the
   Advanced function or the Basic Function. (Of course, new Logo is
   distinguished from old Logo.)
---

Best regards
---
Kiyoaki KAWAGUCHI

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 08 Nov 2006 11:32:22 -0800

> If possible, please consolidate it at the meeting.
Hi,

The list of items to go into your testing program is not a work item for 
NEMO, and although you can gather informal opinions from the list, there 
would not be working group consensus provided to any Logo or testing 
program run by an independent entity. It would be up to you to decide 
what features you want to certify for your Logo program.

TJ

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 9 Nov 2006 07:32:37 +0900

Hi TJ

On 2006/11/09, at 4:32, T.J. Kniveton wrote:

> The list of items to go into your testing program is not a work  
> item for NEMO, and although you can gather informal opinions from  
> the list, there would not be working group consensus provided to  
> any Logo or testing program run by an independent entity. It would  
> be up to you to decide what features you want to certify for your  
> Logo program.

Regardless of logo, it is true that the RFC 3963 is vague on this.
MR can support either one or both configurations.
I'm not sure whether 3963 will take "Hoa from home prefix" as a  
default configuration in future revision,

Regarding to the logo, you can pick one of configuration as a default.
But before making such decision, you should check the below document  
too.
Aggregated home network is one example to support HoA from MNP.
http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network- 
models-06.txt

The current SHISA implementation supports only HoA from the home prefix,
but we knew it's easily extend to support both case.

regards,
ryuji

---

From: "K.Kawaguchi" <[email-masked]>
Date: Thu, 9 Nov 2006 17:54:11 +0900

Hi,

> > be up to you to decide what features you want to certify for your  

I consented. The decision of the Logo program is the independent work of
us. Also, we will keep participating in NEMO WG according to the outline
of IETF.

> http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network- 

Yes. I am referring to this draft. I see that the product package of a
different specification exists according to those home network models.
Also in the opinion that has been obtained before, a lot of developers
seem to be advancing development by one method.

> but we knew it's easily extend to support both case.

The product that can achieve both provides high applicability to the
career and the user. It is one advantage for the product.

As a result, I think that we will separately treat each home address
setting method.

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 10 Nov 2006 19:03:59 +0900

Hi,

Being able to register an HoA from a MNP may be more important on the HA
than on the MR, for interoperability purposes. This could bring a new
option: being a basic feature on the HA, and a advanced one on the MR.

I personally like this way of configuring the MR, as the HA does not
need to deal with 2 prefixes anymore (one to build the MR's HoA, and one
MNP to delegate to the MR), and just need to delegate an MNP to the MR.

FYI the NEPL implementation is designed to support also HoA from MNP,
although a small bug prevents to do so in the current version (could get
it working with a small fix).

Regards,

-- 
Romain KUNTZ
[email-masked]

RYUJI WAKIKAWA wrote:
>> The list of items to go into your testing program is not a work item 
>> for NEMO, and although you can gather informal opinions from the list, 
>> there would not be working group consensus provided to any Logo or 
>> testing program run by an independent entity. It would be up to you to 
>> decide what features you want to certify for your Logo program.
> 
> I'm not sure whether 3963 will take "Hoa from home prefix" as a default 
> configuration in future revision,
> 
> But before making such decision, you should check the below document too.
> http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-06.txt 
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 10 Nov 2006 13:51:01 -0800 (PST)

Hi Romain,

> option: being a basic feature on the HA, and a advanced one on the MR.

Using a HoA from MNP introduces some interesting situation, when
the MR returns home. The MNP is anchored at the HA and when the
MR returns home, there is no routing state for that prefix at
the HA. At home, is the MR a bridge ? Is the prefix split between
HA and MR and MR and itself ? If some one case fix the text in
3963 and address all the issues, I'm ok supporting this. Currently,
we dont support this.

> MNP to delegate to the MR), and just need to delegate an MNP to the MR.

But, at a cost of configuration complexity. If are clear as how the
routing/configuration looks when the MR is at home, in this scenario,
I'm ok with this.

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 13 Nov 2006 11:13:14 +0900

Hi Sri,

> 3963 and address all the issues, I'm ok supporting this. Currently,

When returning home, the MR could configure an autoconfigured address on 
its egress interface and send routing protocol messages (section 5.8). 
Are there any issues with such solution?

Regards,
-- 
Romain KUNTZ
[email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 12 Nov 2006 19:57:08 -0800 (PST)

Hi Romain,

> When returning home, the MR could configure an autoconfigured address on its 
> egress interface and send routing protocol messages (section 5.8). Are there 
> any issues with such solution?
>

How does your NEMO state machine know, its at home ? Typically,
you compare the advertised prefix from the RA, with the
configured home network prefix. In this case, when the HOA is
from the MNP, how does your current implementation determine
it is at home ?

Sri

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 14 Nov 2006 18:00:08 +0900

Hi,

> Are there any issues with such solution?

If the routing protocol is indispensable, I want to know which routing
protocol should provide.
I think that default is necessary to secure the interoperability and the
NEMO connection test between many products. I think the default only now
to be acceptable, even if the default will be changed in the future.

Best regards
---
Kiyoaki KAWAGUCHI