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

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 May 2012 12:51:11 -0400

Helo wg folk,
Since we (I really I think) messed up the last WGLC for this document,
can we get another attempt at this now?
  <http://www.ietf.org/internet-drafts/draft-ietf-grow-simple-va-05.txt>

Abstract:
     The continued growth in the Default Free Routing Table (DFRT)
   stresses the global routing system in a number of ways.  One of the
   most costly stresses is FIB size: ISPs often must upgrade router
   hardware simply because the FIB has run out of space, and router
   vendors must design routers that have adequate FIB.

   FIB suppression is an approach to relieving stress on the FIB by NOT
   loading selected RIB entries into the FIB.  Simple Virtual
   Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
   allows any and all edge routers to shrink their RIB and FIB
   requirements substantially and therefore increase their useful
   lifetime.

   S-VA does not increase FIB requirements for core routers.  S-VA is
   extremely easy to configure considerably more so than the various
   tricks done today to extend the life of edge routers.  S-VA can be
   deployed autonomously by an ISP (cooperation between ISPs is not
   required), and can co-exist with legacy routers in the ISP.

If we could finish this 5/28/2012 || 28/5/2012 that would be good.

-Chris

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 May 2012 18:55:18 +0200

Support.

Thx,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 May 2012 18:15:09 +0100

nits:

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

- "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..."

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

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

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

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.

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.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 May 2012 18:16:46 +0100

> nits:

another nit:

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

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

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 May 2012 19:45:56 +0200

Hello Nick,

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

Fixed.

> 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

Fixed.

> suggest xml -> html -> cut-n-paste -> Microsoft word -> spell check?

Done.

> happens, the fib compression can explode with an upper bound of the

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.

 > 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

---

From: Shishio Tsuchiya <[email-masked]>
Date: Tue, 15 May 2012 10:44:29 +0900

Support.

Regards,
-Shishio

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 May 2012 01:46:14 +0000

+1

BR,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert
> Raszuk
> 发送时间: 2012年5月15日 0:55
> 收件人: Christopher Morrow
> 抄送: [email-masked] [email-masked]; [email-masked];
> [email-masked]
> 主题: Re: [GROW] WGLC: draft-ietf-grow-simple-va
> 
> Support.
> 
> Thx,
> R.
> 
> > Helo wg folk,

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 May 2012 11:38:33 +0100

I meant to say that I approve of the doc for wglc.

Nick