Subject: [v6ops] draft-ietf-v6ops-design-choices-00

From: Philip Matthews <[email-masked]>
Date: Thu, 14 Feb 2013 14:03:52 -0500

Folks:

I have just submitted draft-ietf-v6ops-design-choices-00, which is a renamed version of the Design Guidelines draft (draft-matthews-v6ops-design-guidelines). It should be appearing in the online drafts repository shortly.

Though I had hoped to get a more substantial revision out, work intervened and I was only able to make a few smaller changes.
I have been working on adding more design choices, but ran out of time. Sorry.

Comments on the new version are most welcome.

- Philip

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 22 Feb 2013 13:23:24 -0500

Mitch,

Some Comments

<Section 2.1>

- Additional reasoning for option (b) may be related to limitations in
mobile networks (no support for IPv4v6 bearers due to signalling node, UE
or gateway limitations). In that case, there are two logical connections (I
guess one can argue separate radio resources are used, so you can say
physical as well).

<Section 2.2>

- Would it make sense to have the points in the first paragraph (after a,
and b options listed) to itemize the supporting points for unnumbered links
with bullets? May make is easier for reader to pick out this points. The
counter points (support numbered links) is much easier to follow.

<Section 2.3>

- No comment yet. But was thinking about Ralphs draft from 2009 on DHCPv6
use case (which I guess does not technically exist now)

<Section 2.4>

- Also for case B. Some SPs may not use the same physical RRs or have a
different RR structure for IPv4 vs. IPv4. This may be related to
hardware/software reasons, and/or other factors as they transition.

- Option B allows you to retain flexibility to choose a different routing
structure for IPv6 (given that it's a different beast - as least in my case
it was).

<Section 2.5>

- Not sure if you will agree, but another case for not using LL for peering
is related to security as well. Many orgs with well structure ACLs and
policy rules built around address ranges used for P2P and LB interfaces. By
now mixing that model, they need to make sure they capture/udpate those
practices correctly. Not sure if I am making sense on this point.

<New Discussion area>

I was also wondering if a new section may be added to discuss how one may
deal with or consider modify routing policy for IPv6.  Example points of
discussion:

(1) Perhaps with IPv6, operator may consider chaining how they utilize
common Link State protocols vs. BGP for internal routing (given route scale
may be different - I.e. Concept of PDs for everyone).

(2) For internal routing, on the BGP side, the operator may also choose to
select different routing structures (eluded to that in my comment for 2.4)
for IPv6.  I know that we has considered this to a great deal since we
where not trying to solve for some different problems.

Just some thoughts based on experience - not sure if anyone will agree here.

More comments to come.

regards,

Victor K

On Thu, Feb 14, 2013 at 2:03 PM, Philip Matthews
<[email-masked]>wrote:

> Folks:
>
> I have just submitted draft-ietf-v6ops-design-choices-00, which is a
> renamed version of the Design Guidelines draft
> (draft-matthews-v6ops-design-guidelines). It should be appearing in the
> online drafts repository shortly.
>
> Though I had hoped to get a more substantial revision out, work intervened
> and I was only able to make a few smaller changes.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "George, Wes" <[email-masked]>
Date: Tue, 26 Feb 2013 13:12:52 -0500

One thing I might recommend highlighting as you discuss pros and cons in the different sections and especially as an expansion of section 3.2 is the idea that eventually the network will transition from dual-stack back to single-stack (v6-only), and your design choices now will impact how easy or hard it is to make that transition later. The actual timeframe for when that happens is not important in the design phase, but the fact that it will eventually happen, probably in phases across the network, is something that people need to be considering. It certainly informs decisions like 2.4, and may well impact the way that you build your routing policies and QoS.

If I were to summarize what I interpret from the current section 3.2, it's that short-term, you want IPv4 and IPv6 to mirror each other as closely as possible in order to reduce the amount of double or parallel work that must be done to manage the two independent protocol stacks. I agree with this, but I think we should take it further to talk about the long-term considerations. While fate sharing between control and data plane is valuable, the other rule of thumb is probably that you want to design things modularly enough that you can eventually shut off IPv4 without having to redesign large parts of the network config.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Philip Matthews
> Sent: Thursday, February 14, 2013 2:04 PM
> To: [email-masked] list
> Subject: [v6ops] draft-ietf-v6ops-design-choices-00
>
> Folks:
>
> renamed version of the Design Guidelines draft (draft-matthews-v6ops-
> design-guidelines). It should be appearing in the online drafts
> repository shortly.
>
> Though I had hoped to get a more substantial revision out, work
> intervened and I was only able to make a few smaller changes.

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.