Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3421F85E6; Wed, 18 Apr 2012 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.454 X-Spam-Level: X-Spam-Status: No, score=-109.454 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyGrmfFEFrkd; Wed, 18 Apr 2012 03:40:37 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id F23A921F8596; Wed, 18 Apr 2012 03:40:29 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3IAePRA012775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2012 12:40:25 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 18 Apr 2012 12:40:25 +0200 From: "Bocci, Matthew (Matthew)" To: IETF-IESG via RT Date: Wed, 18 Apr 2012 12:40:23 +0200 Thread-Topic: Publication request for draft-ietf-pwe3-vccv-impl-survey-results-00.txt Thread-Index: Ac0dT6liRcEp01ISRAKhTIQbfxRybw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB458A7293E4matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "pwe3@ietf.org" , Stewart Bryant Subject: [PWE3] Publication request for draft-ietf-pwe3-vccv-impl-survey-results-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:40:41 -0000 --_000_CBB458A7293E4matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PWE3 working group requests the publication of draft-ietf-pwe3-vccv-imp= l-survey-results-00.txt. The document write-up is attached below. Best regards, Matthew --------- draft-ietf-pwe3-vccv-impl-survey-results-00.txt Document Shepherd Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review and was discussed ov= er a period of a number of IETFs. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are no formal review criteria that should be met. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. Only one Informational reference is used by the document. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists. There are no requests of IANA= , which seems reasonable given that the draft simply documents the resu= lts of an implementation/deployment survey. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. This document is a product of the PWE3 working group. This document is Informational. Working Group Summary RFC5085 defines 3 VCCV channel types. These are essentially the mechanis= ms for transport of the PW associated channel that is used to carry e.g. PW= OAM messages. In addition, RFC6423 adds a 4th mechanism which uses the GAL. = There is currently no clear definition of which modes are mandatory and which = modes are optional to implement. This has caused concerns by some participants= in the operator community that the proliferation of modes causes interopera= bility issues between vendors. As a first step to rationalising the number of m= odes, the WG conducted a survey to try to quantify which modes are in use toda= y and so determine which ones could be either deprecated, or made optional in a p= ossible future update to RFC5085. This draft contains the results of that survey= . Since the survey contains useful information pertaining to the current state of PW= deployments, there was consensus to record the results of the survey in an Informatio= nal RFC. Note that the name of the document that was originally last called by th= e WG was draft-ietf-pwe3-pw-vccv-impl-survey-results-00, but this was updated to draft-ietf-pwe3-vccv-impl-survey-results-00 as a result of a comment fro= m the WG. Document Quality The document describes a service provider implementation survey, samplin= g the deployments of PWs and their respective VCCV types. There is likely to be a skew in = the results towards operators that are willing to divulge details of their network deploymen= ts, and towards those that participate in the IETF. However, the results were anonymised, and a broad cross-section of both large and= smaller operators participated, which may help to mitigate any skew. I have no c= oncerns about the quality of the document. The document does not specify any MIB changes or additions which would n= eed review. Personnel The document shepherd is Matthew Bocci. The responsible Area Director is Stewart Bryant. --_000_CBB458A7293E4matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The PWE3 working group requests the publi= cation of draft-ietf-pwe3-vccv-impl-survey-results-00.txt.

The document write-up is attached = below.

<= /div>
Best regards= ,

=
Matthew

---------

draft-ietf-pwe3-vccv-impl-survey-results-00.txt<= /div>

Document Shepherd W= rite-Up

=

<= div style=3D"font-family: Consolas; font-size: medium; ">    (1.a= ) Who is the Document Shepherd for this document? Has the 
      &n= bsp;   Document Shepherd personally reviewed this version of the =
  &nbs= p;       document and, in particular, does he or she believe= this 
=           version is ready for forwarding to the I= ESG for publication? 

&= nbsp;  Matthew Bocci (matthew.bocci@alcatel-lucent.com)
       = ; Yes, I have reviewed the document and I believe it is ready for 
    &= nbsp;   forwarding to the IESG.


    (1.b) Has the document had adequate review both fr= om key WG members 
          and from key non-WG members?= Does the Document Shepherd have 
          any concerns = about the depth or breadth of the reviews that 
         = have been performed? 

        Yes, the document has received adequat= e review and was discussed over a
        period of a number of IET= Fs.
  &= nbsp;     


=     (1.c) Does the Document Shepherd have concerns that the docum= ent 
&n= bsp;         needs more review from a particular or bro= ader perspective, 
          e.g., security, operational = complexity, someone familiar with 
          AAA, interna= tionalization or XML? 

       No.


    (1.d) Does the Document Shepherd have any speci= fic concerns or 
          issues with this document that= the Responsible Area Director 
          and/or the IESG= should be aware of? For example, perhaps he 
          o= r she is uncomfortable with certain parts of the document, or 
     = ;     has concerns whether there really is a need for it. In any&= nbsp;
 =         event, if the WG has discussed those issues an= d has indicated 
          that it still wishes to advanc= e the document, detail those 
          concerns here. Ha= s an IPR disclosure related to this document 
          b= een filed? If so, please include a reference to the 
       =   disclosure and summarize the WG discussion and conclusion on <= /div>
   = ;       this issue. 

       No specific concerns. = ;

=

    (1.e) How = solid is the WG consensus behind this document? Does it 
      &nbs= p;   represent the strong concurrence of a few individuals, with =
  &nbs= p;       others being silent, or does the WG as a whole unde= rstand and 
          agree with it? 

      I am comfort= able that the document represents WG consensus and has
      been review= ed by a reasonable number of active WG participants. 
      <= /div>

    (1.f)= Has anyone threatened an appeal or otherwise indicated extreme 
=
    &nb= sp;     discontent? If so, please summarise the areas of conflict= in 
&n= bsp;         separate email messages to the Responsible= Area Director. (It 
          should be in a separate em= ail because this questionnaire is 
          entered into= the ID Tracker.) 

       None indicated.


    (1.g) Has the Document Shepherd persona= lly verified that the 
          document satisfies all I= D nits? (See 
          http://www.ietf.org/ID-Checklist.= html and 
          not enough; this check= needs to be thorough. Has the document 
          met al= l formal review criteria it needs to, such as the MIB 
       =   Doctor, media type and URI type reviews? 


       Yes. 
     =  
&nbs= p;      There are no formal review criteria that should be m= et.

    (= 1.h) Has the document split its references into normative and 
     = ;     informative? Are there normative references to documents th= at 
&nb= sp;         are not ready for advancement or are otherw= ise in an unclear 
          state? If such normative ref= erences exist, what is the 
          strategy for their = completion? Are there normative references 
          tha= t are downward references, as described in [RFC3967]? If 
      &nb= sp;   so, list these downward references to support the Area 
    &= nbsp;     Director in the Last Call procedure for them [RFC3967].=  

<= /div>
   = ;   Yes, the references are split appropriately. Only one Informationa= l 
&nbs= p;     reference is used by the document.



    (1.i) Has the Document Shepherd verified t= hat the document IANA 
          consideration section ex= ists and is consistent with the body 
          of the do= cument? If the document specifies protocol 
          ext= ensions, are reservations requested in appropriate IANA 
      &nbs= p;   registries? Are the IANA registries clearly identified? If <= /div>
   = ;       the document creates a new registry, does it define = the 
&n= bsp;         proposed initial contents of the registry = and an allocation 
          procedure for future registr= ations? Does it suggest a 
          reasonable name for = the new registry? See [RFC5226]. If the 
          docume= nt describes an Expert Review process has Shepherd 
        &n= bsp; conferred with the Responsible Area Director so that the IESG 
    =       can appoint the needed Expert during the IESG Evaluati= on? 
  &n= bsp;   The IANA considerations section exists. There are no requests o= f IANA,
&nbs= p;     which seems reasonable given that the draft simply documen= ts the results


    (1.j) Has the Document = Shepherd verified that sections of the 
          documen= t that are written in a formal language, such as XML 
       =   code, BNF rules, MIB definitions, etc., validate correctly in =
  &nbs= p;       an automated checker? 

      There are no sections= that use a formal language.


  =         Announcement Write-Up. Please provide such a Do= cument 
          Announcement Write-Up? Recent examples = can be found in the
          "Action" announcements for appro= ved documents. The approval 
          announcement conta= ins the following sections: 

Technical Summary

   Most Pseudowire Emulation Edge-to-Edge (PWE3) en= capsulations mandate
   the use of the Control Word (CW) in order to better e= mulate the
&= nbsp;  services for which the encapsulations have been defined.  = However,
&nb= sp;  some encapulations treat the Control Word as optional.  As a= result,
&nb= sp;  implementations of the CW, for encapsulations for which it is
   op= tional, vary by equipment manufacturer, equipment model and service
   provid= er network.  Similarly, Virtual Circuit Connectivity
   Verification (= VCCV) supports three Control Channel (CC) types and
   multiple Connectivity = Verification (CV) Types.  This flexibility has
   led to reports of inte= roperability issues within deployed networks
   and associated drafts to atte= mpt to remedy the situation.  This
   survey of the PW/VCCV user communi= ty was conducted to determine
   implementation trends.  The survey and = results is presented herein.

   This document is a product of the PWE3 working group= .

=
   This= document is Informational.

Working Group Summary
   
   RFC5085 defines 3 VCCV channel types. The= se are essentially the mechanisms 
   for transport of the PW associated= channel that is used to carry e.g. PW OAM
   messages. In addition, RFC6423 = adds a 4th mechanism which uses the GAL. There
   is currently no clear defin= ition of which modes are mandatory and which modes 
   are optional to i= mplement. This has caused concerns by some participants in 
   the opera= tor community that the proliferation of modes causes interoperability
=
   issu= es between vendors. As a first step to rationalising the number of modes,&n= bsp;
  =  the WG conducted a survey to try to quantify which modes are in use t= oday and so 
   determine which ones could be either deprecated, or made= optional in a possible 
   future update to RFC5085. This draft contain= s the results of that survey. Since the
   survey contains useful information= pertaining to the current state of PW deployments,
   there was consensus to= record the results of the survey in an Informational RFC. 
   
   Note th= at the name of the document that was originally last called by the WG was
   = draft-ietf-pwe3-pw-vccv-impl-survey-results-00, but this was updated to
   d= raft-ietf-pwe3-vccv-impl-survey-results-00 as a result of a comment from
   t= he WG.
 = ; 

=
Document Qu= ality

   = The document describes a service provider implementation survey, sampling t= he deployments
   operators that are willing to divul= ge details of their network deployments, and towards
   those that participat= e in the IETF. However,
   the results were anonymised, and a broad cross-sec= tion of both large and smaller
   operators participated, which may help to m= itigate any skew. I have no concerns 
   about the quality of the docume= nt.
  &= nbsp;
 =  The document does not specify any MIB changes or additions which wou= ld need review.

&nb= sp;  
<= br>
 Pe= rsonnel
&nbs= p;  The document shepherd is Matthew Bocci.
   The responsible Area Dire= ctor is Stewart Bryant.

--_000_CBB458A7293E4matthewboccialcatellucentcom_--