RE: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



To make sure that my concerns are not missed, I attach them:

--
Hi,

I cannot support the publication of the document in its current version.

I have the following concerns:

*	It is indicated that the channel is intended to be used to carry
Ethernet based OAM messages. It is not clear why there is a need for
ACH. PWs can be used to transmit Ethernet OAM. 
If the intention is to use the channel for OAM messages for operating
MPLS-TP based networks, the IETF *already* defined a solution for
MPLS-TP OAM and I expect to see first a technical *justification* why a
second solution is needed. In addition, I would expect to see
*references to the arguments* raised in
draft-sprecher-mpls-tp-oam-considerations. 

*	It is not clear what the maturity status of G.8113.1 is. It
seems that the document was not approved by SG15 and the discussion was
deferred to WTSA. This indicates that there is *no consensus* for the
approval of G.8113.1. A code point should not be allocated before a
consensus/decision is reached in the ITU-T and before the document is
mature and approved. I do not think it is appropriate to allocate a code
point and try to force a resolution in the ITU-T. 

*	I find a contradiction in the draft. In one place it is
mentioned: "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." In another place it
is mentioned: "all ITU-T Recommendations are subject to revision.
Therefore, the code point allocated by this document may be used for
future versions of [G.8113.1].". The last statement opens the door for
the definition of additional messages in G.8113.1 in the following
versions, for example, for APS (supporting linear or ring protection
mechanisms) and by this creates two solutions for other mechanisms as
well. 

The use of the code point can go much beyond its original purpose and it
will hide other messages....a code point should not be allocated at this
point at all, but specifically not for unknown usage that may be defined
in future versions of G.8113.1. 

Best regards,
Nurit
---


-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Thursday, March 01, 2012 8:07 PM
To: ext Russ Housley; Loa Andersson
Cc: ietf@xxxxxxxx
Subject: RE: Last Call:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated
Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational
RFC

Russ,
Independently of that point, draft-betts in its current version has many
issues....
Many clarifications are needed before it can be considered....please see
my mail for the details.
Best regards,
Nurit


-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
ext Russ Housley
Sent: Thursday, March 01, 2012 8:02 PM
To: Loa Andersson
Cc: ietf@xxxxxxxx
Subject: Re: 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:

Right now, there is no ITU-T approved document to reference.   I am
certainly not an expert on ITU-T process, but my understanding is that
earliest that we could see an approved G.8113.1 is December 2012.  My
point is that we don't want to assign a code point until the ITU-T
approves their document.  However, if we are willing to assign a code
point to G.8113.1 once it is approved, then this would be an approach
where the code point assignment would block on the approval of the
normative reference.

I like this approach from the political point of view.  With this
approach the IETF tells the ITU-T that if and only if they are able to
achieve consensus on G.8113.1, then a code point will be assigned.

Russ


On Mar 1, 2012, at 11:42 AM, Loa Andersson wrote:

> Russ,
> 
> I'm not KY, but I feel that your question is a bit loaded.
> 
> Certainly if the document is reviewed and approved by the IETF/IESG
> it would be no problem to support the assignment of a ACh Type.
> 
> But I can't see that approval by some other instance actually carry
> the same merit - so exactly what do u mean by "approved G.8113.1"?
> 
> /Loa
> 
> On 2012-03-01 17:06, Russ Housley wrote:
>> KY:
>> 
>> Would you support the assignment to an approved G.8113.1?  That is,
if the document contained a normative reference to the approved
G.8113.1, then the document that makes the code point allocations would
sit in the RFC Editor queue until the ITU-T reaches consensus and
approves G.8113.1.
>> 
>> Russ
>> 
>> 
>> On Mar 1, 2012, at 10:14 AM, Kyung-Yeop Hong (hongk) wrote:
>> 
>>> No/do not support.
>>> 
>>> One of the issues with G.8113.1 in LS370 is its stability and
maturity.
>>> That was one of the reasons why it was not approved.
>>> 
>>> The Ethernet based OAM protocol documented in the LS370 version is
>>> intended to be deployed for MPLS networks. I think the IETF has a
duty
>>> to ensure that a solution is stable and works for MPLS networks
before
>>> the code point allocation. A number of concerns with the deployment
of
>>> this proposed protocol raised in
>>> draft-spercher-mpls-tp-oam-considerations are critical to the
Internet
>>> and must be taken into consideration in this Last Call.
>>> 
>>> KY
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-
>>>> bounces@xxxxxxxx] On Behalf Of The IESG
>>>> Sent: 22 February 2012 15:13
>>>> To: IETF-Announce
>>>> Subject: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
>>> (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'
>>>>  <draft-betts-itu-oam-ach-code-point-03.txt>  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@xxxxxxxx mailing lists by 2012-03-21. Exceptionally, comments
may
>>> be
>>>> sent to iesg@xxxxxxxx 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.
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> IETF-Announce@xxxxxxxx
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/mpls
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 
>> 
>> _______________________________________________
>> Ietf mailing list
>> Ietf@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> -- 
> 
> 
> Loa Andersson                         email:
loa.andersson@xxxxxxxxxxxx
> Sr Strategy and Standards Manager            loa@xxxxx
> Ericsson Inc                          phone: +46 10 717 52 13
>                                             +46 767 72 92 13

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]