From rcallon@juniper.net Fri Oct 1 09:50:34 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434B03A6AED for ; Fri, 1 Oct 2010 09:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoJn6BrDGwjH for ; Fri, 1 Oct 2010 09:50:18 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 783DD3A6BE4 for ; Fri, 1 Oct 2010 09:50:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTKYRdMhP8/JBTnUBnPibBUeBddN/KsIG@postini.com; Fri, 01 Oct 2010 09:51:06 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Oct 2010 09:49:53 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 1 Oct 2010 12:49:52 -0400 From: Ross Callon To: Juliusz Chroboczek , Adrian Farrel , Stewart Bryant Date: Fri, 1 Oct 2010 12:49:47 -0400 Thread-Topic: Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 Thread-Index: ActhiKhPpCdHb4aOSU68LFrGNjpG6A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A9D97B979EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" Subject: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:50:34 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A9D97B979EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello. I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other comments tha= t you receive, and strive to resolve them through discussion or by updating= the draft. Document: draft-chroboczek-babel-routing-protocol-04 Reviewer: Ross Callon Review Date: October 1, 2010 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: This is a very interesting document which describes an experimental protoco= l with interesting capabilities. Given the complexity of a routing protocol= , this is well written and relatively easy to understand. It is appropriate that this is experimental. It is not clear to me why the = world needs another routing protocol, although experiments can be useful. T= here are a number of SHOULD's in the document which are entirely appropriat= e as SHOULD's for an experimental protocol, but which IMHO would want to be= come either MUST's or be removed for a standards track document. I believe that this document should have the standard warning that it is no= t a product of the IETF and is not a candidate for standardization at any l= evel. Major Issues: None. Minor Issues: - General: It might be worth mentioning somewhere that loop-free routing do= es not strictly speaking ensure that one or more individual data packets wo= n't visit the same node twice (which some might think of as a loop). For ex= ample, suppose that routing could respond infinitely fast and always took t= he shortest path to the destination. Suppose furthermore that the entire ne= twork consisted of four nodes (A, B, C, D), and four links (A-B, B-C, C-D, = and A-D). Suppose that node A has a packet destined for node C, and selects= the path via B for a particular data packet (therefore forwarding the data= packet from A to B). As the packet arrives at B, the link B-C fails. In th= is case since routing is instant and always correct, node B knows to forwar= d the packet back to A, and A then knows to forward it to D (which forwards= it to C). Thus while routing was perfect and never had a network-wide set = of forwarding tables that created a loop, packets may still travel on a pat= h, during network changes, that some might call a loop. Similarly, with the Babel protocol, if a node prefers an update with a long= er distance but newer sequence number (apparently true as explained in 3.5.= 1), then a similar issue could occur even in the absence of topology change= s when a node originates an update with a new (larger) sequence number, if = the update propagates much more quickly on some paths than on others (for e= xample, due to one node which propagates routing updates very slowly, but w= hich is on the shortest path from some points in the network to the node or= iginating the update). In this case if the routing updates propagate faster= than packets are forwarded (possible with large packets over small links i= f the routers give preference to routing updates - for example under the pr= inciple that there isn't much point in forwarding a packet if it is going i= n the wrong direction), then some packets might start off following the sho= rtest path, then an update with a newer sequence number but following a lon= ger path might overtake the packets causing them to be routed over the diff= erent longer path, then the update following the shortest path might overta= ke the packets causing them to return to the original shortest path. If we = assume that the periodicity of sequence number changes is much slower than = the time required to deliver a data packet, then any such looping will be b= rief and transitory (and the packets will be delivered after a short loop, = assuming TTL doesn't expire). - Section 1.1, first paragraph: I don't think that the Babel routing protoc= ol is "black hole" free, at least if you define "black hole" as a router in= a network that has no route, for some period of time, to a particular dest= ination. I do understand that black holes will not persist indefinitely. Sp= ecifically, you describe events where a node notices that it has no feasibl= e route to a particular destination. Isn't this the definition of "black ho= le"? I do understand that at this point it will *try* to send an explicit r= equest to the source for a new sequence number -- and that somewhere in the= network will be a router which is able to send the explicit request. Howev= er, it will take some time for the request to arrive and for the route anno= uncement (with updated sequence number) to propagate back to the node that = was without a feasible route. Doesn't this mean that black holes will not p= ersist indefinitely, but can occur for some period of time? I do also under= stand that you avoid counting to infinity, which is of course a very good t= hing to avoid (and which makes possible the "fairly arbitrary metrics" whic= h you are able to use). - Section 1.1, third bullet item (that reads "any routing black-holes that = may appear after a mobility event are corrected in a time at most proportio= nal to the network's diameter."). I think that this is true *unless* the se= t of one or more "explicit requests to the source for a new sequence number= " (described in 2.6) are all lost. Given that the requests should be repeat= ed if an update with a new sequence number doesn't show up, this seems to b= e as close to reliable delivery as you can get in this case (since there co= uld be many nodes which are requesting the updated sequence number at the s= ame time, and there might be no reverse path other than flooding available = for many or most of them - eg due to same failure which causes the infeasib= ility event). However, if they all happen to be lost, then you might need t= o wait for a timeout at the source of the route advertisement to cause the = new sequence number to occur. - Section 1.2: Under "limitations", you could mention that since Babel is a= distance vector routing protocol it does not provide each router with a fu= ll map of the topology. This prevents it from being applicable in certain t= raffic engineering applications (reference OSPF-TE and IS-IS-TE) and potent= ially in PCE applications. - Section 2.6, second paragraph: "When a node detects that it is suffering = from a potentially spurious starvation, it sends an explicit request to the= source for a new sequence number". It is probably worth mentioning that in= general for some or even many nodes there will be no way to route the expl= icit request back to the source, but that for each possible failure there w= ill be at least one (and possibly more) nodes that experience spurious star= vation but nonetheless have a (non-feasible but shortest available) route t= hat will work to route a packet back to the source. I can see that it is un= desirable to attempt to send this packet reliably, since many of the packet= s won't be routable, and probably more importantly because the same failure= might cause routing in the backward direction to be similarly temporarily = disrupted. However, this has the unfortunate effect that the explicit reque= sts are not sent reliably, and at least in principle might be lost. This im= plies that in some cases "black holes" may exist for as long as it takes fo= r a node to originate a routing update with an updated sequence number on i= ts own based on timeout. These explicit requests might therefore want to be= given high priority. I see in a later section that the requests SHOULD be = repeated if there is no routing updated with an updated sequence number for= a period of time. You might want to say this briefly (one sentence) here i= n 2.6. Alternately 2.6 might just want to contain a forward reference to 3.= 8. - Section 3.2.1 mentions that sequence numbers are incremented whenever a n= ode receives a request for a new sequence number. Given that these requests= are not sent reliably, it is probably a good idea for the node to also upd= ate its sequence number periodically, and to mention this in this section. = (Assuming that sequence numbers already area updated periodically based on = timeout, this becomes an editorial comment.) - In section 3.2.6 you talk about the table of pending segno requests. I ap= ologize if I am just being slow but when first reading this I managed to lo= se context of what this table is for. After finishing the paper, I think th= at this section relates to forwarding the explicit requests for a node to i= ncrease its sequence number. However, if this is the case I don't understan= d the triplet (neigh, seqno, neighbour). First of all what is "neigh" and w= hat is "neighbor". Secondly, shouldn't the node or prefix for which we are = requesting an updated sequence number be included in this somewhere? Some m= ore explanation seems to be needed for this section. - Section 3.7.4: "Since Babel does not suffer from routing loops, split hor= izon with poison reverse SHOULD NOT be used." I am not sure that anyone (ot= her than I) remembers this, but I was the one who originally came up with t= he idea of poison reverse (which I just blurted out at a RIP WG meeting, an= d then later regretted that I hadn't patented the idea first). The reason f= or poison reverse with RIP is that there was previously no way to withdraw = a route, and thus the only way to say that a route had gone away was to sim= ply not advertise it, and wait for it to timeout from your neighbors. This = was of course horridly slow. Poison reverse is therefore simply the equival= ent to your route withdrawal. As such this sentence doesn't seem to make mu= ch sense. Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as you explain= in the introduction). Perhaps "nearly loop-free" might be more precise. (t= he same issue applies to the first sentence of section 2). - Section 1.1, first sentence: Later on you explain situations where there = could be very short-lived loops or black holes (at least by my understandin= g of the term "black hole"). Thus perhaps rather than "it does not cause ro= uting pathologies such as" you might say "it strongly limits the duration o= f routing pathologies such as". - Section 1.2, first paragraph, last sentence, you probably should include = IS-IS in the list of other routing protocols. - Very minor, section 2.4, I am pretty sure that "parametrised" is misspell= ed. I think that it should be either "parameterised" or "parameterized" (-i= ze in US use, and apparently either -ise or -ize in England and other Engli= sh speaking countries depending upon which country and which dictionary you= use). - In section 2.5 you introduce the notion of sequence numbers, so that an u= pdate is feasible if either the sequence number is larger (newer), or the d= istance from the next hop to the destination (originator of the update) is = less than the previous distance from here to the destination. Do you actual= ly prefer routes with a newer sequence number to an older route, or do you = prefer routes with smaller distances to the destination, and use the sequen= ce number only to determine feasibility? I didn't quite figure this out unt= il section 3.5.1 (where I discovered that my original expectation is right)= . You might want to briefly clarify this in section 2.5. - Section 3.5.2, "gove" should be "give" Note: - You are entirely correct in your use of MUST, SHOULD, etc notation, and i= t is interpreted in accordance to the status of the document. Thus, if anyo= ne claims that they implement your protocol, then they must do the things t= hat you list as MUST. However, since this is (appropriately) an experimenta= l protocol, no one is required to implement it. For some reason the issue o= f using MUST, ... in non-standards track document keeps coming up, but you = are correct in doing so. --_000_DF7F294AF4153D498141CBEFADB177049A9D97B979EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello.
I have been selected a= s the Routing Directorate reviewer for this draft. The Routing Directorate = seeks to review all routing or routing-related drafts as they pass through = IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more= information about the Routing Directorate, please see http://www.ie= tf.org/iesg/directorate/routing.html
Although these comment= s are primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other comments that you receive, and str= ive to resolve them through discussion or by updating the draft.
Document: draft-chrobo= czek-babel-routing-protocol-04
Reviewer: Ross Callon
Review Date: October 1, 2010
Intended Status: Experimental
Summary:
I have some minor conc= erns about this document that I think should be resolved before publication= .
Comments:
This is a very interes= ting document which describes an experimental protocol with interesting cap= abilities. Given the complexity of a routing protocol, this is well written= and relatively easy to understand.
It is appropriate that this is experimental. It is not clear to me why= the world needs another routing protocol, although experiments can be usef= ul. There are a number of SHOULD’s in the document which are entirely= appropriate as SHOULD’s for an experimental protocol, but which IMHO would want to become either MUST’s or be rem= oved for a standards track document.
 
I believe that this document should have the standard warning that it = is not a product of the IETF and is not a candidate for standardization at = any level.
Major Issues:
None.
Minor Issues:
- General: It might be worth mentioning somewhere that loop-free routi= ng does not strictly speaking ensure that one or more individual data packe= ts won’t visit the same node twice (which some might think of as a lo= op). For example, suppose that routing could respond infinitely fast and always took the shortest path to the dest= ination. Suppose furthermore that the entire network consisted of four node= s (A, B, C, D), and four links (A-B, B-C, C-D, and A-D). Suppose that node = A has a packet destined for node C, and selects the path via B for a particular data packet (therefore forwa= rding the data packet from A to B). As the packet arrives at B, the link B-= C fails. In this case since routing is instant and always correct, node B k= nows to forward the packet back to A, and A then knows to forward it to D (which forwards it to C). Thus wh= ile routing was perfect and never had a network-wide set of forwarding tabl= es that created a loop, packets may still travel on a path, during network = changes, that some might call a loop.
 
Similarly, with the Babel protocol, if a node prefers an update with a= longer distance but newer sequence number (apparently true as explained in= 3.5.1), then a similar issue could occur even in the absence of topology c= hanges when a node originates an update with a new (larger) sequence number, if the update propagates much m= ore quickly on some paths than on others (for example, due to one node whic= h propagates routing updates very slowly, but which is on the shortest path= from some points in the network to the node originating the update). In this case if the routing updates pr= opagate faster than packets are forwarded (possible with large packets over= small links if the routers give preference to routing updates – for = example under the principle that there isn’t much point in forwarding a packet if it is going in the wrong d= irection), then some packets might start off following the shortest path, t= hen an update with a newer sequence number but following a longer path migh= t overtake the packets causing them to be routed over the different longer path, then the update following the sho= rtest path might overtake the packets causing them to return to the origina= l shortest path. If we assume that the periodicity of sequence number chang= es is much slower than the time required to deliver a data packet, then any such looping will be brief and = transitory (and the packets will be delivered after a short loop, assuming = TTL doesn’t expire).
 
- Section 1.1, first paragraph: I don’t think that the Babel rou= ting protocol is “black hole” free, at least if you define R= 20;black hole” as a router in a network that has no route, for some p= eriod of time, to a particular destination. I do understand that black holes will not persist indefinitely. Specifically, you describe event= s where a node notices that it has no feasible route to a particular destin= ation. Isn’t this the definition of “black hole”? I do un= derstand that at this point it will *try* to send an explicit request to the source for a new sequence number -- and that som= ewhere in the network will be a router which is able to send the explicit r= equest. However, it will take some time for the request to arrive and for t= he route announcement (with updated sequence number) to propagate back to the node that was without a feasible = route. Doesn’t this mean that black holes will not persist indefinite= ly, but can occur for some period of time? I do also understand that you av= oid counting to infinity, which is of course a very good thing to avoid (and which makes possible the “fair= ly arbitrary metrics” which you are able to use).
 
- Section 1.1, third bullet item (that reads “any routing black-= holes that may appear after a mobility event are corrected in a time at mos= t proportional to the network's diameter.”). I think that this is tru= e *unless* the set of one or more “explicit requests to the source for a new sequence number” (described in 2.6) = are all lost. Given that the requests should be repeated if an update with = a new sequence number doesn’t show up, this seems to be as close to r= eliable delivery as you can get in this case (since there could be many nodes which are requesting the updated sequence = number at the same time, and there might be no reverse path other than floo= ding available for many or most of them – eg due to same failure whic= h causes the infeasibility event). However, if they all happen to be lost, then you might need to wait for a timeout at= the source of the route advertisement to cause the new sequence number to = occur. 
 
- Section 1.2: Under “limitations”, you could mention that= since Babel is a distance vector routing protocol it does not provide each= router with a full map of the topology. This prevents it from being applic= able in certain traffic engineering applications (reference OSPF-TE and IS-IS-TE) and potentially in PCE applications.
 
- Section 2.6, second paragraph: “When a node detects that it is= suffering from a potentially spurious starvation, it sends an explicit req= uest to the source for a new sequence number”. It is probably worth m= entioning that in general for some or even many nodes there will be no way to route the explicit request back to the source= , but that for each possible failure there will be at least one (and possib= ly more) nodes that experience spurious starvation but nonetheless have a (= non-feasible but shortest available) route that will work to route a packet back to the source. I can see that i= t is undesirable to attempt to send this packet reliably, since many of the= packets won’t be routable, and probably more importantly because the= same failure might cause routing in the backward direction to be similarly temporarily disrupted. However, this has= the unfortunate effect that the explicit requests are not sent reliably, a= nd at least in principle might be lost. This implies that in some cases = 220;black holes” may exist for as long as it takes for a node to originate a routing update with an updated sequen= ce number on its own based on timeout. These explicit requests might theref= ore want to be given high priority. I see in a later section that the reque= sts SHOULD be repeated if there is no routing updated with an updated sequence number for a period of time.= You might want to say this briefly (one sentence) here in 2.6. Alternately= 2.6 might just want to contain a forward reference to 3.8.
 
- Section 3.2.1 mentions that sequence numbers are incremented wheneve= r a node receives a request for a new sequence number. Given that these req= uests are not sent reliably, it is probably a good idea for the node to als= o update its sequence number periodically, and to mention this in this section. (Assuming that sequence numbers alread= y area updated periodically based on timeout, this becomes an editorial com= ment.)
 
- In section 3.2.6 you talk about the table of pending segno requests.= I apologize if I am just being slow but when first reading this I managed = to lose context of what this table is for. After finishing the paper, I thi= nk that this section relates to forwarding the explicit requests for a node to increase its sequence number= . However, if this is the case I don’t understand the triplet (neigh,= seqno, neighbour). First of all what is “neigh” and what is &#= 8220;neighbor”. Secondly, shouldn’t the node or prefix for which we are requesting an updated sequence number be included in this some= where? Some more explanation seems to be needed for this section.
 
- Section 3.7.4: “Since Babel does not suffer from routing loops= , split horizon with poison reverse SHOULD NOT be used.” I am not sur= e that anyone (other than I) remembers this, but I was the one who original= ly came up with the idea of poison reverse (which I just blurted out at a RIP WG meeting, and then later regretted that I had= n’t patented the idea first). The reason for poison reverse with RIP = is that there was previously no way to withdraw a route, and thus the only = way to say that a route had gone away was to simply not advertise it, and wait for it to timeout from your neighb= ors. This was of course horridly slow. Poison reverse is therefore simply t= he equivalent to your route withdrawal. As such this sentence doesn’t= seem to make much sense.
Nits:
- Abstract: Strictly speaking, Babel is not quite loop-free (as you ex= plain in the introduction). Perhaps “nearly loop-free” might be= more precise. (the same issue applies to the first sentence of section 2).=
 
- Section 1.1, first sentence: Later on you explain situations where t= here could be very short-lived loops or black holes (at least by my underst= anding of the term “black hole”). Thus perhaps rather than R= 20;it does not cause routing pathologies such as” you might say “it strongly limits the duration of routing pathologies= such as”.
 
- Section 1.2, first paragraph, last sentence, you probably should inc= lude IS-IS in the list of other routing protocols.
 
- Very minor, section 2.4, I am pretty sure that “parametrised&#= 8221; is misspelled. I think that it should be either “parameterised&= #8221; or “parameterized” (-ize in US use, and apparently eithe= r -ise or -ize in England and other English speaking countries depending upon which country and which dictionary you use).
 
- In section 2.5 you introduce the notion of sequence numbers, so that= an update is feasible if either the sequence number is larger (newer), or = the distance from the next hop to the destination (originator of the update= ) is less than the previous distance from here to the destination. Do you actually prefer routes with a newer se= quence number to an older route, or do you prefer routes with smaller dista= nces to the destination, and use the sequence number only to determine feas= ibility? I didn’t quite figure this out until section 3.5.1 (where I discovered that my original expectation is= right). You might want to briefly clarify this in section 2.5. 
 
- Section 3.5.2, “gove” should be “give”
Note:
- You are entirely correct in your use of MUST, SHOULD, etc notation, = and it is interpreted in accordance to the status of the document. Thus, if= anyone claims that they implement your protocol, then they must do the thi= ngs that you list as MUST. However, since this is (appropriately) an experimental protocol, no one is required = to implement it. For some reason the issue of using MUST, ... in non-standa= rds track document keeps coming up, but you are correct in doing so.
 
 
 --_000_DF7F294AF4153D498141CBEFADB177049A9D97B979EMBX01WFjnprn_-- From enkechen@cisco.com Fri Oct 1 14:29:03 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DA13A6BDD for ; Fri, 1 Oct 2010 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmkwBqI5uMvn for ; Fri, 1 Oct 2010 14:29:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D70353A6BB0 for ; Fri, 1 Oct 2010 14:29:02 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,268,1283731200"; d="scan'208";a="282465174" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Oct 2010 21:29:52 +0000 Received: from dhcp-171-71-139-120.cisco.com (dhcp-171-71-139-120.cisco.com [171.71.139.120]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o91LTpdT003864; Fri, 1 Oct 2010 21:29:52 GMT Message-ID: <4CA652CF.7000507@cisco.com> Date: Fri, 01 Oct 2010 14:29:51 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.12) Gecko/20100824 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org, Enke Chen Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:29:03 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt Reviewer: Enke Chen Review Date: 27 October 2010 IETF LC End Date: 27 October 2010 Intended Status: Informational Summary: In general the goals and the requirements for the "BGP graceful shutdown" are clearly stated. I have some comments, though, that I think should be addressed before publication. Comments: The document is about the requirements for "BGP graceful shutdown". It is an interesting, and relatively new topic, and the requirements are clearly stated. However, in the document there are occasional (or scattered) mentions of "BGP graceful bringup", which seems confusing and unnecessary. Major Issues: I suggest that "BGP graceful bringup" related text be either removed from the document for the following reasons: - To reduce packet loss during BGP bringup, several techniques have been developed and are well known, including setting the "overload bit" in IS-IS, and using large metrics in OSPF; and also also postponing the bringup of external links until the IGPs and IBGPs have converged. - When a primary path is added (such as in the case of BGP bringup), routing needs to reconverge. IMO there is not much more that can be done or needs to be done than what is already known. - It is not clear from the document if there is a new requirement. Minor Issues: 1) Section 2, Introduction The draft says: Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any operation to gracefully withdraw a prefix while traffic toward that prefix could still be correctly forwarded. When a BGP session is taken down, BGP behaves as if it was a sudden link or router failure and withdraws the prefixes learnt over that session, which may trigger traffic loss. There is no mechanism to advertise to its BGP peers that the prefix will soon be unreachable, while still being reachable. When applicable, such mechanism would reduce or prevent traffic loss. This paragraph seems to suggest a particular enhancement ("graceful prefix withdraw") in the protocol might be needed. This is a bit misleading, and may not be the intention. First, such an enhancement is not really required as there are a number of parameters (in particular LOCAL-PREF) in BGP that can be used to influence the degree of preference in route selection, and thus influence the traffic flow. Second, this is a requirement document, and is not about a specific solution to satisfy the requirement. So I suggest that the text be removed, or expanded to include the possible re-use of existing protocol machinery. -------------------------------------------------- -- Enke From ginsberg@cisco.com Mon Oct 4 11:08:41 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8883A6FE8 for ; Mon, 4 Oct 2010 11:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHTUf8EyCJXh for ; Mon, 4 Oct 2010 11:08:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6406B3A6FFF for ; Mon, 4 Oct 2010 11:08:39 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,279,1283731200"; d="scan'208";a="367859157" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2010 18:09:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o94I9ZCU005298; Mon, 4 Oct 2010 18:09:35 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 11:09:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AIzu BdWd HYBa H0xW H42z KWTK K51o LqzN N5A3 TRY+ ULUQ WCWA XDaB ccHZ dFpL iqiz; 3; bgBhAGIAaQBsAC4AbgAuAGIAaQB0AGEAcgBAAHYAZQByAGkAegBvAG4ALgBjAG8AbQA7AHIAdABnAC0AYQBkAHMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwByAHQAZwAtAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {67EADB83-B017-41FC-BD8A-F8D1909463E4}; ZwBpAG4AcwBiAGUAcgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 04 Oct 2010 18:09:26 GMT; UgBFADoAIABSAHQAZwBEAGkAcgAgAHIAZQB2AGkAZQB3ADoAIAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHMAaQBzAC0AZwBlAG4AYQBwAHAALQAwADMALgB0AHgAdAA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {67EADB83-B017-41FC-BD8A-F8D1909463E4} Content-class: urn:content-classes:message Date: Mon, 4 Oct 2010 11:09:26 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-isis-genapp-03.txt Thread-Index: ActjxLdJnTz0+Poxg0qS2bHaCGT0VQAHYhhA References: From: "Les Ginsberg (ginsberg)" To: "Bitar, Nabil N" , , "Stefano Previdi (sprevidi)" , "Mike Shand (mshand)" X-OriginalArrivalTime: 04 Oct 2010 18:09:35.0338 (UTC) FILETIME=[4D2DECA0:01CB63EF] X-Mailman-Approved-At: Tue, 05 Oct 2010 04:26:32 -0700 Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-genapp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:08:41 -0000 Nabil - Thanx for the detailed review. Responses inline. > -----Original Message----- > From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com] > Sent: Monday, October 04, 2010 7:32 AM > To: rtg-ads@tools.ietf.org; Les Ginsberg (ginsberg); Stefano Previdi > (sprevidi); Mike Shand (mshand) > Cc: rtg-dir@ietf.org; > Subject: RtgDir review: draft-ietf-isis-genapp-03.txt >=20 >=20 > Hi, >=20 > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or routing- > related drafts as they pass through IETF last call and IESG review. The > purpose of the review is to provide assistance to the Routing ADs. For > more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html >=20 > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. >=20 > Document: draft-ietf-isis-genapp-03.txt >=20 > Reviewer: Nabil Bitar > Review Date: October, 03, 2010 > IETF LC End Date: date-if-known > Intended Status: Standards >=20 > Summary: >=20 >=20 > I have some minor concerns about this document that I think should be > resolved before publication. >=20 > Comments: >=20 > This draft describes a mechanism that enables advertisement of generic > information, and specifically application support and associated > attributes, by a router via IS-IS. The document is generally well- > written, but some clarifying text and re-ordering of text will improve > completeness and readability as noted in this review. The major area > that needs clarification is related to section 4.3 and the processing > of different GENINFO information with same GENINFO Context (GENINFO- > CTX) at a receiving node. > In general, There are interesting applications that can take advantage > of the capability introduced in this document. However, it will help > the reader if an example or examples of applications that can make use > of this capability are covered in the Overview section for instance. > The authors may have applications in mind. An example of such > applications can be the support for a Path Computation Element on a > router, or the support for an Application Layer Transport Optimization > (ALTO) server. The authors can choose these examples, if they believe > they are applicable or other examples. The introduction of GENAPP is a begrudging acceptance of the fact that there have been requests to use the reliable flooding mechanism of the IGPs (IS-IS in this case) to send information which is not used by the protocol in support of routing. The authors in fact would have preferred that this not be necessary - and don't really want to encourage this usage - which is one of the reasons we did not provide an example. Instead we focused on the correct way to use this extension. PCE - as defined in RFC 5089 - uses the the router capability TLV as it was defined BEFORE GENAPP existed. I agree it would have been a good use case for GENAPP had GENAPP been defined at the time - and in fact PCE was one of the reasons we decided to invent GENAPP before other use cases come along. To my knowledge ALTO has no requirement for using GENAPP. >=20 > Major Issues: >=20 > - Section 4.3 > In the first paragraph first sentence, you state: "Where a receiving > system has two copies of a GENINFO TLV with the same GENINFO-CTX, > attribute information in the two TLVs which does not conflict MUST be > considered additive.". Additive in the sense that you take the union of > the two, right? Correct. > In addition, the last sentence leaves the behavior undefined when > processing received GENINFO with same GENFO-CTX. This is a concern, This is deliberate. There is no way to reliably determine which information is newer in such cases. >=20 > This section is not clear and the processing rules need to be > tightened, as based on the description you are not disambiguating what > information is valid or not (stale). It seems to me that processing > rules based on GENINFO-CTX, flooding scope, encapsulating LSP lifetime, > encapsulating PDU type, and the level of the receiving node taken > together should provide a better way for processing rules. I request > that this section be revisited and the processing rules be better > developed and articulated. There are no changes to the normal operation of the IS-IS Update process which is defined in ISO 10589. That specification covers the issues you raise (lifetime, PDU type, level, etc.). Any attempt to discuss them here would be ill-advised as it would suggest that we have somehow changed them for GENAPP - which is NOT true. >=20 >=20 > Minor Issues: >=20 > -Abstract: " This draft describes the manner in which generic > application information (i.e. information not directly related to the > operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and > defines guidelines which SHOULD be used when flooding such > information." >=20 > (1) The first SHOULD is justified as other mechanisms could be used but > this is a recommendation to use the mechanism defined in this document. > However, I think the second SHOULD needs to be replaced by MUST as > relayed in the later parts of the document, and specifically in the > flooding section and leaking section. Alternatively, you may say: ... > and defines guidelines for flooding and leaking such information. SHOULD is used here because we recognize that many of the guidelines defined in the document are unenforceable i.e. as the advertisement of new TLV information does not introduce interoperability issues a vendor may choose (for example) to advertise GENAPP in instance 0 - despite our strong recommendations not to do so. >=20 > (2) In addition, What is defined in this document has implication on > the operations of IS-IS protocol, albeit it does not impact IS-IS for > the purpose of IP routing. Therefore, I suggest the following change: > (i.e. information not directly related to the operation of the IS-IS > protocol) --> (i.e., information that does not relate to IGP routing > table computation or IP network > topology and traffic Engineering information dissemination and > discovery). The manner of defining what information qualifies for GENAPP and what does not received considerable scrutiny during the WG review. Traffic engineering information in particular was a point of discussion. Had GENAPP existed when TE requirements were defined it may well have been the case that GENAPP could have been used to advertise TE information. In Section 6 we state: "The applicability statement above is expected to cover some information currently being advertised by IS-IS in previously defined TLVs." Rather than specifically call out TE as something which is NOT applicable to GENAPP we have deliberately left the door open to allow TE to be moved to GENAPP if there is consensus to do so. Note that we do not expect this to happen - nor are we advocating that it should happen - but it should not be ruled out as a possible alternative. >=20 > - Section 2 (Overview): >=20 > (1) I suggest adding text in this section for example applications > that can take advantage of the capability introduced in this document > as a use case. Such text will give better context to the reader. Often, > such examples/uses cases are found in requirements documents that > define the reason a problem needs to be solved, but in the absence of > that it would be useful to have a synopsis of that in this section. > Candidate examples are mentioned earlier. >=20 > (2) second paragraph, I suggest adding the word "processing" to the > text so that it reads as follows: This document also discusses optimal > behavior associated with the > advertisement, processing, and flooding of LSPs containing GENINFO > ...... OK >=20 > (3) Last paragraph, having the GENINFO advertisement in a non-zero iIS- > IS instance should be recommended but not mandated. Accordingly, I > suggest changing MUST to SHOULD as follows: "In order to minimize the > impact advertisement of GENINFO may have on the operation of routing, > such advertisements MUST occur in the context of a non-zero instance of > the IS-IS protocol as defined in [I-D.ietf-isis-mi]." --> In order to > minimize the impact advertisement of GENINFO may have on the operation > of routing, such advertisements SHOULD occur in the context of a non- > zero instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi]. Our choice of wording here was deliberate. We want to mandate the use of a non-zero instance. If an exception to this policy is needed it would need to be reviewed - which is what we state. >=20 > - Section 3.1 >=20 > (1) I suggested adding "IS-IS" as noted in the following, starting on > page 4: > "S bit (0x01): If the S bit is set(1), the GENINFO TLV MUST be flooded > across the entire routing domain. If the S bit is not set(0), the TLV > MUST NOT be leaked between levels. This bit MUST NOT be altered during > the TLV leaking." --> S bit (0x01): If the S bit is set(1), the GENINFO > TLV MUST be flooded across the entire IS-IS routing domain, across IS- > IS levels/area. If the S bit is not set(0), the TLV MUST NOT be leaked > between IS-IS levels/areas. This bit MUST NOT be altered during the TLV > leaking. I do not object to this change - but it seems unnecessary as clearly the IS-IS Update process can only operate on areas/domain known to IS-IS. >=20 > (2) GENINFO-REG acronym is used for the first time without definition > in the definition of Application ID: "Application ID An identifier > assigned to this application via the GENINFO-REG." It can be defined > earlier where you talk about establishing a new registry for > application IDs. Yes - this point has been made by another reviewer in a more general way and I agree this should be done. >=20 > (3) Question: for IP addresses associated with an application, wouldn't > it be better if the application has an IPv4 and an IPv6 address > associated with it to be able to advertise that in the same TLV when > the other attributes do not change between the two. That can be > achieved by allowing the "I" and "V" bits to be simultaneously set in > the flag, and mandating for instance that when the I and V bits are > set, the first IP address following the flag will be an IPv4 address > followed by an IPv6 address. What is your current procedure in this > case? Is it to have one GENINFO TLV with the same application ID for > IPv4 and another for IPv6? Use of both an IPv4 and an IPv6 address in a single TLV is allowed. In such a case the IPv4 address would occur first in the TLV followed by the IPv6 address. This is stated in Section 3.1 in the description of the V bit: " V bit (0x08): When the V bit is set, the 16 octet IPv6 address associated with the application immediately follows either the Application ID (if I bit is clear) or the IPv4 address (if I bit is set)." > In addition, it would be good to include a > sentence here stating that how the IP address associated with an > application ID is generated will be application dependent and specified > in the a respective application-specific document that makes use of > this mechanism. We do state: " The IPv4[IPv6] address associated with the application. This is not necessarily an address of a router running the IS-IS protocol." This clearly leaves the manner in which the address is chosen to be outside the scope of this document. >=20 > (4) Under "Additional Application Specific Information" definition, > shouldn't TLV be sub-TLV in the following: "Each application may define > additional information to > be encoded in a GENINFO TLV following the fixed > information." That is, change GENINFO TLV to GENINFO sub-TLV. We allow that an application MAY choose to encode additional information directly after the fixed information defined in the document without using sub-TLVs - so the current wording is correct. >=20 > - Section 3.2 >=20 > (1) 4th paragraph first sentence. I suggest the following change or > similar rewording for clarity: "The use of additional levels of subTLVs > is discouraged due to the > inherent inefficiency in encoding introduced because the parent > subTLV must encode the nested subTLV length." ---> Nested sub-TLVs > introduce encoding inefficiency due to the fact that the parent TLV > and parent sub-TLV must account for the length of nested sub-TLVs in > each context. >=20 > (2) Can you please explain what you mean in the following sentence. It > is not clear to me what you mean by the "one additional octet" as the > length is accounted in the parent TLV/sub-TLV length value. "While > this inefficiency is small (one additional octet), it may be > sufficient to extend the total information about a single application > object beyond the > carrying capacity of a single GENINFO TLV. " I agree that the current text is both inaccurate and confusing. I suggest that the first two sentences be rewritten as follows: "The use of additional levels of subTLVs is discouraged due to the inherent inefficiency in encoding introduced when the parent subTLV is used solely to scope the set of sub-TLVs it contains. While this inefficiency is small (two additional octets),..." >=20 > - Section 3.3 >=20 > This section refers to public documents in the first and last > paragraph. Public document is a very broad reference. What form of a > public document? An IETF draft/RFC, a specification generated by > another standard body maybe after liaising with IETF (or not)? Document > published by a vendor that can appliy for an application ID from IANA > as stated earlier? Or anything that is made public?. I am not sure why > this should be referenced here. If something is done by a vendor for > instance or an application developer but not by a standard body, it is > categorically proprietary or vendor-specific although it is publically > made available. Is the assumption that applications can come from other > standards bodies as well? Are there restrictions or obligations? For > instance, does assigning an application ID require review by IETF as it > is carried by IS-IS? > This section requires clarification. Your clarification is appreciated > as to the intention(s). The forum in which the document used to define the application is beyond the scope of this draft. However, we do make two very important stipulations: 1)In Section 3.3 we require that there be a public document. We specifically do NOT allow proprietary/experimental use of GENAPP. 2)In Section 8 we stipulate "Specification Required" as defined in RFC 5226. >=20 > - Section 3 overall: >=20 > Some procedural description that relates to the generation of GENINFO > TLVs is missing from this section. In particular, it seems to me that > to complete this section, you should explicitly state that one or more > GENINFO TLVs can appear in each LSP (it does not come out explicitly). > In addition, what makes a GENINFO TLV unique is the GENINFO-CTX defined > by the application ID and associated IP address. Thus, GENINFO TLVs > that share the same GENINFO-CTX with the same flooding scope (in a way, > it seems to make sense if the flooding scope is part of the GENINFO > context definition) are comparable in terms of generating updates, > comparing attributes, and/or determining what is more current. I > suggest that some of the text in the first two sentences of the second > paragraph under section 4 be pulled within section 3 under a separate > subsection titled "Rules for GENINFO encoding" and have the section of > title 3 changed to "GENINFO encoding". Section 3 discusses the format of the information within a given TLV. Section 4 discusses issues associated with flooding/leaking encoded information. I don't think mixing these two types of information in a single section (even partially) would aid clarity. I would be happy to add the following to Section 3.1: "GENINFO TLVs may appear in any LSP and multiple GENINFO TLVs may appear in the same LSP." >=20 > - Section 4.1 > First paragraph, it should state clearly what is being compared to > determine duplication or more recent update. In particular, as stated > in an earlier comment, it seems to me that you can compare two GENINFO > TLVs for duplication or currency when they share the same context and > flooding scope. Would you agree? If you do, that should be spelled > out. As stated above, in cases of duplication it is impossible to know in any reliable way which copy is newer. >=20 > - Section 4.2 > Last paragraph suggests a holddown time from the reception of a GENINFO > TLV before processing. While the benefit is mentioned, the tradeoff > should also be mentioned. That is, the longer the holddown time is, the > more latency can be incurred in propagating potentially current > information. The section is discussing how to address cases where the complete update may be contained in multiple LSPs. It does not suggest that the holddown time should be applied to proagation. It only suggests that the local system may wish to delay processing for a time so that it does not process a partial update. Whether or not this strategy is beneficial to a given application depends on the information advertised. >=20 >=20 > Section 6: > (1) I suggest the following change for the first sentence: > "The GENINFO TLV supports the advertisement of application specific > information in IS-IS LSPs which is not directly related to the > operation of the IS-IS protocol." --> > The GENINFO TLV supports the advertisement of application specific > information in IS-IS LSPs which is not directly related to the > operation of IP routing or Traffic Engineering as provided by the IS-IS > protocol. I have responded to this above. >=20 >=20 >=20 >=20 > Nits: >=20 > (1) Make sure IS-IS is used consistently across the document. In > certain cases you use ISIS, and in others IS-IS. Replace ISIS with IS- > IS Agreed. > (2) Replace subTLV with sub-TLV Agreed - this is consistent w RFC 5305. > (3) The first reference in section 10.1, make sure that the reference > description starts on the same line as the reference code. Agreed. Les >=20 >=20 > Thanks, > Nabil From nabil.n.bitar@verizon.com Thu Oct 7 06:26:01 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100DB3A6FEA for ; Thu, 7 Oct 2010 06:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxhlcI3dZweG for ; Thu, 7 Oct 2010 06:25:30 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 7F9743A6F33 for ; Thu, 7 Oct 2010 06:25:30 -0700 (PDT) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o97DPiSA015446; Thu, 7 Oct 2010 09:26:13 -0400 (EDT) X-AuditID: 8a532265-b7b75ae000001e9f-b7-4cadca74f85d Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id B8.D9.07839.57ACDAC4; Thu, 7 Oct 2010 08:26:13 -0500 (CDT) Received: from FLDP1LUMXC7HB02.us.one.verizon.com (fldp1lumxc7hb02.verizon.com [166.68.75.85]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o97DQ2md018854; Thu, 7 Oct 2010 09:26:12 -0400 (EDT) Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:4b55::a644:4b55]) with mapi; Thu, 7 Oct 2010 09:26:08 -0400 From: "Bitar, Nabil N" To: "Les Ginsberg (ginsberg)" , "Bitar, Nabil N" , "rtg-ads@tools.ietf.org" , "Stefano Previdi (sprevidi)" , "Mike Shand (mshand)" Date: Thu, 7 Oct 2010 09:26:05 -0400 Thread-Topic: RtgDir review: draft-ietf-isis-genapp-03.txt Thread-Index: ActjxLdJnTz0+Poxg0qS2bHaCGT0VQAHYhhAAJA8c48= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8D342ADF48Anabilnbitarverizoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-genapp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:26:01 -0000 --_000_C8D342ADF48Anabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, You are welcome. Please see inline as denoted by . Thanks, Nabil On 10/4/10 2:09 PM, "Les Ginsberg (ginsberg)" wrote: Nabil - Thanx for the detailed review. Responses inline. > -----Original Message----- > From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com] > Sent: Monday, October 04, 2010 7:32 AM > To: rtg-ads@tools.ietf.org; Les Ginsberg (ginsberg); Stefano Previdi > (sprevidi); Mike Shand (mshand) > Cc: rtg-dir@ietf.org; > Subject: RtgDir review: draft-ietf-isis-genapp-03.txt > > > Hi, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or routing- > related drafts as they pass through IETF last call and IESG review. The > purpose of the review is to provide assistance to the Routing ADs. For > more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-isis-genapp-03.txt > > Reviewer: Nabil Bitar > Review Date: October, 03, 2010 > IETF LC End Date: date-if-known > Intended Status: Standards > > Summary: > > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > This draft describes a mechanism that enables advertisement of generic > information, and specifically application support and associated > attributes, by a router via IS-IS. The document is generally well- > written, but some clarifying text and re-ordering of text will improve > completeness and readability as noted in this review. The major area > that needs clarification is related to section 4.3 and the processing > of different GENINFO information with same GENINFO Context (GENINFO- > CTX) at a receiving node. > In general, There are interesting applications that can take advantage > of the capability introduced in this document. However, it will help > the reader if an example or examples of applications that can make use > of this capability are covered in the Overview section for instance. > The authors may have applications in mind. An example of such > applications can be the support for a Path Computation Element on a > router, or the support for an Application Layer Transport Optimization > (ALTO) server. The authors can choose these examples, if they believe > they are applicable or other examples. The introduction of GENAPP is a begrudging acceptance of the fact that there have been requests to use the reliable flooding mechanism of the IGPs (IS-IS in this case) to send information which is not used by the protocol in support of routing. The authors in fact would have preferred that this not be necessary - and don't really want to encourage this usage - which is one of the reasons we did not provide an example. Instead we focused on the correct way to use this extension. Understood and I understand the concern. However, the fact is that th= is was triggered by requests as you state that must have been triggered by applications that ma= de enough of a case to define the extension in this document. The concerns ar= e expressed in the document when you discuss the strong recommendation to run in a non-zero instance o= f IS-IS. Given all that, I still think it would helpful to mention an example of an application that probably was = expressed as part of the requests. I am not sure if I would consider that an encouragement but the fact is the= extension in this document will be availble for use and people will make jusdgment how to use tit or enable it. PCE - as defined in RFC 5089 - uses the the router capability TLV as it was defined BEFORE GENAPP existed. I agree it would have been a good use case for GENAPP had GENAPP been defined at the time - and in fact PCE was one of the reasons we decided to invent GENAPP before other use cases come along. That is what I thought. I understand the existing support for PCE. How= ever, what triggered my suggestion is the applicability of the extension here to the PCE application, and what= you state in the applicability section of this document: " The applicability statement above is expected to cover= some information currently being advertised by IS-IS in previously defined TLVs. It is expected and seen as desirable that an effort be made to migra= te the advertisement of such information to utilize the procedures defined in this document." So, why not mention this as ana app= lication example? To my knowledge ALTO has no requirement for using GENAPP. Understand. So, Iwas thinking about potential uses. If an ALTO server = is running on a router and there is need for ALTO servers to discover and c= ommunicate with each other, there can be an application here. It is fair though to say= that was not expressed or documented. You may disregard that. Gaian, I wa= s stating examples that could have been used to make the case for the extensions here. > > Major Issues: > > - Section 4.3 > In the first paragraph first sentence, you state: "Where a receiving > system has two copies of a GENINFO TLV with the same GENINFO-CTX, > attribute information in the two TLVs which does not conflict MUST be > considered additive.". Additive in the sense that you take the union of > the two, right? Correct. > In addition, the last sentence leaves the behavior undefined when > processing received GENINFO with same GENFO-CTX. This is a concern, This is deliberate. There is no way to reliably determine which information is newer in such cases. > > This section is not clear and the processing rules need to be > tightened, as based on the description you are not disambiguating what > information is valid or not (stale). It seems to me that processing > rules based on GENINFO-CTX, flooding scope, encapsulating LSP lifetime, > encapsulating PDU type, and the level of the receiving node taken > together should provide a better way for processing rules. I request > that this section be revisited and the processing rules be better > developed and articulated. There are no changes to the normal operation of the IS-IS Update process which is defined in ISO 10589. That specification covers the issues you raise (lifetime, PDU type, level, etc.). Any attempt to discuss them here would be ill-advised as it would suggest that we have somehow changed them for GENAPP - which is NOT true. I am suggesting to discuss them here in the general sense nor to chang= e them. What I am suggesting is to use to define how that information can be used to determine which GEN= INFO is newer since this is explicitely stated as you also noted above remains unresolved. I think that information in combination of how GE= NINFO is generated should provide rules for determining what GENINFO is newer, which is important. Otherwise, applications may be acting on stal= e information. I am still not clear why this cannot be done. Can you please explain? > > > Minor Issues: > > -Abstract: " This draft describes the manner in which generic > application information (i.e. information not directly related to the > operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and > defines guidelines which SHOULD be used when flooding such > information." > > (1) The first SHOULD is justified as other mechanisms could be used but > this is a recommendation to use the mechanism defined in this document. > However, I think the second SHOULD needs to be replaced by MUST as > relayed in the later parts of the document, and specifically in the > flooding section and leaking section. Alternatively, you may say: ... > and defines guidelines for flooding and leaking such information. SHOULD is used here because we recognize that many of the guidelines defined in the document are unenforceable i.e. as the advertisement of new TLV information does not introduce interoperability issues a vendor may choose (for example) to advertise GENAPP in instance 0 - despite our strong recommendations not to do so. To be clear, I am referring to the guidelines on flooding. I am fine with the recommendation on using non-zero instance (what I referred to as t= he first SHOULD) and I agree that cannot be enforced. SO, I am referring to the SHOULD that rela= tes to flooding and the suggestion to change that to MUST. In the document section 4 last paragraph before sec= tion 4.1, you state: "Each GENINFO TLV contains information regarding exactly one application instance as identified by the GENINFO-CTX[NB17]. When it is necessary to advertise sets of information with the same GENINFO-CTX which have different flooding scopes, a router MUST originate a minimum of one GENINFO TLV for each required flooding scope. GENINFO TLVs which contain information having area/level scope will have the S bit clear. These TLVs MUST NOT be leaked into another level. GENINFO TLVs which contain information which has domain scope will have the S bit set. These TLVs MUST be leaked into other IS-IS levels. When a TLV is leaked from level-2 to level-1, the D bit MUST be set in the level-1 LSP advertisement." This paragraph uses MUST in defining the flooding and leaking procedures = This is Not inline to what is expressed in the abstract. Are you saying that the MU= STs in this paragraph Need to be changed to SHOULD's then? I don't think that should be the case.= I think the change Needs to be made in the abstract to be in sync with this paragraph. The MUS= Ts and SHOULDs are not because What can be enforced or not but because what is needed to have correct beha= vior. > > (2) In addition, What is defined in this document has implication on > the operations of IS-IS protocol, albeit it does not impact IS-IS for > the purpose of IP routing. Therefore, I suggest the following change: > (i.e. information not directly related to the operation of the IS-IS > protocol) --> (i.e., information that does not relate to IGP routing > table computation or IP network > topology and traffic Engineering information dissemination and > discovery). The manner of defining what information qualifies for GENAPP and what does not received considerable scrutiny during the WG review. Traffic engineering information in particular was a point of discussion. Had GENAPP existed when TE requirements were defined it may well have been the case that GENAPP could have been used to advertise TE information. In Section 6 we state: "The applicability statement above is expected to cover some information currently being advertised by IS-IS in previously defined TLVs." Rather than specifically call out TE as something which is NOT applicable to GENAPP we have deliberately left the door open to allow TE to be moved to GENAPP if there is consensus to do so. Note that we do not expect this to happen - nor are we advocating that it should happen - but it should not be ruled out as a possible alternative. Understood. However, the current wording says the information does not= relate to the operation of IS-IS. What I am simply suggesting that to clarify that as this informat= ion has implication on IS-IS protocol operation, but it does not impact IP routing. If you think that TE does not need to be mentioned f= or the reasons you stated, it is fine although I may have different opinion= on the applicability of moving TE to GENAPP but this is not the place to discu= ss that and not needed either. > > - Section 2 (Overview): > > (1) I suggest adding text in this section for example applications > that can take advantage of the capability introduced in this document > as a use case. Such text will give better context to the reader. Often, > such examples/uses cases are found in requirements documents that > define the reason a problem needs to be solved, but in the absence of > that it would be useful to have a synopsis of that in this section. > Candidate examples are mentioned earlier. > > (2) second paragraph, I suggest adding the word "processing" to the > text so that it reads as follows: This document also discusses optimal > behavior associated with the > advertisement, processing, and flooding of LSPs containing GENINFO > ...... OK Thanks. > > (3) Last paragraph, having the GENINFO advertisement in a non-zero iIS- > IS instance should be recommended but not mandated. Accordingly, I > suggest changing MUST to SHOULD as follows: "In order to minimize the > impact advertisement of GENINFO may have on the operation of routing, > such advertisements MUST occur in the context of a non-zero instance of > the IS-IS protocol as defined in [I-D.ietf-isis-mi]." --> In order to > minimize the impact advertisement of GENINFO may have on the operation > of routing, such advertisements SHOULD occur in the context of a non- > zero instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi]. Our choice of wording here was deliberate. We want to mandate the use of a non-zero instance. If an exception to this policy is needed it would need to be reviewed - which is what we state. To your point earlier point on the inability to enforce a guideline, I= am not sure how this can be enforced. In addition, the document leaves the option of using non-zero instance of I= S-IS as open, although rightfully though is not recommended. Here is what the document says leaving that opt= ion open in the following sentence to what is stated above: " Advertisement of GENINFO therefore MUST occur in the contex= t of a non-zero instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi]. Exceptions to this policy MAY be allowed only when t= here exists a standards track RFC which defines the application." I think allowing execeptions to happen and using the MAY,= makes the first sentence as a strong recommendation but not a mandate. > > - Section 3.1 > > (1) I suggested adding "IS-IS" as noted in the following, starting on > page 4: > "S bit (0x01): If the S bit is set(1), the GENINFO TLV MUST be flooded > across the entire routing domain. If the S bit is not set(0), the TLV > MUST NOT be leaked between levels. This bit MUST NOT be altered during > the TLV leaking." --> S bit (0x01): If the S bit is set(1), the GENINFO > TLV MUST be flooded across the entire IS-IS routing domain, across IS- > IS levels/area. If the S bit is not set(0), the TLV MUST NOT be leaked > between IS-IS levels/areas. This bit MUST NOT be altered during the TLV > leaking. I do not object to this change - but it seems unnecessary as clearly the IS-IS Update process can only operate on areas/domain known to IS-IS. I agree. I thought it would make it clearer. However, I am fine if tha= t change is not made. > > (2) GENINFO-REG acronym is used for the first time without definition > in the definition of Application ID: "Application ID An identifier > assigned to this application via the GENINFO-REG." It can be defined > earlier where you talk about establishing a new registry for > application IDs. Yes - this point has been made by another reviewer in a more general way and I agree this should be done. Thanks. > > (3) Question: for IP addresses associated with an application, wouldn't > it be better if the application has an IPv4 and an IPv6 address > associated with it to be able to advertise that in the same TLV when > the other attributes do not change between the two. That can be > achieved by allowing the "I" and "V" bits to be simultaneously set in > the flag, and mandating for instance that when the I and V bits are > set, the first IP address following the flag will be an IPv4 address > followed by an IPv6 address. What is your current procedure in this > case? Is it to have one GENINFO TLV with the same application ID for > IPv4 and another for IPv6? Use of both an IPv4 and an IPv6 address in a single TLV is allowed. In such a case the IPv4 address would occur first in the TLV followed by the IPv6 address. This is stated in Section 3.1 in the description of the V bit: " V bit (0x08): When the V bit is set, the 16 octet IPv6 address associated with the application immediately follows either the Application ID (if I bit is clear) or the IPv4 address (if I bit is set)." Somehow I missed that. I am good with it as it captures what I intende= d to say. It is also implied in the encoding diagram. > In addition, it would be good to include a > sentence here stating that how the IP address associated with an > application ID is generated will be application dependent and specified > in the a respective application-specific document that makes use of > this mechanism. We do state: " The IPv4[IPv6] address associated with the application. This is not necessarily an address of a router running the IS-IS protocol." This clearly leaves the manner in which the address is chosen to be outside the scope of this document. It could be implied. I am suggesting to state more explicitly that the= application-specific document must define that. > > (4) Under "Additional Application Specific Information" definition, > shouldn't TLV be sub-TLV in the following: "Each application may define > additional information to > be encoded in a GENINFO TLV following the fixed > information." That is, change GENINFO TLV to GENINFO sub-TLV. We allow that an application MAY choose to encode additional information directly after the fixed information defined in the document without using sub-TLVs - so the current wording is correct. I read it differently based on the word ordering. I can see the optio= n of allowing additional information to be encoded without using sub-TLVs. If I may sugge= st another word ordering that I think would make it clearer: "Each application may de= fine additional information to follow the fixed information part in a GENINFO TLV". > > - Section 3.2 > > (1) 4th paragraph first sentence. I suggest the following change or > similar rewording for clarity: "The use of additional levels of subTLVs > is discouraged due to the > inherent inefficiency in encoding introduced because the parent > subTLV must encode the nested subTLV length." ---> Nested sub-TLVs > introduce encoding inefficiency due to the fact that the parent TLV > and parent sub-TLV must account for the length of nested sub-TLVs in > each context. > > (2) Can you please explain what you mean in the following sentence. It > is not clear to me what you mean by the "one additional octet" as the > length is accounted in the parent TLV/sub-TLV length value. "While > this inefficiency is small (one additional octet), it may be > sufficient to extend the total information about a single application > object beyond the > carrying capacity of a single GENINFO TLV. " I agree that the current text is both inaccurate and confusing. I suggest that the first two sentences be rewritten as follows: "The use of additional levels of subTLVs is discouraged due to the inherent inefficiency in encoding introduced when the parent subTLV is used solely to scope the set of sub-TLVs it contains. While this inefficiency is small (two additional octets),..." Sound good. > > - Section 3.3 > > This section refers to public documents in the first and last > paragraph. Public document is a very broad reference. What form of a > public document? An IETF draft/RFC, a specification generated by > another standard body maybe after liaising with IETF (or not)? Document > published by a vendor that can appliy for an application ID from IANA > as stated earlier? Or anything that is made public?. I am not sure why > this should be referenced here. If something is done by a vendor for > instance or an application developer but not by a standard body, it is > categorically proprietary or vendor-specific although it is publically > made available. Is the assumption that applications can come from other > standards bodies as well? Are there restrictions or obligations? For > instance, does assigning an application ID require review by IETF as it > is carried by IS-IS? > This section requires clarification. Your clarification is appreciated > as to the intention(s). The forum in which the document used to define the application is beyond the scope of this draft. However, we do make two very important stipulations: 1)In Section 3.3 we require that there be a public document. We specifically do NOT allow proprietary/experimental use of GENAPP. 2)In Section 8 we stipulate "Specification Required" as defined in RFC 5226. Section 8 is fine. I would suggest that in section 3.3., you add a sen= tence or 2 at the end that say something to the extent of: "The application must be registered with IANA as discussed in Section 8. Th= e public document describing the application must support the registration = process as defined in RFC 5226 [RFC 4226]". > > - Section 3 overall: > > Some procedural description that relates to the generation of GENINFO > TLVs is missing from this section. In particular, it seems to me that > to complete this section, you should explicitly state that one or more > GENINFO TLVs can appear in each LSP (it does not come out explicitly). > In addition, what makes a GENINFO TLV unique is the GENINFO-CTX defined > by the application ID and associated IP address. Thus, GENINFO TLVs > that share the same GENINFO-CTX with the same flooding scope (in a way, > it seems to make sense if the flooding scope is part of the GENINFO > context definition) are comparable in terms of generating updates, > comparing attributes, and/or determining what is more current. I > suggest that some of the text in the first two sentences of the second > paragraph under section 4 be pulled within section 3 under a separate > subsection titled "Rules for GENINFO encoding" and have the section of > title 3 changed to "GENINFO encoding". Section 3 discusses the format of the information within a given TLV. Section 4 discusses issues associated with flooding/leaking encoded information. I don't think mixing these two types of information in a single section (even partially) would aid clarity. I am not suggesting mixing the two. What I am suggesting that these tw= o sentences really belong in section 3 as they are related to how to generate GENINFO TLVs not how to= flood them. The remaining part in section 4 remains in the flooding section. The 2 sentences I am suggesting to move ar= e: " Each GENINFO TLV contains information regarding exactly one application instance as identified by the GENINFO-CTX. When it is necessary to advertise sets of information with the same GENINFO-CTX which have different flooding scopes, a router MUST originate a minimum of one GENINFO TLV for each required flooding scope." If you decide not to move them, it is fine. I would be happy to add the following to Section 3.1: "GENINFO TLVs may appear in any LSP and multiple GENINFO TLVs may appear in the same LSP." That will be fine. > > - Section 4.1 > First paragraph, it should state clearly what is being compared to > determine duplication or more recent update. In particular, as stated > in an earlier comment, it seems to me that you can compare two GENINFO > TLVs for duplication or currency when they share the same context and > flooding scope. Would you agree? If you do, that should be spelled > out. As stated above, in cases of duplication it is impossible to know in any reliable way which copy is newer. Let me try the following reasoning and what I am thinking, and please = tell where the gap is or the fallacy (1) If a receiving node receives two IGENINFO TLVs in two different LSPs (d= ifferent ID's) with the same GENFO-CTX and same local flood scope then the = one contained in an LSP with the longer lifetime is newer. If there iare co= mmon attributes being shared between two GENINFO T:Vs one with IS-IS domain= -wide flooding scope and a local-area scope, the same attributes must be pr= esent in each and the values in the local scope GENINFO TLV will take prece= dence. (2) If a receiving node receives two GENINFO TLVs in two different LSPs (d= ifferent IDs) with the same GENFO-CTX and domain-level scope but with IPv4/= IPv6 application address that is reachable in another area (ie., a GENINFO = TLV generated in level 1 but leaked into level2, then the one contained in= the the LSP with longest lifetime is more recent (3) If a receiving node receives two GENINFO TLVs in two different LSPs (d= ifferent IDs) with the same GENFO-CTX and domain-level scope but with IPv4/= IPv6 application address that is reachable in another area with D-bit set (= leaked from level2 to level1), then the one contained in the the LSP with l= ongest lifetime is more recent .... > > - Section 4.2 > Last paragraph suggests a holddown time from the reception of a GENINFO > TLV before processing. While the benefit is mentioned, the tradeoff > should also be mentioned. That is, the longer the holddown time is, the > more latency can be incurred in propagating potentially current > information. The section is discussing how to address cases where the complete update may be contained in multiple LSPs. It does not suggest that the holddown time should be applied to proagation. So, (1) are you saying you propagate that information before you proce= ss it? and (2) locally, you have the implication that you may be holding on proces= sing most recent information. I agree you that is application dependent and configuration dependent. It only suggests that the local system may wish to delay processing for a time so that it does not process a partial update. Whether or not this strategy is beneficial to a given application depends on the information advertised. > > > Section 6: > (1) I suggest the following change for the first sentence: > "The GENINFO TLV supports the advertisement of application specific > information in IS-IS LSPs which is not directly related to the > operation of the IS-IS protocol." --> > The GENINFO TLV supports the advertisement of application specific > information in IS-IS LSPs which is not directly related to the > operation of IP routing or Traffic Engineering as provided by the IS-IS > protocol. I have responded to this above. > > > > > Nits: > > (1) Make sure IS-IS is used consistently across the document. In > certain cases you use ISIS, and in others IS-IS. Replace ISIS with IS- > IS Agreed. > (2) Replace subTLV with sub-TLV Agreed - this is consistent w RFC 5305. > (3) The first reference in section 10.1, make sure that the reference > description starts on the same line as the reference code. Agreed. Les > > > Thanks, > Nabil --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 117 West Street Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C8D342ADF48Anabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: RtgDir review:  draft-ietf-isis-genapp-03.txt
Hi Les,
You are welcome. Please see inline as denoted by <NB>.

Thanks,
Nabil

On 10/4/10 2:09 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:

Nabil -

Thanx for the detailed review.
Responses inline.

> -----Original Message-----
> From: Bitar, Nabil N [mai= lto:nabil.n.bitar@verizon.com]
> Sent: Monday, October 04, 2010 7:32 AM
> To: rtg-ads@tools.ietf.org; Les= Ginsberg (ginsberg); Stefano Previdi
> (sprevidi); Mike Shand (mshand)
> Cc: rtg-dir@ietf.org;
> Subject: RtgDir review: draft-ietf-isis-genapp-03.txt
>
>
> Hi,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or routing-=
> related drafts as they pass through IETF last call and IESG review. The
> purpose of the review is to provide assistance to the Routing ADs. For=
> more information about the Routing Directorate, please see
> http://w= ww.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing ADs,<= BR> > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft.
>
> Document: draft-ietf-isis-genapp-03.txt
>
> Reviewer: Nabil Bitar
> Review Date: October, 03, 2010
> IETF LC End Date: date-if-known
> Intended Status: Standards
>
> Summary:
>
>
> I have some minor concerns about this document that I think should be<= BR> > resolved before publication.
>
> Comments:
>
> This draft describes a mechanism that enables advertisement of generic=
> information, and specifically application support and associated
> attributes, by a router via IS-IS. The document is generally well-
> written, but some clarifying text and re-ordering of text will improve=
> completeness and readability as noted in this review. The major area > that needs clarification is related to section 4.3 and the processing<= BR> > of different GENINFO information with same GENINFO Context (GENINFO- > CTX) at a receiving node.
> In general, There are interesting applications that can take advantage=
> of the capability introduced in this document. However, it will help > the reader if an example or examples of applications that can make use=
> of this capability are covered in the Overview section for instance. > The authors may have applications in mind. An example of such
> applications can be the support for a Path Computation Element on a > router, or the support for an Application Layer Transport Optimization=
> (ALTO) server. The authors can choose these examples, if they believe<= BR> > they are applicable or other examples.

The introduction of GENAPP is a begrudging acceptance of the fact that
there have been requests to use the reliable flooding mechanism of the
IGPs (IS-IS in this case) to send information which is not used by the
protocol in support of routing. The authors in fact would have preferred that this not be necessary - and don't really want to encourage this
usage - which is one of the reasons we did not provide an example.
Instead we focused on the correct way to use this extension.

<NB> Understood and I understand the concern.  However, the fact= is that this was triggered by
requests as you state that must have been triggered by applications that ma= de
 enough of a case to define the extension in this document. The concer= ns are expressed in the document
 when you discuss the strong recommendation to run in a non-zero insta= nce of IS-IS. Given all that, I still think
it would helpful to mention an example of an application that probably was = expressed as part of the requests.
I am not sure if I would consider that an encouragement but the fact is the= extension in this document will be availble
for use and people will make jusdgment how to use tit or enable it.

PCE - as defined in RFC 5089 - uses the the router capability TLV as it
was defined BEFORE GENAPP existed. I agree it would have been a good use case for GENAPP had GENAPP been defined at the time - and in fact PCE
was one of the reasons we decided to invent GENAPP before other use
cases come along.

<NB> That is what I thought. I understand the existing support for PC= E. However, what triggered my suggestion
is the applicability of the extension here to the PCE application, and what= you state in the applicability section of this

To my knowledge ALTO has no requirement for using GENAPP.
<NB> Understand. So, Iwas thinking about potential uses. If an ALTO s= erver is running on a router and there is need for ALTO servers to discover= and communicate
with each other, there can be an application here. It is fair though to say= that was not expressed or documented. You may disregard that.  Gaian,= I was stating examples that
could have been used to make the case for the extensions here.  
>
> Major Issues:
>
> - Section 4.3
> In the first paragraph first sentence, you state: "Where a receiv= ing
> system has two copies of a GENINFO TLV with the same GENINFO-CTX,
> attribute information in the two TLVs which does not conflict MUST be<= BR> > considered additive.". Additive in the sense that you take the un= ion
of
> the two, right?

Correct.

> In addition, the last sentence leaves the behavior undefined when
> processing received GENINFO with same GENFO-CTX.  This is a conce= rn,

This is deliberate. There is no way to reliably determine which
information is newer in such cases.

>
> This section is not clear and the processing rules need to be
> tightened, as based on the description you are not disambiguating what=
> information is valid or not (stale). It seems to me that processing > rules based on GENINFO-CTX, flooding scope, encapsulating LSP
lifetime,
> encapsulating PDU type, and the level of the receiving node taken
> together should provide a better way for processing rules. I request > that this section be revisited and the processing rules be better
> developed and articulated.

There are no changes to the normal operation of the IS-IS Update process which is defined in ISO 10589. That specification covers the issues you
raise (lifetime, PDU type, level, etc.). Any attempt to discuss them
here would be ill-advised as it would suggest that we have somehow
changed them for GENAPP - which is NOT true.

<NB> I am suggesting to discuss them here in the general sense nor to= change them. What I am suggesting
is to use to define how that information can be used to determine which GEN= INFO is newer since this is explicitely stated as you also noted
above remains unresolved. I think that information in combination of how GE= NINFO is generated should provide rules for determining what GENINFO
is newer, which is important. Otherwise, applications may be acting on stal= e information.  I am still not clear why this cannot be done.
Can you please explain?

>
>
> Minor Issues:
>
> -Abstract: " This draft describes the manner in which generic
> application information (i.e. information not directly related to the<= BR> > operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and
> defines guidelines which SHOULD be used when flooding such
> information."
>
> (1) The first SHOULD is justified as other mechanisms could be used but
> this is a recommendation to use the mechanism defined in this
document.
> However, I think the second SHOULD needs to be replaced by MUST as
> relayed in the later parts of the document, and specifically in the > flooding section and leaking section. Alternatively, you may say: ...<= BR> > and defines guidelines for flooding and leaking such information.

SHOULD is used here because we recognize that many of the guidelines
defined in the document are unenforceable i.e. as the advertisement of
new TLV information does not introduce interoperability issues a vendor
may choose (for example) to advertise GENAPP in instance 0 - despite our strong recommendations not to do so.

<NB> To be clear, I am referring to the guidelines on flooding. I am = fine
with the recommendation on using non-zero instance (what I referred to as t= he first SHOULD) and
I agree that cannot be enforced. SO, I am referring to the SHOULD that rela= tes to flooding and the suggestion
to change that to MUST. In the document section 4 last paragraph before sec= tion 4.1, you state:

>
> (2) In addition, What is defined in this document has implication on > the operations of IS-IS protocol, albeit it does not impact IS-IS for<= BR> > the purpose of IP routing. Therefore, I suggest the following change:<= BR> > (i.e. information not directly related to the operation of the IS-IS > protocol)  --> (i.e., information that does not relate to IGP = routing
> table computation or IP network
> topology and traffic Engineering information dissemination and
> discovery).

The manner of defining what information qualifies for GENAPP and what
does not received considerable scrutiny during the WG review. Traffic
engineering information in particular was a point of discussion. Had
GENAPP existed when TE requirements were defined it may well have been
the case that GENAPP could have been used to advertise TE information.
In Section 6 we state:

"The applicability statement above is expected to cover some
   information currently being advertised by IS-IS in previo= usly defined
   TLVs."

Rather than specifically call out TE as something which is NOT
applicable to GENAPP we have deliberately left the door open to allow TE to be moved to GENAPP if there is consensus to do so. Note that we do
not expect this to happen - nor are we advocating that it should happen
- but it should not be ruled out as a possible alternative.

<NB> Understood. However, the current wording says the information do= es not relate to the operation
of IS-IS. What I am simply suggesting that to clarify that as this informat= ion has implication on IS-IS protocol operation, but it does
not impact IP routing. If you think that TE does not need to be mentioned f= or the reasons you stated, it is fine although I may have different opinion= on
the applicability of moving TE to GENAPP but this is not the place to discu= ss that and not needed either.

>
> - Section 2 (Overview):
>
> (1)  I suggest adding text in this section for example applicatio= ns
> that can take advantage of the capability introduced in this document<= BR> > as a use case. Such text will give better context to the reader.
Often,
> such examples/uses cases are found in requirements documents that
> define the reason a problem needs to be solved, but in the absence of<= BR> > that it would be useful to have a synopsis of that in this section. > Candidate examples are mentioned earlier.
>
> (2) second paragraph, I suggest adding the word "processing"= to the
> text so that it reads as follows: This document also discusses optimal=
> behavior associated with the
>    advertisement, processing, and flooding of LSPs cont= aining GENINFO
> ......

OK

<NB> Thanks.  
>
> (3) Last paragraph, having the GENINFO advertisement in a non-zero
iIS-
> IS instance should be recommended but not mandated. Accordingly, I
> suggest changing MUST to SHOULD as follows: "In order to minimize= the
> impact advertisement of GENINFO may have on the operation of routing,<= BR> > such advertisements MUST occur in the context of a non-zero instance of
> the IS-IS protocol as defined in [I-D.ietf-isis-mi]."  -->= ;  In order
to
> minimize the impact advertisement of GENINFO may have on the operation=
> of routing, such advertisements SHOULD occur in the context of a non-<= BR> > zero instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi].<= BR>
Our choice of wording here was deliberate. We want to mandate the use of a non-zero instance. If an exception to this policy is needed it would
need to be reviewed - which is what we state.

<NB> To your point earlier point on the inability to enforce a guidel= ine, I am not sure how this can be enforced.
In addition, the document leaves the option of using non-zero instance of I= S-IS as open, although rightfully
though is not recommended.  Here is what the document says leaving tha= t option open in the following sentence to what is


>
> - Section 3.1
>
> (1)  I suggested adding "IS-IS" as noted in the followi= ng, starting on
> page 4:
> "S bit (0x01): If the S bit is set(1), the GENINFO TLV MUST be fl= ooded
> across the entire routing domain. If  the S bit is not set(0), th= e TLV
> MUST NOT be leaked between levels. This bit MUST NOT be altered during=
> the TLV leaking." --> S bit (0x01): If the S bit is set(1), th= e
GENINFO
> TLV MUST be flooded across the entire IS-IS routing domain, across IS-=
> IS levels/area. If  the S bit is not set(0), the TLV MUST NOT be<= BR> leaked
> between IS-IS levels/areas. This bit MUST NOT be altered during the TLV
> leaking.

I do not object to this change - but it seems unnecessary as clearly the IS-IS Update process can only operate on areas/domain known to IS-IS.

<NB> I agree. I thought it would make it clearer. However, I am fine = if that change is not made.

>
> (2) GENINFO-REG  acronym is used for the first time without defin= ition
> in the definition of Application ID:  "Application ID An ide= ntifier
> assigned to this application via the GENINFO-REG." It can be defi= ned
> earlier where you talk about establishing a new registry for
> application IDs.

Yes - this point has been made by another reviewer in a more general way and I agree this should be done.

<NB> Thanks.
>
> (3) Question: for IP addresses associated with an application,
wouldn't
> it be better if the application has an IPv4 and an IPv6 address
> associated with it to be able to advertise that in the same TLV when > the other attributes do not change between the two. That can be
> achieved by allowing the "I" and "V" bits to be si= multaneously set in
> the flag, and mandating for instance that when the I and V bits are > set, the first IP address following the flag will be an IPv4 address > followed by an IPv6 address. What is your current procedure in this > case? Is it to have one GENINFO TLV with the same application ID for > IPv4 and another for IPv6?

Use of both an IPv4 and an IPv6 address in a single TLV is allowed. In
such a case the IPv4 address would occur first in the TLV followed by
the IPv6 address. This is stated in Section 3.1 in the description of
the V bit:

" V bit (0x08): When the V bit is set, the 16 octet IPv6
            &nb= sp;    address associated with the application immediat= ely
            &nb= sp;    follows either the Application ID (if I bit is c= lear)
            &nb= sp;    or the IPv4 address (if I bit is set)."

<NB> Somehow I missed that. I am good with it as it captures what I i= ntended to say. It is
also implied in the encoding diagram.

> In addition, it would be good to include a
> sentence here stating that how the IP address associated with an
> application ID is generated will be application dependent and
specified
> in the a respective application-specific document that makes use of > this mechanism.

We do state:

" The IPv4[IPv6] address associated with the application. This
            &nb= sp;    is not necessarily an address of a router runnin= g the
            &nb= sp;    IS-IS protocol."

This clearly leaves the manner in which the address is chosen to be
outside the scope of this document.

<NB> It could be implied. I am suggesting to state more explicitly th= at the application-specific document must
define that.

>
> (4) Under  "Additional Application Specific Information"= ; definition,
> shouldn't TLV be sub-TLV in the following: "Each application may<= BR> define
> additional information to
>            &nbs= p;    be encoded in a GENINFO TLV following the fixed > information." That is, change GENINFO TLV to GENINFO sub-TLV.

We allow that an application MAY choose to encode additional information directly after the fixed information defined in the document without
using sub-TLVs - so the current wording is correct.

<NB> I read it differently based on the word ordering.  I can se= e the option of  allowing
additional information to be encoded without using sub-TLVs. If I may sugge= st another
word ordering that I think would make it clearer:  “Each applica= tion may define additional
information to follow the fixed information part in a GENINFO TLV”. <= BR> >
> - Section 3.2
>
> (1) 4th paragraph first sentence. I suggest the following change or > similar rewording for clarity: "The use of additional levels of subTLVs
> is discouraged due to the
>   inherent inefficiency in encoding introduced because the p= arent
> subTLV must encode  the nested subTLV length."  --->= Nested sub-TLVs
> introduce encoding inefficiency due to the fact that  the parent = TLV
> and parent sub-TLV must account for the length of nested sub-TLVs in > each context.
>
> (2) Can you please explain what you mean in the following sentence. It=
> is not clear to me what you mean by the "one additional octet&quo= t; as the
> length is accounted in the parent TLV/sub-TLV length value.  &quo= t;While
> this inefficiency  is small (one additional octet), it may be
> sufficient to extend the total information about a single application<= BR> > object beyond the
>    carrying capacity of a single GENINFO TLV. "
I agree that the current text is both inaccurate and confusing. I
suggest that the first two sentences be rewritten as follows:

"The use of additional levels of subTLVs is discouraged due to the
   inherent inefficiency in encoding introduced when the par= ent
   subTLV is used solely to scope the set of sub-TLVs it con= tains.
While this inefficiency
   is small (two additional octets),..."

<NB> Sound good.

>
> - Section 3.3
>
> This section refers to public documents in the first and last
> paragraph. Public document is a very broad reference. What form of a > public document? An IETF draft/RFC, a specification generated by
> another standard body maybe after liaising with IETF (or not)?
Document
> published by a vendor that can appliy for an application ID from IANA<= BR> > as stated earlier? Or anything that is made public?. I am not sure why=
> this should be referenced here. If something is done by a vendor for > instance or an application developer but not by a standard body, it is=
> categorically proprietary or vendor-specific although it is publically=
> made available. Is the assumption that applications can come from
other
> standards bodies as well? Are there restrictions or obligations? For > instance, does assigning an application ID require review by IETF as it
> is carried by IS-IS?
> This section requires clarification. Your clarification is appreciated=
> as to the intention(s).

The forum in which the document used to define the application is beyond the scope of this draft. However, we do make two very important
stipulations:

1)In Section 3.3 we require that there be a public document. We
specifically do NOT allow proprietary/experimental use of GENAPP.

2)In Section 8 we stipulate "Specification Required" as defined i= n RFC
5226.

<NB> Section 8 is fine. I would suggest that in section 3.3., you add= a sentence or 2 at the end that say something to the extent of:
“The application must be registered with IANA as discussed in Section= 8. The public document describing the application must support the registr= ation process as defined in RFC 5226 [RFC 4226]”.

>
> - Section 3 overall:
>
> Some procedural description that relates to the generation of GENINFO<= BR> > TLVs is missing from this section. In particular, it seems to me that<= BR> > to complete this section, you should explicitly state that one or more=
> GENINFO TLVs can appear in each LSP (it does not come out explicitly).=
> In addition, what makes a GENINFO TLV unique is the GENINFO-CTX
defined
> by the application ID and associated IP address. Thus, GENINFO TLVs > that share the same GENINFO-CTX with the same flooding scope (in a
way,
> it seems to make sense if the flooding scope is part of the GENINFO > context definition) are comparable in terms of generating updates,
> comparing attributes, and/or determining what is more current. I
> suggest that some of the text in the first two sentences of the second=
> paragraph under section 4 be pulled within section 3 under a separate<= BR> > subsection titled "Rules for GENINFO encoding" and have the = section of
> title 3 changed to "GENINFO encoding".

Section 3 discusses the format of the information within a given TLV.
Section 4 discusses issues associated with flooding/leaking encoded
information.

I don't think mixing these two types of information in a single section
(even partially) would aid clarity.

<NB> I am not suggesting mixing the two. What I am suggesting that th= ese two sentences really belong
in section 3 as they are related to how to generate GENINFO TLVs not how to= flood them. The remaining part in section 4
remains in the flooding section. The 2 sentences I am suggesting to move ar= e:
 minimum of one GENINFO TLV for each = required flooding scope.”

If you decide not to move them, it is fine.


I would be happy to add the following to Section 3.1:

"GENINFO TLVs may appear in any LSP and multiple GENINFO TLVs may appe= ar
in the same LSP."


>
> - Section 4.1
> First paragraph, it should state clearly what is being compared to
> determine duplication or more recent update. In particular, as stated<= BR> > in an earlier comment, it seems to me that you can compare two GENINFO=
> TLVs  for duplication or currency when they share the same contex= t and
> flooding scope. Would you agree?  If you do, that should be spell= ed
> out.

As stated above, in cases of duplication it is impossible to know in any reliable way which copy is newer.

<NB> Let me try the following reasoning and what I am thinking, and p= lease tell where the gap is or the fallacy
(1) If a receiving node receives two IGENINFO TLVs in two different LSPs (d= ifferent ID’s) with the same GENFO-CTX and same local flood scope the= n the one contained in an LSP with the longer lifetime is newer. If there i= are common attributes being shared between two GENINFO T:Vs one with IS-IS = domain-wide flooding scope and a local-area scope, the same attributes must= be present in each and the values in the local scope GENINFO TLV will take= precedence.
(2)  If a receiving node receives two GENINFO TLVs in two different LS= Ps (different IDs) with the same GENFO-CTX and domain-level scope but with = IPv4/IPv6 application address that is reachable in another area (ie., a GEN= INFO TLV generated in level 1 but leaked into level2,  then the one co= ntained in the the LSP with longest lifetime is more recent
(3)  If a receiving node receives two GENINFO TLVs in two different LS= Ps (different IDs) with the same GENFO-CTX and domain-level scope but with = IPv4/IPv6 application address that is reachable in another area with D-bit = set (leaked from level2 to level1), then the one contained in the the LSP w= ith longest lifetime is more recent
....

>
> - Section 4.2
> Last paragraph suggests a holddown time from the reception of a
GENINFO
> TLV before processing.  While the benefit is mentioned, the trade= off
> should also be mentioned. That is, the longer the holddown time is, the
> more latency can be incurred in propagating potentially current
> information.

The section is discussing how to address cases where the complete update may be contained in multiple LSPs. It does not suggest that the holddown time should be applied to proagation.
<NB> So, (1) are you saying you propagate that information before you= process it?
and (2) locally, you have the implication that you may be holding on proces= sing most recent information.
I agree you that is application dependent and configuration dependent.

 It only suggests that the local
system may wish to delay processing for a time so that it does not
process a partial update. Whether or not this strategy is beneficial to
a given application depends on the information advertised.

>
>
> Section 6:
> (1) I suggest the following change for the first sentence:
> "The GENINFO TLV supports the advertisement of application specif= ic
> information in IS-IS LSPs which is not directly related to the
> operation of the IS-IS protocol." -->
> The GENINFO TLV supports the advertisement of application specific
> information in IS-IS LSPs which is not directly related to the
> operation of IP routing or Traffic Engineering as provided by the
IS-IS
> protocol.

I have responded to this above.

>
>
>
>
> Nits:
>
> (1) Make sure IS-IS is used consistently across the document. In
> certain cases you use ISIS, and in others IS-IS. Replace ISIS with IS-=
> IS

Agreed.

> (2) Replace subTLV with sub-TLV

Agreed - this is consistent w RFC 5305.

> (3) The first reference in section 10.1, make sure that the reference<= BR> > description starts on the same line as the reference code.

Agreed.

  Les

>
>
> Thanks,
> Nabil


 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4CADF261.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4CADF261.001/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ X-Mailman-Approved-At: Thu, 07 Oct 2010 09:31:15 -0700 Cc: "rtg-dir@ietf.org" , Adrian Farrel , Stewart Bryant Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:15:47 -0000 Dear Mr. Callon, Thank you very much for your thoughtful review of draft-chroboczek-babel-routing-protocol-04. I agree with most of your comments, for which many thanks. In the following, I'm only replying to those points that I disagree with, or that otherwise deserve being discussed. Please let me know whether I should produce a -05 now, or whether I should wait for some further event. 1. Why a new protocol ********************* > It is not clear to me why the world needs another routing protocol, > although experiments can be useful. While the world certainly doesn't need a new routing protocol for stable, well-administered wired networks, Babel has been shown to be suitable for networks built with sticks and pieces of string ("wireless mesh networks"). Much of the research in this area (AODV/DYMO, OLSR) is about designing protocols based on all-new principles; Babel takes the opposite approach, by just being distance-vector with some refinements. So please think of Babel as a proof of the statement that plain old DV can be made to work in mesh networks. It is certainly not meant to compete with OSPF. 2. About blackholes ******************* > - Section 1.1, first paragraph: I don't think that the Babel routing > protocol is "black hole" free, at least if you define "black hole" > as a router in a network that has no route, for some period of time, > to a particular destination. I do understand that black holes will > not persist indefinitely. Agreed -- Babel ensures that blackholes will not persist indefinitely. This is just a way of saying that Babel eventually converges to an acceptable configuration. I'll fix this. (Since the draft leaves the route selection policy to the implementation, Babel does not, in general, converge to a tree of shortest paths, although it certainly does if route selection prefers smaller metrics.) > - Section 1.1, third bullet item (that reads "any routing black-holes > that may appear after a mobility event are corrected in a time at > most proportional to the network's diameter."). I think that this is > true *unless* the set of one or more "explicit requests to the > source for a new sequence number" (described in 2.6) are all lost. You are right, this assumes that the number of requests is such that the probability of that happening is negligible. I have no objection to making that explicit. 3. About requests and seqnos **************************** As you've justly noted, the mechanisms used for avoiding starvation are the most tricky parts of Babel. The algorithms described in the draft are certainly not the only ones that work; however, they are the ones currently implemented in Babel, and they have been shown to work reasonably well in practice. This is to say that while improvements are doubtless possible, this draft is meant to describe the set of algorithms currently implemented; and I'd be unwilling to describe any behaviour in the draft unless it's been implemented and the implementation's behaviour evaluated experimentally. > It is probably worth mentioning that in general for some or even many > nodes there will be no way to route the explicit request back to the > source, but... Seeing it written down in your words is extremely helpful. Thanks for this paragraph. > - Section 3.2.1 mentions that sequence numbers are incremented > whenever a node receives a request for a new sequence number. Given > that these requests are not sent reliably, it is probably a good > idea for the node to also update its sequence number periodically, > and to mention this in this section. (Assuming that sequence numbers > already area updated periodically based on timeout, this becomes an > editorial comment.) As explained by private mail, this is not the case -- unlike in DSDV, a node never spontaneously increases its seqno. I'll make that clear. > - In section 3.2.6 you talk about the table of pending segno requests > [...] I don't understand the triplet (neigh, seqno, neighbour). [...] > Some more explanation seems to be needed for this section. This is a typo, as you suspected. I'll fix and expand this section. 4. About poison reverse *********************** > - Section 3.7.4: "Since Babel does not suffer from routing loops, > split horizon with poison reverse SHOULD NOT be used." [...] I was the > one who originally came up with the idea of poison reverse [...] (Shakes hands.) > Poison reverse is therefore simply the equivalent to your route > withdrawal. As such this sentence doesn't seem to make much sense. Hmm. I was under the impression that poison reverse is more than just explicit retractions, since it consists in advertising a reverse unreachable route for an unbounded amount of time. However, I have no strong feelings about this sentence, please let me know if you if you insist that it should be removed. 5. About being loop-free ************************ > Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as > you explain in the introduction). Well, Babel is loop-free in a mesh network (only host routes) with at most on Internet gateway. Since this is the only case that the existing literature on mesh networking even considers, Babel is loop-free in the same sense as, say, DSDV or AODV/DYMO are loop-free. > Perhaps "nearly loop-free" might be more precise. (the same issue > applies to the first sentence of section 2) I'll do that. Thanks again for your review, Juliusz From rcallon@juniper.net Thu Oct 7 16:59:56 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776483A7076 for ; Thu, 7 Oct 2010 16:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJuiFov5Ngjk for ; Thu, 7 Oct 2010 16:59:55 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 459CE3A6F96 for ; Thu, 7 Oct 2010 16:59:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTK5fINZrEt/vraBXkT5pe9JZUAYwYEop@postini.com; Thu, 07 Oct 2010 17:00:58 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 17:00:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Oct 2010 20:00:27 -0400 From: Ross Callon To: Juliusz Chroboczek Date: Thu, 7 Oct 2010 19:59:54 -0400 Thread-Topic: Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 Thread-Index: ActmOxAKRd6ROMgST5mFqMIkrunZ6wAQJDDw Message-ID: References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , Adrian Farrel , Stewart Bryant Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 23:59:56 -0000 Thanks for the response. I just wanted to quickly let you know that I am on= travel, and thus won't be able to give you a detailed response for a few d= ays (probably Sunday or Monday).=20 Thanks, Ross -----Original Message----- From: Juliusz Chroboczek [mailto:Juliusz.Chroboczek@pps.jussieu.fr]=20 Sent: Thursday, October 07, 2010 12:15 PM To: Ross Callon Cc: Adrian Farrel; Stewart Bryant; rtg-dir@ietf.org Subject: Re: Rtg Directorate review of draft-chroboczek-babel-routing-proto= col-04 Dear Mr. Callon, Thank you very much for your thoughtful review of draft-chroboczek-babel-routing-protocol-04. I agree with most of your comments, for which many thanks. In the following, I'm only replying to those points that I disagree with, or that otherwise deserve being discussed. Please let me know whether I should produce a -05 now, or whether I should wait for some further event. 1. Why a new protocol ********************* > It is not clear to me why the world needs another routing protocol, > although experiments can be useful. While the world certainly doesn't need a new routing protocol for stable, well-administered wired networks, Babel has been shown to be suitable for networks built with sticks and pieces of string ("wireless mesh networks"). Much of the research in this area (AODV/DYMO, OLSR) is about designing protocols based on all-new principles; Babel takes the opposite approach, by just being distance-vector with some refinements. So please think of Babel as a proof of the statement that plain old DV can be made to work in mesh networks. It is certainly not meant to compete with OSPF. 2. About blackholes ******************* > - Section 1.1, first paragraph: I don't think that the Babel routing > protocol is "black hole" free, at least if you define "black hole" > as a router in a network that has no route, for some period of time, > to a particular destination. I do understand that black holes will > not persist indefinitely. Agreed -- Babel ensures that blackholes will not persist indefinitely. This is just a way of saying that Babel eventually converges to an acceptable configuration. I'll fix this. (Since the draft leaves the route selection policy to the implementation, Babel does not, in general, converge to a tree of shortest paths, although it certainly does if route selection prefers smaller metrics.) > - Section 1.1, third bullet item (that reads "any routing black-holes > that may appear after a mobility event are corrected in a time at > most proportional to the network's diameter."). I think that this is > true *unless* the set of one or more "explicit requests to the > source for a new sequence number" (described in 2.6) are all lost. You are right, this assumes that the number of requests is such that the probability of that happening is negligible. I have no objection to making that explicit. 3. About requests and seqnos **************************** As you've justly noted, the mechanisms used for avoiding starvation are the most tricky parts of Babel. The algorithms described in the draft are certainly not the only ones that work; however, they are the ones currently implemented in Babel, and they have been shown to work reasonably well in practice. This is to say that while improvements are doubtless possible, this draft is meant to describe the set of algorithms currently implemented; and I'd be unwilling to describe any behaviour in the draft unless it's been implemented and the implementation's behaviour evaluated experimentall= y. > It is probably worth mentioning that in general for some or even many > nodes there will be no way to route the explicit request back to the > source, but... Seeing it written down in your words is extremely helpful. Thanks for this paragraph. > - Section 3.2.1 mentions that sequence numbers are incremented > whenever a node receives a request for a new sequence number. Given > that these requests are not sent reliably, it is probably a good > idea for the node to also update its sequence number periodically, > and to mention this in this section. (Assuming that sequence numbers > already area updated periodically based on timeout, this becomes an > editorial comment.) As explained by private mail, this is not the case -- unlike in DSDV, a node never spontaneously increases its seqno. I'll make that clear. > - In section 3.2.6 you talk about the table of pending segno requests > [...] I don't understand the triplet (neigh, seqno, neighbour). [...] > Some more explanation seems to be needed for this section. This is a typo, as you suspected. I'll fix and expand this section. 4. About poison reverse *********************** > - Section 3.7.4: "Since Babel does not suffer from routing loops, > split horizon with poison reverse SHOULD NOT be used." [...] I was the > one who originally came up with the idea of poison reverse [...] (Shakes hands.) > Poison reverse is therefore simply the equivalent to your route > withdrawal. As such this sentence doesn't seem to make much sense. Hmm. I was under the impression that poison reverse is more than just explicit retractions, since it consists in advertising a reverse unreachable route for an unbounded amount of time. However, I have no strong feelings about this sentence, please let me know if you if you insist that it should be removed. 5. About being loop-free ************************ > Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as > you explain in the introduction). Well, Babel is loop-free in a mesh network (only host routes) with at most on Internet gateway. Since this is the only case that the existing literature on mesh networking even considers, Babel is loop-free in the same sense as, say, DSDV or AODV/DYMO are loop-free. > Perhaps "nearly loop-free" might be more precise. (the same issue > applies to the first sentence of section 2) I'll do that. Thanks again for your review, Juliusz From rcallon@juniper.net Wed Oct 13 20:41:06 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341863A68A9 for ; Wed, 13 Oct 2010 20:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6zrk0Z7rva for ; Wed, 13 Oct 2010 20:41:04 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 422DC3A6863 for ; Wed, 13 Oct 2010 20:40:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTLZ8FekYQxq4kLHhWe4ONslV3pkyg9h2@postini.com; Wed, 13 Oct 2010 20:42:22 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Oct 2010 20:41:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 13 Oct 2010 23:41:55 -0400 From: Ross Callon To: Juliusz Chroboczek Date: Wed, 13 Oct 2010 23:41:53 -0400 Thread-Topic: Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 Thread-Index: ActmOxAKRd6ROMgST5mFqMIkrunZ6wEtnb5g Message-ID: References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel , Stewart Bryant Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 03:41:06 -0000 Regarding whether to update the document: Strictly speaking, my authority i= n reviewing this document is solely as an advisor to the routing ADs. Thus = it is actually up to you and the routing ADs what if anything you do with t= hese comments. That being said, I think that it is reasonable for you to up= date the document based on these comments and our email exchange, and I wou= ld be very surprised if the routing ADs felt differently. Also, you might w= ant to get this in before the ID cutoff date (which is quite soon) -- alter= nately you would need to wait until the IETF starts in Beijing (whether you= are there or not).=20 I am fine with your comments, and have only two additional points (one of w= hich is an agreement with a proposed update from your email).=20 Regarding section 3.7.4, I agree with your suggestion in your email below t= o remove the sentence (which is actually its own paragraph) which reads:=20 Since Babel does not suffer from routing loops, split horizon with poison reverse SHOULD NOT be used. In section 3.8.2.1 (Avoiding Starvation), you specify that "In order to com= pensate for packet loss, a node SHOULD repeat such a request a small number= of times if no route becomes feasible within a short time." I continue to= be concerned that it is possible, although admittedly a rare event, that a= ll such requests will be lost, resulting in a stuck routing state. Of cours= e I also see that we don't want to keep retransmitting seqno requests forev= er in the case that a destination has actually gone away and will never ret= urn. It would seem to me that this sort of problem (stuck routing to the n= ode which is still in the network) is most likely when the network is going= through some sort of ugly near-partition where the network is partitioned = for a very short period of time, or is almost partitioned in the sense that= a link that corrects a potential partition comes up at pretty much the sam= e time that the link that would have caused the potential partition fails. = I am thinking that some discussion of this might want to be added. One poss= ible approach might be along the lines of: In principle, if all seqno requests are lost, it may be possible for = the=20 network to get stuck in a state where no feasible route exists to a=20 particular destination and all nodes have stopped retransmitting seqn= o requests for that destination. Depending upon operational results, fu= ture versions of this document might require that nodes with no feasible r= oute to a particular destination, but which have neighbors who are adverti= sing routes to that destination (which therefore must be unfeasible), cont= inue to transmit seqno requests on a low-frequency basis until either a feasible route is received, or the node no longer has a neighbor advertising a (non-feasible) route to the destination.=20 Thanks, Ross =20 -----Original Message----- From: Juliusz Chroboczek [mailto:Juliusz.Chroboczek@pps.jussieu.fr]=20 Sent: Thursday, October 07, 2010 12:15 PM To: Ross Callon Cc: Adrian Farrel; Stewart Bryant; rtg-dir@ietf.org Subject: Re: Rtg Directorate review of draft-chroboczek-babel-routing-proto= col-04 Dear Mr. Callon, Thank you very much for your thoughtful review of draft-chroboczek-babel-routing-protocol-04. I agree with most of your comments, for which many thanks. In the following, I'm only replying to those points that I disagree with, or that otherwise deserve being discussed. Please let me know whether I should produce a -05 now, or whether I should wait for some further event. 1. Why a new protocol ********************* > It is not clear to me why the world needs another routing protocol, > although experiments can be useful. While the world certainly doesn't need a new routing protocol for stable, well-administered wired networks, Babel has been shown to be suitable for networks built with sticks and pieces of string ("wireless mesh networks"). Much of the research in this area (AODV/DYMO, OLSR) is about designing protocols based on all-new principles; Babel takes the opposite approach, by just being distance-vector with some refinements. So please think of Babel as a proof of the statement that plain old DV can be made to work in mesh networks. It is certainly not meant to compete with OSPF. 2. About blackholes ******************* > - Section 1.1, first paragraph: I don't think that the Babel routing > protocol is "black hole" free, at least if you define "black hole" > as a router in a network that has no route, for some period of time, > to a particular destination. I do understand that black holes will > not persist indefinitely. Agreed -- Babel ensures that blackholes will not persist indefinitely. This is just a way of saying that Babel eventually converges to an acceptable configuration. I'll fix this. (Since the draft leaves the route selection policy to the implementation, Babel does not, in general, converge to a tree of shortest paths, although it certainly does if route selection prefers smaller metrics.) > - Section 1.1, third bullet item (that reads "any routing black-holes > that may appear after a mobility event are corrected in a time at > most proportional to the network's diameter."). I think that this is > true *unless* the set of one or more "explicit requests to the > source for a new sequence number" (described in 2.6) are all lost. You are right, this assumes that the number of requests is such that the probability of that happening is negligible. I have no objection to making that explicit. 3. About requests and seqnos **************************** As you've justly noted, the mechanisms used for avoiding starvation are the most tricky parts of Babel. The algorithms described in the draft are certainly not the only ones that work; however, they are the ones currently implemented in Babel, and they have been shown to work reasonably well in practice. This is to say that while improvements are doubtless possible, this draft is meant to describe the set of algorithms currently implemented; and I'd be unwilling to describe any behaviour in the draft unless it's been implemented and the implementation's behaviour evaluated experimentall= y. > It is probably worth mentioning that in general for some or even many > nodes there will be no way to route the explicit request back to the > source, but... Seeing it written down in your words is extremely helpful. Thanks for this paragraph. > - Section 3.2.1 mentions that sequence numbers are incremented > whenever a node receives a request for a new sequence number. Given > that these requests are not sent reliably, it is probably a good > idea for the node to also update its sequence number periodically, > and to mention this in this section. (Assuming that sequence numbers > already area updated periodically based on timeout, this becomes an > editorial comment.) As explained by private mail, this is not the case -- unlike in DSDV, a node never spontaneously increases its seqno. I'll make that clear. > - In section 3.2.6 you talk about the table of pending segno requests > [...] I don't understand the triplet (neigh, seqno, neighbour). [...] > Some more explanation seems to be needed for this section. This is a typo, as you suspected. I'll fix and expand this section. 4. About poison reverse *********************** > - Section 3.7.4: "Since Babel does not suffer from routing loops, > split horizon with poison reverse SHOULD NOT be used." [...] I was the > one who originally came up with the idea of poison reverse [...] (Shakes hands.) > Poison reverse is therefore simply the equivalent to your route > withdrawal. As such this sentence doesn't seem to make much sense. Hmm. I was under the impression that poison reverse is more than just explicit retractions, since it consists in advertising a reverse unreachable route for an unbounded amount of time. However, I have no strong feelings about this sentence, please let me know if you if you insist that it should be removed. 5. About being loop-free ************************ > Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as > you explain in the introduction). Well, Babel is loop-free in a mesh network (only host routes) with at most on Internet gateway. Since this is the only case that the existing literature on mesh networking even considers, Babel is loop-free in the same sense as, say, DSDV or AODV/DYMO are loop-free. > Perhaps "nearly loop-free" might be more precise. (the same issue > applies to the first sentence of section 2) I'll do that. Thanks again for your review, Juliusz From stbryant@cisco.com Thu Oct 14 03:53:23 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A783A68B7 for ; Thu, 14 Oct 2010 03:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEjiJ2je4onT for ; Thu, 14 Oct 2010 03:53:22 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C9E8B3A6A38 for ; Thu, 14 Oct 2010 03:53:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGN+tkxAZnwM/2dsb2JhbAChInGefYI2DAGaHYVIBIpB X-IronPort-AV: E=Sophos;i="4.57,329,1283731200"; d="scan'208";a="170390943" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2010 10:54:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9EAsd6I013530; Thu, 14 Oct 2010 10:54:39 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9EAsZ823909; Thu, 14 Oct 2010 11:54:36 +0100 (BST) Message-ID: <4CB6E16B.6010703@cisco.com> Date: Thu, 14 Oct 2010 11:54:35 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ross Callon References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Juliusz Chroboczek , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 10:53:23 -0000 I agree with Ross here. Please update the document. Thanks Stewart On 14/10/2010 04:41, Ross Callon wrote: > Regarding whether to update the document: Strictly speaking, my authori= ty in reviewing this document is solely as an advisor to the routing ADs.= Thus it is actually up to you and the routing ADs what if anything you d= o with these comments. That being said, I think that it is reasonable for= you to update the document based on these comments and our email exchang= e, and I would be very surprised if the routing ADs felt differently. Als= o, you might want to get this in before the ID cutoff date (which is quit= e soon) -- alternately you would need to wait until the IETF starts in Be= ijing (whether you are there or not). > > I am fine with your comments, and have only two additional points (one = of which is an agreement with a proposed update from your email). > > > Regarding section 3.7.4, I agree with your suggestion in your email bel= ow to remove the sentence (which is actually its own paragraph) which rea= ds: > > Since Babel does not suffer from routing loops, split horizon with > poison reverse SHOULD NOT be used. > > > In section 3.8.2.1 (Avoiding Starvation), you specify that "In order to= compensate for packet loss, a node SHOULD repeat such a request a small = number of times if no route becomes feasible within a short time." I con= tinue to be concerned that it is possible, although admittedly a rare eve= nt, that all such requests will be lost, resulting in a stuck routing sta= te. Of course I also see that we don't want to keep retransmitting seqno = requests forever in the case that a destination has actually gone away an= d will never return. It would seem to me that this sort of problem (stuc= k routing to the node which is still in the network) is most likely when = the network is going through some sort of ugly near-partition where the n= etwork is partitioned for a very short period of time, or is almost parti= tioned in the sense that a link that corrects a potential partition comes= up at pretty much the same time that the link that would have caused the= potential partition fails. I am thinking that some discussion of this mi= ght want to be added. One possible approach might be along the lines of: > > In principle, if all seqno requests are lost, it may be possible= for the > network to get stuck in a state where no feasible route exists t= o a > particular destination and all nodes have stopped retransmitting= seqno > requests for that destination. Depending upon operational result= s, future > versions of this document might require that nodes with no feasi= ble route > to a particular destination, but which have neighbors who are ad= vertising > routes to that destination (which therefore must be unfeasible),= continue > to transmit seqno requests on a low-frequency basis until either= a > feasible route is received, or the node no longer has a neighbor= > advertising a (non-feasible) route to the destination. > > Thanks, Ross > > > -----Original Message----- > From: Juliusz Chroboczek [mailto:Juliusz.Chroboczek@pps.jussieu.fr] > Sent: Thursday, October 07, 2010 12:15 PM > To: Ross Callon > Cc: Adrian Farrel; Stewart Bryant; rtg-dir@ietf.org > Subject: Re: Rtg Directorate review of draft-chroboczek-babel-routing-p= rotocol-04 > > Dear Mr. Callon, > > Thank you very much for your thoughtful review of > draft-chroboczek-babel-routing-protocol-04. > > I agree with most of your comments, for which many thanks. In the > following, I'm only replying to those points that I disagree with, or > that otherwise deserve being discussed. > > Please let me know whether I should produce a -05 now, or whether > I should wait for some further event. > > > 1. Why a new protocol > ********************* > >> It is not clear to me why the world needs another routing protocol, >> although experiments can be useful. > While the world certainly doesn't need a new routing protocol for > stable, well-administered wired networks, Babel has been shown to be > suitable for networks built with sticks and pieces of string ("wireless= > mesh networks"). Much of the research in this area (AODV/DYMO, OLSR) i= s > about designing protocols based on all-new principles; Babel takes the > opposite approach, by just being distance-vector with some refinements.= > > So please think of Babel as a proof of the statement that plain old DV > can be made to work in mesh networks. It is certainly not meant to > compete with OSPF. > > > 2. About blackholes > ******************* > >> - Section 1.1, first paragraph: I don't think that the Babel routing >> protocol is "black hole" free, at least if you define "black hole" >> as a router in a network that has no route, for some period of time= , >> to a particular destination. I do understand that black holes will >> not persist indefinitely. > Agreed -- Babel ensures that blackholes will not persist indefinitely. > This is just a way of saying that Babel eventually converges to an > acceptable configuration. I'll fix this. > > (Since the draft leaves the route selection policy to the > implementation, Babel does not, in general, converge to a tree of > shortest paths, although it certainly does if route selection prefers > smaller metrics.) > >> - Section 1.1, third bullet item (that reads "any routing black-holes >> that may appear after a mobility event are corrected in a time at >> most proportional to the network's diameter."). I think that this i= s >> true *unless* the set of one or more "explicit requests to the >> source for a new sequence number" (described in 2.6) are all lost. > You are right, this assumes that the number of requests is such that th= e > probability of that happening is negligible. I have no objection to > making that explicit. > > > 3. About requests and seqnos > **************************** > > As you've justly noted, the mechanisms used for avoiding starvation are= > the most tricky parts of Babel. The algorithms described in the draft > are certainly not the only ones that work; however, they are the ones > currently implemented in Babel, and they have been shown to work > reasonably well in practice. > > This is to say that while improvements are doubtless possible, this > draft is meant to describe the set of algorithms currently implemented;= > and I'd be unwilling to describe any behaviour in the draft unless it's= > been implemented and the implementation's behaviour evaluated experimen= tally. > >> It is probably worth mentioning that in general for some or even many >> nodes there will be no way to route the explicit request back to the >> source, but... > Seeing it written down in your words is extremely helpful. Thanks for > this paragraph. > >> - Section 3.2.1 mentions that sequence numbers are incremented >> whenever a node receives a request for a new sequence number. Given= >> that these requests are not sent reliably, it is probably a good >> idea for the node to also update its sequence number periodically, >> and to mention this in this section. (Assuming that sequence number= s >> already area updated periodically based on timeout, this becomes an= >> editorial comment.) > As explained by private mail, this is not the case -- unlike in DSDV, > a node never spontaneously increases its seqno. I'll make that clear. > >> - In section 3.2.6 you talk about the table of pending segno requests >> [...] I don't understand the triplet (neigh, seqno, neighbour). [.= =2E.] >> Some more explanation seems to be needed for this section. > This is a typo, as you suspected. I'll fix and expand this section. > > > 4. About poison reverse > *********************** > >> - Section 3.7.4: "Since Babel does not suffer from routing loops, >> split horizon with poison reverse SHOULD NOT be used." [...] I was the= >> one who originally came up with the idea of poison reverse [...] > (Shakes hands.) > >> Poison reverse is therefore simply the equivalent to your route >> withdrawal. As such this sentence doesn't seem to make much sense. > Hmm. I was under the impression that poison reverse is more than just > explicit retractions, since it consists in advertising a reverse > unreachable route for an unbounded amount of time. However, I have no > strong feelings about this sentence, please let me know if you if you > insist that it should be removed. > > > 5. About being loop-free > ************************ > >> Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as >> you explain in the introduction). > Well, Babel is loop-free in a mesh network (only host routes) with at > most on Internet gateway. Since this is the only case that the existin= g > literature on mesh networking even considers, Babel is loop-free in the= > same sense as, say, DSDV or AODV/DYMO are loop-free. > >> Perhaps "nearly loop-free" might be more precise. (the same issue >> applies to the first sentence of section 2) > I'll do that. > > > Thanks again for your review, > > Juliusz > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Mon Oct 18 06:14:51 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE31D3A6DA9 for ; Mon, 18 Oct 2010 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M1IEaaeAAOw for ; Mon, 18 Oct 2010 06:14:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1BE583A6BC3 for ; Mon, 18 Oct 2010 06:14:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG/lu0xAZnwN/2dsb2JhbAChLHGgdII4DAGZXIVJBIpK X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="171806920" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2010 13:16:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9IDGEsC027676; Mon, 18 Oct 2010 13:16:14 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9IDGB806918; Mon, 18 Oct 2010 14:16:12 +0100 (BST) Message-ID: <4CBC489B.1040001@cisco.com> Date: Mon, 18 Oct 2010 14:16:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Juliusz Chroboczek References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 13:14:51 -0000 Juliusz I apologize for my earlier email (I am relatively new to the AD role). As this is an independent stream document the content needs to be agreed between you and the RFC editor. I can only request changes to the document. However I believe that the changes need to address Ross's concerns would significantly improve the document, and would request that you make them. Thanks Stewart On 07/10/2010 17:15, Juliusz Chroboczek wrote: > Dear Mr. Callon, > > Thank you very much for your thoughtful review of > draft-chroboczek-babel-routing-protocol-04. > > I agree with most of your comments, for which many thanks. In the > following, I'm only replying to those points that I disagree with, or > that otherwise deserve being discussed. > > Please let me know whether I should produce a -05 now, or whether > I should wait for some further event. > > > 1. Why a new protocol > ********************* > >> It is not clear to me why the world needs another routing protocol, >> although experiments can be useful. > While the world certainly doesn't need a new routing protocol for > stable, well-administered wired networks, Babel has been shown to be > suitable for networks built with sticks and pieces of string ("wireless > mesh networks"). Much of the research in this area (AODV/DYMO, OLSR) is > about designing protocols based on all-new principles; Babel takes the > opposite approach, by just being distance-vector with some refinements. > > So please think of Babel as a proof of the statement that plain old DV > can be made to work in mesh networks. It is certainly not meant to > compete with OSPF. > > > 2. About blackholes > ******************* > >> - Section 1.1, first paragraph: I don't think that the Babel routing >> protocol is "black hole" free, at least if you define "black hole" >> as a router in a network that has no route, for some period of time, >> to a particular destination. I do understand that black holes will >> not persist indefinitely. > Agreed -- Babel ensures that blackholes will not persist indefinitely. > This is just a way of saying that Babel eventually converges to an > acceptable configuration. I'll fix this. > > (Since the draft leaves the route selection policy to the > implementation, Babel does not, in general, converge to a tree of > shortest paths, although it certainly does if route selection prefers > smaller metrics.) > >> - Section 1.1, third bullet item (that reads "any routing black-holes >> that may appear after a mobility event are corrected in a time at >> most proportional to the network's diameter."). I think that this is >> true *unless* the set of one or more "explicit requests to the >> source for a new sequence number" (described in 2.6) are all lost. > You are right, this assumes that the number of requests is such that the > probability of that happening is negligible. I have no objection to > making that explicit. > > > 3. About requests and seqnos > **************************** > > As you've justly noted, the mechanisms used for avoiding starvation are > the most tricky parts of Babel. The algorithms described in the draft > are certainly not the only ones that work; however, they are the ones > currently implemented in Babel, and they have been shown to work > reasonably well in practice. > > This is to say that while improvements are doubtless possible, this > draft is meant to describe the set of algorithms currently implemented; > and I'd be unwilling to describe any behaviour in the draft unless it's > been implemented and the implementation's behaviour evaluated experimentally. > >> It is probably worth mentioning that in general for some or even many >> nodes there will be no way to route the explicit request back to the >> source, but... > Seeing it written down in your words is extremely helpful. Thanks for > this paragraph. > >> - Section 3.2.1 mentions that sequence numbers are incremented >> whenever a node receives a request for a new sequence number. Given >> that these requests are not sent reliably, it is probably a good >> idea for the node to also update its sequence number periodically, >> and to mention this in this section. (Assuming that sequence numbers >> already area updated periodically based on timeout, this becomes an >> editorial comment.) > As explained by private mail, this is not the case -- unlike in DSDV, > a node never spontaneously increases its seqno. I'll make that clear. > >> - In section 3.2.6 you talk about the table of pending segno requests >> [...] I don't understand the triplet (neigh, seqno, neighbour). [...] >> Some more explanation seems to be needed for this section. > This is a typo, as you suspected. I'll fix and expand this section. > > > 4. About poison reverse > *********************** > >> - Section 3.7.4: "Since Babel does not suffer from routing loops, >> split horizon with poison reverse SHOULD NOT be used." [...] I was the >> one who originally came up with the idea of poison reverse [...] > (Shakes hands.) > >> Poison reverse is therefore simply the equivalent to your route >> withdrawal. As such this sentence doesn't seem to make much sense. > Hmm. I was under the impression that poison reverse is more than just > explicit retractions, since it consists in advertising a reverse > unreachable route for an unbounded amount of time. However, I have no > strong feelings about this sentence, please let me know if you if you > insist that it should be removed. > > > 5. About being loop-free > ************************ > >> Nits: - Abstract: Strictly speaking, Babel is not quite loop-free (as >> you explain in the introduction). > Well, Babel is loop-free in a mesh network (only host routes) with at > most on Internet gateway. Since this is the only case that the existing > literature on mesh networking even considers, Babel is loop-free in the > same sense as, say, DSDV or AODV/DYMO are loop-free. > >> Perhaps "nearly loop-free" might be more precise. (the same issue >> applies to the first sentence of section 2) > I'll do that. > > > Thanks again for your review, > > Juliusz > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Juliusz.Chroboczek@pps.jussieu.fr Mon Oct 18 10:47:36 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111193A6D9C for ; Mon, 18 Oct 2010 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv32GSTl+B4i for ; Mon, 18 Oct 2010 10:47:31 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by core3.amsl.com (Postfix) with ESMTP id BEA293A6B90 for ; Mon, 18 Oct 2010 10:47:29 -0700 (PDT) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id o9IHmitB019261 ; Mon, 18 Oct 2010 19:48:45 +0200 (CEST) X-Ids: 168 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id o9IHmc7L018138 ; Mon, 18 Oct 2010 19:48:39 +0200 Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1P7tp8-0002aE-PH; Mon, 18 Oct 2010 19:48:38 +0200 From: Juliusz Chroboczek To: stbryant@cisco.com References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> <4CBC489B.1040001@cisco.com> Date: Mon, 18 Oct 2010 19:48:38 +0200 In-Reply-To: <4CBC489B.1040001@cisco.com> (Stewart Bryant's message of "Mon, 18 Oct 2010 14:16:11 +0100") Message-ID: <7i8w1vjssp.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4CBC887C.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4CBC887C.001/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ X-Mailman-Approved-At: Mon, 18 Oct 2010 12:54:58 -0700 Cc: Juliusz Chroboczek , Ross Callon , Adrian Farrel , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 17:47:37 -0000 > I apologize for my earlier email [...] However I believe that the > changes need to address Ross's concerns would significantly improve > the document I'm not sure what you're apologising for -- your feedback is very much appreciated. I've got a few urgent things to do right now (October is not the most easy time of the year for us University lecturers), but I'll certainly submit a -05 in time for the deadline. Ross said: > I believe that this document should have the standard warning that it > is not a product of the IETF and is not a candidate for standardization > at any level. Could you please provide me with the suitable boilerplate? Thanks, Juliusz From Adrian.Farrel@huawei.com Mon Oct 18 13:41:19 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0B93A6BB3 for ; Mon, 18 Oct 2010 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nd5EmWqTDPY for ; Mon, 18 Oct 2010 13:41:18 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 02B723A6A12 for ; Mon, 18 Oct 2010 13:41:18 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI00LG76VAB0@usaga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Oct 2010 15:42:46 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAI0035J6V7EX@usaga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Oct 2010 15:42:46 -0500 (CDT) Date: Mon, 18 Oct 2010 21:40:20 +0100 From: Adrian Farrel To: Routing Area Directorate Message-id: <0CA35F63E9A641B0BED0B096D57AFF9A@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [RTG-DIR] New Directorate Member X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:41:19 -0000 Hi, Please welcome Alia Atlas to your esteemed ranks. Secretaries, please add Alia as akatlas@gmail.com to your spreadsheets. Thanks, Adrian From Adrian.Farrel@huawei.com Mon Oct 18 13:41:20 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F173A6A12 for ; Mon, 18 Oct 2010 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzQc8gy9k7O6 for ; Mon, 18 Oct 2010 13:41:19 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 150143A6AA7 for ; Mon, 18 Oct 2010 13:41:19 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI00LGE6VCB0@usaga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Oct 2010 15:42:48 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAI0035J6V7EX@usaga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Oct 2010 15:42:48 -0500 (CDT) Date: Mon, 18 Oct 2010 21:42:33 +0100 From: Adrian Farrel To: Juliusz Chroboczek , stbryant@cisco.com Message-id: <3DCF3C691E6E4582A025FA29118D8C57@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> <4CBC489B.1040001@cisco.com> <7i8w1vjssp.fsf@lanthane.pps.jussieu.fr> Cc: Juliusz Chroboczek , Ross Callon , rtg-dir@ietf.org Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:41:20 -0000 Hi, > Ross said: > >> I believe that this document should have the standard warning that it >> is not a product of the IETF and is not a candidate for standardization >> at any level. > > Could you please provide me with the suitable boilerplate? Don't worry about that. It is something that the RFC Editor will drop in right at the last minute if he agrees with the IESG that it should be there. We'll take care of suggesting it, and he'll take care of inserting it. Cheers, Adrian From jmh@joelhalpern.com Mon Oct 18 13:44:13 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB95E3A6AA7 for ; Mon, 18 Oct 2010 13:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaMV7uU2GHR6 for ; Mon, 18 Oct 2010 13:44:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7F0763A6BF1 for ; Mon, 18 Oct 2010 13:44:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CA1743236DB5; Mon, 18 Oct 2010 13:45:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-141.clppva.btas.verizon.net [71.161.51.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id E21BA3236DB2; Mon, 18 Oct 2010 13:45:40 -0700 (PDT) Message-ID: <4CBCB1F4.1020605@joelhalpern.com> Date: Mon, 18 Oct 2010 16:45:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Juliusz Chroboczek References: <7ihbgy9dyi.fsf@lanthane.pps.jussieu.fr> <4CBC489B.1040001@cisco.com> <7i8w1vjssp.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7i8w1vjssp.fsf@lanthane.pps.jussieu.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel , stbryant@cisco.com Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:44:14 -0000 I believe we no longer add such warning boilerplate. Instead, the document heading is clear as to what the track and intention of the document is. Yes, at one time the IESG asked for such warning on all documents. Yours, Joel On 10/18/2010 1:48 PM, Juliusz Chroboczek wrote: >> I apologize for my earlier email [...] However I believe that the >> changes need to address Ross's concerns would significantly improve >> the document > > I'm not sure what you're apologising for -- your feedback is very much > appreciated. I've got a few urgent things to do right now (October is > not the most easy time of the year for us University lecturers), but > I'll certainly submit a -05 in time for the deadline. > > Ross said: > >> I believe that this document should have the standard warning that it >> is not a product of the IETF and is not a candidate for standardization >> at any level. > > Could you please provide me with the suitable boilerplate? > > Thanks, > > Juliusz > From Juliusz.Chroboczek@pps.jussieu.fr Mon Oct 25 16:44:17 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF903A6918 for ; Mon, 25 Oct 2010 16:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hsvt953nIpT for ; Mon, 25 Oct 2010 16:44:16 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by core3.amsl.com (Postfix) with ESMTP id D647A3A6868 for ; Mon, 25 Oct 2010 16:44:15 -0700 (PDT) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id o9PNjjnn003507 ; Tue, 26 Oct 2010 01:45:45 +0200 (CEST) X-Ids: 168 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id o9PNjdDQ025904 ; Tue, 26 Oct 2010 01:45:40 +0200 Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1PAWjT-00065k-Gw; Tue, 26 Oct 2010 01:45:39 +0200 From: Juliusz Chroboczek To: Ross Callon References: Date: Tue, 26 Oct 2010 01:45:39 +0200 In-Reply-To: (Ross Callon's message of "Fri, 1 Oct 2010 12:49:47 -0400") Message-ID: <7i7hh5hm58.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4CC616A9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4CC616A9.001/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ X-Mailman-Approved-At: Tue, 26 Oct 2010 00:45:21 -0700 Cc: Juliusz Chroboczek , "rtg-dir@ietf.org" , Adrian Farrel , Stewart Bryant Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 23:44:17 -0000 Dear Ross, dear all, I have just submitted draft-chroboczek-babel-routing-protocol-05, which implements all but two of Ross's suggestions. Some discussion of the two exceptions follows. > - It might be worth mentioning somewhere that loop-free routing does > not strictly speaking ensure that one or more individual data packets > won't visit the same node twice (which some might think of as a loop). I've failed to do that. On the one hand, just mentioning it in passing has a very "oh, by the way, did I mention that" feel to it; on the other hand, this document is clearly not the right place for an extended chapter about the different notions of loop-freeness. Rather than a half-baked paragraph, I've simply decided to leave it as is. > - Section 1.2: Under "limitations", you could mention that since Babel > is a distance vector routing protocol it does not provide each router > with a full map of the topology. This prevents it from being > applicable in certain traffic engineering applications (reference > OSPF-TE and IS-IS-TE) and potentially in PCE applications. Since I know more or less nothing about TE, I feel a little uncomfortable citing your suggested references. The obvious workaround -- just mentioning that the global topology is not flooded, with either no further comments or the usual sentence or two about debugging networks -- feels awkward and unconvincing. Hence, I've simply omitted this suggestion. Thanks again for your review, Juliusz Chroboczek From stbryant@cisco.com Tue Oct 26 10:56:15 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848343A67F0 for ; Tue, 26 Oct 2010 10:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxtnA1q-YinK for ; Tue, 26 Oct 2010 10:56:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 54A033A6876 for ; Tue, 26 Oct 2010 10:56:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIizxkxAZnwM/2dsb2JhbAChTnGkTYI7DAGZeYVIBIpT X-IronPort-AV: E=Sophos;i="4.58,242,1286150400"; d="scan'208";a="175453136" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2010 17:58:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9QHw0wv022417; Tue, 26 Oct 2010 17:58:01 GMT Received: from dhcp-gpk02-vlan300-64-103-65-105.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9QHvw826854; Tue, 26 Oct 2010 18:57:59 +0100 (BST) Message-ID: <4CC716A6.4090909@cisco.com> Date: Tue, 26 Oct 2010 18:57:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Juliusz Chroboczek References: <7i7hh5hm58.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7i7hh5hm58.fsf@lanthane.pps.jussieu.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:56:15 -0000 On 26/10/2010 00:45, Juliusz Chroboczek wrote: > Dear Ross, dear all, > > I have just submitted draft-chroboczek-babel-routing-protocol-05, which > implements all but two of Ross's suggestions. > > Some discussion of the two exceptions follows. > >> - It might be worth mentioning somewhere that loop-free routing does >> not strictly speaking ensure that one or more individual data packets >> won't visit the same node twice (which some might think of as a loop). > I've failed to do that. On the one hand, just mentioning it in passing > has a very "oh, by the way, did I mention that" feel to it; on the other > hand, this document is clearly not the right place for an extended > chapter about the different notions of loop-freeness. Rather than > a half-baked paragraph, I've simply decided to leave it as is. >> - Section 1.2: Under "limitations", you could mention that since Babel >> is a distance vector routing protocol it does not provide each router >> with a full map of the topology. This prevents it from being >> applicable in certain traffic engineering applications (reference >> OSPF-TE and IS-IS-TE) and potentially in PCE applications. > Since I know more or less nothing about TE, I feel a little > uncomfortable citing your suggested references. The obvious > workaround -- just mentioning that the global topology is not flooded, > with either no further comments or the usual sentence or two about > debugging networks -- feels awkward and unconvincing. Hence, I've > simply omitted this suggestion. There are many applications that may wish to take advantage of the knowledge of the topology, not just TE. You could say: ==== Since Babel is a distance vector routing protocol it does not provide each router with a full map of the topology. In the case where a network application, such as TE, needs some knowledge beyond its immediate neighborhood, Babel would need to be enhanced to deliver that knowledge, possibly by including knowledge of the application within the Babel protocol. ==== I have some direct experience of this. As an intellectual exercise we decided to make notvia fast reroute work with RIP. Conventional wisdom was that since this needed knowledge of the network topology we could not make this work. The trick was to flood the re-route information everywhere and by selective address filtering get RIP to do the calculation for us. I can't remember off hand, but do you note that the normal problem with DV, and hence the reason that we went to LS is that LS converges much faster then DV. All these remarks are review that you are of course free to include or not. When you have a version that you are happy to proceed with I will process it through the IESG, which will be some time after the next IETF. - Stewart From Juliusz.Chroboczek@pps.jussieu.fr Thu Oct 28 09:29:19 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855C93A681B for ; Thu, 28 Oct 2010 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goolaWhSYw1F for ; Thu, 28 Oct 2010 09:29:18 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by core3.amsl.com (Postfix) with ESMTP id 289B33A6834 for ; Thu, 28 Oct 2010 09:29:17 -0700 (PDT) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id o9SGUeth052724 ; Thu, 28 Oct 2010 18:30:41 +0200 (CEST) X-Ids: 164 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id o9SGUOgY003636 ; Thu, 28 Oct 2010 18:30:29 +0200 Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1PBVMu-00076b-B1; Thu, 28 Oct 2010 18:30:24 +0200 From: Juliusz Chroboczek To: stbryant@cisco.com References: <7i7hh5hm58.fsf@lanthane.pps.jussieu.fr> <4CC716A6.4090909@cisco.com> Date: Thu, 28 Oct 2010 18:30:24 +0200 In-Reply-To: <4CC716A6.4090909@cisco.com> (Stewart Bryant's message of "Tue, 26 Oct 2010 18:57:58 +0100") Message-ID: <7ir5fa8elb.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4CC9A531.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4CC9A531.000/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ X-Mailman-Approved-At: Fri, 29 Oct 2010 02:07:20 -0700 Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:29:19 -0000 > There are many applications that may wish to take advantage of the > knowledge of the topology, not just TE. I have no doubts about that; however, I have no personal experience with such applications, and anything I know about it is pure hearsay; for that reason, I'd be a little nervous about including anything on this subject in a document of which I am the author. > All these remarks are review that you are of course free to include or > not. > > When you have a version that you are happy to proceed with I will > process it through the IESG, which will be some time after the next > IETF. I've re-read the current version, and I am happy with it. I'd be grateful if you could process it. Thanks, Juliusz From nomcom2010@gmail.com Thu Oct 28 20:59:13 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D2B3A69EC; Thu, 28 Oct 2010 20:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.643 X-Spam-Level: X-Spam-Status: No, score=-103.643 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeRYbBOUTwUi; Thu, 28 Oct 2010 20:59:12 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 80ABA3A680E; Thu, 28 Oct 2010 20:59:11 -0700 (PDT) Received: by qyk1 with SMTP id 1so5829892qyk.10 for ; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SGIwT1Hf5VGLR+RTMpiG3/diVhRiCweq4JVck5hf97Q=; b=DXHggXYmK5fmd/FnJyglfcK42Utp3XuX8hB61Mab2XGcZGWZMaW7N8OVpcggMWuN6c 8PTtXkmZZtRX4hhkETyRo5dAUGTLFXwQ2tj1JBbsixa64YWNZHz1M4aoES4AUQnLFdg1 ZLS7D7VVZLWZJWEmLduZ0ADdNl4FPpc/4PhTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=ZDo2XpXLGJQu0PBiScEYI6DDdXw4hEXOfahqdZkxbvkwKqUYJ507ITZu6F2F+8TR95 Wa2lyHqg27Hau3p5bcKKkVVhrtfAC2Sg1joCqY0UEulEKVtdDkQR23Dsrd3lLy9iATA8 pnK2dFCwU0U+qCXVv3sIuClPKW0sVIlbXuqts= MIME-Version: 1.0 Received: by 10.229.96.130 with SMTP id h2mr10143109qcn.284.1288324864439; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) Sender: nomcom2010@gmail.com Received: by 10.220.72.74 with HTTP; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) Date: Thu, 28 Oct 2010 21:01:04 -0700 X-Google-Sender-Auth: ChdaKG7zm8SnWLZ8AiqdYXSvobk Message-ID: From: NomCom-Chair To: nomcom-chair@ietf.org Content-Type: multipart/alternative; boundary=001636426cebe675f90493b98147 X-Mailman-Approved-At: Fri, 29 Oct 2010 02:07:20 -0700 Subject: [RTG-DIR] Invitation to provide IETF Nominee Feedback X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 03:59:13 -0000 --001636426cebe675f90493b98147 Content-Type: text/plain; charset=ISO-8859-1 Nomcom 2010-2011 requests your input on the willing nominees for the IETF open positions. We request that as much as possible, comments are provided within two weeks of the receipt of this email. Please provide comments as soon as possible and no later than November 12th. Comments received after the Beijing meeting may receive less consideration, although we will make every effort to consider any and all input. The feedback form is available at the following URL: https://wiki.tools.ietf.org/group/nomcom/10/input/ Note, you must have an IETF tools login to respond to this invitation. If you do not have one, http://www1.tools.ietf.org/newlogin can be used to get one. The web-based feedback tool gives the NomCom an automated process for collecting input on the nominees. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. When you access the feedback form, you will see a list of all of the willing nominees. By clicking on a nominee's name, you will be presented with a text-input form into which you can type your input. While we encourage feedback through the form, you may send feedback to the nomcom list, nomcom10@ietf.org, directly. Community feedback is essential for the nomcom process to be effective. Notes on comparison of nominees to each other are also useful to the nomcom. You are also encouraged to provide notes on how a nominee satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the nominee has a different set of skills necessary for the job and those skills are different from the posted requirements, please provide details. If you prefer to provide anonymous input, please send it directly to the nomcom chair, Tom Walsh, or any other member of the nomcom and request them to anonymize your input. All information provided to the nomcom and the sources of such information are confidential. Thanks in advance for your feedback. Regards, Thomas Walsh NomCom 2010-11 nomcom10@ietf.org nomcom-chair@ietf.org --001636426cebe675f90493b98147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Nomcom 2010-2011 requests your input on the willing nominees for the IETF open positions.

We request that as much as possible, comments are provided within two weeks of the receipt of this email.=A0 Please provide comments as soon as=
possible and no later than November 12th.=A0 Comments received after t= he
Beijing meeting may receive less consideration, although we will make every=
effort to consider any and all input.

The feedback form is available at the following URL:
=A0 https://wiki.tools.ietf.= org/group/nomcom/10/input/

Note, you must have an IETF tools login to respond to this invitation. <= br>If you do not have one,
=A0=A0=A0 http://www1.tools.ietf.org/newlogin
can be used to get= one.

The web-based feedback tool gives the NomCom an automated process for collecting input on the nominees.=A0 Your input will be encrypted before =
it is stored by the feedback tool, and can only be decrypted by the Nom= Com.=A0

When you access the feedback form, you will see a list of all of the willing nominees.=A0 By clicking on a nominee's name, you will be pres= ented
with a text-input form into which you can type your input.=A0

While we encourage feedback through the form, you may send feedback to <= br>the nomcom list, nomcom10@ietf.org<= /a>, directly.

Community feedback is essential for the nomcom process to be effective. =
Notes on comparison of nominees to each other are also useful to the nomcom. You are also encouraged to provide notes on how a nominee
satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the <= br>nominee has a different set of skills necessary for the job and those skills are different from the posted requirements, please provide
details.

If you prefer to provide anonymous input, please send it directly to the nomcom chair, Tom Walsh, or any other member of the nomcom and
req= uest them to anonymize your input.=A0 All information provided to the
nomcom and the sources of such information are confidential.
Thanks in = advance for your feedback.

Regards,
Thomas Walsh
NomCom 2010-11 nomcom10@ietf.org
nomcom-chair@ietf.org


=A0

--001636426cebe675f90493b98147--