Subject: [renum] Handling Renumbering Events

From: RJ Atkinson <[email-masked]>
Date: Tue, 13 Sep 2011 09:28:52 -0400

Earlier, Brian Carpenter wrote, in part:
> However, I also wonder whether we should identify a gap here: a standardised 
> solution for communicating a prefix update to all systems that need to know it. 

It would be worthwhile, IMHO, to look at Teco Boot's work on a "Border Router 
Discovery Protocol (BRDP)".   His technical approach to BRDP appears to be 
nicely generalisable, hence applicable here, as well as in MANET deployments.

BRDP appears to be a way that devices within a site can learn of 
updates to the set of valid routing prefixes for that site.

With an enhanced BRDP, the site border router(s) that experience a
renumbering event (or an outage) on an exterior interface can communicate 
the change in valid uplinks and valid exterior routing prefixes
to all routers within a site.  Those routers can then use existing
mechanisms (e.g. IPv6 ND) to inform all nodes within that site.

	BRDP Project:		<http://www.inf-net.nl/brdp.html>

Security issues (e.g. authorisation, authentication) would need 
to be sorted through, just as with any other approach.

> (Another question is whether that can be NETCONF.)

NETCONF is a mechanism that might be used to transmit a prefix
update from a central network configuration database to a set of 
(centrally-managed) networked devices, but NETCONF has a number 
of limitations that mean it is not sufficient in the Renum case:

	- When would NETCONF be invoked ?  
	- What events would trigger NETCONF ?
	- Which entity would invoke/operate the NETCONF protocol ?
	- How would the centralised configuration database
	  behind NETCONF get updated dynamically, rapidly, accurately ?
	- What about devices that are not centrally-managed ?

So NETCONF is potentially a component of a future solution,
but is not enough by itself.

Yours,

Ran Atkinson

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Sep 2011 09:48:11 +1200

Yes, BRDP has been on my radar screen for a while, but at the
moment we aren't chartered for solutions development.

I agree with you that NETCONF is not a panacea; it's simply
part of the existing set of potential solutions, and therefore
needs to be considered during the gap analysis.

Regards
   Brian

On 2011-09-14 01:28, RJ Atkinson wrote:
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum
>

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Wed, 14 Sep 2011 02:08:01 +0000

> Brian E Carpenter
> Sent: Wednesday, September 14, 2011 5:48 AM
> To: RJ Atkinson

> needs to be considered during the gap analysis.

Yes, for renumbering, NETCONF is a tool/component rather than a solution.
As a tool, we can investigate whether it is proper to deal with the "filter update" issues mentioned in gap analysis document.
To make it a solution, we need to address the issues RJ mentioned in the mail, which may falls into the scope of "Renumbering event management" in gap analysis document.