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

[Loa Andersson <[e-mail]>]

Malcolm,

good that we are making some progress!

On the experimental code point
------------------------------

I doesn't seem appropriate to call out the fact that some commercial
products has been using an experimental code point in production
setting!

On the remain (key) disagreements
---------------------------------

I will let other people comment for now.


/Loa

On 2012-03-21 21:33, [e-mail] wrote:
> Loa,
>
> Thank you for your comments and suggestions, please see in line below.
>
> Regards,
>
> Malcolm
>
>
> [e-mail] wrote on 12/03/2012 04:31:43 AM:
>
>  > Loa Andersson <[e-mail]>
>  > Sent by: [e-mail]
>  >
>  > 12/03/2012 04:31 AM
>  >
>  > To
>  >
>  > [e-mail]
>  >
>  > 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: [e-mail]
>  > Sr Strategy and Standards Manager [e-mail]
>  > Ericsson Inc phone: [phone]
>  > [phone]
>  > _______________________________________________
>  > Ietf mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/ietf
>  >

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]