On Mar 20, 2007, at 6:19 AM, Henk Uijterwaal wrote:
David,
On Thu, Mar 15, 2007 at 01:11:50PM +0100, ext Henk Uijterwaal wrote:
While this is probably correct, there is still one outstanding work
item for the group: draft-ietf-grow-mrt-04.txt. I think it is very
important for people working with BGP dumps to have this document
finished, as MRT dumps are a widely used format and should be
documented somewhere.
[ ... stuff deleted ... ]
I suggest that before the WG is closed, we establish a path how to
finish this document.
As I wrote in my mail:
"In fact, we would like to emphasize that we are quite open to
sponsor
individual submissions when the need arises (eg. we are happy to
take
on draft-ietf-grow-mrt as an individual submission), or even spin up
a new working group if we are dealing with a bigger project."
To summarize: this draft did not fall off our radar screen and we are
happy to take it on as an individual submission sponsored by AD.
Yes, I read the original mail. I was trying to make it a bit
stronger:
we agree on who does what and when in order to finish the draft NOW,
then proceed to work accordingly. Lots of people use this format so
the draft is needed.
Henk
Copying Henk's word, I would like to make it an even bit stronger
(I've sent a similar msg to the ADs earlier): I see values of keeping
GROW for another while. In addition to the need of finishing MRT
work, this group seems appropriate place to help with the coming
effort (which is supposedly topics of Routing area meeting on
Thursday) on the need to better understand BGP table growth and on
what can be done to improve BGP dynamics/churn, topics that have been
covered by GROW in the past.
taking BGP update dynamics as example, well defined protocol
mechanisms exist to dampen routing churns (MRAI, flap damping), but
dampening is probably seeing reduced deployment, and even MRAI is not
universally turned on (I showed some data at IETF61 GROW meeting,
http://www3.ietf.org/proceedings/04nov/index.html). So it seems to
me these issues are not so much of being on IDR plate but on GROW's.
We need a clear understanding of deployment status of existing
protocol mechanisms and the reasons/causes of why some places don't
do it. There can be need for new protocol knobs (IDR job), but it
seems to me a pre-requisite is a good understanding of issues with
existing knobs.
Lixia
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
