Re: [renum] Parameterized IP-Specific configuration

On 20 Nov 2012, at 17:24, Stig Venaas <stig@cisco.com> wrote:

> On 11/19/2012 6:57 PM, Liubing (Leo) wrote:
>> Hi, all
>> 
>> This is not talking about a new idea. The " Parameterized IP-Specific configuration" comes from the 6renum WG item, see http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-04#page-11
>> 
>> The draft is under 6renum WGLC, according to the comment in the Atlanta meeting, we need your review/comment of whether the "Parameterized IP-specific configuration" is a proper expression.
>> And if you still have other comments of the document, that would be also appreciated very much.
> 
> Looks good to me. Whether "parametrized" is the correct expression I'm
> not sure. I cannot really find a good/better term for this. The main
> thing is that there is enough detail for people to understand what it is
> about. Would it be useful to have an example in the draft (maybe in an
> appendix?). Just so it is clear? I think the current text is fairly
> clear though.

I agree - further comments welcome though.

Tim

> Stig
> 
>> Thanks a lot.
>> 
>> B.R.
>> Bing
>> 
>> 
>> ****For your convenient, abstract the original texts here****
>> (In draft-ietf-6renum-gap-analysis-04#page-11)
>> 
>> 6.3. Parameterized IP-specific Configuration
>> 
>>    Besides the DNS records and the in-host server address entries, there
>>    are also many places in which the IP addresses are configured, for
>>    example, filters such as ACL and routing policies, etc. There are
>>    even more sophisticated cases where the IP addresses are used for
>>    deriving values, for example, using the unique portion of the
>>    loopback address to generate an ISIS net ID.
>> 
>>    Ideally, a layer of abstraction for IP-specific configuration within
>>    various devices (routers, switches, hosts, servers, etc.) is needed.
>>    However, this cannot be achieved in one step. One possible
>>    improvement is to make the IP-specific configuration parameterized.
>>    Two aspects of parameterized configuration could be considered to
>>    achieve this.
>> ...
>> 
>> Here's an example (not in the draft, just for your easy understanding the above texts.)
>> First, we define the addresses for a given interface interface gigabitethernet1/1
>> ipv4 address 192.0.2.10/24
>> ipv6 address 2001:db8::10/64
>> 
>> Note that these addresses could also be automatically configured using DHCP or SLAAC, perhaps then the example would be:
>> Interface gigabitethernet1/1
>> ipv4 address dynamic dhcp
>> ipv6 address dynamic dhcpv6
>> 
>> then elsewhere in the configuration:
>> 
>> access-list example1
>> permit ipv4 any [gigabitethernet1/1] mask /24 #this permits any ip address that matches the prefix assigned to the interface in brackets [], in the range defined by the subnet mask at the end of the command permit ipv6 any [gigabitethernet1/1] mask /48 #this is the ipv6 equivalent, but permits any address in the entire /48
>> 
>> Similar examples could be possible for a BGP session, snmp source address, etc. Anywhere else you would hard-code an IP address could use a parameter to invoke an address inherited from an interface.
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------