Subject: RE: 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

From: Fangyu Li <[email-masked]>
Date: Wed, 14 Mar 2012 21:36:28 +0800

I support the allocation of an ACH codepoint to G.8113.1.

For G.8113.1 had reached the technical and industry maturity to be assigned
a code point, the codepoint allocation from IETF should allow the ITU-T to
progress refinements to G.8113.1 such that it could satisfy all the
functional requirements defined in RFC 5860.

-----????? ??????-----
???: ext Ross Callon
????:  13/03/2012, 19:27
??: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon)
????: [email-masked]
????: 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
I agree that the allocation of a code point should be to a specific version
of 8113.1, and specifically should be to the final version that is approved
by the ITU-T (assuming that a final version of 8113.1 will be approved by
the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should
contain a normative reference to the final approved version of 8113.1.
Given normal IETF processes, this implies that the final RFC resulting from
draft-betts-itu-oam-ach-code-point could be published as soon as the final
version of 8113.1 is approved (with the understanding that there will be a
small normal delay between "approved" and "published" which gives time for
coordination). Given that the final version of 8113.1 might need to
reference the RFC resulting from draft-betts-itu-oam-ach-code-point, a bit
of cooperation might be needed between editorial staff at the ITU and RFC
editorial staff, but I don't see why this should be a problem (I am sure
that they all have access to email).
Ross

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 14 Mar 2012 14:41:55 +0100

Hi,

Which version of G.8113.1 has reached the technical and industry
maturity? Is it the one that was submitted to WTSA or is it the one that
the ITU worked on the December meeting? Or maybe it is the same document
that the ITU worked on in the December meeting and sent to WTSA? Can you
please clarify the point?

You say that " the codepoint allocation from IETF should allow the ITU-T
to progress refinements to G.8113.1 such that it could satisfy all the
functional requirements defined in RFC 5860" - does it meant that the
matured version does not fully satisfy the requirements presented in RFC
5860?

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Fangyu Li
Sent: Wednesday, March 14, 2012 3:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Last
Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an
Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to
Informational RFC

For G.8113.1 had reached the technical and industry maturity to be
assigned a code point, the codepoint allocation from IETF should allow
the ITU-T to progress refinements to G.8113.1 such that it could satisfy
all the functional requirements defined in RFC 5860. 

-----????? ??????-----
???: ext Ross Callon
????:  13/03/2012, 19:27
??: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon)
????: [email-masked]
????: 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
I agree that the allocation of a code point should be to a specific
version of 8113.1, and specifically should be to the final version that
is approved by the ITU-T (assuming that a final version of 8113.1 will
be approved by the ITU-T). This would imply that
draft-betts-itu-oam-ach-code-point should contain a normative reference
to the final approved version of 8113.1.

Given normal IETF processes, this implies that the final RFC resulting
from draft-betts-itu-oam-ach-code-point could be published as soon as
the final version of 8113.1 is approved (with the understanding that
there will be a small normal delay between "approved" and "published"
which gives time for coordination). Given that the final version of
8113.1 might need to reference the RFC resulting from
draft-betts-itu-oam-ach-code-point, a bit of cooperation might be needed
between editorial staff at the ITU and RFC editorial staff, but I don't
see why this should be a problem (I am sure that they all have access to
email).

Ross

---

From: Fangyu Li <[email-masked]>
Date: Wed, 14 Mar 2012 22:07:33 +0800

Hi,

For your questions:

 1) Both of the versions of G.8113.1 reach the technical and industry
maturity, for there are only editorial and little modifications such as
Global ICC based MEP/MIP formats.
 2) In last SG15 plenary meeting in Dec, at the drafting session of Q10 on
G.8113.1 and G.8113.2, both OAM solutions could not meet all the
requirements of RFC5654 and RFC5860, you could check this in
 wd16_MPLS-TP_requirementsTable_G.8113.1and
wd15r1_MPLS-TP_requirementsTable-G-8113-2-R1 in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q10/2011-12-Geneva/.

Li Fang from CATR

2012/3/14 Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]>

>  Hi,****
>
> Which version of G.8113.1 has reached the technical and industry maturity?
> Is it the one that was submitted to WTSA or is it the one that the ITU
> worked on the December meeting? Or maybe it is the same document that the
> ITU worked on in the December meeting and sent to WTSA? Can you please
> clarify the point?****
>
> functional requirements defined in RFC 5860" – does it meant that the
> 5860?****
> Best regards,****
> Nurit****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Fangyu Li
> *Sent:* Wednesday, March 14, 2012 3:36 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: Last
> Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated
> Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
> ****
>
> ** **
>
> I support the allocation of an ACH codepoint to G.8113.1. ****
>
>  ****
>
> assigned a code point, the codepoint allocation from IETF should allow the
> ITU-T to progress refinements to G.8113.1 such that it could satisfy all
> the functional requirements defined in RFC 5860. ****
>
>  ****
>
> -----????? ??????-----
> ???: ext Ross Callon
> ????:  13/03/2012, 19:27
> version of 8113.1, and specifically should be to the final version that is
> approved by the ITU-T (assuming that a final version of 8113.1 will be
> approved by the ITU-T). This would imply that
> draft-betts-itu-oam-ach-code-point should contain a normative reference to
> the final approved version of 8113.1.****
>
> from draft-betts-itu-oam-ach-code-point could be published as soon as the
> final version of 8113.1 is approved (with the understanding that there will
> be a small normal delay between "approved" and "published" which gives time
> for coordination). Given that the final version of 8113.1 might need to
> that they all have access to email).****
>
> Ross****
>
>  ****
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Mar 2012 15:53:38 +0000

On 14/03/2012 13:36, Fangyu Li wrote:
> the ITU-T to progress refinements to G.8113.1 such that it could 
> satisfy all the functional requirements defined in RFC 5860.

Please can you tell me version of the G.8113.1 text one would
need to implement to be able to seamlessly interwork with the
equipment that has already been been deployed?

- Stewart

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Mar 2012 09:46:44 +0100

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "Fangyu Li" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 14, 2012 4:53 PM
> equipment that has already been been deployed?

Stewart

I am sure you already know the answer to that from posts made to the mpls list,
where we have been told that there is currently an extensive deployment
('running code') using an experimental value (interesting that there is a last
call just ending seeking to exterminate such practice, at least for application
protocols) and that the wish is to move to a standards-based value which will,
perforce, be a different value.

Tom Petch

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 16 Mar 2012 15:12:06 +0000

On 16/03/2012 08:46, t.petch wrote:
> From: "Stewart Bryant"<[email-masked]>
> To: "Fangyu Li"<[email-masked]>
> Cc:<[email-masked]>;<[email-masked]>

Tom,

I don't think you understood my question.

There are several version of the G.8113.1 text in circulation within
the ITU-T. I was asking which version accurately describes the
deployed protocol.

I would be interested to also know what ACh Type it is actually running
on.

Stewart

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Mar 2012 16:05:30 +0100

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Fangyu Li" <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2012 4:12 PM
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof
an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to
Informational RFC

Stewart

One of the e-mails I had in mind was that of Huub Helvoort last December where
he said
"The draft recommendation G.8113.1 is stable, there have been no major technical
changes since it was sent to the IETF (when it still had the draft name G.tpoam)
attache to liaison: https://datatracker.ietf.org/liaison/983/
This is also the status I reported when we did discuss this during IETF82 in
Taipei."

while another such e-mail is that of Malcolm Betts in January where he said
"I can confirm that the draft is requesting a code point for the version of
G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the
draft that was determined in February 2011, I am not anticipating any
changes prior to the approval decision at WTSA.  None of the changes in
G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01
were implemented,  I will post a new version
draft-betts-itu-oam-ach-code-point to correctly reflect the content and
title on G.8113.1 and respond to the other questions later this week."

I was thinking that that was enough reassurance about the protocol and its
stability.

I agree that the documents as liaised to us specify that special value of XXXX
but we were told, on the mpls list, that an experimental value was in use, ie
one that fell within the remit of section 10 of RFC5586, which, again, I took to
be sufficient information.

Tom Petch

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 18 Mar 2012 12:07:22 +0100

Tom,
Did Huub and Malcolm represent the ITU in their assessments? 
I guess other ITU members have different view on this!
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext t.petch
Sent: Friday, March 16, 2012 5:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Last
Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationofan
Associated Channel Code Point for Use by ITU-T EthernetbasedOAM) to
Informational RFC

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Fangyu Li" <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2012 4:12 PM
Subject: Re: Last
Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof
an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to
Informational RFC

> > I am sure you already know the answer to that from posts made to the
mpls
list,
> > ('running code') using an experimental value (interesting that there
is a
last
> > protocols) and that the wish is to move to a standards-based value
which
will,

Stewart

One of the e-mails I had in mind was that of Huub Helvoort last December
where
he said
"The draft recommendation G.8113.1 is stable, there have been no major
technical
changes since it was sent to the IETF (when it still had the draft name
G.tpoam)
attache to liaison: https://datatracker.ietf.org/liaison/983/
This is also the status I reported when we did discuss this during
IETF82 in
Taipei."

while another such e-mail is that of Malcolm Betts in January where he
said
"I can confirm that the draft is requesting a code point for the version
of
G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the
draft that was determined in February 2011, I am not anticipating any
changes prior to the approval decision at WTSA.  None of the changes in
G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01
were implemented,  I will post a new version
draft-betts-itu-oam-ach-code-point to correctly reflect the content and
title on G.8113.1 and respond to the other questions later this week."

I was thinking that that was enough reassurance about the protocol and
its
stability.

I agree that the documents as liaised to us specify that special value
of XXXX
but we were told, on the mpls list, that an experimental value was in
use, ie
one that fell within the remit of section 10 of RFC5586, which, again, I
took to
be sufficient information.

Tom Petch

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 18 Mar 2012 08:32:02 -0400

Stewart,

To answer your second question, SG15 C1123 (January 2011) states that
0x7FFA is the experimental ACh Type actually in use by CT.

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 18 Mar 2012 08:47:06 -0400

Whoops, I slightly misspoke. Amend my previous email to just say "To
answer your second question, SG15 C1123 (January 2011) states that
0x7FFA is the experimental ACh Type actually in use."

Cheers,
Andy

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Mar 2012 09:15:06 +0100

----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 18, 2012 12:07 PM
Tom,

<tp>
Nurit

You know full well that, on a WG list such as the mpls one from which my quotes
came, we all speak as individuals, you, I and everyone else, not representing
any organisation.

At the same time, as any WG chair must know and act on, some people's views
deserve more weight than other people's.  My personal judgement is that the
people I quoted are likely to have a good insight into the practices and
processes of the ITU-T, most likely the best view I will get, absent a formal
liaison on this particular point. YMMV.

Tom Petch
</tp>

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Fangyu Li" <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2012 4:12 PM

mpls
list,
is a
last
which
will,

Stewart

Tom Petch

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 20 Mar 2012 10:52:23 +0100

Your statement that "some people's views deserve more weight than other
people's." is even offending...
Still, since there is clearly no consensus in the ITU (and not even
close to consensus), we cannot rely on anything except of a formal
liaison which is approved by the ITU expert with consensus. 
Nurit

----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 18, 2012 12:07 PM
Tom,

<tp>
Nurit

You know full well that, on a WG list such as the mpls one from which my
quotes
came, we all speak as individuals, you, I and everyone else, not
representing
any organisation.

At the same time, as any WG chair must know and act on, some people's
views
deserve more weight than other people's.  My personal judgement is that
the
people I quoted are likely to have a good insight into the practices and
processes of the ITU-T, most likely the best view I will get, absent a
formal
liaison on this particular point. YMMV.

Tom Petch
</tp>

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Fangyu Li" <[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2012 4:12 PM

mpls
list,
is a
last
which
will,

Stewart

Tom Petch