Subject: [renum] Gaps discussion - General Issues

From: "Leo Liu(bing)" <[email-masked]>
Date: Fri, 12 Aug 2011 03:45:04 +0000

Hi, all

In the 6renum meeting @Quebec, we presented a number of open questions about 6renum gaps analysis.
But there was not much response in the meeting, maybe because we didn't have enough time for discussion or the questions were not easy to achieve consensus immediately. So I'd like to provoke discussion about the open questions again though the mail list. The gap analysis is about what potential work we can do in the future, I believe more discussion will bring more clear vision.

Let's start with a couple of general issues (not limited to the following, if you have any other ideas please add them on):

1.       Do we need a fully automatic renumbering technology? Is it possible to be realized?
This question is about renumbering automation. IMHO, human intervene is one of the most obvious reasons of why renumbering is painful and error-prone. So I'm wondering whether we could consider avoiding human intervene as much as possible to be an important goal of our work.

2.       Do we need recommendations for site address management tools?
There are several such tools, both commercial and open-source, and many large sites have home-made solutions. I think there's experience there to be tapped to help us identify gaps in current network management systems.

3.       Is session survivability within our scope?
Outage is another reason makes renumbering painful and expensive.
I think it is obvious that we won't develop any new technologies like shim6, SCTP for survivability in the name of renumbering.
But the question is how we treat the session survivability issue when thinking about renumbering. Shall we just exclude it out of renumbering, or consider it as a requirement(at least "best effort" )?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2011 08:45:53 +1200

I've been hoping somebody other than "the usual suspects" would
comment, but since they haven't, here are my opinions. It would
be great if people who have been mainly silent on the list could
speak up too.

On 2011-08-12 15:45, Leo Liu(bing) wrote:
> Hi, all
> 
> In the 6renum meeting @Quebec, we presented a number of open
> questions about 6renum gaps analysis. But there was not much
> response in the meeting, maybe because we didn't have enough
> time for discussion or the questions were not easy to achieve
> consensus immediately. So I'd like to provoke discussion
> about the open questions again though the mail list. The gap
> analysis is about what potential work we can do in the
> future, I believe more discussion will bring more clear
> vision.
> 
> Let's start with a couple of general issues (not limited to
> the following, if you have any other ideas please add them
> on):
> 
> 
> 1.       Do we need a fully automatic renumbering technology?

In an abstract sense, of course we do. Anybody who's ever had to
renumber a network the hard way will agree. However...

> Is it possible to be realized? This question is about
> renumbering automation. 

Certainly not 100% possible. As discussed in RFC 5887 and well
known for many years, some IP addresses will always be manually
embedded in unexpected places. So the real question is: what is
the maximum reasonable amount of automation that can be achieved?

(That is in our context of managed enterprise networks. Things
might be different in an unmanaged self-configuring network in
the "Internet of things" but that is not our scope in 6renum.)

> IMHO, human intervene is one of the
> most obvious reasons of why renumbering is painful and
> error-prone. So I'm wondering whether we could consider
> avoiding human intervene as much as possible to be an
> important goal of our work.

"as much as possible at reasonable cost" I think.

> 
> 
> 2.       Do we need recommendations for site address
> management tools? There are several such tools, both
> commercial and open-source, and many large sites have
> home-made solutions. I think there's experience there to be
> tapped to help us identify gaps in current network management
> systems.

I'm pretty sure we need to define some general requirements,
which may or may not be met by existing solutions. For example,
to relate this to our other current thread, requirements about
the relationship between such a tool and the generation of
DHCPv6 and DNS tables.

> 
> 3.       Is session survivability within our scope? Outage is
> another reason makes renumbering painful and expensive. I
> think it is obvious that we won't develop any new
> technologies like shim6, SCTP for survivability in the name
> of renumbering. But the question is how we treat the session
> survivability issue when thinking about renumbering. Shall we
> just exclude it out of renumbering, or consider it as a
> requirement(at least "best effort" )?

We have an enormous advantage in IPv6 which is the ability to
overlap the old and new prefixes and to use the address lifetime
 mechanisms in SLAAC and DHCPv6. That is fully described in RFC
4192. IMHO that is sufficient. (Also, I doubt whether shim6,
SCTP or MPTCP would help in practice, since an existing session
will not know about a new address which is added *after* the
session starts.)

   Brian

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Wed, 17 Aug 2011 03:13:32 +0000

Thanks for your comments, Brian. Please see Inline.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2011 4:46 AM
> To: Leo Liu(bing)
> Cc: [email-masked]
> Subject: Re: [renum] Gaps discussion - General Issues
> 

I'm wondering the silence means consensus or these questions are too general to discuss.
Maybe I need to throw out some more specific or controversial issues : )

> the maximum reasonable amount of automation that can be achieved?
I think this belongs to the static address configuration issue which is the nodus of renumbering. Current gap analysis draft hasn't described the issue in detail. At least we need to categorize the issue to try to cover all the possible situations.

> the relationship between such a tool and the generation of
Agree, we need to analysis the interaction between the tools and renumbering relevant protocols as DHCP/SLAAC/DNS .etc.

> will not know about a new address which is added *after* the
4192 is indeed a sufficient way. The most obvious problem may be whether the administrators treat running multiple addresses as a very hard job :)

---

From: Brian Haberman <[email-masked]>
Date: Wed, 17 Aug 2011 13:22:08 -0400

On 8/16/11 11:13 PM, Leo Liu(bing) wrote:
>> -----Original Message----- From: Brian E Carpenter
>> [mailto:[email-masked]] Sent: Tuesday, August 16, 2011
>> 4:46 AM To: Leo Liu(bing) Cc: [email-masked] Subject: Re: [renum]
>> Gaps discussion - General Issues
>> 
>> comment, but since they haven't, here are my opinions. It would be
>> great if people who have been mainly silent on the list could speak
>> up too.
> 
> I'm wondering the silence means consensus or these questions are too
> general to discuss. Maybe I need to throw out some more specific or
> controversial issues : )
> 
>> 
>>> response in the meeting, maybe because we didn't have enough time
>>> for discussion or the questions were not easy to achieve 
>>> consensus immediately. So I'd like to provoke discussion about
>>> the open questions again though the mail list. The gap analysis
>>> is about what potential work we can do in the future, I believe
>>> more discussion will bring more clear vision.
>>> 
>>> Let's start with a couple of general issues (not limited to the
>>> following, if you have any other ideas please add them on):
>>> 
>>> 
>>> Is it possible to be realized? This question is about renumbering
>>> automation.
>> 
>> embedded in unexpected places. So the real question is: what is the
>> maximum reasonable amount of automation that can be achieved?
>> 
> I think this belongs to the static address configuration issue which
> is the nodus of renumbering. Current gap analysis draft hasn't
> described the issue in detail. At least we need to categorize the
> issue to try to cover all the possible situations.
> 

I think Brian C. is referring to addresses configured in devices outside
of the hosts.  Firewall rules and router ACLs come to my mind
immediately.  I don't think I need to recapitulate the whole list from
RFC 5887.

>> might be different in an unmanaged self-configuring network in the
>> "Internet of things" but that is not our scope in 6renum.)
>> 
>>> IMHO, human intervene is one of the most obvious reasons of why
>>> renumbering is painful and error-prone. So I'm wondering whether
>>> we could consider avoiding human intervene as much as possible to
>>> be an important goal of our work.
>> 

Agreed.

>> 
>>> 
>>> 
>>> 2.       Do we need recommendations for site address management
>>> tools? There are several such tools, both commercial and
>>> open-source, and many large sites have home-made solutions. I
>>> think there's experience there to be tapped to help us identify
>>> gaps in current network management systems.
>> 
>> I'm pretty sure we need to define some general requirements, which
>> may or may not be met by existing solutions. For example, to relate
>> this to our other current thread, requirements about the
>> relationship between such a tool and the generation of DHCPv6 and
>> DNS tables.
>> 
> Agree, we need to analysis the interaction between the tools and
> renumbering relevant protocols as DHCP/SLAAC/DNS .etc.
> 
> 
>>> 
>>> another reason makes renumbering painful and expensive. I think
>>> it is obvious that we won't develop any new technologies like
>>> shim6, SCTP for survivability in the name of renumbering. But the
>>> question is how we treat the session survivability issue when
>>> thinking about renumbering. Shall we just exclude it out of
>>> renumbering, or consider it as a requirement(at least "best
>>> effort" )?
>> 
>> 4192. IMHO that is sufficient. (Also, I doubt whether shim6, SCTP
>> or MPTCP would help in practice, since an existing session will not
>> know about a new address which is added *after* the session
>> starts.)
>> 
> 4192 is indeed a sufficient way. The most obvious problem may be
> whether the administrators treat running multiple addresses as a very
> hard job :)

The only issue I have is with the definition of long-lived.  I have seen
active TCP sessions that have lasted for months on end.  What happens to
that session when the old prefix it used to originate the session is no
longer available at all (the old and new prefix overlap goes away)?  I
agree that the advantages in IPv6 will help, just not in all cases.

Regards,
Brian H.

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Thu, 18 Aug 2011 09:49:48 +0000

Hi, Brian H. Thanks for your comments, inline.

> immediately.  I don't think I need to recapitulate the whole list from

IMHO, I don't think firewall rules and router ACLs belong to the "unexpected" . In fact it is possible to manage and update these filters when renumbering though proper tools (please refer to http://inl.info.ucl.ac.be/publications/preparing-network-configurations-ipv6-renumbering). 
There are other address configurations might be widely dispersed and much harder to find. Appendix A of rfc5887(http://tools.ietf.org/html/rfc5887#appendix-A) listed some of them. 

> agree that the advantages in IPv6 will help, just not in all cases.

Thanks for pointing out this. Whether the months-lived TCP sessions are common or not, it is indeed a gap of 4192 for session survivability. 

> Regards,
> Brian H.
> 
> 
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: "George, Wesley" <[email-masked]>
Date: Mon, 29 Aug 2011 13:34:01 -0400

WEG] I think that it is worth including it in the gap analysis, first to cover what might be done (BCP) to limit the impacts to existing sessions, and then to note what gaps exist that would further improve renumbering's impact to existing sessions. Brian's comments are quite right, there are limits to what the existing mechanisms can do, and it's worth covering that in our drafts.
Session survivability is something that is interesting and applicable in multiple places (think mobility, locator-ID split implementations, etc), and while it's unlikely that there will be interest in a wide implementation of some sort of update to TCP, etc to make session survivability a reality just for renumbering, it might be implemented for other reasons, and we'd be remiss not to cover the specifics of how renum might be able to make use of such a feature. In general, I've always looked at renumbering as a specific case of mobility (or perhaps vice versa) in terms of the way that it has to handle existing sessions - either it has to use some sort of care of address and a forwarding mechanism like a tunnel (as in MIP) or it has to have a way to signal the remote end mid-stream, "dear device, my address is changing, please send your next round of packets to this address instead." And this may or may not be using the same mechanism (such as a DNS change) that it uses to update its address for new sessions...
That said, I'm not totally sure it belongs completely in the gap analysis document. It may be worth considering breaking the high-level requirements out into a separate document since that goes well beyond simply gap analysis into identifying a specific problem for another WG to solve with protocol work. We can always decide after we've discussed the gaps whether we want to go for that last step or not.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wesley" <[email-masked]>
Date: Mon, 29 Aug 2011 14:24:15 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leo Liu(bing)
Sent: Thursday, August 11, 2011 11:45 PM
Subject: [renum] Gaps discussion - General Issues

1.       Do we need a fully automatic renumbering technology? Is it possible to be realized?
This question is about renumbering automation. IMHO, human intervene is one of the most obvious reasons of why renumbering is painful and error-prone. So I'm wondering whether we could consider avoiding human intervene as much as possible to be an important goal of our work.
WEG] I think the form I'd like to see this take is to show what tools are available to automate an onerous task, but not to assume that they will be used in every case, let alone require them. There are plenty of folks who believe that removing human intervention is a good way to reduce the potential for errors. There are others who have an inherent mistrust for an automated system or don't see it as any more efficient due to the setup time required to get it integrated and customized to a point where it's useful. In some ways, this is a question of whether renumbering is expected to be common or uncommon, and at what scale. In some cases, a one-off manual renumber will be better, but if you end up repeating it, getting an automated system in place starts to look better.
Further, as Brian noted, you tend to stumble across statically defined addresses in strange places, so the other part of this is to point out the places where the current way of doing things (whether it's in the configuration method, the management/access method, etc) make it harder to manage something systematically. For example - configuration management on a router would be much easier to systematically manage during a renumber if things like addresses were parameterized so that when they appear multiple places within the config, they only have to be changed one place, rather than having to implement a system with enough logic to know that it has to change it 5 different places within the config, and the different syntax for each.
So perhaps this also comes in the form of a couple of different sets of requirements - one for device config issues (like parameterization, inheritance, hierarchy, use of DNS) and one for tools to drive device configs.
The authors and WG might also want to have a look at things like Capirca http://code.google.com/p/capirca/ that can be used to manage things like ACLs and FW rules such that it abstracts the logic and rules from the syntax of the box. I could see this being extended or adapted to handle reconfiguration for renumbering purposes.

2.       Do we need recommendations for site address management tools?
There are several such tools, both commercial and open-source, and many large sites have home-made solutions. I think there's experience there to be tapped to help us identify gaps in current network management systems.
WEG] Personally, I don't want this set of drafts to turn into a survey of address-management tools. Each application has its benefits, each user has different needs, etc. It's probably appropriate to simply note that they exist, and make a note of the more popular open-source and COTS options as an FYI. Perhaps there is an opening for a separate address management tool survey draft, but (speaking as an individual, not as chair) I don't want it in the existing drafts. What would be more constructive is for the existing draft to identify what an address management tool should be able to do - a set of requirements that are likely common among all of the different flavors that this group believes are critical to effectively improving the network admin's ability to manage a network through a renumbering event.

Thanks
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2011 11:44:13 +1200

Wes,

On 2011-08-30 06:24, George, Wesley wrote:

...
> For example – configuration management on a router would be much easier to systematically manage during a renumber if things like addresses were parameterized so that when they appear multiple places within the config, they only have to be changed one place, rather than having to implement a system with enough logic to know that it has to change it 5 different places within the config, and the different syntax for each.

As it happens I am in Beijing and discussed this point yesterday with Bing and Sheng.

There's an assertion in RFC 5887 related to this:

  "o  Addresses might be used by configured tunnels, including VPN
      tunnels, although at least the Internet Key Exchange (IKE)
      supports the use of Fully-Qualified Domain Names instead.

   On the latter point, the capability to use FQDNs as endpoint names in
   IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3
   and [RFC4306], Section 3.5).  This capability is present in most
   IPsec VPN implementations.  There does seem to be an "educational" or
   "awareness" issue that many system/network administrators do not
   realise that it is there and works well as a way to avoid manual
   modification during renumbering."

My questions are
a) are existing routers able to configure prefixes, VPNs or next hops
   by DNS name instead of IP address, not only for the IPsec/IKE case
   but in general?
b) is this a sensible idea as a way to parameterise router config?
c) if not, how could we do it?

Note that RFC 1958 says:

  "3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing."

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2011 11:55:27 +1200

> That said, I'm not totally sure it belongs completely in the gap analysis document. It may be worth considering breaking the high-level requirements out into a separate document since that goes wel…

Maybe the conclusion is that if the transport layer wants to survive
major disruptions such as renumbering, then the transport layer needs
to provide features for adding and dropping addresses (i.e., locators)
for sessions in progress. When the old MULTI6 WG decided that session
survivability was a requirement for multihoming solutions, the assumption
was that all the locators would be known in advance. Renumbering changes
that assumption (and so does mobility, I think).

Anyway - my feeling is that this gap lies in the transport layer
(or just below it and above the network layer, if you include the SHIM6
model).

     Brian

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 30 Aug 2011 13:50:56 -0400

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Monday, August 29, 2011 7:55 PM
To: George, Wesley
Cc: Leo Liu(bing); [email-masked]
Subject: Session survivability [was Gaps discussion - General Issues]

>> 3.       Is session survivability within our scope?

<snip>

WEG] I generally agree with this approach. Perhaps we can note this explicitly in the section for session survivability in the renum drafts, and then simply discuss the specific considerations that are applicable to renumbering when considering an update to the protocol to manage changing locators for sessions in progress. Then we can reach out to TSV Area to discuss this as a part of a larger discussion at some later point.

Wes George

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 30 Aug 2011 13:54:53 -0400

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Monday, August 29, 2011 7:44 PM
To: George, Wesley
Cc: Leo Liu(bing); [email-masked]
Subject: Parameterised router config [was Gaps discussion - General Issues]

Wes,

My questions are
a) are existing routers able to configure prefixes, VPNs or next hops
   by DNS name instead of IP address, not only for the IPsec/IKE case
   but in general?
WEG] I think it varies widely by vendor and platform, as well as by application even within the same platform (eg some places/features in the config will support it while others may not). We should probably make note of the general inconsistency as a gap, but I'm not sure we need to survey all of the devices.
b) is this a sensible idea as a way to parameterise router config?
WEG] Yes and no. It's worth noting all of the places that we believe that this sort of abstraction makes sense, where you can rely on DNS names and not have the 1958 circular issue that you note in your mail be a problem. However, this isn't what I had in mind when I talked of parameterized config.
c) if not, how could we do it?
WEG] I am thinking more of hierarchy and inheritance within a config to minimize the number of discrete instances of a statically defined address, especially if it's the same address appearing multiple places in the config. If I define the IP address and mask associated with a given interface, I should be able to call it in things like ACLs, routing policy, BGP neighbor definitions, etc using the interface name rather than the IP, and have the system sort out the interaction completely independent of DNS. It may even be necessary to have an option to tell the system to show the IP in all of the places it appears in the config to make it more human-readable so that you can see either the inheritance or the absolute config depending on what you need. There is also considerations about how you handle inherited changes downstream (eg I change the interface IP, how do you manage the BGP session whose IP has just been changed?) It's an implementation detail, but one that is in need of some guidance so that there is some consistency.

Thanks
Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Aug 2011 11:32:50 +1200

On 2011-08-31 05:54, George, Wesley wrote:
> WEG] I am thinking more of hierarchy and inheritance within a config to minimize the number of discrete instances of a statically defined address, especially if it's the same address appearing multiple places in the config. If I define the IP address and mask associated with a given interface, I should be able to call it in things like ACLs, routing policy, BGP neighbor definitions, etc using the interface name rather than the IP, and have the system sort out the interaction completely independent of DNS. It may even be necessary to have an option to tell the system to show the IP in all of the places it appears in the config to make it more human-readable so that you can see either the inheritance or the absolute config depending on what you need. There is also considerations about how you handle inherited changes downstream (eg I change the interface IP, how do you manage the BGP session whose IP has just been changed?) It's an implementation detail, but one that is in n
eed of some guidance so that there is some consistency.
> Wes George

Yes, I think we agree. My point about DNS is that it does allow us to name
interfaces (interface01.router07.example.com) but of course it could be done otherwise.
However, if we want vendor-independent techniques there would need to be
an agreed naming convention.

   Brian