Subject: Re: [renum] Fwd: New Version Notification for draft-jiang-ipv6-site-renum-guideline-00

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 00:11:13 +0000

Wanted to get some of my comments from the mic out to the list-

I think that there are a number of places where we need to break up the problem space in order to make it more manageable, both in
terms of work that this group might take on vs work that is already partially done/belongs in existing groups, etc. Please add to
the list and provide comments...

Questions:
Do we care about supporting hitless renumbering (that is, some form of make-before-break that allows end hosts to migrate their
active sessions)?
 - I say nice to have, if at all, definitely not a primary goal
Should we be considering an encapsulation (like IRON) or Locator ID split implementation within scope to solve the renumbering
problem?
 - I say that we should be concentrating on renumbering problems that we can solve independent of any improved support in the
network infrastructure for mobility and route scaling, but others may disagree.

Different problem spaces:
- BCP on how to limit the impact of renumbering when it is required - especially important as IPv6 rolls out and people are doing
their once-in-a-blue-moon numbering plans, plus code work to support it
- Device config:
*on-box CLI and the places where it supports/requires IP address literals - places we can recommend that vendors support
parameterization either through FQDNs or external files that allow you to change an address in multiple places in the config at once
*a centralized management infrastructure that abstracts local config  from addressing
*Dynamically numbered devices/networks vs static

Thanks, 
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Wednesday, January 26, 2011 4:43 AM
To: [email-masked]
Subject: [renum] Fwd: New Version Notification for draft-jiang-ipv6-site-renum-guideline-00

A new version of I-D, draft-jiang-ipv6-site-renum-guideline-00.txt has been successfully submitted by Sheng Jiang and posted to the
IETF repository.

Filename:	 draft-jiang-ipv6-site-renum-guideline
Revision:	 00
Title:		 IPv6 Site Renumbering Guidelines and Further Works
Creation_date:	 2011-01-26
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This document analyzes the existing issues for IPv6 site renumbering.
It also analyzes the possible directions to solve these issues and gives recommendations. This document only takes the perspective
of network and network protocols. Renumbering in IPv4 networks, in the dual-stack network or in the IPv4/IPv6 transition networks
are out of scope.

This document only takes the perspective of network and network protocols. According to the different stages, these issues are
described in three categories: considerations during network design, considerations for routine network management, and
considerations during renumbering operation. Recommended solutions or strategies are also described. Issues that still remain
unsolvable are listed as the fourth category.

Although we list a few non-network issues in this document, we consider them as issues that ISPs or network providers cannot affect.
So, these issues are considered to be unsolvable and not explore further in these document, though they may be solved by OS
implementations or application implementations.

We summary the requests that need to extend current protocols as further works at the end of this document.

The IETF Secretariat.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Apr 2011 19:42:27 +1200

Thanks Wes. Yes, we clearly need a 'divide and conquer' approach.

We definitely need to separate renumbering avoidance (both the goal
and potential solutions) from the problem of how to renumber when
it's unavoidable.

Also we need to separate the target networks into major classes
such as managed vs unmanaged.

Regards
   Brian

On 2011-04-04 12:11, George, Wes E [NTK] wrote:
> ------------------------------------------------------------------------
>

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 14:23:49 +0000

Got some offlist comments that I should clarify what I mean by hitless renumbering in the first question below.

This isn't referring to what we have today, where we can take a node and provide one or more additional IPv6 addresses to it so that
you can use this as a way to make renumbering less painful. Ultimately, you still have some point where traffic has to stop flowing
from the old address and start flowing from the new one, even if it's pretty short.
What I'm specifically referring to is yet-to-be implemented machinery to let a host take that new address and signal to the other
side that it's going to be moving to a new address so that active traffic flows can be migrated without being reset. Since this is a
lot more complicated, that's what I'm referring to as nice-to-have. 

Thanks, 
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wes E [NTK]
Sent: Sunday, April 03, 2011 8:11 PM
To: Sheng Jiang; [email-masked]
Subject: Re: [renum] Fwd: New Version Notification for draft-jiang-ipv6-site-renum-guideline-00

Questions:
Do we care about supporting hitless renumbering (that is, some form of make-before-break that allows end hosts to migrate their
active sessions)?
 - I say nice to have, if at all, definitely not a primary goal Should we be considering an encapsulation (like IRON) or Locator ID
split implementation within scope to solve the renumbering problem?
 - I say that we should be concentrating on renumbering problems that we can solve independent of any improved support in the
network infrastructure for mobility and route scaling, but others may disagree.

*a centralized management infrastructure that abstracts local config  from addressing *Dynamically numbered devices/networks vs
static

Thanks,
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Wednesday, January 26, 2011 4:43 AM
To: [email-masked]
Subject: [renum] Fwd: New Version Notification for draft-jiang-ipv6-site-renum-guideline-00

Abstract:

The IETF Secretariat.

---

From: Teco Boot <[email-masked]>
Date: Mon, 4 Apr 2011 16:50:47 +0200

Wes,

I think there are lots of pieces of the puzzle for smooth, hitless renumbering. We can have the ambition combine those and complete the picture. I think this is more than a nice-to-have for unmanaged sites, although it may not work from day one, with basic IPv6 nodes. 

Teco

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Apr 2011 19:47:49 +1200

This is more or less the use case for shim6, which is standardised
and has running code. Shim6 was designed to maintain sessions
across multihoming events, and planned renumbering is a multihoming
event.

Regards
   Brian