ietf
[Top] [All Lists]

Re: [PWE3] FW: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC

2012-03-21 15:33:55
Loa,

Thank you for your comments and suggestions, please see in line below.

Regards,

Malcolm


ietf-bounces(_at_)ietf(_dot_)org wrote on 12/03/2012 04:31:43 AM:

Loa Andersson <loa(_at_)pi(_dot_)nu> 
Sent by: ietf-bounces(_at_)ietf(_dot_)org

12/03/2012 04:31 AM

To

ietf(_at_)ietf(_dot_)org

cc

Subject

Re: [PWE3] FW: Last Call: <draft-betts-itu-oam-ach-code-
point-03.txt>(Allocation of an Associated Channel Code Point for Use
byITU-T Ethernet based OAM) to Informational RFC

All,

I've been asked to clarify thee comments in this mail, I done
so by proposing new text to draft-betts-.

I hope this helps.


Title
=====

Comment: We want to assign a Associated Channel Type. The registry
that it  will be assigned from is "Pseudowire Associated Channel
Types"; however RFC 5586, makes the Channel Types generic and I
think the title should be changed as follows:

OLD:
Allocation of an Associated Channel Code Point for Use by ITU-T
Ethernet based OAM

NEW:
Allocation of an Generic Associated Channel Type for ITU-T
MPLS-TP OAM

Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown
acronyms, therfore the title probably should be:

NEW:
Allocation of an Generic Associated Channel Type for ITU-T
MPLS Transport Profile Operation, Maintenance and Administration.


MB: No objection to this change


Introduction - first paragraph
==============================

In the first paragraph of the introduction, there seems to be an
oddity in the description of the role of the ietf-tp-oam-analysis
document.  Instead of:

OLD
"tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that
are intended to meet the OAM functional requirements defined in
[RFC5860]."

NEW:
"tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which
are used to meet the OAM functional requirements defined
in [RFC5860]."

MB: No objection to this change


Intrduction - second paragraph
==============================

The next paragraph in describing G.8113.1, stumbles over the current
vs anticipated future state of G.8113.1 and its relationship to
its antecedents.  I'm a bit un-certain about the correct terminology,
but I think the following change would improve the document.

OLD:

The ITU-T has documented, in draft new Recommendation [G.8113.1], the
use of Ethernet based OAM mechanisms, originally defined in [Y.1731],
carried in the MPLS Generic Associated Channel (G-ACh). This approach
requires the allocation of an ACH Type from the registry of ACH types
maintained by IANA in order that the messages that will be described
in [G.8113.1] can be identified by an implementation.

NEW:

"The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM
which as of this writing is undergoing the ITU-T Traditional
Approval Process (TAP). This Recommendation builds upon Ethernet
OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined
to be carried in a new Associated Channel Type in the MPLS Generaic
  Associated Channel (G-Ach).  In order to carry these messages in an
interoperable fashion, an Associated Channel Type from the IANA
maintained registry "Pseudowire Associated Channel Types is to be
used."

MB: Since the draft will not be published as an RFC until after G.8113.1 
is approved we can directly reference the approved Recommendation and I 
suggest that we modify paragraph to:


ITU-T Recommendation [G.8113.1] documents MPLS OAM. This Recommendation 
builds upon Ethernet OAM as documented in [Y.1731]. The messages in 
[G.8113.1] are defined to be carried in a new Associated Channel Type in 
the MPLS Generaic Associated Channel (G-Ach).  In order to carry these 
messages in an interoperable fashion, an Associated Channel Type from the 
IANA maintained registry "Pseudowire Associated Channel Types is to be 
used."



Note there are confusion around some of the Associated Channel
acronyms that are refledted in this document.

ACh is Associated Channel
ACH is Associated Chamnnel Header
G-ACh is Generic Associated Channel

"ACH Type" is not used anywhere in IETF documents; we talk about
Associated Channel Type or Generic Associated Channel Type
(G-ACh Type).

MB: Thank you, I will fix this.


Introduction - third paragraph
==============================

In the third paragraph, there seems to be an unnecessary reference
to experimental types.  When asking for a code point for a standard,
it is not helped to bring up experimental code space.  Can we remove
the text reading:

OLD:
"without continuing to resorting to the use of an experimental
ACH Type,"

NEW
-

MB: I do not agree with the deletion of this text, these existing 
deployments, and the desire to migrate to an allocated code point, are 
part of the rational for requesting the code point.



Section 2 - first paragraph
===========================



In section 2, the first sentence refers to Ethernet based OAM
messages. As far as I know, the messages in G.8113.1 are either
MPLS-TP OAM messages, or they are simply the OAM messages defined
in G.8113.1.  The simplest path to clarity would seem to be to
replace "Ethernet based OAM messages" in that sentence with
"messages".

The second sentence of that paragraph does not seem to say anything
we need to say.  Can we remove it?

OLD:

    The code point allocated by this document is intended to be used 
only
    for Ethernet based OAM messages, defined in the ITU-T Recommendation
    [G.8113.1], carried in the G-ACh . These Ethernet based OAM messages
    and procedures, address the OAM functional requirements defined in
    [RFC5860]. Other message types should not be carried behind this 
code
    point.

NEW:

    The code point allocated by this document is intended to be used
    only for OAM messages, defined in the ITU-T Recommendation
    [G.8113.1], carried in the G-ACh . Other message types should not
    be carried behind this Associated Channel Type.


MB: I do not agree with this proposed change. Other comments request that 
the restriction on the applicability of the code point is strengthened so 
I propose the following:

The code point allocated by this document should only be used for OAM 
messages, defined in the ITU-T Recommendation [G.8113.1], carried in the 
G-ACh. The messages and procedures carried behind this code point, are 
restricted to only those that the address the OAM functional requirements 
defined in [RFC5860]. Other message types should not be carried behind 
this code point.



Section 2 - second paragraph
============================

A matter of some clarity, can we change this paragrap like this:

OLD:
    This code point may be used on any transport construct that uses
    the G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs.

NEW:

    The Generic Associated Channel Type assigned by this
    document may be used on any transport construct that uses the
    G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs as specified
    by G.8113.1.

MB: No objection to this change.



Section 2 - third paragraph
===========================

With regard to revisions, which is what I think the third paragraph
is about, I am not clear what you are trying to say.  A code point
allocation must point to a stable referent.  If the desired referent
changes, then process needs to be followed to make sure that the IANA
is updated in accordance with IETF procedures.  Hence, I am left to
the conclusion that the third paragraph is actually asking for
something we can not do.  Can we remove that?

OLD:
    All ITU-T Recommendations are subject to revisions. Therefore, the
    code point allocated by this document may be used for future 
versions
    of [G.8113.1].

NEW:
    -



MB: I do not agree with the removal of this text:

The intention of this statement is to bring to the attention of the IETF 
the normal practice in the ITU of developing amendments to Recommendations 
to fully meet the functional requirements (e.g. adding pro-active loss 
measurement).  Normally any reference to ITU-T Rec G.8113.1 will 
automatically be directed to the current version (including any 
amendments). 

Only those interfaces that support G.8113.1 OAM will act on these OAM 
messages, any interface that does not support this G-ACh type will discard 
these OAM messages as defined in RFC5586.

Restricting the application of the code point to a specific version of 
Recommendation G.8113.1 would require the ITU to deviate from its normal 
process for enhancing Recommendations and would put the IETF back into the 
discussion for approval.



---------------snip



Loa Andersson                         email: 
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager            loa(_at_)pi(_dot_)nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf