Subject: [v6ops] Fwd: Re: Some questions on draft-elkins-v6ops-ipv6-ipid-needed

From: joel jaeggli <[email-masked]>
Date: Tue, 05 Feb 2013 11:47:03 -0800

for  the record since this was my commentary on the response to our 
traditional questions.

-------- Original Message --------
Subject: 	Re: Some questions on draft-elkins-v6ops-ipv6-ipid-needed
Date: 	Sun, 03 Feb 2013 14:02:12 -0800
From: 	joel jaeggli <[email-masked]>
To: 	Nalini Elkins <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
CC: 	[email-masked] <[email-masked]>, Bill 
Jouris <[email-masked]>, Ackermann Michael 
<[email-masked]>, Larry Kratzke <[email-masked]>, 
[email-masked] <[email-masked]>

Inline,

On 2/3/13 11:29 AM, Nalini Elkins wrote:
> Fred,
>
> Please find my comments below your questions.
>
>
> Thanks,
>
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
>
>
> ----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Saturday, February 2, 2013 5:45 AM
> Subject: Some questions on draft-elkins-v6ops-ipv6-ipid-needed
>
>> Let me ask some questions. This is not intended to put you off or offend, but to help the chairs in understanding where the draft fits in the big scheme of things.
> First, let me preface this discussion by saying that it seems that there may be a disconnect between the parties (IETF and some end-user companies) and we have an opportunity here to start to work together.  The following is what I believe to be the case, please correct me if I am wrong.
>
> 1.  The RFCs decided on by the IETF apply not just to the Internet but to large, private networks or Intranets.
> 2.  Some of these Intranets are quite large indeed.  For example, I worked in network design and planning for Chevron for many years & and at that time Chevron had its own microwave network in the Gulf region, etc.  Obviously, BCBS Michigan and US Bank run some of the largest intranets in the world.
> 3.  The companies who run these intranets are responsible for the traffic end-to-end.   Huge amounts of money are involved.  Time saved in diagnostics means real dollars for their bottom line.
> 4.  The IETF generally, I believe, does not realize the complexity of these internal networks.
> 5.  This is because the end-user companies, by and large, do not understand they need to participate in the IETF!
>
> To quote one of the people in my group:
>
> "A business like ours understands the significance of lobbying Congress for legislation, but they don't understand the significance of lobbying the IETF for network architecture.  Even though IPv6 has been around for 10 years or more, we're just now starting to seriously take a look at using it.  We did not have the foresight, leadership, finances, etc., 10 years ago to realize we should have been lobbying the IETF for the IPID when IPv6 was first designed.  (If our RFC is not approved it might take another 5-10 years before enough organizations start feeling the pain of not having an IPv6 IPID that they'll begin to realize there is a problem at all.  Much less have any idea what needs to be done to fix the problem.)"
>
> Having said that, I HOPE(!) to have 5 end-user companies all together attending the IETF in Orlando.   These are cross-industry.  (One is in the Fortune 20, another is one of the underpinnings of our financial system, and of course, BCBS Michigan and US Bank).  Now, it is hard persuading companies to do something - e.g. attend IETF - that they have never done before.  Especially when it involves spending money.   I would like to suggest working together to do some outreach; as it is in the interests of both IETF and end user companies to participate in protocol discussions.   I will bring this up again after answering all your questions.
>
> Also, it is somewhat disconcerting that, in order to get on the agenda for the IETF, we need to have support for our idea on the IETF email list.

I'm not sure you're interpreting that correctly. the v6ops chairs are
looking for evidence of involvement. Support is more equivocally
positive. We are above  all concerned that documents that get on the
agenda are things that people are prepared to discuss, because that ends
up producing in actionable results, notwithstanding what sort of action
it results in.

>   To give an analogy, it is somewhat like saying if a bunch of zebras wants to join a herd of giraffes in doing something, then the zebras need support from the giraffes before they can join.  Well, the giraffes may not understand the needs of the zebras and some of the needs may well be conflicting.  So, it is hard to get support!   And, that is why we are trying to join the discussion - so we can change the discussion from the inside.  And, as we are new, I am sure that we are not obeying all of the protocols of the group - if indeed, we even understand them!   Let me assure you, we are trying.  Please let us know when we unwittingly miss something.
>
>> 1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks?
> A sequence number such as IPv4 IPID helps reduce the time for problem diagnostics.    At its most basic, the operational problems involve connections which are failing and connections which are slow.  This, obviously, takes many forms depending on the applications involved - for example, http which kicks off SSL,   law enforcement using cell phones over a VPN, etc.  The point being that an end-to-end connection needs to be diagnosed.   Hence, the networks affected are end-user networks - primarily intranets but not exclusively. Such problems are also complex enough to require packet tracing rather than log or SNMP analysis.   We have provided 5 examples of such problems in the Use Cases in our 6man and v6ops drafts.
So, you also have a previous draft, which received some dicussion but,

I'm not sure the problem statement adequately conveys how ipid's are
used for troubleshooting  or responds to dicussion of the previous draft.

In my own network I have a little trouble  understanding how to do this,
I would have a lot of trouble extracting ipids from ipv4 headers at most
hops other than end systems and L4 or higher middle boxes, e.g. it's
really hard to ask a router to do this, installing a mediation device
across a 16 x 10Gb path is a non-starter, diverting traffic for a given
destination through a device that allows measurement is straight forward
but clearly what you're measuring at that point relative to the common
path is an open question. putting it in and ipv6 extension header, is
potentially even more expensive because it implies parsing a big chunk
of a potentially large header chain (which is a known problem), which in
fact the protocol expects you not to parse it all (parsing L4 headers
headers when you have a extension header chain to look through is a
known problem too) .

In our case Largely this means we rely on a lot of statistical sampling
and end to end measurement  the latter case being where missing
data-grams are readily identified...

v6 extension headers are multiples of 8 octetes, so a device that
originates this header is either sending smaller tcp/udp datagrams
larger packets or is deliberately fragmenting all of which seem like
really bad things to introduce to the measurement path, e.g. part of the
value of an ipid from your current vantage point is that it's present.

>>
>> 2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable.
> I believe this fits into section 1:
>
> "Solicit input from network operators *and users* [emphasis added] to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. "
>
> In your categorization, I believe we are 'users'.   In your terminology,  the telecommunications vendors (Comcast, AT&T, etc) are 'operators'.   I don't know if the charter needs to be amended to include companies such as ourselves or if a new group needs to be formed?   We are very impacted by the TCP/IP protocols and should have a voice somehow.

If you operate a network you're an operator as far as I'm concerned.
Carriers are something else.

>
>>
>> 3) Who is this draft's audience?
> Anyone who is interested in assisting end-user companies implement and use IPv6 effectively.
>
>>
>> 4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion?
> If we understand correctly, by 'operators', you mean the telecommunications vendors (Comcast, AT&T, etc.).  If that is correct, then I would venture to say none of them have any compelling business interest.  Other than to make sure that their customers - end user companies - have the diagnostics that they need.   Now, the reason that they or network equipment vendors, would not care about something such as IPID is, to put it simplistically,  that they are responsible for getting bytes from one place to another successfully.  If they are not the RIGHT bytes, or if it is taking an unacceptably long time to get them there, that is someone else's job to figure that out.  Well, as the people working for and supporting the end user companies, we are the 'someone else'.
>
> Having said that, I do know some people at Comcast reasonably well and have asked them offline to review our submission and await their feedback.  (I have also asked people at Cisco & university professors where my daughter goes to school & federal agencies who are customers & friends.)
>
> As, one of the others in my group put it:
>
> "For the 99% of the world who uses TCP/IP in one way or another they probably don't even know the IPID exists.  Even if they did, they might not have any understanding of its use or care about it.   For the 1% of the TCP/IP world that troubleshoots problems, especially complex problems, we've likely run into one or more occasions in which it was essential to have the IPID to get quickly to the root of the problem."
>
> I would say that this is a problem that is relevant probably exclusively to end-user companies.   In particular, the 1% who have the largest and most complex networks.  But, I just worked on a consulting contract for quite a small financial where I used IPID quite useful.
>
> I have also talked this over with the original developer of a network analysis product that you will all have heard of, and who has his own entry in Wikipedia (that passes for fame in today's world!  Sigh.)  I am trying to get him on the phone to see if he will comment publicly or at least let me forward his email to you.  But, as it is Superbowl Sunday, it may take a day or two.   He understands the issue VERY well and in fact, read over our draft submission.   Let me quote from his email:
>
> "I think this is a great idea! An explicit (and separate) [IPID] diagnostic field for IPv6 would definitely be helpful for xxx and many other tools.
>
> "Two quick notes:
>
> "You might want to add a SHOULD NOT or MUST NOT explicitly stating that gateways must not modify or remove the IPID from packets that they forward.
> Many OSes support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl which is currently enabled), primarily to improve security. Is that needed here? "
>
> As I say, I will ask him to comment publicly.
>
>
>>
>> 5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel.
> 6Man.  We understood that the actual solution was to be presented in 6man.   We may have misunderstood.   Also, the 6man charter says that, if they are not the right venue for a particular proposed RFC, they are the venue to advise on which Working Group is the right place.

Protocol change and in this cases the proposed creation of a new
extension header is unequivocally the domain of 6man. there is certainly
an operational component of the problem statement. I don't see any
reason not to dicuss it.

>
>>
>> 6) Is any protocol work being recommended in the draft?
>>
> In the 6man draft, we asked for a Destination Options header, to include the IPID field.  But, this is ONLY a suggestion.   What we really hope to get is a collaborative effort with current IETF members and some of us to come up with a solution.   This, I think, will be in the best interests of all.
>
>> the criteria the WG asked me to apply for new work or presentation slots are:
>>     - recent or recently updated draft
>>     - within charter
>>     - results in constructive discussion on the mailing list
>>
>> I need for you to provoke discussion on the list. You may respond to my opening email to do so if it's helpful.
>>
>>
> I am trying to get people and companies to join the IETF email list and comment publicly.  As I said, this is an uphill battle as many companies ask  'Why should I do this?'   'Who is the IETF anyway?'   And, "Will we get sued for commenting?"  (I kid you not.  This is a serious concern for some end-user companies.)
>
> I hope that we can do some outreach together with the goal of getting more end-user companies involved in the IETF.  As a first step, my company is happy to arrange webcasts where I can try to get many of the Fortune 1000.   Many are already customers of our classes, products, or consulting.  I can also try to get IBM to support.  We will be at a trade show this coming week where there will be quite a few large companies as well as IBM.  I hope to do some face-to-face arm-twisting.
>