Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-v6ops-eh-deepdive-cs-00.txt

["[e-mail]" <[e-mail]>]

Ed,Thanks so much for your careful reading and comments.> IMHO: it is a good idea to develop “EH troubleshooting BCP”. It is a completely new initiative for v6ops/IETF.Thanks!> Problem statement (draft-elkins-v6ops-eh-deepdive-fw) is good.> I do not agree with the word “test” in all documents’ names – it should be “troubleshooting”.> “Test” in the text itself is fine.I think "Troubleshooting" is better to use.  Good point.
For : Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server

> It looks like “network operator” in this document means “network owner”. The industry typically assumes that “operator”=”carrier”. Hence, > it is better to replace “operator” with something that has no double meaning.
Hmm.  This is something that we have thought about getting the right word for.   People are saying that enterprises who run their own networks arealso "operators".   I don't know about "network owner" although that may be the right word.   What we mean to say is that the person needs to beable to control the equipment enough to do diagnostics.   It may be that root access is required.   I am willing to go with whatever the group thinks is best.
> Curl generates random-sized packets (mostly small):



> Typically, “tests“ are done with predictable frame sizes and should be replicable that is not the case for curl.> With such a tool, it looks more like troubleshooting, not tests.



> It is not stated in the document what type of EHs with particular sizes should be used.> Fernando and Jen have shown in different tests that there is a big dependency on the EH size and type.> It is again pushing to suspect that it is troubleshooting, not tests.

> It may lead to a situation when this troubleshooting would fail.> Because the test (by curl) may show no problem, but the real application may not work.> Primarily, because it would use different EH type and size.> In this corner case, troubleshooting makes sense to continue by the application that has a problem.> It is possible to add this statement to the draft.
This is a very good point.  We used a very large index.html file for the CURL.  So, then it created not only largepackets but also fragmentation.   We will add a discussion of the test environment for CURL so that people donot make mistakes.
Of course, IMHO, testing with any real application is always best!
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone] 

    On Friday, October 7, 2022 at 10:47:02 AM PDT, Vasilenko Eduard <[e-mail]> wrote:  
 
  
Hi Nalini,
 IMHO: it is a good idea to develop “EH troubleshooting BCP”. It is a completely new initiative for v6ops/IETF. Problem statement (draft-elkins-v6ops-eh-deepdive-fw) is good. I do not agree with the word “test” in all documents’ names – it should be “troubleshooting”. “Test” in the text itself is fine. 
 
 
Deep Dive into IPv6 Extension Header Testing
 
draft-elkins-v6ops-eh-deepdive-fw-00.txt
 
 
 
“EH transmission does not workwritlarge”
 
 
 
 
 
Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server
 
draft-elkins-v6ops-eh-deepdive-cs-00.txt
 
 
 
It looks like “network operator” in this document means “network owner”. The industry typically assumes that “operator”=”carrier”. Hence, it is better to replace “operator” with something that has no double meaning.
 
 
 
Curl generates random-sized packets (mostly small):

Typically, “tests“ are done with predictable frame sizes and should be replicable that is not the case for curl.
With such a tool, it looks more like troubleshooting, not tests.
 
It is not stated in the document what type of EHs with particular sizes should be used.
Fernando and Jen have shown in different tests that there is a big dependency on the EH size and type.
It is again pushing to suspect that it is troubleshooting, not tests.
 
 
 
It may lead to a situation when this troubleshooting would fail.
 
Because the test (by curl) may show no problem, but the real application may not work.
 
Primarily, because it would use different EH type and size.
 
In this corner case, troubleshooting makes sense to continue by the application that has a problem.
 
It is possible to add this statement to the draft.
 
 
 
Eduard
 
From: v6ops [mailto:[e-mail]]On Behalf Of [e-mail]
Sent: Wednesday, October 5, 2022 4:42 PM
To: V6ops List <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: [v6ops] Fw: New Version Notification for draft-elkins-v6ops-eh-deepdive-cs-00.txt
 
  
 
All,
 
  
 
We have posted the second in our series on how to find problems with transmission of IPv6 extension headers.   We will start with the simplest type of network topology and then continue to more complex areas.
 

We welcome comments and discussion.
 
  
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone]
 
  
 
  
 
----- Forwarded Message -----
 
From: "[e-mail]" <[e-mail]>
 
To:[e-mail] <[e-mail]>; Dhruv Dhody <[e-mail]>; Michael Ackermann <[e-mail]>; Nalini Elkins <[e-mail]>
 
Sent: Wednesday, October 5, 2022 at 06:36:51 AM PDT
 
Subject: New Version Notification for draft-elkins-v6ops-eh-deepdive-cs-00.txt
 
  
 
  
 
A new version of I-D, draft-elkins-v6ops-eh-deepdive-cs-00.txt
 
has been successfully submitted by Nalini Elkins and posted to the
 
IETF repository.
 
  
 
Name:        draft-elkins-v6ops-eh-deepdive-cs
 
Revision:    00
 
Title:        Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server
 
Document date:    2022-10-05
 
Group:        Individual Submission
 
Pages:        6
 
URL:           https://www.ietf.org/archive/id/draft-elkins-v6ops-eh-deepdive-cs-00.txt
 
Status:       https://datatracker.ietf.org/doc/draft-elkins-v6ops-eh-deepdive-cs/
 
Htmlized:     https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-cs
 
  
 
  
 
Abstract:
 
  This document proposes a methodology for isolating the location and
 
  reasons for IPv6 Extension Headers blockage in a network where the
 
  operator has access to install products and run diagnostic tests on
 
  both the client and server.  Neither the client nor the server should
 
  be behind a CDN or on a Cloud infrastructure.  This document is a
 
  part of the Deep Dive into EH Testing set of documents.
 
  
 
                                                                                 
 
  
 
  
 
The IETF Secretariat