Dan, Comments inline. Coauthors: rNNN refers to svn revision.
On 18/09/2014 11:27, Romascanu, Dan (Dan) wrote: [...] > 1. The reference [RS-ARCH] mentioned in 4.2.1.1 and 4.2.1.2 is not > reachable (Error 404). As the understanding of the issues described in the > two sections depend on this reference, a valid reference is required. This has now been updated to a fresh link (svn r101). The location of this URL has not been static over the years, which means that in future, a web search may be required to locate it. The information included in the reference was deliberately chosen to ensure that it could be found by a future web search. > 2. Section 4.2.1.3 uses the term ‘flat layer 2 network’ which has at > least two meanings depending on the context or layer – either one VLAN > space at the link layer (as to differentiate from Customer VLAN and > Provider VLAN) or a bridged network with no routers between the bridged > segments. Clarification is needed. changed to "deployed at IXPs where all connected routers are on the same layer 2 broadcast domain". r102. > 3. The usage of keywords is inconsistent in a few place. In 4.6.1 the > ‘should’ in the second paragraph needs to be capitalized. In 4.6.3 we have > a capitalized SHOULD, but then a non-capitalized ‘may’ for statements that > both seem to describe requirements of the same level. mmm, the great rfc2119 debate. SHOULD is better in this paragraph. MAY won't work for the other points. r103. (oops, just noticed another typo in the previous paragraph too - r104.) > 4. I am doubt that Section 4.7 is that useful. On one hand > reliability of layer 2 forwarding is not in my opinion such a big issue, > and measures can be taken a the link layer to improve it (use lags or > redundant paths). Second the recommended mitigation (RFC 5881 BFD) is > described as non-optimal, with no other alternative. I would just drop this > section completely. Practical experience shows that this happens from time to time, caused by things like e.g. broken transceivers on an individual LAG bearer link, misconfigured VPLS LSPs and so forth. In fact, at the end of Sep, we had a serious problem at INEX for several hours due to a suspected ASIC misprogramming event on a switch. ICMP monitoring probes didn't detect this and BGP sessions on all affected routers stayed up but ~90-95% of regular traffic was dropped. Full failure is fine because traffic will be rerouted; partial failure like this which causes traffic to be blackholed is devastating for the affected parties when it happens. Generally speaking, this is an extremely difficult problem to handle because it requires monitoring from angles that the ixp operator may not have visibility into, e.g. point to point connectivity between two mac addresses across a fabric. If there were a good generalised way of handling this problem, it would be present in section 4.7, but there isn't outside implementing ad-hoc heuristic-based reactive monitoring to look out for specific failure modes. This mostly throws up false negatives due to e.g. ixp participant traffic engineering, etc. You're not the only person that finds this unsatisfactory. On balance, we'd prefer to leave this paragraph in. > Nits/editorial comments: > > > > 1. The English syntax of the second paragraph in the Abstract is broken. yes, clumsy. Reworded to: -- ... reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information. -- r107 > 2. In the introduction there is a mention of ‘using shared Layer-2 > networking media such as Ethernet’. Actually Ethernet is seldom used > nowadays as a shared media, I would just recommend saying ‘using data link > layers protocols such as Ethernet’ noted. r105. > 3. In section 4.2 s/optimization technique is > implemented/optimization technique that is implemented/ oops! r106. We're working through a number of points brought up by various people at the moment, and expect to post a new ID revision in a couple of days. Otherwise, thanks for the time you took to read the draft and write this review - this is very much appreciated. Nick _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
