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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
