Subject: [v6ops] Agenda discussion

From: Fred Baker <[email-masked]>
Date: Tue, 6 Mar 2012 13:46:37 +0900

Stated in no particular order, we have the following documents that meet these criteria:
  - not in the IESG process somewhere
  - posted or updated since IETF 82
  - have had list discussion since IETF 82 or responds to discussion at IETF 82

At this point, I take them as our agenda at IETF 83. If I am missing a document (if you have posted it since Sunday, I may well be missing it), please remind me.

http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance
  "IPv6 Guidance for Internet Content and Application Service Providers",
  Brian Carpenter, Sheng Jiang, 22-Feb-12

No presentation expected, but the authors would like working group adoption. We need to decide whether we want to do that.

http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance
  "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter,
  Sheng Jiang, Willy Tarreau, 17-Jan-12

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
  "464XLAT: Combination of Stateful and Stateless Translation", Masataka
  Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis
  "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark,
  Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11

http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address
  "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao
  Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12

http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation
  "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)",
  Fernando Gont, 3-Mar-12

http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6
  "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12

In the coming week, I am told to expect one additional -00 draft, and I could imagine other drafts being updated. I will be looking for those drafts to meet the criteria above as well, but please drop the chairs a note.

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Mar 2012 13:59:11 +0900

Downloading the new drafts, I observe three new ones:

-rw-rw-r--  1 fred  fred  10823 Mar  5 17:46 draft-ma-v6ops-terminal-test-00.txt
-rw-rw-r--  1 fred  fred  18058 Mar  6 08:44 draft-gundavelli-v6ops-community-wifi-svcs-00.txt
-rw-rw-r--  1 fred  fred  21172 Mar  6 10:08 draft-lopez-v6ops-dc-ipv6-00.txt

(the date/time stamp reflects the fact that I'm in Japan and therefore a day ahead)

In each case, I will be looking for list traffic related to them as my cue for agenda time. Authors, please provoke list traffic...

On Mar 6, 2012, at 1:46 PM, Fred Baker wrote:

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

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Mar 2012 15:29:54 -0500

IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. I'll provide a few comments separately on that one, but I don't want those to be misconstrued as interest in seeing the draft presented.

I'm interested in draft-gundavelli, but I think it has an awful lot of placeholders for it to be effectively discussed in Paris. Perhaps next meeting, unless the authors are currently working on a -01 draft to be posted later this week that fills in some of the gaps.

Regarding draft-lopez, As with previous documents of this type, I think there's a certain burden of proof that we need another cookbook document on "IPv6 deployment in [foo]" and that IETF is the proper venue for it. As other work (like ARMD) in IETF is finding out, "datacenter" is such a nebulous concept that purporting to represent a deployment strategy for a datacenter is probably simplistic and overbroad. It will either be so generic that it won't say anything new, or it will be so specific that it won't be applicable to very many applications, and either way that's not overly helpful.
While Brian is correct in his observation than ICP != datacenter, many of the same things are suggested/useful, so I do think that there's a lot of overlap. The authors either need to propose solving for a different problem space, or identify a way to eliminate the overlap.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred
> Baker
> Sent: Monday, March 05, 2012 11:59 PM
> To: v6ops v6ops WG
> Subject: Re: [v6ops] Agenda discussion
>
> In each case, I will be looking for list traffic related to them as my cue for
> agenda time. Authors, please provoke list traffic...
>
>
> > At this point, I take them as our agenda at IETF 83. If I am missing a
> document (if you have posted it since Sunday, I may well be missing it),
> please remind me.
> >
> >
> > No presentation expected, but the authors would like working group adoption.
> We need to decide whether we want to do that.
> >
> > In the coming week, I am told to expect one additional -00 draft, and I
> could imagine other drafts being updated. I will be looking for those drafts
> to meet the criteria above as well, but please drop the chairs a note.

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: Fred Baker <[email-masked]>
Date: Thu, 8 Mar 2012 07:22:30 +0900

> While Brian is correct in his observation than ICP != datacenter, many of the same things are suggested/useful, so I do think that there's a lot of overlap. The authors either need to propose solvi…

Thanks for the view. I'll discuss that with the authors.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 07 Mar 2012 21:33:35 -0500

On 12-03-07 3:29 PM, "George, Wes" <[email-masked]> wrote:

>
>I'm interested in draft-gundavelli, but I think it has an awful lot of
>placeholders for it to be effectively discussed in Paris. Perhaps next
>meeting, unless the authors are currently working on a -01 draft to be
>posted later this week that fills in some of the gaps.

I am interested in this draft as well - timely topic .  I agree with Wes
that there is a significant amount of text which needs to be created to
have a qualify discussion on this.

Sections which I think need more content for discussion

4.7 Mobility in WLAN.  A very important part of the WiFi discussion.

4.8 Mobility across WLAN and Macro Access.  This is a complex topic.  I am
not sure how much detail needs to be put down here.  I think the content
is a bit light (but maybe that what the authors were looking for - not
sure).  I would say (perhaps) a reference to 3GPP 23.327 may be applicable.

4.10 Service and Network Security.  This is also a large part of the WiFi
discussion.  If we put security items here, do we still need section 7?
(Security Considerations)

4.11 Should this say "Lawful Intercept"? Vs Legal Intercept?  I guess this
section could be short (I guess requirements here will differ greatly by
country/region.

Also, related to 4.7, but likely a separate section is around RF planning
for WiFi deployment.  This may include comments/topics around what
channels to use, 2.4GHz vs. 5.0GHz ranges etc.

A section around potential encryption requirements? (maybe in security
section or separate?)

Regards,

Victor Kuarsingh

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 07 Mar 2012 21:22:57 -0800

Hi George/Victor,

On 3/7/12 12:29 PM, "George, Wes" <[email-masked]> wrote:

> IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. I'll
> provide a few comments separately on that one, but I don't want those to be
> misconstrued as interest in seeing the draft presented.
> 
> meeting, unless the authors are currently working on a -01 draft to be posted
> later this week that fills in some of the gaps.
> 

Ack. We have revised the draft and we plan to do one more rev before Monday
and that should bring the draft to a point where we can have meaningful
discussions in the Paris meeting.

http://www.ietf.org/id/draft-gundavelli-v6ops-community-wifi-svcs-02.txt

Regards
Sri

---

From: Rick van Rein <[email-masked]>
Date: Thu, 8 Mar 2012 09:38:55 +0100

Hello,

> document (if you have posted it since Sunday, I may well be missing it),

I am working to get a new version of draft-vanrein-v6ops-6bed4 out --
the tunnel that works without account and on any network.  The
response on v00 has given me a lot to think about, but it is now
technically quite clear and will be documented as a draft during next
week.  Meanwhile, tests with v00 have shown that the concept is
succesful and really, really simple to use.

This is my first draft submission, if I'm braking any rules or if
there are any deadlines then feel not hesitation in correcting me.

Thanks,

RIck van Rein
OpenFortress

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Mar 2012 17:40:32 +0900

> section could be short (I guess requirements here will differ greatly by

The term nowadays seems to be Lawfully Authorized Electronic Surveillance (LAES). Specifics of procedure, audit, and integrity validation vary by jurisdiction, but once the bar has been passed that the surveillance is in fact legal and authorized, what one does next is pretty common. It falls under CyberCrime Article 20 (data retention, which in most cases means keeping application logs much longer than an ISP usually does, but in some countries adds IPFIX captures) or Article 21 (Content Intercept).

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Mar 2012 17:51:52 +0900

> there are any deadlines then feel not hesitation in correcting me.

Don't worry about breaking rules; that what rules are made for. There is, however, a deadline, and this working group has a criterion for discussion slots that I have found I need to be pretty firm on. The deadline for new drafts was Monday; the deadline for updates to existing drafts is this coming Monday. Given a newly-posted draft or update, the authors are on the hook to get discussion going on the list; I'm looking for operators saying that they are interested in the proposal.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 8 Mar 2012 05:50:22 -0800

> have a qualify discussion on this.

Interesting topic but I have not seen any novel or meaningful work.... and
that is probably good. The internet model is smart end points and simple
network. So the solution set should basis application solutions, not
another mobile IP or GTP

> 4.7 Mobility in WLAN.  A very important part of the WiFi discussion.

Why? Do session persistence / resume in the app.

> sure).  I would say (perhaps) a reference to 3GPP 23.327 may be
applicable.

Complex. Tried to solve this with UMA/ GAN, failed. Too much complexity for
too little gain. Make the endpoints figure it out in the app. Or ...mSCTP?

VoLTE and SCC will be interesting to watch as technical aspirations meet
instrumentation and deployment reality.

> (Security Considerations)

You want to secure the internet? Once again, e2e not smart networks.

Cb

---

From: Qiong <[email-masked]>
Date: Tue, 13 Mar 2012 04:14:52 +0800

Dear George and all,

We have submitted an updated version of
draft-sunq-v6ops-contents-transition based on our practices of IPv4/IPv6
transition system for data center. Since China Telecom has deployed the
transition system for data center, we would like to share our experience.

Please find it in the following link:
http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition-03

We would be appreciated to have your comments and suggestions.

Best wishes

Qiong

On Thu, Mar 8, 2012 at 4:29 AM, George, Wes <[email-masked]>wrote:

> IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris.
> I'll provide a few comments separately on that one, but I don't want those
> to be misconstrued as interest in seeing the draft presented.
>
> Regarding draft-lopez, As with previous documents of this type, I think
> there's a certain burden of proof that we need another cookbook document on
> "IPv6 deployment in [foo]" and that IETF is the proper venue for it. As
> other work (like ARMD) in IETF is finding out, "datacenter" is such a
> nebulous concept that purporting to represent a deployment strategy for a
> datacenter is probably simplistic and overbroad. It will either be so
> generic that it won't say anything new, or it will be so specific that it
> won't be applicable to very many applications, and either way that's not
> overly helpful.
> While Brian is correct in his observation than ICP != datacenter, many of
> the same things are suggested/useful, so I do think that there's a lot of
> overlap. The authors either need to propose solving for a different problem
> space, or identify a way to eliminate the overlap.
>
> Thanks,
>
> Wes George
>
>
> > -rw-rw-r--  1 fred  fred  10823 Mar  5 17:46
> draft-ma-v6ops-terminal-test-
> > 00.txt
> > -rw-rw-r--  1 fred  fred  18058 Mar  6 08:44
> draft-gundavelli-v6ops-community-
> > wifi-svcs-00.txt
> > (the date/time stamp reflects the fact that I'm in Japan and therefore a
> day
> > ahead)
> >
> > > Stated in no particular order, we have the following documents that
> meet
> > these criteria:
> > >  - have had list discussion since IETF 82 or responds to discussion at
> IETF
> > 82
> > >
> 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: Fred Baker <[email-masked]>
Date: Mon, 12 Mar 2012 13:39:15 -0700

As with all submissions, I'm looking for interest expressed on the mailing list by other operators.

On Mar 12, 2012, at 1:14 PM, Qiong wrote:

> Dear George and all,
> 
> We have submitted an updated version of draft-sunq-v6ops-contents-transition based on our practices of IPv4/IPv6 transition system for data center. Since China Telecom has deployed the transition system for data center, we would like to share our experience.
> 
> On Thu, Mar 8, 2012 at 4:29 AM, George, Wes <[email-masked]> wrote:

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Mar 2012 16:40:22 +0100

Hi Fred,

There has been discussion on the list about the relationship between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms)
The latest version of draft-despres-softwire-4rd-U (posted on March 12) introduces a NAT64 variant called NAT64+.
Its purpose is 464XLAT-like scenarios with improved IPv4 transparency.

I would appreciate a slot (10 minutes or more) to present what is at stake, operationally speaking. 
There is no v6ops-specific draft: time has been too short to make one despite relevance to v6ops of the subject matter to v6ops.
(There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.)

Thanks,
RD

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Mar 2012 03:38:32 -0700

> (There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.)

4rd and dIVI are two legs of MAP, as I understand it. I was expecting that discussion during the 464xlat discussion, from the floor, but I'm willing to give someone ten minutes to present the MAP effort

	http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u
	http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation
	http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port
	http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd
	http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast

and discuss its implications vis-a-vis 464clat. In ten minutes, this is obviously at a very high level. Do you think you can talk with your fellow contributors to the MAP effort and find one person who can fairly the describe all of that?

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Mar 2012 12:23:43 +0100

Fred,

>> (There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.)

This is only based on a small part of the latest 4rd-u draft.
There is definitely no need to present all other documents you listed below.
I do believe that, in 10 min, I can usefully inform the v6ops WG about the relationship between 464XLAT and 4rd.

Regards,
RD

---

From: Tom Taylor <[email-masked]>
Date: Wed, 14 Mar 2012 09:22:30 -0400

Perhaps it would be useful to know that Rémi's 4rd-U is actually a 
competitor to MAP.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 14 Mar 2012 06:32:00 -0700

competitor to MAP.

Yep. And they both see 464xlat as a competitor.

I oppose bringing this "mine is better than yours" story to the floor. It
has not been productive on the list and it will be less productive in
person where it is harder to counter the hand waving arguments (like
concerns about a /96 that have been addressed clearly on the list and seems
to be only the interest of one person)

The stateless solutions have a place in softwires. Once they have
operational scenarios and deployment lessons learned, they will fit v6ops.

Cb
>>>> There has been discussion on the list about the relationship between
464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms)
>>>> The latest version of draft-despres-softwire-4rd-U (posted on March
12) introduces a NAT64 variant called NAT64+.
>>>> There is no v6ops-specific draft: time has been too short to make one
despite relevance to v6ops of the subject matter to v6ops.
>> I do believe that, in 10 min, I can usefully inform the v6ops WG about
the relationship between 464XLAT and 4rd.
>>
>> Regards,
>> RD
>>
>>
>>
>>
>>>>
>>>> Thanks,
>>>> RD
>>>
>>>
>>> 4rd and dIVI are two legs of MAP, as I understand it. I was expecting
that discussion during the 464xlat discussion, from the floor, but I'm
willing to give someone ten minutes to present the MAP effort
>>>
>>> and discuss its implications vis-a-vis 464clat. In ten minutes, this is
obviously at a very high level. Do you think you can talk with your fellow
contributors to the MAP effort and find one person who can fairly the
describe all of that?
>>>>> - have had list discussion since IETF 82 or responds to discussion at
IETF 82
>>>>>
>>>>> At this point, I take them as our agenda at IETF 83. If I am missing
a document (if you have posted it since Sunday, I may well be missing it),
please remind me.
>>>>> No presentation expected, but the authors would like working group
adoption. We need to decide whether we want to do that.
>>>>> In the coming week, I am told to expect one additional -00 draft, and
I could imagine other drafts being updated. I will be looking for those
drafts to meet the criteria above as well, but please drop the chairs a
note.

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Mar 2012 14:33:32 +0100

Le 2012-03-14 à 14:22, Tom Taylor a écrit :

> Perhaps it would be useful to know that Rémi's 4rd-U is actually a competitor to MAP.

Yes, indeed.
4rd is proposed as a unified standard, expected to replace the two standards of the MAP proposal, but the two designs have otherwise a lot in common.

That said, the point to be presented in v6ops is the relationship between 4rd and 464XLAT, while such a relationship hasn't been considered so far for MAP.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Mar 2012 14:41:30 +0100

Hi Cameron,

I see more the NAT64+ proposed in the latest 4rd draft as a complement to the 464XLAT approach that you promoted.

The goal is some commonality in customer nodes between a stateful solution (DS hosts using NAT64s) and a stateless  solution (4rd in this instance).

Of course, it's difficult to have it understood if there is no opportunity to explain it.

Regards,
RD

Le 2012-03-14 à 14:32, Cameron Byrne a écrit :

> I oppose bringing this "mine is better than yours" story to the floor. It has not been productive on the list and it will be less productive in person where it is harder to counter the hand waving arguments (like concerns about a /96 that have been addressed clearly on the list and seems to be only the interest of one person)
> 
> The stateless solutions have a place in softwires. Once they have operational scenarios and deployment lessons learned, they will fit v6ops.
>