Subject: [nemo] Home Network models update

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 17 Jan 2006 10:40:03 +0100

Hi: 

Margaret sent us the IESG review for the Home net model draft. Please see inline:

---------------------------------------------------------------------------------------

Ted Hardie:

Discuss:

[2005-11-29] In 6.4.1, the document says:

  Thus, on the Home Link, the Home Agent must intercept all the packets

  to ALL the Mobile Network Nodes on the registered prefixes.  In order

  to do so, the Home Agent might perform some form of ND proxying for

  all addresses in all registered Mobile Network Prefixes.  The Home

  Agent must also protect the MNP space from autoconfiguration by

  uncontrolled visitors at Neighbor Discovery level.

  Alternatives based on a routing protocol or ICMP redirect may apply

  in some cases.

The second paragraph is not clear to me.  Is the intent to say that ICMP redirect or some routing 

protocol behavior will substitute for ND proxying?

Pascal: MADE THAT ISSUE 9

-------------------------

We'll make a separate discussion for it.

---------------------------------------------------------------------------------------

 

Comment:

[2005-11-29] The document uses this example:

"Cab Co is a taxi Company that owns a /32 prefix"

The phrase "owns a /NN prefix" might be better put as "uses".  The question of ownership and address 

prefixes has been the subject of non-technical debate over the years, and skipping it might make 

sense.

Pascal: OK

----------

---------------------------------------------------------------------------------------

Scott Hollenbeck:

Comment:

[2005-11-29] The citation "[8]" should be removed from the Abstract and the technical summary portion 

of the ballot write-up.

Pascal: OK

----------

---------------------------------------------------------------------------------------

David Kessens:

Comment:

[2005-11-30] Comments from the Ops directorate by Pekka Savola:

I found this document reasonably clear.  I do not think there are any blocking issues, but there seem 

to be suitably many editorial clarifications that could help.  As the doc has normative refs to work 

that is still at WG, there should be time to revise it.

semi-editorial issues

---------------------

  If the Mobile Router returns Home by Egress, a specific support is

  required to control the bridging operation depending on whether a

  Mobile Router is at Home or not.  This support might not be present

  in all implementations.

==> in a number of places you say "present in ... implementations" ..

but what about the specifications?  Do specifications provide with sufficient mechanisms to convey 

which mechanism should be used by mobile routers in each of the scenarios so that they would pick an 

interoperable and/or working approach?  (As I haven't studied the specs in detail, I don't know the 

answer -- this is just something that was not apparent from reading the doc.)

Pascal: Made that issue 10

--------------------------

We'll make a separate discussion for it.

 

---------------------------------------------------------------------------------------

13.1  normative reference

...

  [9]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",

        draft-ietf-nemo-terminology-03 (work in progress),

        February 2005.

  [10]  Ernst, T., "Network Mobility Support Goals and Requirements",

        draft-ietf-nemo-requirements-04 (work in progress),

        February 2005.

==> these two are normative references but are still at WG.  The publication of this document will be 

blocked until these are published as well... I hope the WG is aware of this.

Pascal: Thierry says it's OK, he will submit soon to IESG.

-----------------------------------------------------------

---------------------------------------------------------------------------------------

 

editorial

---------

==> examples used the prefixes A:B:C::/48 and CAB:C0::/32.  You should use 2001:db8::/32 instead as 

it's specifically meant as a doc prefix -- unless you have strong reasons for otherwise.

Pascal: it was supposed to help the user understand it's Cab Co. Is that a big problem?

---------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------

==> a number of terms weren't spelled out, such as MNP, MNN, ...

Pascal: OK

----------

---------------------------------------------------------------------------------------

Abstract

  This paper documents some usage patterns and the associated issues

  when deploying a Home Network for NEMO-enabled Mobile Routers,

  conforming the NEMO Basic Support draft [8].

==> no refs in the abstract.  Don't use the word, "draft" especially if it's an RFC ;-).

Pascal: OK

----------

---------------------------------------------------------------------------------------

  The following terms used in this document are defined in the IPv6

  Addressing Architecture document [5]:

      link-local unicast address

      link-local scope multicast address

==> these terms are in fact not used in this doc, so this can be removed.

Pascal: OK

----------

---------------------------------------------------------------------------------------

6.2 [Aggregated Home Network - Returning home] ...

  Since the Home Network prefix is an aggregation that encompasses all

  the MNPs, the Home Address that an MR forms from one of its Mobile

  Network Prefixes will actually match both the Home Network prefix and

  its Mobile Network prefix.  To properly identify the Home Network,

  the MR must expect a shorter prefix than that of the Mobile Network

  from which the Home Address was formed.

  When the Mobile Router forms its Home Address out of one of its

  Mobile Network Prefixes, since the Home Network prefix is an

  aggregation that encompasses all the MNPs, the Home Address actually

  matches both prefixes.  As a result, the MR must expect a shorter

  prefix than that of the Mobile Network from which the Home Address

  was formed.

==> Isn't the 2nd paragraph baiscally text duplication of the first, or was there a separate point 

there?  I had hard time following this.  In any case, I'd suggest rewording.

Pascal: Oups, this is actually a leftover after a rewording of that sentence

----------------------------------------------------------------------------

this sentence has been reworked a number of time. I'll try a limited update:

            When the Mobile Router

            forms its Home Address out of one of its MNPs,

            since the Home Network prefix is an aggregation that encompasses all

            the MNPs, the Home Address actually matches both prefixes.

            To properly identify the Home Network as it returns Home, the MR

            must expect a shorter prefix length than that of the MNP from

            which the Home Address was formed.

---------------------------------------------------------------------------------------

Please

  refer to the NEMO multihoming issues [13] draft for more on this.

== remove or reword "draft"

Pascal: OK

----------

---------------------------------------------------------------------------------------

  One should check with the product specifications of an Home Agent to

  see whether the implementation actually supports a Virtual Home

  Network, and if so, whether in that cases, it is optimized for faster

  DAD-less bindings.

==> remove "with".  Is the present wording even good for an IETF doc?

Pascal: changed to a mere:

--------------------------

Note that NEMO basic does not mandate the support of Virtual Home Networks.

Thanks a lot to all reviewers :-)

 

Pascal Thubert
software engineer 

Cisco Systems
Village d'Entreprises GREEN SIDE
400, Avenue Roumanille
Bâtiment T3
06410 BIOT - Sophia-Antipolis 

[email-masked] <mailto:[email-masked]>  

tel: 
mobile: 

+33 4 97 23 26 34
+33 6 19 98 29 85

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Jan 2006 12:15:22 +0200 (EET)

> Pascal: it was supposed to help the user understand it's Cab Co. Is that a big problem?

The document needs to justify why it uses those if that's what you 
wish to do.

In this particular case, I see the "CAB:C0::/32" prefix used only 
under section 8, where you don't use any other prefixes, so I
think using 2001:DB8::/32 shouldn't cause confusion here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings