Re: [Gen-art] Gen-ART review for draft-ietf-grow-ix-bgp-route-server-operations

[Nick Hilliard <[e-mail]>]

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