Subject: [v6ops] Prep for v6ops IETF 84 agenda

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 25 Jun 2012 02:04:53 +0000

I sat down this morning to assess our agenda. Interested in working group comment.

# no update
Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt
Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt
Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt
Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt
Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt
Mar  5 17:46 draft-ma-v6ops-terminal-test-00.txt
Mar  7 07:33 draft-carpenter-v6ops-label-balance-02.txt
Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt
Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt
Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt
Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt
Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt
Mar 31 11:33 draft-yang-v6ops-fast6-00.txt

#no expressed interest
Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt
Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt

#out of charter
Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt
May 10 11:44 draft-templin-v6ops-isops-17.txt

#in IESG queue
May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt
May 17 11:02 draft-ietf-v6ops-6204bis-09.txt

#WGLC in v6ops or move to sunset4; awaiting AD direction
May  8 10:14 draft-ietf-v6ops-464xlat-03.txt

#potential for agenda
Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt
May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt
May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt

#for agenda, perhaps ready for last call
Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt

For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April, and we were to expect an update. If that happens, I expect to bring that to the agenda. 

Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but I see no update and I wasn't clear on the list commentary, whether the operators want to discuss. 

There is still, of course, time for folks to post -00 drafts (until 9 July); if there is list discussion of those drafts, we will include them in the agenda.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2012 09:05:56 +0100

> Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt

We would like to ask for a WGLC, as discussion has died down.

> Mar  7 07:33 draft-carpenter-v6ops-label-balance-02.txt

This is replaced by draft-carpenter-flow-label-balancing-01 and
draft-tarreau-extend-flow-label-balancing-00.txt. We are
not planning to discuss these in v6ops for now. The first one
doesn't suggest any protocol changes, so we could bring it
back to v6ops if asked to so so.

Regards
   Brian Carpenter

---

From: t.petch <[email-masked]>
Date: Tue, 26 Jun 2012 12:00:28 +0100

I am confused about the legend for
draft-ietf-v6ops-464xlat-03.txt

There was a lively discussion in May which left a number of issues
unclear for me, and I see that, today, a new version has arrived, so I
think that further discussion should ensue, preferrably on the list.

Tom Petch

----- Original Message -----
From: "Fred Baker (fred)" <[email-masked]>
To: <[email-masked]>
Cc: "Ron Bonica" <[email-masked]>
Sent: Monday, June 25, 2012 3:04 AM
Subject: [v6ops] Prep for v6ops IETF 84 agenda

> For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in
April, and we were to expect an update. If that happens, I expect to
bring that to the agenda.
>
> Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list,
but I see no update and I wasn't clear on the list commentary, whether
the operators want to discuss.
>
> There is still, of course, time for folks to post -00 drafts (until 9
July); if there is list discussion of those drafts, we will include them
in the agenda.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 26 Jun 2012 13:54:30 +0000

> think that further discussion should ensue, preferrably on the list.

Happy to have list discussion, and if my AD tells me it's a v6ops item, at IETF 84. That discussion may happen in sunset4.

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 26 Jun 2012 23:55:49 +0900

Hi Tom,

Thank you for your comment.

We took your opinion into consideration.
I think that we did everything we could.
Could you please comment us your unclear points or suggestion?
If we should revise the document, we will revise it immediately.

Regards,
Masanobu

>July); if there is list discussion of those drafts, we will include them

========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: t.petch <[email-masked]>
Date: Tue, 26 Jun 2012 16:28:40 +0100

----- Original Message -----
From: "Masanobu Kawashima" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Fred Baker (fred)" <[email-masked]>; "Ron Bonica"
<[email-masked]>
Sent: Tuesday, June 26, 2012 3:55 PM
> If we should revise the document, we will revise it immediately.

Ah, I haven't read -04 yet:-(

There was a quite a lot of comment on -03 so I was expecting a -04 and
confirmation or otherwise, on the list, that the comments had been
addressed.  Then I saw Fred's note about -03, which I still don't
understand but I realise I have no idea what sunset4 is, which may be
part of the part of the problem but thought that WGLC was premature
until a new version appeared so I drafted a note in response to Fred.

As I was about to hit send, I saw -04 had appeared but still thought
WGLC premature and sent the note anyway.

So I will read -04 and hope that everyone else who had comments will do
likewise, after which, I hope that the chairs will initiate WGLC.

Tom Petch

> >> Feb 21 18:10
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt
> >> May 16 02:12
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 26 Jun 2012 23:18:45 +0000

On Jun 26, 2012, at 11:28 PM, t.petch wrote:

> addressed.  Then I saw Fred's note about -03,

which came out a few minutes before I got the announcement of -04 :-)

> which I still don't

http://datatracker.ietf.org/wg/sunset4/charter/ isn't all that helpful; the IESG isn't done with the charter. But in essence, it is a working group for documents that address issues in IPv4 during the IPv6 turn-up. As originally written, it sounded like they couldn't mention IPv6 at all, which is silly. Current discussion among the chairs and the relevant ADs stops it short of being a "transition mechanism working group", but permits discussion of transition mechanisms. At this point, the discussion has come down to cases: does document X fit? does document Y? How do we adjust the proposed charter so that the point, yea or nay, is clear?

Wes and Marc can probably comment more thoroughly, but that's where the discussion stands as I understand it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Jun 2012 09:34:25 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker (fred)
> Sent: Sunday, June 24, 2012 7:05 PM
> To: [email-masked] WG
> Cc: Ron Bonica

OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu'
as "#out of charter"?

Thanks - Fred
[email-masked]

> For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April,
> and we were to expect an update. If that happens, I expect to bring that
> to the agenda.
> 
> Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but
> I see no update and I wasn't clear on the list commentary, whether the
> operators want to discuss.
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Jun 2012 18:37:56 +0200

Hi, Tom,

2012-06-26 à 17:28, t.petch:
...
> likewise, after which, I hope that the chairs will initiate WGLC.

FYI, after previous comments I had made on previous versions, I commented -04 in /www.ietf.org/mail-archive/web/v6ops/current/msg13314.html, to say:

<< I have to confirm, no surprise, that I object to its BCP status because:
- it proposes more than just a combination of existing RFCs
- it has close relationship with subjects discussed in Softwires such as MAP and 4rd, without serious examination of this relationship.

OTOH, I also confirm that I would be pleased to support it if its status is changed back to Informational (its original status) because:
- It deals with a subject not covered by existing RFCs
- It is based on ideas that have been, at least in part, tested in the field.
- Issues raised in the WG (other than the RFC status) have been dealt with. >>

Regards,
RD

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 28 Jun 2012 23:21:02 +0000

> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu'

Because changes to section 4.5 of RFC 2460 ("a source node may divide the packet...") is a change to RFC 2460, and should be discussed by the folks maintaining RFC 2460. 

Begin forwarded message:

> Date: June 23, 2012 5:43:22 AM GMT+08:00
> To: Fred Templin <[email-masked]>, "[email-masked] WG" <[email-masked]>
> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> Coming back to this as a meta-issue.
> 
> v6ops is about operational considerations and procedures, but not protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protocol issue.
> 
> The reason to not do inner fragmentation, if memory serves, has to do with the behavior of fragmentation in the network and its effect on communications. For example, suppose you and I are in 9K clean networks (so the TCP MSS starts out as 9K), my link to the public network has an MTU of 1500, and somewhere en route to you there is another link with an MTU of 1400. When I send a 9K packet, it will become six 1500 byte packets with a small caboose that picks up the size of five IP headers (IPv4 or IPv6), and what you will receive is six 1400 byte packets interspersed with six 100+IP byte packets, followed by the original caboose. What if the fragmenting router's queue, at the time of fragmentation, was one packet short of the needed capacity? Maybe the retransmission follows a different path and is fragmented differently, resulting in funny overlaps whose handling isn't very well specified. There's nothing *incorrect* about a stream of 13 packets of various sizes being reassem
> bled, but integrating retransmissions gets messy. IIRC, they just wanted to clean that up.
> 
> Which brings me to the following consideration.
> 
> If we're talking about having one tunnel endpoint put a message into a tunnel datagram and then fragment it, and have the other tunnel endpoint reassemble the original and forward it, we are talking about an operational procedure that requires support in a router, but which I can correlate with section 5 of RFC 2460.
> 
> One thing I would invite is discussion of operational experience with RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based on what actually worked (shades of Happy Eyeballs), rather than depending on error messages that network operators routinely filter out?
> 
> If we're talking about changing the recommendation of RFC 2460 regarding who does fragmentation, that sounds like an IPv6 protocol change, and I'd like to refer that to 6MAN.
> 
> Does that make sense?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Jun 2012 09:14:12 -0700

Hi Fred,

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Thursday, June 28, 2012 4:21 PM
> To: Templin, Fred L
> Cc: [email-masked] WG; Ron Bonica
> Subject: Re: Prep for v6ops IETF 84 agenda
> 
> 
> >> I sat down this morning to assess our agenda. Interested in working
> group
> >> comment.
> >
> Because changes to section 4.5 of RFC 2460 ("a source node may divide the
> packet...") is a change to RFC 2460, and should be discussed by the folks
> maintaining RFC 2460.

OK, I think I get your meaning now. You are concerned
that the draft in its current form seems to call for
an update to RFC2460 - right?

I'd like to propose a second alternative. Rather than
taking this over to 6man, my draft could be revised to
become a problem statement only rather than a functional
specification. Then, the fact that "(only) a source node
may divide the packet" becomes a problem to be addressed
in a different document - and not something to be defied
by this document.

Would you be willing to consider a new draft version
that stays within the problem statement narrative?

Thanks - Fred
 
> > v6ops is about operational considerations and procedures, but not
> protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protocol
> issue.
> >
> > The reason to not do inner fragmentation, if memory serves, has to do
> with the behavior of fragmentation in the network and its effect on
> communications. For example, suppose you and I are in 9K clean networks
> (so the TCP MSS starts out as 9K), my link to the public network has an
> MTU of 1500, and somewhere en route to you there is another link with an
> MTU of 1400. When I send a 9K packet, it will become six 1500 byte packets
> with a small caboose that picks up the size of five IP headers (IPv4 or
> IPv6), and what you will receive is six 1400 byte packets interspersed
> with six 100+IP byte packets, followed by the original caboose. What if
> the fragmenting router's queue, at the time of fragmentation, was one
> packet short of the needed capacity? Maybe the retransmission follows a
> different path and is fragmented differently, resulting in funny overlaps
> whose handling isn't very well specified. There's nothing *incorrect*
> about a stream of 13 packets of various sizes being reassem
> > If we're talking about having one tunnel endpoint put a message into a
> tunnel datagram and then fragment it, and have the other tunnel endpoint
> reassemble the original and forward it, we are talking about an
> operational procedure that requires support in a router, but which I can
> correlate with section 5 of RFC 2460.
> >
> > One thing I would invite is discussion of operational experience with
> RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based
> on what actually worked (shades of Happy Eyeballs), rather than depending
> on error messages that network operators routinely filter out?
> >
> > If we're talking about changing the recommendation of RFC 2460 regarding
> who does fragmentation, that sounds like an IPv6 protocol change, and I'd
> like to refer that to 6MAN.
> >
> > Does that make sense?

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jun 2012 12:42:43 -0700

...
> in a different document - and not something to be defied

I was expecting a differrent approach:

	a) revise this doc to focus on ops issues that
	don't require any standards changes

	b) propose the problem of IPv6 downstream refragmentation
	in a separate doc in a different WG

Even a problem statement for (b) would need to be handled in a non-ops 
WG, AFAICT.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Jun 2012 13:10:52 -0700

Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, June 29, 2012 12:43 PM
> To: Templin, Fred L
> Cc: Fred Baker (fred); [email-masked] WG; Ron Bonica
> Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda
> 
> 
> 

That sounds like a reasonable approach that can be
accommodated within the draft cutoff date timeframe.

> Even a problem statement for (b) would need to be handled in a non-ops

OK - Thanks.

Fred