Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D421F871C for ; Thu, 11 Apr 2013 20:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cyDqdd6rYaz for ; Thu, 11 Apr 2013 20:01:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9573121F8678 for ; Thu, 11 Apr 2013 20:01:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ART58298; Fri, 12 Apr 2013 03:01:05 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 04:00:29 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 11:01:03 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 12 Apr 2013 11:00:56 +0800 From: "Liubing (Leo)" To: Ted Hardie , "apps-discuss@ietf.org" , "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" Thread-Topic: Review of draft-ietf-6renum-gap-analysis-05 Thread-Index: AQHONwcY0vdwoOJq1Eis2vBZoqHNl5jRyugQ Date: Fri, 12 Apr 2013 03:00:54 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 12 Apr 2013 13:44:42 -0700 Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 03:01:17 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ted Many thanks for your review, it would be helpful to refine the draft. Pleas= e see replies inline. Best regards, Bing From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: Friday, April 12, 2013 6:51 AM To: apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.ietf.or= g Subject: Review of draft-ietf-6renum-gap-analysis-05 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document:draft-ietf-6renum-gap-analysis-05 Title: IPv6 Site Renumbering Gap Analysis Reviewer: Ted Hardie Review Date: April 11, 2013 Summary: This document is basically ready to be published as an Information= al draft. There are minor issues which the authors may wish to address bef= ore final publication. Minor Issues: The document currently motivates its work with the following statement: If IPv6 site renumbering continues to be considered difficult, network managers will turn to Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. A citation for this would be useful. It might also be worth it to highlight other potential risks--for example, the widespread deployment of ULAs, which do not admit of aggregation, or the deployment of [Bing] Ok, thanks for the suggestion. We'll include the reference on BGP4 s= caling issue, as well as considering whether there are other potential risk= s. But for the specific ULA problem, it might be different. ULA is intended to= be used within a certain scope, normally, within an enterprise network. So= it won't bother the global routing scalability. In fact we suggest to use ULA along with PA in enterprise to avoid some ren= umbering or to make internal communication more stable when switching globa= l prefixes. It was documented in the recently published 6renum RFC6879 (Ple= ase see section 4.1) address translation technologies which make referral more difficult. I not= e that RFC 5887 included some of these issues. If the intent is to reference those from RFC 5887, I note that the document currently says that it "starts from existing work in [RFC5887], [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references to these documents are informative. If the document is meant to be an exte= nsion, rather than a replacement, such that these documents must be read to get th= e full picture, than a normative reference may be better. [Bing] These documents are important input for the gap analysis draft. They= indeed have not a few crossed content, but our intention on the gap draft = was different, so it is neither extension nor replacement. RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IPv6= renumbering issue; RFC4192 emphasizes on a "make before break" prefix swit= ching operation. This gap draft addresses the IPv6 enterprise scenarios described in RFC687= 9, and focusing on identifying what is missing to make renum more automatic= and less error-prone. For the session survivability section, a reference to RFC 6724 may be usefu= l, so that those adding new global addresses understand how the application API t= o determine which address is used with interact with the addition of new addresses (if = there is a specific draft or other treatment of that topic, that would be even be= tter, but I am not personally aware of one). [Bing] OK. Address selection is indeed important. In section 6, the document currently says: When nodes in a site have been renumbered, then all the entries in the site which contain the nodes' addresses must be updated. The entries mainly include DNS records and filters in various entities such as ACLs in firewalls/gateways. This appears to imply that these updates must take place after the renumber= ing event, but this is variable. ACLs and filters may well be updated in advan= ce; DNS may be updated concurrently or post facto. A rewording to highlight th= at this is variable by record type may be useful. [Bing] Ok, thanks. Section 9.2, in the bullet entitled "DNS data structure optimization" The discusses a DNS feature proposed but declared historic. I don't think i= t identifies the related renumbering gap in a way that is useful for a naive reader. If it cannot be reworded to focus on the gap, I suggest it be removed. [Bing] When we wrote the draft, we considered if the IPv6 DNS record could = be structured as separating prefix and suffix, that would be very helpful f= or renumbering. Because in IPv6, most of the time we just change the prefix= es rather than the whole addresses. We found A6 has the similar feature, but it has been moved to historic. How= ever, the idea of separating prefix and suffix is still considered valuabl= e, but there might not be able to develop a new DNS record in a short time= , so we name the idea as "DNS data structure optimization" and put it into = "gaps considered unsolvable". We can add some minor texts to explain the intention. In section 9.4, the document says: For application layer, as [RFC5887] said, in general, we can assert that any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session. This might be reworded to include or focus on session resumption, rather t= han new communications sessions. From an applications perspective, the laptop "sleep" function seems to be one of the bigger risks of this. [Bing] Ok, thanks. Nit: For me personally, section 6.1 seemed needlessly pessimistic. [Bing] It is sad but true. And we are curious about how much operational is= sues there to prevent DDNS widely deployed in real networks. If possible, we might consider to make a dedicated draft to talk about this= issue in the future. --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Ted

 = ;

Many thank= s for your review, it would be helpful to refine the draft. Please see repl= ies inline.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Friday, April 12, 2013 6:51 AM
To: apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.= ietf.org
Subject: Review of draft-ietf-6renum-gap-analysis-05

 

I have been selected as the App= lications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/= ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05

Title: IPv6 Site Renumbering Ga= p Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

=
Summary: This document is basically ready to be published as an Information= al draft.  There are minor issues which the authors may wish to addres= s before final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues t=
o be considered
   difficult, network managers will tur=
n to Provider Independent (PI)
   addressing for IPv6 to attempt to mi=
nimize the need for future
   renumbering. However, widespread use=
 of PI may create very serious
   BGP4 scaling problems. It is thus de=
sirable to develop tools and
   practices that may make renumbering =
a simpler process to reduce
   demand for IPv6 PI space.

A c=
itation for this would be useful.  It might also be worth it to 
hi=
ghlight other potential risks--for example, the widespread deployment
of=
 ULAs, which do not admit of aggregation, or the deployment of 

[Bing] Ok, thanks for the su=
ggestion. We’ll include the reference on BGP4 scaling issue, as well =
as considering whether there are other potential risks.

But for the specific ULA pro=
blem, it might be different. ULA is intended to be used within a certain sc=
ope, normally, within an enterprise network. So it won’t bother the g=
lobal routing scalability.


In fact we suggest to use UL=
A along with PA in enterprise to avoid some renumbering or to make internal=
 communication more stable when switching global prefixes. It was documente=
d in the recently published 6renum RFC6879 (Please see section 4.1)


 


address translation technologies which make refer=
ral more difficult.  I note
that RFC 5887 included some of these is=
sues.  If the intent is to reference
those from RFC 5887, I note th=
at  the document currently says that it 



 


"starts from existing work in [RFC5887],


[I-D.chown-v6ops-renumber-thinkabout] and [RFC419=
2]." but the references
to these documents are informative.  I=
f the document is meant to be an extension,
rather than a replacement, s=
uch that these documents must be read to get the full

picture, than a normative reference may be better=
.


 

[Bing] These documents are i=
mportant input for the gap analysis draft. They indeed have not a few cross=
ed content, but our intention on the gap draft was different, so it is neit=
her extension nor replacement.


RFC5887&draft-thinkabout=
 are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4=
192 emphasizes on a “make before break” prefix switching operat=
ion.


This gap draft  address=
es the IPv6 enterprise scenarios described in RFC6879, and focusing on iden=
tifying what is missing to make renum more automatic and less error-prone.<=
o:p>




For the session survivability section, a =
reference to RFC 6724 may be useful, so 
that those adding new global ad=
dresses understand how the application API to determine

<=
/span>


which address is used with interact with the addi=
tion of new addresses (if there
is a specific draft or other treatment o=
f that topic, that would be even better,
but I am not personally aware o=
f one).


 

[Bing] OK. Address selection=
 is indeed important. 




In section 6, the document currently says=
:




   When nodes in a site have been r=
enumbered, then all the entries in


   the site which contain the nodes' ad=
dresses must be updated. The


   entries mainly include DNS records a=
nd filters in various entities


   such as ACLs in firewalls/gateways.<=
br>
This appears to imply that these updates must take place after the r=
enumbering
event, but this is variable.  ACLs and filters may well =
be updated in advance;
DNS may be updated concurrently or post facto.&nb=
sp; A rewording to highlight that 


this is variable by record type may be useful.


 

[Bing] Ok, thanks.

Section 9.2, in the bullet entitled "DNS dat=
a structure optimization"
The discusses a DNS feature proposed but =
declared historic. I don't think it


identifies the related renumbering gap in a way t=
hat is useful for a naive 
reader.  If it cannot be reworded to foc=
us on the gap, I suggest it be
removed.



[Bing] When we wrote the dra=
ft, we considered if the IPv6 DNS record could be structured as separating =
prefix and suffix, that would be very helpful for renumbering. Because in I=
Pv6, most of the time we just change the prefixes rather than the whole add=
resses.


We found A6 has the similar =
feature, but it has been moved to historic. However,  the idea of sepa=
rating prefix and suffix is still considered valuable, but there might not =
 be able to develop a new DNS record in a short time, so we name the i=
dea as “DNS data structure optimization” and put it into “=
;gaps considered unsolvable”.


We can add some minor texts =
to explain the intention.



In section 9.4, the document says:

&nb=
sp;     For application layer, as [RFC5887] said, in ge=
neral, we can


      assert that any im=
plementation is at risk from renumbering if it


      does not check tha=
t an address is valid each time it opens a new


      communications ses=
sion.

This might be reworded to  include or focus on session re=
sumption, rather than 
new communications sessions.  From an applic=
ations perspective, the laptop
"sleep" function seems to be on=
e of the bigger risks of this.  



[Bing] Ok, thanks.



Nit:

For me personally, section 6.1 se=
emed needlessly pessimistic. 


[Bing] It is sad but true. A=
nd we are curious about how much operational issues there to prevent DDNS w=
idely deployed in real networks.


If possible, we might consid=
er to make a dedicated draft to talk about this issue in the future. <=
/o:p>


 
--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_--