[Mobopts] RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]

"Wes Beebee \(wbeebee\)" <wbeebee@cisco.com> Fri, 31 August 2007 22:10 UTC

Return-path: <mobopts-bounces@irtf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IREhC-00083Y-CS; Fri, 31 Aug 2007 18:10:30 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRB6h-0001Ea-PP; Fri, 31 Aug 2007 14:20:35 -0400
Received: from rtp-iport-1.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRB6g-0007HS-Fg; Fri, 31 Aug 2007 14:20:35 -0400
Received: from rtp-dkim-2.cisco.com ([]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2007 14:20:10 -0400
X-IronPort-AV: i="4.20,193,1186372800"; d="scan'208"; a="69777534:sNHT65952275316"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com []) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7VIK92Y023542; Fri, 31 Aug 2007 14:20:09 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com []) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7VIK25m011743; Fri, 31 Aug 2007 18:20:02 GMT
Received: from xmb-rtp-211.amer.cisco.com ([]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 14:19:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Aug 2007 14:20:47 -0400
Message-ID: <CA8EB93B28BD0F4C88392699600BD655042A4729@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D039DC361@xmb-rtp-20e.amer.cisco.com>
Thread-Topic: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]
Thread-Index: AcfD0J5rK0240mUVSa+wcH+2tni9PwoE7nYAAAO5fiA=
From: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, ipv6@ietf.org, netlmm@ietf.org, mobopts@ietf.org, nemo@ietf.org
X-OriginalArrivalTime: 31 Aug 2007 18:19:55.0756 (UTC) FILETIME=[8830B2C0:01C7EBFB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5919; t=1188584409; x=1189448409; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20\(wbeebee\)=22=20<wbeebee@cisco.com> |Subject:=20RE=3A=20[Fwd=3A=20WGLC=20for=20draft-ietf-dna-protocol-06.txt ] |Sender:=20 |To:=20=22Hemant=20Singh=20\(shemant\)=22=20<shemant@cisco.com>, =0A=20=20 =20=20=20=20=20=20=22Suresh=20Krishnan=22=20<suresh.krishnan@ericsson.com> , =20<ipv6@ietf.org>, =0A=20=20=20=20=20=20=20=20<netlmm@ietf.org>, =20<mobop ts@ietf.org>,=20<nemo@ietf.org>; bh=jjWtRWiutsvwaXHV/ZxQzqj6hGQKOgKIMrCHOaFN8Rw=; b=afktPId0/o+15T1JFBxz5vI369qZY1xJ/lwrd3zJELKZybqxpBnJerj1R2hUhgAjYytaKa2M vBJf9Mg69sZSHVSExpKyx8te94KW2bT6DIC5kG5+qytHSwaLSUkhvLLv;
Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: -3.7 (---)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
X-Mailman-Approved-At: Fri, 31 Aug 2007 18:10:29 -0400
Subject: [Mobopts] RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org

Here's my review of the DNA I-D:

One global concern: 
I'm concerned that DNA may not be applicable to all networks.  There
seems to be some 
implicit assumptions about the networks that must be true - and these
assumptions are
not necessarily going to be true on all of the networks that DNA seems
to be targeting.
In cases where DNA cannot automatically determine that the host is in
such a network, 
it should be possible to turn DNA off manually and resort to old-style

Specific concerns:
1) What track is this Internet Draft on - Standards?
2) I'm concerned about two major deployment scenarios, each of which is
likely to affect millions of subscribers
   off of the same aggregation router:
   a) The router offers no PIO in the RA - thus, no prefix is available.
This is currently being 
      discussed as a possible way to prevent poorly implemented host
stacks which ignore the M and A bits 
      in the RA from doing SLAAC and force them to do DHCPv6 or not get
online.  Unfortunately, this
      case breaks DNA as there is no prefix available to identify the
link.  The "at least one router
      on a link MUST be configured with one prefix" is a limitation of
   b) The prefix for a neighborhood is the same for all access points in
the neighborhood.  This can happen
      if home users are off of bridge modems and they are all bridging
the same prefix (which is defined 
      on a bundle interface of the aggregation router.  This is done to
conserve address space and simplify
      network configuration by MSO's.  Unfortunately, this means that
DNA will detect every AP in the neighborhood
      as the same link.  Even worse, when DNA causes the node not to do
DHCPv6 again, the aggregation router
      which understands which home corresponds to which addresses,
causes source verify to reject traffic
      from the roaming laptop.  What should happen is that the node
should try to do DHCPv6 again when it roams
      even when the prefix is the same - this doesn't work in DNA.
3) The routers being able to advertise a prefix list as complete assumes
that they know about all the routers on the link.
   However, one of the routers could be silent for a while, and a router
may assume that it knows all of the prefixes on
   the link but may be wrong.
4) "Any future non-prefix link identifier MUST be 128 bits long." - Why?
scale up to 100,000 hosts off of an 
   aggregation router?  What if multiple interfaces startup at the same
time?  Will there be an RS storm and will
   the token bucket rate limiting cause RS's to be dropped as described
in the security considerations case?
   I suspect that this case may be even more common than you might
suspect...  You may have to adjust
   UNICAST_RA_INTERVAL and MAX_UNICAST_RA_BURST to deal with interface
bringups on the aggregation router.
6) "The router MUST pick the smallest prefix of all the prefixes
configured on the routers on the link as the
    common prefix."  What if there are 2 smallest prefixes?
7) "an absence of that overlap can be used to infer link change" in
5.1.8 is repeated again in 5.1.9, and - please
   eliminate redundancy.
8) In, one of the IF statements is missing - "{ Link change has
occurred. RETURN; }" but no IF, and occurred is
   spelled wrong.
9) Why do you need to infer upstream reachability?

- Wes

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Friday, August 31, 2007 11:40 AM
To: Suresh Krishnan; ipv6@ietf.org; netlmm@ietf.org; mobopts@ietf.org;
Subject: RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]


I have few minor comments on this I-D. Wes Beebee will send more
detailed comments sometime later today. He has reviewed the I-D.

1. While reading the Abstract, I'd like to know what is the maximum
delay DNAv6 is ready to accept in a response from router?  
2. Stateful has been deprecated for use. We should call it DHCPv6.
Therefore section 5.2.7 should change statefully to DHCPv6.


-----Original Message-----
From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]
Sent: Wednesday, July 11, 2007 11:29 AM
To: ipv6@ietf.org; netlmm@ietf.org; mobopts@ietf.org; nemo@ietf.org
Subject: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]

Hi Folks,
   We would like to hear your comments on this document as well. This
document is a significant update to ipv6 neighbor discovery and we would
like some more eyeballs. Please spare some time from your busy schedule
to give it a look.


-------- Original Message --------
Subject: WGLC for draft-ietf-dna-protocol-06.txt
Date: Wed, 04 Jul 2007 15:47:24 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Dna <dna@eng.monash.edu.au>
CC: Greg Daley <Greg.Daley@eng.monash.edu.au>,  Jari Arkko

This mail starts a 2 week working group Last Call for comments for the
following dna working group document


to be sent to the IESG for consideration as a Standards Track RFC.

Please review the document carefully, and send your feedback to the
list. Please also indicate whether or not you believe that this document
is ready to go to the IESG.

The last call will end on 2007/07/18.

Suresh & Greg

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

Mobopts mailing list