Subject: [nemo] RE: draft-ietf-nemo-home-network-models-05

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 9 Feb 2006 12:35:32 +0100

Hi:

At IESG review, a number of questions and issues were raised against the
home network models draft.
A pre-version 6 of the draft was edited to address them. It is available
at:

http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
els-xx.txt 

Issue list:
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
els-issues.html

In particular, issue 9 was a "discuss" item.

In fact, the text did not appear particularly useful, and would have
lead to discussion going above and beyond the scope of the draft; so the
text was simply removed.

Comments welcome :)

Pascal 

>-----Original Message-----
>From: Margaret Wasserman [mailto:[email-masked]]
>Sent: Sunday, January 08, 2006 5:24 AM
>To: Pascal Thubert (pthubert); [email-masked];
[email-masked]; [email-masked];
>[email-masked]
>Subject: draft-ietf-nemo-home-network-models-05
>
>
>Hi All,
>
>I wanted to check on the status of
>draft-ietf-nemo-home-network-models-05...  This document was reviewed
by
>the IESG on 12/1/2005, and there was one blocking issue ("discuss")
>raised by Ted.  There were also some comments from other ADs.  I have
>included Ted's discuss and the other comments below for reference.
>
>Authors, have you had a chance to look at Ted's discuss and the other
>comments?  Do you have any questions about these issues and/or do you
>have a plan to update the document to address them?
>
>Theirry and TJ, which one of you is serving as the PROTO shepherd for
>this document?  Please let me know, so that I can include a comment in
>the tracker.  And, also, could whichever one of you is shepherding the
>document please make sure that these issues get resolved?
>
>I am going to put the document into the "Revised ID Needed" substate
and
>wait for an update.  If it turns out that no document update is needed
>to address these concerns, please let me know.
>
>Thanks,
>Margaret
>
>---
>
>
>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?
>
>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.
>
>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.
>
>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.)
>
>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.
>
>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.
>
>
>==> a number of terms weren't spelled out, such as MNP, MNN, ...
>
>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 ;-).
>
>  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.
>
>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.
>
>Please
>  refer to the NEMO multihoming issues [13] draft for more on this.
>
>== remove or reword "draft"
>
>  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?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Feb 2006 14:14:47 +0100

Pascal Thubert \(pthubert\) wrote:
[...]
>  lead to discussion going above and beyond the scope of the draft; so
>  the text was simply removed.

If that ICMP Redirect text (between HA and MR) did not appear to be
particularly useful then I wonder how proxy ND by HA for _all_ addresses
in the moving network is of any use at all.  By RFC3963 the HA does
proxy ND only for MR's Home Address.

draft-ietf-nemo-home-network-models-xx.txt:
>  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.

This above paragraph makes no particular sense at all, since a HA doing
proxy ND for a LFN node which is below MR will intercept packets from
all the neighbours of HA addressed to LFN, even though it is the MR who
should intercept or receive those packets.

There can be no "proxy ND" for an LFN on HA's link as long as the normal
ND of same LFN is not happening on the home link.

Alex

> 
> Comments welcome :)
> 
> Pascal
> 
>> -----Original Message----- From: Margaret Wasserman 
>> [mailto:[email-masked]] Sent: Sunday, January 08, 2006 5:24 AM
>> [email-masked] Subject: 
>> draft-ietf-nemo-home-network-models-05
>> 
>> 
>> Hi All,
>> 
>>  raised by Ted.  There were also some comments from other ADs.  I 
>> have included Ted's discuss and the other comments below for 
>> reference.
>> 
>> Authors, have you had a chance to look at Ted's discuss and the 
>> other comments?  Do you have any questions about these issues 
>> and/or do you have a plan to update the document to address them?
>> 
>> Theirry and TJ, which one of you is serving as the PROTO shepherd 
>> for this document?  Please let me know, so that I can include a 
>> comment in the tracker.  And, also, could whichever one of you is 
>> shepherding the document please make sure that these issues get 
>> resolved?
>> 
>> wait for an update.  If it turns out that no document update is 
>> needed to address these concerns, please let me know.
>> 
>> Thanks, Margaret
>> 
>> ---
>> 
>> 
>> 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.
>> 
>> redirect or some routing protocol behavior will substitute for ND 
>> proxying?
>> 
>> Comment: [2005-11-29] The document uses this example:
>> 
>>  question of ownership and address prefixes has been the subject of
>>  non-technical debate over the years, and skipping it might make 
>> sense.
>> 
>> 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.
>> 
>> 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 ---------------------
>> 
>> 
>>  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.)
>> 
>> 13.1  normative reference ... [9]  Ernst, T. and H. Lach, "Network 
>> Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work
>>  in progress), February 2005.
>> 
>>  draft-ietf-nemo-requirements-04 (work in progress), February 2005.
>> 
>> 
>> 
>> publication of this document will be blocked until these are 
>> published as well... I hope the WG is aware of this.
>> 
>> 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.
>> 
>> 
>> ==> no refs in the abstract.  Don't use the word, "draft" 
>> especially if it's an RFC ;-).
>> 
>> 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 
>> 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.
>> 
>> Please refer to the NEMO multihoming issues [13] draft for more on 
>> this.
>> 
>> 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.
>>