Re: [GROW] WGLC: draft-ietf-grow-simple-va

[Robert Raszuk <[e-mail]>]

Hello Nick,

Many thx for reading the document and your comments. Please see below:

> nits:
>
> - please run: s/it's/its/s on the document.

Fixed.

> - "In some protocol's implementations for example BGP loc-RIB can be
> further...".  Change to "For example, in some protocol implementations BGP
> loc-RIB can be further..."

Fixed.

> - "Let's illustrate...".  Too informal.  "We illustrate..."

Fixed.

> - "Another deploymet consideration" =>  "Another deployment consideration"

Fixed.

> - "Therefor under the above intra" =>  "Therefore under the above intra"

Fixed.

> "different from the one assinged to VA-prefix" => "different from the one
> assigned to VA-prefix".

Fixed.

> There are possibly more spelling mistakes which I haven't caught.  Could I
> suggest xml -> html -> cut-n-paste -> Microsoft word -> spell check?

Done.

> Most of the document looks fine.  However, there is one content omission,
> namely that there is no analysis of what happens when a compressed RIB
> undergoes a topology change which modifies a bunch of next-hops.  If this
> happens, the fib compression can explode with an upper bound of the
> uncompressed size.

The point is that we are not compressing RIB nor FIB here. The entire 
mechanism really operates at the BGP level and suppresses overlapping 
prefixes before they end up in RIB.

That's very different and much simpler then any algorithm which would 
compress RIB or FIB. IGP topology changes have absolutely no bearing on 
the BGP suppression.

BGP will continue to rerun it's best path and while attempting to 
install the new set of best paths to RIB either suppress them or walk 
back and install those previously suppressed depending on the next hop 
value of given prefix which has changed due to topology change.

 > This may cause Interesting and Unexpected side effects - e.g. routers
 > falling over due to topology changes and so forth.  From an
 > operational point of view, I think this is probably important enough
 > to warrant a mention in the draft.

The implementation we have tested it with did efficient walk back in the 
above case as compared with normal unsuppressed case.

Btw the same walk back is used when BGP path becomes best which prefix 
length is between less specific and suppressed more specific.

Those requirements are necessary to remove burden from operator to match 
the topology to the knob. The assumption is that it should work in nay 
topology. However if one would deploy it in the edged of the POP most of 
the below would never apply as POP to core ABRs would be always less 
specific for all prefixes coming from other POPs. (Just a deployment 
option).

Many thx for your review. Please let me know if there are any other 
points for clarification or fix.

Best regards,
R.

PS. I have placed version -06 with above fixes into temporary location: 
http://goo.gl/yq7fF