On 20 Nov 2012, at 17:24, Stig Venaas <[email protected]> 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 > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
