If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. To do so, go to
https://www.ietf.org/mailman/listinfo/ietf
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. You can set this option
globally for all the list digests you receive at this point.
Send Ietf mailing list submissions to
ietf(_at_)ietf(_dot_)org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request(_at_)ietf(_dot_)org
You can reach the person managing the list at
ietf-owner(_at_)ietf(_dot_)org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."
Today's Topics:
1. Re: Protocol Definition (Dave CROCKER)
2. Re: Protocol Definition (John Day)
3. FW: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration and Maintenance mechanism for MPLS-TP in Packet
Transport Network (PTN)" (Scott Mansfield)
4. FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
(Scott Mansfield)
5. Re: Requirements for improving IETF remote participation
(Joel jaeggli)
6. RE: Questions about draft-betts-itu-oam-ach-code-point
(Adrian Farrel)
7. RE: [CCAMP] New Liaison Statement, "LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration andMaintenance mechanism for MPLS-TP in
PacketTransport Network (PTN)"
(Sprecher, Nurit (NSN - IL/Hod HaSharon))
----------------------------------------------------------------------
Message: 1
Date: Mon, 09 Jan 2012 06:39:24 -0800
From: Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
To: "t.petch" <daedulus(_at_)btconnect(_dot_)com>
Cc: dcrocker(_at_)bbiw(_dot_)net, IETF-Discussion <ietf(_at_)ietf(_dot_)org>
Subject: Re: Protocol Definition
Message-ID: <4F0AFC1C(_dot_)1060905(_at_)dcrocker(_dot_)net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 1/8/2012 12:03 AM, t.petch wrote:
I agree that a message is not the right word, but I think that protocol
is:-)
There is a specific distinction that is intended by having two different
words:
description vs. operation.
A program is a description of behavior. A process is the operation of the
description. It is the behavioral performance.
Protocol refers to the description of an interaction. The term being
explored
is for the operation of that description. It is the interaction.
For the abstract side of networking, I would use the same terminology as
I would
use for a 'program'.
If you mean that you would say 'process' for both, that does have the
appeal of
familiarity, but the problem of overloading. Worse, I'd fear that it
encourages
a failure to appreciate the differences between networking architecture and
software implementation. Since this failure is quite prevalent, I suggest
we
not encourage it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
------------------------------
Message: 2
Date: Mon, 9 Jan 2012 10:36:59 -0500
From: John Day <jeanjour(_at_)comcast(_dot_)net>
To: dcrocker(_at_)bbiw(_dot_)net, "t.petch"
<daedulus(_at_)btconnect(_dot_)com>
Cc: dcrocker(_at_)bbiw(_dot_)net, IETF-Discussion <ietf(_at_)ietf(_dot_)org>
Subject: Re: Protocol Definition
Message-ID: <a06240809cb30b7a03ac3@[10.0.1.26]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 6:39 -0800 2012/01/09, Dave CROCKER wrote:
On 1/8/2012 12:03 AM, t.petch wrote:
I agree that a message is not the right word, but I think that protocol
is:-)
There is a specific distinction that is intended by having two
different words: description vs. operation.
A program is a description of behavior. A process is the operation
of the description. It is the behavioral performance.
Protocol refers to the description of an interaction. The term
being explored is for the operation of that description. It is the
interaction.
Agreed.
For the abstract side of networking, I would use the same
terminology as I would
use for a 'program'.
If you mean that you would say 'process' for both, that does have
the appeal of familiarity, but the problem of overloading. Worse,
I'd fear that it encourages a failure to appreciate the differences
between networking architecture and software implementation. Since
this failure is quite prevalent, I suggest we not encourage it.
Well, pretty close. There is a copious literature on the formal
description and verification of protocols beginning in the 70s.
There are two major issues that is not normally found in defining a
"program": 1) is specifying the asynchrony, ensuring no races, and
2) keeping the specification implementation independent. One does
not want the specification to unnecessarily constrain the
implementation strategy. The general rule is Day's First Rule of
Architecture: Anything you can get away with that is undetectable
from the outside is legal. Or when it comes to implementation sleaze
the architecture.
We have seen the problems of code monoculture or just assuming the
other guys knew how to code.
Take care,
John
------------------------------
Message: 3
Date: Sun, 8 Jan 2012 08:53:05 -0500
From: Scott Mansfield <scott(_dot_)mansfield(_at_)ericsson(_dot_)com>
To: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>,
"mpls(_at_)ietf(_dot_)org" <mpls(_at_)ietf(_dot_)org>,
"pwe3(_at_)ietf(_dot_)org" <pwe3(_at_)ietf(_dot_)org>,
"ccamp(_at_)ietf(_dot_)org" <ccamp(_at_)ietf(_dot_)org>
Cc: "swallow(_at_)cisco(_dot_)com" <swallow(_at_)cisco(_dot_)com>,
"stbryant(_at_)cisco(_dot_)com"
<stbryant(_at_)cisco(_dot_)com>,
"adrian(_at_)olddog(_dot_)co(_dot_)uk" <adrian(_at_)olddog(_dot_)co(_dot_)uk
,
"andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com"
<andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com>,
"dbrungard(_at_)att(_dot_)com" <dbrungard(_at_)att(_dot_)com>
Subject: FW: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration
and
Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)"
Message-ID:
<
FDC72027C316A44F82F425284E1C4C321736E51ABE(_at_)EUSAACMS0701(_dot_)eamcs(_dot_)ericsson(_dot_)se>
Content-Type: text/plain; charset="us-ascii"
This is a liaison from the ITU-T SG15 WP3 providing a copy of the
Determined recommendation G.8113.1 (May 2011). The liaison also provides a
pointer to the internet draft draft-betts-itu-oam-ach-code-point that
requests an ACh code point that is needed by G.8113.1. This is a liaison
that will require a response and the ITU-T has requested a response no
later than 1 August 2012. I would suggest that we use the liaison response
to provide the outcome of running the IETF process required to assign the
requested code point.
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
-----Original Message-----
From: Liaison Statement Management Tool [mailto:lsmt(_at_)ietf(_dot_)org]
Sent: Sunday, January 08, 2012 3:23 AM
To: chair(_at_)ietf(_dot_)org
Cc: yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp;
steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com;
iesg(_at_)ietf(_dot_)org;
lear(_at_)cisco(_dot_)com; Scott Mansfield;
malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn;
tsbsg15(_at_)itu(_dot_)int; greg(_dot_)jones(_at_)itu(_dot_)int;
hiroshi(_dot_)ota(_at_)itu(_dot_)int
Subject: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration and Maintenance mechanism for MPLS-TP in
Packet Transport Network (PTN)"
Title: LS370 - Current status of Recommendation ITU-T
G.8113.1/Y.1372.1, Operations, Administration and Maintenance
mechanism for MPLS-TP in Packet Transport Network (PTN)
Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/
From: ITU-T SG 15 (Greg Jones <greg(_dot_)jones(_at_)itu(_dot_)int>)
To: The IESG (chair(_at_)ietf(_dot_)org)
Cc:
yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp,steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com,ies
g(_at_)ietf(_dot_)org,lear(_at_)cisco(_dot_)com,Scott(_dot_)Mansfield(_at_)Ericsson(_dot_)com
Reponse Contact:
tsbsg15(_at_)itu(_dot_)int,greg(_dot_)jones(_at_)itu(_dot_)int,hiroshi(_dot_)ota(_at_)itu(_dot_)int
Technical Contact: malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn
Purpose: For information
Body: The December meeting of ITU-T Study Group 15 considered
the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
Operations, Administration and Maintenance mechanism for
MPLS-TP in Packet Transport Network (PTN). Unfortunately the
Study Group could not approve this Recommendation so it was
forwarded to the WTSA (20-29 November 2012) for approval.
One of the issues that prevented the approval in SG 15 was
the lack of an ACh code point to support this Recommendation.
To resolve this issue SG 15 therefore requests the IETF to
assign an ACh code point. An IETF draft
draft-betts-itu-oam-ach-code-point has been submitted to
request this code point.
We have attached the text of the current draft of
Recommendation ITU-T G.8113.1/Y.1372.1 that has been
forwarded to the WTSA for approval.
Attach: COM15R-22.
Attachment(s):
LS370 - pdf body
https://datatracker.ietf.org/documents/LIAISON/file1306.pdf
LS370 - pdf attachment
https://datatracker.ietf.org/documents/LIAISON/file1307.pdf
------------------------------
Message: 4
Date: Sun, 8 Jan 2012 09:01:22 -0500
From: Scott Mansfield <scott(_dot_)mansfield(_at_)ericsson(_dot_)com>
To: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>,
"mpls(_at_)ietf(_dot_)org" <mpls(_at_)ietf(_dot_)org>,
"pwe3(_at_)ietf(_dot_)org" <pwe3(_at_)ietf(_dot_)org>,
"ccamp(_at_)ietf(_dot_)org" <ccamp(_at_)ietf(_dot_)org>
Cc: "swallow(_at_)cisco(_dot_)com" <swallow(_at_)cisco(_dot_)com>,
"stbryant(_at_)cisco(_dot_)com"
<stbryant(_at_)cisco(_dot_)com>,
"adrian(_at_)olddog(_dot_)co(_dot_)uk" <adrian(_at_)olddog(_dot_)co(_dot_)uk
,
"andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com"
<andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com>,
"dbrungard(_at_)att(_dot_)com" <dbrungard(_at_)att(_dot_)com>
Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
Message-ID:
<
FDC72027C316A44F82F425284E1C4C321736E51ABF(_at_)EUSAACMS0701(_dot_)eamcs(_dot_)ericsson(_dot_)se>
Content-Type: text/plain; charset="us-ascii"
This is a liaison from SG15 Q9, Q12, and Q14 providing the text of
G.8110.1, G.8121, and G.8151. This liaison is for information only.
G.8110.1 was approved at the SG15 plenary meeting in December 2011.
G.8121 and G.8151 entered the alternative approval process (AAP) and will
enter a 4 week last call (the last call hasn't been initiated yet).
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
-----Original Message-----
From: Liaison Statement Management Tool [mailto:lsmt(_at_)ietf(_dot_)org]
Sent: Sunday, January 08, 2012 3:51 AM
To: rcallon(_at_)juniper(_dot_)net; swallow(_at_)cisco(_dot_)com;
loa(_at_)pi(_dot_)nu
Cc: yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp;
steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com;
mpls(_at_)ietf(_dot_)org;
lear(_at_)cisco(_dot_)com; Scott Mansfield; stbryant(_at_)cisco(_dot_)com;
adrian(_at_)olddog(_dot_)co(_dot_)uk;
malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn; Ghani Abbas;
Kam(_dot_)Lam(_at_)alcatel-lucent(_dot_)com; tsbsg15(_at_)itu(_dot_)int;
greg(_dot_)jones(_at_)itu(_dot_)int; hiroshi(_dot_)ota(_at_)itu(_dot_)int
Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
Title: LS368 - MPLS-TP Recommendations
Submission Date: 2012-01-08
URL of the IETF Web page: /liaison/1126/
From: ITU-T SG 15 (Greg Jones <greg(_dot_)jones(_at_)itu(_dot_)int>)
To: Multiprotocol Label Switching (rcallon(_at_)juniper(_dot_)net,
swallow(_at_)cisco(_dot_)com, loa(_at_)pi(_dot_)nu)
Cc:
yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp,steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com,mpl
s(_at_)ietf(_dot_)org,lear(_at_)cisco(_dot_)com,Scott(_dot_)Mansfield(_at_)Ericsson(_dot_)com,stbryan
t(_at_)cisco(_dot_)com,adrian(_at_)olddog(_dot_)co(_dot_)uk
Reponse Contact:
tsbsg15(_at_)itu(_dot_)int,greg(_dot_)jones(_at_)itu(_dot_)int,hiroshi(_dot_)ota(_at_)itu(_dot_)int
Technical Contact:
malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn,Ghani(_dot_)Abbas(_at_)ericsson(_dot_)com,Kam.Lam@alca
tel-lucent.com
Purpose: For information
Body: At the December 2011 meeting of ITU-T Study Group 15,
Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS
Transport Profile (MPLS-TP) layer network" was approved. A
copy is attached for your information.
We would like to draw your attention to clause 10 that
describes the MPLS-TP Diff-Serv Architecture.
In addition, the approval process was initiated for
Recommendations ITU-T G.8121/Y.1381 "Characteristics of
MPLS-TP Network Equipment Functional Blocks" and ITU-T
G.8151/Y.1374 "Management aspects of the MPLS-TP network element".
Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1.
Attachment(s):
LS368 - pdf body
https://datatracker.ietf.org/documents/LIAISON/file1308.pdf
LS368 - Att1_PLEN-517Rev3
https://datatracker.ietf.org/documents/LIAISON/file1309.pdf
LS368 - Att2_PLEN-540Rev1
https://datatracker.ietf.org/documents/LIAISON/file1310.pdf
LS368 - Att3_PLEN-543Rev1
https://datatracker.ietf.org/documents/LIAISON/file1311.pdf
------------------------------
Message: 5
Date: Mon, 09 Jan 2012 09:09:48 -0800
From: Joel jaeggli <joelja(_at_)bogus(_dot_)com>
To: SM <sm(_at_)resistor(_dot_)net>
Cc: IETF Discussion <ietf(_at_)ietf(_dot_)org>, Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
Subject: Re: Requirements for improving IETF remote participation
Message-ID: <4F0B1F5C(_dot_)10400(_at_)bogus(_dot_)com>
Content-Type: text/plain; charset=ISO-8859-1
On 1/6/12 02:00 , SM wrote:
"The RPS tools must be available for lunch meetings scheduled by
the IETF Secretariat, such as for the Security Directorate"
I object to the non-inclusion of the kangaroo directorate (no offense
intended). :-)
That implies coverage of a much greater number of rooms, e.g. 16 or more
potentialy. when you count the offices and small breakout rooms in
addition to the 8 scheduled meeting rooms.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
------------------------------
Message: 6
Date: Mon, 9 Jan 2012 17:33:16 -0000
From: "Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
To: <draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org>,
"'Huub
helvoort'" <huub(_dot_)van(_dot_)helvoort(_at_)huawei(_dot_)com>
Cc: mpls(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
Subject: RE: Questions about draft-betts-itu-oam-ach-code-point
Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk>
Content-Type: text/plain; charset="us-ascii"
Hi Huub and Malcolm,
I recognise that the intervening month between my original email and this
one
included an SG15 meeting, Christmas, and New Year, but I had hoped for a
response by now so that we could work out what to do with the document.
In the meantime, at least my question 4 has progressed. Can you confirm
that the
version of G.8113.1 for which a code point is requested is that which has
been
sent to WTSA by SG15 (i.e., that which was determined), and that there are
no
plans to make any updates or revisions to that document until after it has
been
approved.
Thanks,
Adrian
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Adrian
Farrel
Sent: 09 December 2011 10:49
To: draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
'Huub helvoort'
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Questions about draft-betts-itu-oam-ach-code-point
Hi Malcolm and Huub,
I have squeezed a little time from the current ITU-T meeting to look at
your
draft and write-up. I have also read the email threads on the IETF
discussion
list and the MPLS list. Sorry that this has taken me a week to process,
but
your
publication request came at pretty much the worst possible time for
getting me
to do this task.
I don't like proliferating threads across multiple mailing lists. On the
other
hand it is difficult to ensure that all the constituencies are present,
so I
am
perpetuating the cross-posting.
My review of the document...
1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I
think
only one of these is real (the spurious space in a citation). The other
nits
are
spurious caused by citations wrapping across lines. Could you please
keep a
note
of the nit so that you can fix it the next time the draft is respun or
so it
can
be captured in an RFC Editor Note at a later stage (you don't have to
post a
new
revision to address this now unless you really want to).
2. This document requests a code point from a registry that contains code
points
that are used equally for MPLS LSPs and pseudowires. I can't tell from
the I-D
whether it is your intention that your code point would also be
applicable in
both cases. What is your intention? Is this "obvious" from G.8113.1 or
does it
need to be clarified?
My review of the write-up and discussions...
3. There seems to be quite a feeling on the mailing lists that this
document
should be run through the MPLS working group. The write-up makes a case
for
progressing it as AD sponsored. As far as I can see, the main assertions
to
answer are as follows. Do you have a view on these points before I make a
decision on what to do?
a. This is a proposal to use an MPLS code point and so is part of MPLS by
definition.
b. The type of network being managed by the OAM described in G.8113.1 is
an
MPLS network. Therefore, this is clearly relevant to the MPLS working .
Do you object to this going through the MPLS on principle, or were you
just
hoping to save the WG the work? If the latter, and if the WG wants to
look at
the draft, the easiest approach seems to be to redirect the work to the
working
group.
4. G.8113.1 is clearly important to understanding to which the code
point is
being put. Thus, an available and stable copy of group. G.8113.1 will be
key
to
the last call review of you I-D. Can you make a stable copy available
(for
example, through liaison)? How does the editing work currently in
progress in
the SG15 meeting affect that availability?
5. Can you clarify for me why the suggested value has been suggested.
This
will
help guide IANA who would normally do their allocation in a "tidy" way.
Looking forward to your reply.
Thanks,
Adrian
------------------------------
Message: 7
Date: Mon, 9 Jan 2012 18:41:43 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com>, "ext Scott Mansfield"
<scott(_dot_)mansfield(_at_)ericsson(_dot_)com>,
<ietf(_at_)ietf(_dot_)org>, <
mpls(_at_)ietf(_dot_)org>,
<pwe3(_at_)ietf(_dot_)org>, <ccamp(_at_)ietf(_dot_)org>
Cc: andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com,
dbrungard(_at_)att(_dot_)com
Subject: RE: [CCAMP] New Liaison Statement, "LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration
andMaintenance mechanism for MPLS-TP in PacketTransport Network
(PTN)"
Message-ID:
<077E41CFFD002C4CAB7DFA4386A5326405178E7C(_at_)DEMUEXC014(_dot_)nsn-intra(_dot_)net>
Content-Type: text/plain; charset="windows-1255"
When saying support, I mean of course that I fully support the proposal of
Scott!
-----Original Message-----
From: ccamp-bounces(_at_)ietf(_dot_)org
[mailto:ccamp-bounces(_at_)ietf(_dot_)org] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: ? 09 ????? 2012 19:20
To: ext Scott Mansfield; ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org;
pwe3(_at_)ietf(_dot_)org;
ccamp(_at_)ietf(_dot_)org
Cc: andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com;
dbrungard(_at_)att(_dot_)com
Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration
andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)"
Support
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
ext Scott Mansfield
Sent: ? 08 ????? 2012 15:53
To: ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org;
pwe3(_at_)ietf(_dot_)org; ccamp(_at_)ietf(_dot_)org
Cc: swallow(_at_)cisco(_dot_)com; stbryant(_at_)cisco(_dot_)com;
adrian(_at_)olddog(_dot_)co(_dot_)uk;
andrew(_dot_)g(_dot_)malis(_at_)verizon(_dot_)com;
dbrungard(_at_)att(_dot_)com
Subject: FW: New Liaison Statement, "LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration
andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)"
This is a liaison from the ITU-T SG15 WP3 providing a copy of the
Determined recommendation G.8113.1 (May 2011). The liaison also provides a
pointer to the internet draft draft-betts-itu-oam-ach-code-point that
requests an ACh code point that is needed by G.8113.1. This is a liaison
that will require a response and the ITU-T has requested a response no
later than 1 August 2012. I would suggest that we use the liaison response
to provide the outcome of running the IETF process required to assign the
requested code point.
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
-----Original Message-----
From: Liaison Statement Management Tool [mailto:lsmt(_at_)ietf(_dot_)org]
Sent: Sunday, January 08, 2012 3:23 AM
To: chair(_at_)ietf(_dot_)org
Cc: yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp;
steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com;
iesg(_at_)ietf(_dot_)org;
lear(_at_)cisco(_dot_)com; Scott Mansfield;
malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn;
tsbsg15(_at_)itu(_dot_)int; greg(_dot_)jones(_at_)itu(_dot_)int;
hiroshi(_dot_)ota(_at_)itu(_dot_)int
Subject: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration and Maintenance mechanism for MPLS-TP in
Packet Transport Network (PTN)"
Title: LS370 - Current status of Recommendation ITU-T
G.8113.1/Y.1372.1, Operations, Administration and Maintenance
mechanism for MPLS-TP in Packet Transport Network (PTN)
Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/
From: ITU-T SG 15 (Greg Jones <greg(_dot_)jones(_at_)itu(_dot_)int>)
To: The IESG (chair(_at_)ietf(_dot_)org)
Cc:
yoichi(_dot_)maeda(_at_)ttc(_dot_)or(_dot_)jp,steve(_dot_)trowbridge(_at_)alcatel-lucent(_dot_)com,ies
g(_at_)ietf(_dot_)org,lear(_at_)cisco(_dot_)com,Scott(_dot_)Mansfield(_at_)Ericsson(_dot_)com
Reponse Contact:
tsbsg15(_at_)itu(_dot_)int,greg(_dot_)jones(_at_)itu(_dot_)int,hiroshi(_dot_)ota(_at_)itu(_dot_)int
Technical Contact: malcolm(_dot_)betts(_at_)zte(_dot_)com(_dot_)cn
Purpose: For information
Body: The December meeting of ITU-T Study Group 15 considered
the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
Operations, Administration and Maintenance mechanism for
MPLS-TP in Packet Transport Network (PTN). Unfortunately the
Study Group could not approve this Recommendation so it was
forwarded to the WTSA (20-29 November 2012) for approval.
One of the issues that prevented the approval in SG 15 was
the lack of an ACh code point to support this Recommendation.
To resolve this issue SG 15 therefore requests the IETF to
assign an ACh code point. An IETF draft
draft-betts-itu-oam-ach-code-point has been submitted to
request this code point.
We have attached the text of the current draft of
Recommendation ITU-T G.8113.1/Y.1372.1 that has been
forwarded to the WTSA for approval.
Attach: COM15R-22.
Attachment(s):
LS370 - pdf body
https://datatracker.ietf.org/documents/LIAISON/file1306.pdf
LS370 - pdf attachment
https://datatracker.ietf.org/documents/LIAISON/file1307.pdf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
CCAMP mailing list
CCAMP(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ccamp
------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 44, Issue 17
************************************