[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf
Subject: Re: [PWE3] FW: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocation
From: Loa Andersson <loa () pi ! nu>
Date: 2012-03-23 9:44:47
Message-ID: 4F6C460F.4080007 () pi ! nu
[Download RAW message or body]
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, Malcolm.BETTS@zte.com.cn wrote:
> Loa,
>
> Thank you for your comments and suggestions, please see in line below.
>
> Regards,
>
> Malcolm
>
>
> ietf-bounces@ietf.org wrote on 12/03/2012 04:31:43 AM:
>
> > Loa Andersson <loa@pi.nu>
> > Sent by: ietf-bounces@ietf.org
> >
> > 12/03/2012 04:31 AM
> >
> > To
> >
> > ietf@ietf.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.andersson@ericsson.com
> > Sr Strategy and Standards Manager loa@pi.nu
> > Ericsson Inc phone: +46 10 717 52 13
> > +46 767 72 92 13
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> >
--
Loa Andersson email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager loa@pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic