Subject: [RADIR] FWD: Re: Please review: draft-narten-radir-problem-statement-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Feb 2008 13:33:59 -0500

Thoughts?
------- Forwarded Message

From: Danny McPherson <[email-masked]>
To: Olaf Kolkman <[email-masked]>, Thomas Narten <[email-masked]>
Cc: IAB IAB <[email-masked]>,
        The Internet Engineering Steering Group <[email-masked]>
Date: Mon, 25 Feb 2008 05:57:33 -0700
Subject: Re: Please review: draft-narten-radir-problem-statement-01.txt

On Oct 24, 2007, at 11:14 AM, Olaf M. Kolkman wrote:

>
> Folk,
>
>
> draft-narten-radir-problem-statement-01.txt has been published in  
> October 9.
>
> This document targets to be _the_ problem statement. At some point  
> this will need to go to the community, but, before defining and  
> taking the next steps (which probably involves IETF last call under  
> Russ' sponsorship) it would be good to have review from these two  
> groups.
>
> Please assess if this document would ready for IETF last call or if  
> not,  where further discussion should take place.

I still believe this document needs an entire section
devoted to iBGP implications.  I.e., the fact that if there's
indeed a problem the first place things are going to
break is going to be in the iBGP core of the most densely
connected networks.

The reason it's going to break there first is because of the
richness of interconnection, both external (e.g., section 5.1)
and internal, and perhaps more importantly, as a result of
architectural constraints imposed by internal BGP routing
architectures that result in anywhere from 2 to 20x the
number of BGP paths in the internal BGP routers as opposed
to PE devices.

There are network topology and routing architecture
considerations, as well as protocol modifications (e.g.,
route reflection advertisement rule sets) that can have a
considerable impact on both churn and scale internally
as well.

Ignoring this entirely in the document, when it's clearly
where the most pain exists today, isn't reasonable.

Furthermore, one could imagine a security considerations
section that discussed a whole slew of topics, from Transport
layer issues to prefix filtering, update authentication and
stability concerns.

I have mentioned these issues on RRG and other lists in
the past, though it's quite likely it's been lost in the noise.

-danny

------- End of Forwarded Message
_______________________________________________
RADIR mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/radir