Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)
draft-betts-itu-oam-ach-code-point-04

[Ballot comment]
This document states that:

"A number of experts in the IETF do not consider that the development or deployment of a second protocol solution within the same architectural problem space is necessary or advisable" and cites draft-sprecher-mpls-tp-oam-considerations.

draft-sprecher-mpls-tp-oam-considerations provides many engineering reasons why the deployment of a second MPLS-TP OAM is undesirable.

If  G.8113.1 were an IETF document I would have entered a Discuss on this enabling document. However, I believe that it is in the best interests of the IETF that this decision be deferred to the  government officials charged with the responsibility for the approval or rejection of ITU-T Recommendation G.8113.1 itself. I request that in applying their wisdom to this difficult problem, these government officials do due diligence to the engineering consequences of their actions.

I have thus entered an abstain.

[Ballot comment]
The experts believe that multiple OAM protocols for MPLS-TP is undesirable for interoperability, and I agree with that.
However, I do not think it is in the best interest of the IETF to  block the allocation of the code point for ITU-T Recommendation G.8113.1.

[Ballot comment]
In the IANA considerations where the value 0x8902 is suggested, it would probably be good to note that the rationale is to be consistent with the EtherType for Y.1731.  If that value does get assigned, I think it would be good to have record of why such a seemingly odd value was picked since there are several earlier blocks of unassigned values.

I agree with other ADs that the IETF participants have not expressed a favorable consensus for making an allocation permitting multiple OAM types.

[Ballot comment]
I agree with the experts in the IETF cited in this document and with
the conclusion reached in other documents that it would be desirable
to have only one MPLS-TP OAM protocol.  Therefore, in my opinion, a
new G-ACh Type should not be assigned for "G.8113.1 OAM" as requested
in this document.  However, I will not block its publication and I
have entered an Abstain position.

[Ballot comment]
I don't believe what this code point represents is in the best interest of the Internet, but also don't believe further changes to this document will improve the situation so I am abstaining.

[Ballot comment]
As others have said, the specification of multiple OAM mechanisms for MPLS-TP does not benefit the community. However, I will not block publication of this draft.

[Ballot comment]
As others have said, the specification of multiple OAM mechanisms of MPLS-TP does not benefit the community. However, I will not block publication of this draft.

[Ballot comment]

(This is an agreed text between the two security ADs, in case there's a concern
its a cut'n'paste error.)

While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15
did approve the contents of RFC 5586 and in that RFC it requires that relevant
associated channel type specification include security considerations.  The
latest version of G.8113.1 available to me does not include a security
considerations section.  It's unclear why G.8113.1 doesn't include the agreed to
section.

If G.8113.1 was an IETF draft, I would have entered this as a Discuss because
G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as
there are two OAM solutions I consider the one that does address security
considerations to be the superior solution.  In addition, experience in the
Security Area has shown developing two standards for the same thing is damaging
and that that damage persists in the long term, so I believe that the current
situation with two OAM solutions represents a bad outcome.

However, I do not think it is in the best interest of the IETF to block the
allocation of the code point for ITU-T Recommendation G.8113.1 based on this
point.

[Ballot comment]
We have a situation here where we are being asked for IETF-wide approval of a code point allocation for a protocol that we have never seen, and a protocol that the present document says "a number of experts in the IETF" think is not "advisable". Though there was minimal objection during IETF Last Call, I'm not completely convinced we would have considered this "in the rough" part of the rough consensus under normal circumstances. However, I think calling it "rough consensus" can be justified, and therefore I'm uninclined to argue about it further. That said, I abstain.

[Ballot comment]
We have a situation here where we are being asked for IETF-wide approval of a code point allocation for a protocol that we have never seen, and a protocol which that the present document says "a number of experts in the IETF" think is not "advisable". Though there was minimal objection during IETF Last Call, I'm not completely convinced we would have considered this "in the rough" part of the rough consensus under normal circumstances. However, I think calling it "rough consensus" can be justified, and therefore I'm uninclined to argue about it further. That said, I abstain.

[Ballot comment]
While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15 did approve the contents of RFC 5586 and in that RFC it requires that relevant associated channel type specification include security considerations.  The latest version of G.8113.1 available to me does not include a security considerations section.  It's unclear why G.8113.1 doesn't include the agreed to section.

If G.8113.1 was an IETF draft, I would have entered this as a Discuss because G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as there are two OAM solutions I consider the one that does address security considerations to be the superior solution.  In addition, experience in the Security Area has shown developing two standards for the same thing is damaging and that that damage persists in the long term, so I believe that the current situation with two OAM solutions represents a bad outcome.

However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1 based on this point.

[Ballot comment]
While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15 did approve the contents of RFC 5586 and in that RFC it requires that relevant associated channel type specification include security considerations.  The latest version of G.8113.1 available to me does not include a security considerations section.  It's unclear why G.8113.1 doesn't include the agreed to section.

If G.8113.1 was an IETF draft, I would have entered this as a Discuss because G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as there are two OAM solutions I consider the one that does address security considerations to be the superior solution.  In addition, experience in the Security Area has shown developing two standards for the same thing is damaging and that that damage persists in the long term, so I believe that the current situation with two OAM solutions represents a bad outcome.  However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1 based on this point.

[Ballot comment]

  I believe that multiple OAM protocols for MPLS-TP is undesirable;
  however, I do not think it is in the best interest of the IETF to
  block the allocation of the code point for ITU-T Recommendation
  G.8113.1.

[Ballot comment]

  I believe that multiple OAM protocols for MPLS-TP is undesirable;
  however, I do not think it is in the best interest of the IETF to
  block the allocation of the code point for ITU-T Recommendation
  G.8113.1.

  The Gen-ART Review by Christer Holmberg on 26-Feb-2012 reports two
  editorial comments:

  - Section 1: Please expand 'MPLS-TP' and 'MPLS' when first used, and
    add a reference to where MPLS-TP and MPLS are defined.

  - Section 1: Please expand ACH when first used.

[Ballot comment]

  I believe that multiple OAM protocols for MPLS-TP is undesirable. I
  do not think it is in the best interest of the IETF to block the
  allocation of the code point for ITU-T Recommendation G.8113.1.

  The Gen-ART Review by Christer Holmberg on 26-Feb-2012 reports two
  editorial comments:

  - Section 1: Please expand 'MPLS-TP' and 'MPLS' when first used, and
    add a reference to where MPLS-TP and MPLS are defined.

  - Section 1: Please expand ACH when first used.

[Ballot comment]

  I believe that multiple OAM protocols for MPLS-TP is undesirable.  I do not think it is in the best
  interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1.

[Ballot discuss]
Please can you  make the following change to clarify what we want the RFC Editor to do:

OLD
[G.8113.1]  ITU-T Recommendation ''Operations, Administration and
            Maintenance mechanism for MPLS-TP in Packet Transport
            Network (PTN)'' 10/12,
            http://www.itu.int/rec/T-REC-G.8113.1/en
            (Note to RFC editor: This link will become valid after
            G.8113.1 is approved)
NEW
[G.8113.1]  ITU-T Recommendation ''Operations, Administration and
            Maintenance mechanism for MPLS-TP in Packet Transport
            Network (PTN)'' ,
            http://www.itu.int/rec/T-REC-G.8113.1/en
            [Notes to RFC editor:
            This link will become valid after G.8113.1 is approved.
            Please insert date of approval of G.8113.1.]
END

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Allocation of an Associated Channel Code Point for Use by ITU-T
  Ethernet based OAM'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document assigns an Associated Channel Type code point for
  carrying Ethernet based Operations, Administration, and Management
  messages in the MPLS Generic Associated Channel (G-ACh).

The file can be obtained via
http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/


No IPR declarations have been submitted directly on this I-D.

AD review comments and questions

---

Hi Malcolm and Huub,

I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task.

I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting.

My review of the document...

1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to).

2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this "obvious" from G.8113.1 or does it need to be clarified?


My review of the write-up and discussions...

3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do?

a. This is a proposal to use an MPLS code point and so is part of MPLS by definition.

b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group.

4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability?

5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a "tidy" way.

Looking forward to your reply.

Thanks,
Adrian

Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt

As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the
current template for the Document Shepherd Write-Up for individual
submissions via the IESG.

Changes are expected over time. This version is dated February 5, 2007.

--

  (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?

Huub van Helvoort (Huub.van.Helvoort@huawei.com)
Yes, I have reviewed the document and I believe it is ready for
forwarding to the IESG to be published.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

The document was first posted on 16th October; no discussion has taken
place on any email lists.  However, this draft is addressing a well know
issue that was first brought to the attention of the IETF in a request
from the director of the ITU-T in June 2010 requesting the assignment of
an ACh code point that would be used to run Ethernet based OAM on
MPLS-TP networks.  The draft requests IANA to assign a code point from
the registry of Pseudowire Associated Channel Types.  It does not make
any proposals to modify the MPLS data plane forwarding behaviour or of
the any IETF defined protocols.  Therefore, review by the MPLS WG is not
required.

  (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. The purpose of the document is clear and the scope is limited to the
assignment of a code point for (restricted) use by the ITU-T.

  (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 interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

The issue of supporting an alternative set of OAM mechanisms for MPLS-TP
based on Ethernet OAM has been widely discussed without reaching any
firm conclusion.  Note that more than 350,000 nodes have now been
deployed with Ethernet based OAM using a code point from the
experimental range.

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

This draft is requesting the assignment of an ACh code point that will
be used to run Ethernet based OAM on MPLS-TP networks.  This protocol
has been defined in the ITU-T and should not be considered to be a MPLS
protocol and therefore should not subject to the provisions of RFC 4929.
This request is supported by a significant number of network operators.
However, discussion on the IETF list during the last call of
draft-sprecher-mpls-tp-oam-considerations indicates that other do not
support the view that aa alternative Ethernet based OAM mechanism is
required.

  (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, however see the discussion on the IETF list during the
last call of draft-sprecher-mpls-tp-oam-considerations.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
        Checklist
        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?

No ID_nits found; the draft does not define a MIB or any protocols.

  (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].

The split is appropriate; the only normative references are to published
RFCs without any downwards references.

  (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 suggested a reasonable name for the new
        registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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 consideration section exists and is consistent.

  (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 formal language.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

        Relevant content can frequently be found in the abstract and/or
        introduction of the document. If not, this may be an
        indication that there are deficiencies in the abstract or
        introduction.

This document assigns an Associated Channel Type code point for carrying
Ethernet based Operations, Administration, and Management messages in
the MPLS Generic Associated Channel (G-ACh).

    Working Group Summary

        Was there anything in the discussion in the interested
        community that is worth noting? For example, was there
        controversy about particular points or were there decisions
        where the consensus was particularly rough? Was the document
        considered in any WG, and if so, why was it not adopted as a
        work item there?

This document is an individual submission via AD sponsorship aiming to
gain IETF consensus. It is not the product of a working group.

This document assigns an Associated Channel Type code point for carrying
Ethernet based Operations, Administration, and Management messages in
the MPLS Generic Associated Channel (G-ACh).  These OAM messages will be
used as an alternative mechanism to support OAM functions in a MPLS-TP
network.  To date more than 350,000 nodes have been deployed using this
mechanism using a code point from the experimental range.

This document does not contain technical details of OAM for MPLS-TP
networks, and does not make any comment on the judgement of the working
groups in their technical decisions. The document is concerned with the
wider issue of IETF policy and process.

It is the opinion of the document shepherd that discussion of this
document on the working group lists would be a distraction from the
technical protocol work that the working groups need to do.

    Document Quality

        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to implement
        the specification? Are there any reviewers that merit special
        mention as having done a thorough review, e.g., one that
        resulted in important changes or a conclusion that the document
        had no substantive issues? If there was a MIB Doctor, Media
        Type or other expert review, what was its course (briefly)? In
        the case of a Media Type review, on what date was the request
        posted?

The Ethernet based OAM protocol that will run behind this code point has
been implemented by at least four vendors and more than 350,000 nodes
have been deployed.  Multi-vendor inter-operability test have been
completed successfully.  The draft does not specify a MIB or provides
any protocol details.