Subject: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines

From: [email-masked]
Date: Wed, 4 Jul 2012 09:14:40 -0400

> A new draft has been posted, at http://tools.ietf.org/html/draft-
> matthews-v6ops-design-guidelines. Please take a look at it and comment.

Useful, although coming a bit late for most ISPs. Some guidelines also 
apply to enterprises. 

A few additionnal comments/ideas: 

3.2 Adressing
Global vs ULA arguments could also be considered. A disadvantage of ULA 
is the lack of reverse DNS, unless the reverse zone is added locally. 
Advantage of ULA is simplicity to filter. Possibly less administrativa. 

4.1 Next-hop
Some early implementations of next hop redundancy protocols supported 
a or b exclusively. 

6. iBGP
Some protocols require a specific combination of AF and transport. For 
example, 6PE/6vPE requires IPv6 and VPNv6 address families over IPv4 
transport. Native IPv6 routes should be over IPv6 transport. 
 
7. ISIS
Multi-topology vs single topology
Some implementations of ISIS have issues running IPv6 with a single 
topology. Multi-topology is recommended, even if IPv4 is not carried in 
LSPs. 

/JF

---

From: Philip Matthews <[email-masked]>
Date: Fri, 6 Jul 2012 08:58:38 -0400

Thanks very much for your helpful comments and your interest in the draft.

Some comments inline.

- Philip

> Advantage of ULA is simplicity to filter. Possibly less administrativa. 

My thought is that the draft should focus on design choices about IPv6 (or the combination of IPv4 and IPv6) that do not come up with pure IPv4. Otherwise, the possible topics to cover in the draft become much bigger, and the draft no longer seems to fall within the charter of V6OPS.

So what I am wondering is: do ULAs provide a design choice that 1918 addresses do not provide in IPv4?  Right now, I don't see any, but maybe I am missing something.  I will think about this some more.

> Some early implementations of next hop redundancy protocols supported 

Perhaps it wasn't clear that section 4.1 is supposed to talk about next-hop addresses for  _static routes_, and not next hops in general.  I will try to make this clearer in the next version.

However, your comment points out that the draft does not currently cover VRRP.  Thanks!   I will add that in future revision, as VRRP does seem to have a few interesting design topics.

> transport. Native IPv6 routes should be over IPv6 transport. 

Yes.
I am trying to figure out how to handle iBGP, as saying something interesting about it really depends on what you are trying to do with it.  I am starting to think that I should not cover it in isolation, but rather in some larger context (e.g., in the context of talking about 6PE or 6VPE) 

> topology. Multi-topology is recommended, even if IPv4 is not carried in 

I agree.  I will cover this in a future revision.

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

---

From: [email-masked]
Date: Fri, 6 Jul 2012 11:53:11 -0400

Philip Matthews <[email-masked]> a écrit sur 06/07/2012 08:58:38 
AM :

> My thought is that the draft should focus on design choices about 
> IPv6 (or the combination of IPv4 and IPv6) that do not come up with 
> pure IPv4. Otherwise, the possible topics to cover in the draft 
> become much bigger, and the draft no longer seems to fall within the
> charter of V6OPS.
> 
> So what I am wondering is: do ULAs provide a design choice that 1918
> addresses do not provide in IPv4?  Right now, I don't see any, but 
> maybe I am missing something.  I will think about this some more.
 
Not sure I'm following your reasoning here. Choosing to number part 
of your network with global vs ULA adressing is an IPv6 design choice.

/JF

---

From: Tina TSOU <[email-masked]>
Date: Fri, 6 Jul 2012 16:31:53 +0000

Hi Phil,
Here is the proposed text for section 8.

8. OSPF

8.1 Enabling OSPFv3 per interface or OSPFv2 per subnet/network: 
Enabling OSPFv3 on a per-interface basis provides us with the advantage of enabling/ disabling a particular interface for the OSPF process. When OSPFv3 is enabled in the router configuration mode, selecting a particular interface by enabling it simplifies the configuration of OSPF, as compared to specifying the network in OSPFv2.
The main advantage of this approach is that the interfaces of the two OSPF neighbor routers do not have to be in the same subnet for successfully forming OSPF neighbors. The interfaces of the two routers participating in the OSPF process have to be enabled with OSPF on the interface configuration mode. Since an interface can have multiple IPv6 addresses, this feature provides one with the ability of efficiently using the addresses for routing.
Initiating IPv6 on the interface also prevents human errors caused by configuring wrong network address or wild card masks. There is no requirement of calculating the network address of the interface for initiating the OSPF process on the routers. 
One of the disadvantages of the per-interface approach is in terms of security concerns. If one of the interfaces of the router is enabled with OSPFv3 in the interface configuration mode, and a second OSPF speaking router is connected to the interface, both the routers will be able to form neighbors, even though the second router may be a rogue router in a different network.OSPFv3 has no authentication field in its header, and thus depends on the IPv6 authentication header (AH) and Encapsulating Security Payload (ESP). Thus, from the security point of view, one should be have a clear idea of the network design, before enabling the OSPF process on the interface.

8.2 Multiple instances per link in OSPFv3 or multiple OSPF processes in OSPFv2 
OSPFv3 supports multiple OSPF instances per interface. This feature makes it possible to add a single interface to be part of more than one area, by having different instance ID. The interface would represent the scenario of multiple logical interfaces on a single physical interface. Adding multiple OSPF processes or instances in OSPFv2 adds more overhead and overloads the router. However, having a single OSPFv3 process and adding instances per interface helps us in maximizing the efficiency of the router, without overloading it.
The only disadvantage would be some amount of added complexity in managing the instances, by maintaining a database of the instance IDs for each instance in the header.

8.3 OSPFv3 next-hop addresses: Local or Global addresses?
After enabling OSPFv3 for internal routing purposes, the next hop address of an OSPFv3 route can be either a:
a.    Link local address.
b.    Global address.
There are a number of advantages of using link local addresses as next hop for OSPFv3 routes. First, the link local addresses are automatically configured when IPv6 is enabled on the router and do not need any additional configuration. Even if link Local addresses change, (due to the change of a network interface card, the MAC address changes), the router would recalculate its link local address on its own and would advertise it to the other routers in the link. 
Link local addresses are a representation of layer 2 to layer 3 mapping (EUI-64). Link local addresses do not propagate outside the scope of a link and are more secure. Routers learn link local addresses with the help of Neighbor Discover protocol (NDP), thus an additional lookup in the routing table is not required. It saves processing and memory of the routers.

8.4 Router ID (RID) inconsistency removed in OSPFv3
In the case of OSPFv2, there is inconsistency in the RID of the routers. If the RID is configured manually in the router configuration mode, it is selected as the RID. Else, the loopback interface with the highest IP address is selected as the RID. If there are no loopback addresses configured, the highest IP address of an interface is selected as the RID. This leads to inconsistency in the RID in the OSPF database. This inconsistency is no longer present in OSPFv3 and it mandates the use of a 32-bit dotted decimal to be configured as RID for each router. Thus, all the routers are recognized by a unique RID, which helps in convenient and easier recognition. 

8.5 Are separate sessions required for IPv4 and IPv6?
OSPFv3 is solely used for routing IPv6 traffic and not IPv4 traffic. There is a separate routing table for OSPFv3 and OSPFv2. If the router is a dual stack router, both OSPFv2 and OSPFv3 have to be configured separately for enabling IPv4 and IPv6 routing respectively.
The disadvantage of a single session for both IPv4 and IPv6 is the unnecessary delay in the lookup of the much larger routing table, containing both IPv4 and IPv6 routes. There is also an added advantage of the separate session approach in maintaining separate traffic measurements for both kind of traffic and thus implementing traffic engineering accordingly. 
The disadvantage of this process is the need of router memory and resources in maintaining two routing tables and two processes for both protocols in the routers.  

Tina

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jul 2012 18:00:03 +0100

> of your network with global vs ULA adressing is an IPv6 design choice.

The design *advantage* of ULAs is that if you merge two networks
using them, the addressing scheme still works. If you merge two
Net 10s, stuff breaks.

Merge = physically merge, or connect temporarily or permanently
with VPNs.

   Brian

---

From: Philip Matthews <[email-masked]>
Date: Sat, 7 Jul 2012 16:08:29 -0400

Brian and JF:

Good point. Forgot about this.

Not quite sure yet how I am going to add this. The section was dealing with just p2p links, and this observation applies to larger networks. Still it should be mentioned somehow.

- Philip

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Jul 2012 15:18:22 +0900

> Net 10s, stuff breaks.           ^ might

the design advantage of using global space is that it will always
work.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jul 2012 10:13:12 +0100

>> Net 10s, stuff breaks.           ^ might

It's true that there is a very small probability of two sites picking
the same ULA prefix, but operationally this seems irrelevantly unlikely,
so I find that unqualified "might" misleading.

> the design advantage of using global space is that it will always

Yes, all other things being equal, I agree.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Jul 2012 18:17:57 +0900

> the same ULA prefix, but operationally this seems irrelevantly
> unlikely, so I find that unqualified "might" misleading.

i'm from ops.  i do not want to have to explain to people who wear funny
clothes why i took the risk that a 9.0 earthquake would not happen.
especially when it was trivially avoidable.

randy

---

From: Philip Matthews <[email-masked]>
Date: Mon, 9 Jul 2012 08:11:50 -0400

Hi Tina:

Thanks for your suggestions!  

Your proposed text seems to be taking the draft in a slightly different direction.  My idea was to discuss the choices that someone configuring a router for IPv6 (or for a mixed v4/v6 network) could make. For example, whether to run v4 and v6 on the same interface or on separate interfaces. One might call these "operational choices".   It seems that your text is documenting protocol and implementation design decisions between v4 and v6 instead.  These are also interesting, but I am wondering if these are not best covered in a separate draft?

- Philip

---

From: Tina TSOU <[email-masked]>
Date: Mon, 9 Jul 2012 23:29:13 +0000

I was thinking in line with:  If we are using OSPF v2 for IPv4, why should we use OSPFV3 for IPv6.

Tina