Subject: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt

From: "Howard, Lee" <[email-masked]>
Date: Thu, 6 Sep 2012 12:17:43 -0400

We are requesting a Working Group Last Call on this document.  Please review and provide comments before September 19, since this may be the final review of this document.

Thanks,

Lee

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of internet- [email-masked]
> Sent: Monday, September 03, 2012 11:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the IPv6 Site Renumbering Working Group of the IETF.
>
>       Title           : IPv6 Site Renumbering Gap Analysis
>       Author(s)       : Bing Liu
>                           Sheng Jiang
>                           Brian Carpenter
>                           Stig Venaas
>       Filename        : draft-ietf-6renum-gap-analysis-03.txt
>       Pages           : 20
>       Date            : 2012-09-03
>
> Abstract:
>    This document briefly introduces the existing mechanisms could be
>    utilized by IPv6 site renumbering and tries to cover most of the
>    explicit issues and requirements of IPv6 renumbering. Through the gap
>    analysis, the document provides a basis for future works that
>    identify and develop solutions or to stimulate such development as
>    appropriate. The gap analysis is presented following a renumbering
>    event procedure clue.
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-gap-analysis-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

Lee Howard
Director, Network Technology
Time Warner Cable
(703) 345-3513
13820 Sunrise Valley Drive, Herndon VA 20171

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: "Fuyu (Eleven)" <[email-masked]>
Date: Wed, 12 Sep 2012 02:01:18 +0000

I am in favor of moving forward this work.

Cheers
Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Howard, Lee
Sent: Friday, September 07, 2012 12:18 AM
To: [email-masked]
Subject: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt

Thanks,

Lee

Lee Howard

---

From: "George, Wes" <[email-masked]>
Date: Fri, 14 Sep 2012 15:39:56 -0400

Generally I think this is good, and it's probably ready to go after a revision to address WGLC comments.

I do see one area where I've made previous comments that never really made it into this gap analysis, which is as it relates to the need for a layer of abstraction for IP-specific configuration within routers/switches and hosts (servers, etc). While you discuss filtering updates in section 7, the number of places where a bare IP is configured in your average router is quite a lot more than just there, sometimes even including things like derived values (using the unique portion of the loopback address to generate an ISIS net ID is common, for example).

Some of this can be solved because IPv6 allows multiple addresses and can do make before break renumbering (changing the addresses on interfaces, BGP sessions, etc) but I've said more than once that this is still a fairly manual and resource-intensive process, prone to mistakes. Likewise, use of FQDN everywhere that it's supported helps, but it's not supported everywhere you'd use an IP, nor is it always appropriate on a box that might need the IP address in order to keep working even if DNS is dead. We could see a lot of benefit from implementations of configuration management tools/CLI that allow you to use inheritance so that there is only one place in the config where the IP address is defined, whether statically or via dynamic means, and the rest of the config simply references and inherits it. There are a lot of "devil in the details" problems here about how you automatically update the inherited or parent/child config without causing disruption or non-deterministic behavior, but that's worth discussing as a problem to be solved. A well-parameterized configuration management system also has the net benefit of solving some of the filtering problems you discuss. Some of this would be implementation-specific, but I think we can articulate clear gaps there to give good guidance to implementers to make this easier.
With the advent of SDN and Openflow, I'm thinking that it's perhaps less of an intractable problem than it might have been in the past, so for completeness, we do need to discuss it in this gap analysis. It may be appropriate to have this in the static draft, but I wanted to raise it here and let the authors and WG decide how best to address it.

Thanks,

Wes

> Of Howard, Lee
> Sent: Thursday, September 06, 2012 12:18 PM
> To: [email-masked]
> We are requesting a Working Group Last Call on this document.  Please
> review and provide comments before September 19, since this may be the
> final review of this document.
>
> Thanks,
>
> Lee
>
>
> 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: Sat, 15 Sep 2012 21:19:15 +0100

Wes,

Simply put, I think you're saying that "A well-parameterized configuration management system"
is an essential tool, and I completely agree. Actually defining all the details of
that is a product design issue, but do you think we should aim at a requirements
document for such a tool?

As for whether this should be added as a specific gap in this draft or in
draft-ietf-6renum-static-problem, I'll await guidance from the WG chairs.

Regards
   Brian

On 14/09/2012 20:39, George, Wes wrote:
> Some of this can be solved because IPv6 allows multiple addresses and can do make before break renumbering (changing the addresses on interfaces, BGP sessions, etc) but I've said more than once that this is still a fairly manual and resource-intensive process, prone to mistakes. Likewise, use of FQDN everywhere that it's supported helps, but it's not supported everywhere you'd use an IP, nor is it always appropriate on a box that might need the IP address in order to keep working even if DNS is dead. We could see a lot of benefit from implementations of configuration management tools/CLI that allow you to use inheritance so that there is only one place in the config where the IP address is defined, whether statically or via dynamic means, and the rest of the config simply references and inherits it. There are a lot of "devil in the details" problems here about how you automatically update the inherited or parent/child config without causing disruption or non-deterministic 
beh
>  avior, but that's worth discussing as a problem to be solved. A well-parameterized configuration management system also has the net benefit of solving some of the filtering problems you discuss. Some of this would be implementation-specific, but I think we can articulate clear gaps there to give good guidance to implementers to make this easier.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 17 Sep 2012 06:20:26 +0000

Hi, Wes

Thanks for your review and comments. I think the issue you pointed out is important and need to be discussed. 
But I'm a little confused about some issues, please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> George, Wes
> Sent: Saturday, September 15, 2012 3:40 AM
> To: Howard, Lee; [email-masked]
> Subject: Re: [renum] Working Group Last Call:
> draft-ietf-6renum-gap-analysis-03.txt
> 
> I do see one area where I've made previous comments that never really made
> it into this gap analysis, which is as it relates to the need for a layer of
> abstraction for IP-specific configuration within routers/switches and hosts
> (servers, etc). While you discuss filtering updates in section 7, the number of
> places where a bare IP is configured in your average router is quite a lot more
> than just there, sometimes even including things like derived values (using the
> unique portion of the loopback address to generate an ISIS net ID is common,
> for example).

[Bing] In fact, when we used the word "filter", we did intend to treat it as a common concept rather than some specific instances such as ACL. Besides the DNS records and the in-host server addresses, we treated all the entries containing IP_addresses-as-IDs as "filter", I think it is align with your "a layer of abstraction for IP-specific configuration"(however, we didn't cover the consideration of the derived values, thanks for pointing it out). Did I understand your "abstraction" correctly? If I did, then the problem is just maybe the word "filter" and the relevant description are not sufficient enough to represent the abstraction, then we can modify them.

> Some of this can be solved because IPv6 allows multiple addresses and can do
> make before break renumbering (changing the addresses on interfaces, BGP
> sessions, etc) but I've said more than once that this is still a fairly manual and
> resource-intensive process, prone to mistakes. Likewise, use of FQDN
> everywhere that it's supported helps, but it's not supported everywhere you'd
> use an IP, nor is it always appropriate on a box that might need the IP address
> in order to keep working even if DNS is dead. We could see a lot of benefit from
> implementations of configuration management tools/CLI that allow you to use
> inheritance so that there is only one place in the config where the IP address is
> defined, whether statically or via dynamic means, and the rest of the config
> simply references and inherits it. There are a lot of "devil in the details"
> problems here about how you automatically update the inherited or
> parent/child config without causing disruption or non-deterministic beh
>  avior, but that's worth discussing as a problem to be solved. A
> well-parameterized configuration management system also has the net benefit
> of solving some of the filtering problems you discuss. Some of this would be
> implementation-specific, but I think we can articulate clear gaps there to give
> good guidance to implementers to make this easier.
> With the advent of SDN and Openflow, I'm thinking that it's perhaps less of an
> intractable problem than it might have been in the past, so for completeness,
> we do need to discuss it in this gap analysis. It may be appropriate to have this
> in the static draft, but I wanted to raise it here and let the authors and WG
> decide how best to address it.

[Bing] The inheritance configuration can make the parameters instead of the specific IP addresses, which provides similar ability of the FQDN, and indeed it doesn't need to rely on DNS systems. But then it will rely on the management system, which may face the problems of compatibility and also availability. So I'm afraid this may be the same assurance level comparing to the DNS. 
And, if we consider how to implement parameterized configuration management system as gaps, it has an implicit assumption that parameterized management is an already chosen solution for the "abstraction for IP-specific configuration" gap. So I'm not sure currently we should only treat the parameterized management as a candidate solution, or we need to do further gap analysis of it in the draft.

> 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, Wes" <[email-masked]>
Date: Mon, 17 Sep 2012 10:52:09 -0400

> From: Brian E Carpenter [mailto:[email-masked]]

> is an essential tool, and I completely agree. Actually defining all the
> details of that is a product design issue, but do you think we should
> aim at a requirements document for such a tool?
>

[WEG] well, defining such a thing might be useful, but I think that it's not something specific to renumbering. There are a lot of additional requirements beyond renumbering that would need to be considered. It might be appropriate to discuss the renumbering-specific considerations/requirements in a gap analysis, but to note that defining a complete list of requirements for a parameterized configuration management system is a good goal but out of scope for this document.

Thanks
Wes George

---

From: "George, Wes" <[email-masked]>
Date: Mon, 17 Sep 2012 11:16:11 -0400

> From: Liubing (Leo) [mailto:[email-masked]]

> [Bing] In fact, when we used the word "filter", we did intend to treat
> it as a common concept rather than some specific instances such as ACL.
> Besides the DNS records and the in-host server addresses, we treated all
> the entries containing IP_addresses-as-IDs as "filter", I think it is
> align with your "a layer of abstraction for IP-specific
> configuration"(however, we didn't cover the consideration of the derived
> values, thanks for pointing it out). Did I understand your "abstraction"
> correctly? If I did, then the problem is just maybe the word "filter"
> and the relevant description are not sufficient enough to represent the
> abstraction, then we can modify them.

[WEG] the word "filter" is at least part of the problem, because it has one or more common definitions within IETF and router implementations in general, specifically that it is a method to allow some information to pass and other info to be dropped, whether traffic, route updates, even things like classification. However, I'm not sure that a reader will make the leap to the generic level that you're trying to use here. Yes, it follows that any sort of configuration that is using a filter as I defined above would benefit from this, but that doesn't cover other uses such as using the interface IP block to build the remote BGP neighbor session, using the interface IP as the source for a certain type of traffic, etc.
>
> [Bing] The inheritance configuration can make the parameters instead of
> the specific IP addresses, which provides similar ability of the FQDN,
> and indeed it doesn't need to rely on DNS systems. But then it will rely
> on the management system, which may face the problems of compatibility
> and also availability. So I'm afraid this may be the same assurance
> level comparing to the DNS.

[WEG] I realized I was a bit unclear in my previous comments - there are two types of parameterized configuration, and both are important. The first is one that is self-contained to the individual device - this is where you can define a value once, and then use either keywords or variables to call that value in the other places where it can be defined in the configuration, a sort of internal inheritance in CLI or other local configuration. This makes it easier to manage a renumbering event by reducing the number of places in a device's configuration that must be updated. Still means that you have to touch every device, but you only have to touch it once, instead of having to scrub the config to ensure that you didn't miss any of the 8 separate places that a given IP occurs. The second is the more formalized off-box configuration management system, where you make the changes in the system and it manages how to push the changes to the individual devices. Since we're talking about enterprise renumbering, it's not necessarily valid to assume that there is going to be a formalized configuration management system to leverage, so making this easier on a device-by-device basis is an important goal to highlight.

> And, if we consider how to implement parameterized configuration
> management system as gaps, it has an implicit assumption that
> parameterized management is an already chosen solution for the
> "abstraction for IP-specific configuration" gap. So I'm not sure
> currently we should only treat the parameterized management as a
> candidate solution, or we need to do further gap analysis of it in the
> draft.
>
[WEG] I wouldn't say that it's an already chosen solution, and I don't think that discussing it leads to that assumption. Most of what we discuss is alternatives that make this easier or help to eliminate the need for some renumbering. This is just one additional alternative that may work in some cases, may not work in others. There is some value in at least a high-level gap analysis of the places where parameterized configuration already exists vs the areas where it isn't common and really should be implemented because it's fairly straightforward, vs the areas where perhaps it doesn't help/isn't practical.

Thanks,

Wes George

---

From: Marc Lampo <[email-masked]>
Date: Tue, 18 Sep 2012 09:54:34 +0200

Hello (and sorry to jump in so late, but as I just changed employer ...),

my remark is about impact of renumbering on IPSEC VPN definitions.
In my opinion this area is not addressed (enough).

I understand that, via a reference to RFC5887 these is a suggestion to
define addresses on either side of an IPSEC VPN via DNS.
One element is that in practice, not all devices "out there" (some
very widely used) are not capable of defining the valid addresses on
an IPSEC endpoint via DNS.

The second element is about the DNS aspect itself.
Suppose there is a site-to-site VPN between organisations A and B.
Suppose organisation A is capable of defining "valid addresses behind
VPN endpoint" via DNS.
Problem is that device at organisation A needs access to a NS that
"knows" about internal addresses at organisation B.
But if organisation B renumbers its internal network !
How can DNS server accessible/used by VPN endpoint at organisation A
know about new addresses in an automatic way ?

Because there is so little about this subject, in the present version,
I think it is not addressed enough.
Either explicitly, in a paragraph firmly stating recommendations and procedures;
or in section 9, Gaps considered unresolvable, where it can be added
why this is a problem and what admins will have to do manually, if
they renumber.

Kind regards,

Marc Lampo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2012 14:07:14 +0100

Marc,

> an IPSEC endpoint via DNS.

True, that's an implementation and deployment gap, not a protocol gap.
All we can do in the IETF is document this kind of gap, since we don't
control implementations.

> know about new addresses in an automatic way ?

Only if B publishes the appropriate AAAA records in global DNS. Of course
B must also use appropriate DNS TTLs and follow the RFC 4192 overlap
procedure. Then when the IPsec SA breaks, the VPN software will retry
and find the new AAAA record.

Nothing works if people don't use the global DNS correctly, due to misguided
belief in security by obscurity.

> why this is a problem and what admins will have to do manually, if

I think we need to separate out implementation and deployment recommendations,
which are in scope for an Ops Area WG, even if we need to add a goal to
the WG Charter.

Regards
    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 19 Sep 2012 02:05:30 +0000

Hi, Wes

Thanks for your reply. Please see inline.

> From: George, Wes [mailto:[email-masked]]
> Sent: Monday, September 17, 2012 11:16 PM
> To: Liubing (Leo); Howard, Lee; [email-masked]
> Subject: RE: [renum] Working Group Last Call:
> [WEG] the word "filter" is at least part of the problem, because it has one or
> more common definitions within IETF and router implementations in general,
> specifically that it is a method to allow some information to pass and other info
> to be dropped, whether traffic, route updates, even things like classification.
> However, I'm not sure that a reader will make the leap to the generic level that
> you're trying to use here. Yes, it follows that any sort of configuration that is
> using a filter as I defined above would benefit from this, but that doesn't cover
> other uses such as using the interface IP block to build the remote BGP
> neighbor session, using the interface IP as the source for a certain type of
> traffic, etc.

[Bing] OK, we can modify the relevant description accordingly. Thanks for clarifying the concept.

> [WEG] I realized I was a bit unclear in my previous comments - there are two
> types of parameterized configuration, and both are important. The first is one
> that is self-contained to the individual device - this is where you can define a
> value once, and then use either keywords or variables to call that value in the
> other places where it can be defined in the configuration, a sort of internal
> inheritance in CLI or other local configuration. This makes it easier to manage a
> renumbering event by reducing the number of places in a device's configuration
> that must be updated. Still means that you have to touch every device, but you
> only have to touch it once, instead of having to scrub the config to ensure that
> you didn't miss any of the 8 separate places that a given IP occurs. The second
> is the more formalized off-box configuration management system, where you
> make the changes in the system and it manages how to push the changes to
> the individual devices. Since we're talking about enterprise renumbering, it's
> not necessarily valid to assume that there is going to be a formalized
> configuration management system to leverage, so making this easier on a
> device-by-device basis is an important goal to highlight.
> 
[Bing] I like the classification of the two types of parameterized configuration, I think it makes the issue much clearer than before.
When we wrote the draft, we were in fact thinking about the second type of configuration. And it is true as you said, probably there is not going to be a formalized configuration management system to leverage. But we considered this as a gap. There might not be a full solution for the gap, but partially solution can also benefit renumbering. 
For the first type, the device-by-device parameterized configuration, actually we didn't touch it in the draft, we can add some description in the revision, thanks for pointing it out.

> [WEG] I wouldn't say that it's an already chosen solution, and I don't think that
> discussing it leads to that assumption. Most of what we discuss is alternatives
> that make this easier or help to eliminate the need for some renumbering. This
> is just one additional alternative that may work in some cases, may not work in
> others. There is some value in at least a high-level gap analysis of the places
> where parameterized configuration already exists vs the areas where it isn't
> common and really should be implemented because it's fairly straightforward,
> vs the areas where perhaps it doesn't help/isn't practical.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 19 Sep 2012 02:58:36 +0000

Hi, Marc & Brian

Thanks for your comments. Please see inline.

> Brian E Carpenter
> Sent: Tuesday, September 18, 2012 9:07 PM
> To: Marc Lampo
> Cc: [email-masked]
[Bing] In previous mails, Di Ma also pointed out this issue, and proposed some texts. Thank you for pointing it out again, then it is obvious that the IPsec renumbering issue would be probably cared by many people. We'll add some more description accordingly.

> which are in scope for an Ops Area WG, even if we need to add a goal to
[Bing] For the detailed gap analysis you proposed above, I generally agree with Brian, we need to distinguish the protocol gaps and implementation gaps.
For the recommendations, I think we can consider to add some description in draft-ietf-6renum-enterprise-scenarios, which contains BCPs for renumbering as an important part of the draft.

> review and provide comments before September 19, since this may be the final
> review of this document.
> >>
> >> Thanks,
> >>
> >> Lee
> >>
> >>