I will be out of the office starting 10/05/2013 and will not return until
20/05/2013.
I will not have access to email, I will respond to your message when I
return on May 20th.
I will be out of the office starting 03/10/2012 and will not return until
22/10/2012.
I will not have access to email, I will respond to your message when I
return on October 22nd.
I will be out of the office starting 25/05/2012 and will not return until
04/06/2012.
I will not have access to email, I will respond to your message when I
return.
Tom,
I have no objections to using the RFC 2119 key words, I am not sure if
that is appropriate in an informational track document, I expect that our
AD will provide some guidance.
Regards,
Malcolm
t.petch daedu...@btconnect.com
23/03/2012 05:50 AM
To
Loa Andersson l...@pi.nu,
Loa,
Thank you for your comments and suggestions, please see in line below.
Regards,
Malcolm
ietf-boun...@ietf.org wrote on 12/03/2012 04:31:43 AM:
Loa Andersson l...@pi.nu
Sent by: ietf-boun...@ietf.org
12/03/2012 04:31 AM
To
ietf@ietf.org
cc
Subject
Re: [PWE3] FW: Last
All,
Two points to consider:
1) Below it is stated:
In the future, all codepoint allocations to the ITU-T should be tied to
one specific, dated revision of their specification only. This is similar
to the ITU-T's own processes, such as section 2.2.1 of Rec. A.5, which
requires a version
Nurit,
Section 2 “Scope of the Ethernet based OAM ACH Type” contains the
following text:
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
Hi Adrian,
Please see in line below for my response to your questions. I will post a
revised version of the draft tomorrow.
Regards,
Malcolm
Adrian Farrel adr...@olddog.co.uk
Sent by: ietf-boun...@ietf.org
09/12/2011 05:49 AM
Please respond to
adr...@olddog.co.uk
To
Hi Adrian,
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
Hi Adrian,
Thank you for finding time to respond to this request. As you know I was
attending the same 2 week SG 15 meeting and was probably at least as busy
as you given my official role in the meeting.
I will update draft-betts-itu-oam-ach-code-point early in the new year
based on the
Loa,
As per my previous email , I have only seen one response to the 12 points
that I raised, I do not agree with your assessment of this document.
Just to remind you of the points made by myself and several others on
SONET and SDH:
SONET is a true subset of SDH:
The SDH standard supports
Loa,
As per my previous email , I have only seen one response to the 12 points
that I raised, I do not agree with your assessment of this document.
Just to remind you of the points made by myself and several others on
SONET and SDH:
SONET is a true subset of SDH:
The SDH standard supports
Loa,
I still do not understand how you can claim that the words from slide 113
of RFC 5317 and quoted in section 1.1 of
draft-sprecher-mpls-tp-oam-considerations-01:
It is technically feasible that the existing MPLS architecture can be
extended to meet the requirements of a Transport profile
Loa,
I have added - comment 2 to the subject line and deleted all the other
comments.
I cannot find section 1.1 or the text one OAM solution in the PDF
version of RFC 5317.
The last paragraph of section 1 states:
In the case of a conflict between the summary and the
slides, the slides take
Below are my comments on this draft, these are in addition to the comments
that I have provided previously. I also support the comments that propose
the deletion of sections 4, 5 and 6.
I have numbered my comments (1-12) to simplify identification for those
who wish to respond.
I do not
Adrian,
A similar statement is already included in draft-tsb-mpls-tp-ach-ptn-01
5.3. LSP or PW originating in a PTN network and terminating in a PSN
network
In this case the PW (or LSP) originates (or terminates) in a PTN and
terminates (or originates) in a PSN. The default OAM for
Huub,
I agree.
Regards,
Malcolm
Huub van Helvoort huubatw...@gmail.com
Sent by: ietf-boun...@ietf.org
09/10/2011 07:42 AM
Please respond to
huubatw...@gmail.com
To
IETF Discussion ietf@ietf.org
cc
Subject
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The
Reasons for
Russ,
You may not be fully aware of the context of the statement in RFC 5317:
As the co-chair of the JTW and co-editor of the JWT report I must point
out the context of the text that you have quoted:
First, the text is on slide 113, slide 12 states:
This presentation is a collection of
Brian,
The second solution already exists, (300,00+ nodes already deployed - see
other emails on this thread). We must acknowledge this and find the most
cost effective way of allowing interconnection. That is best achieved by
recognizing the Ethernet tool set based solution and defining
Rui,
Excellent point, I fully agree, we need to focus on the 99% that is
identical and not cause the 1% that is different (for good reasons) to
cause a rift that will drive further divergence.
Regards,
Malcolm
Rui Costa rco...@ptinovacao.pt
Sent by: ietf-boun...@ietf.org
05/10/2011 11:06
Brian,
Thank you for your constructive suggestion.
I will attempt to start a discussion on a new thread in a few days - I am
currently travelling with very limited time windows when I can access the
Internet.
Regards,
Malcolm
Brian E Carpenter brian.e.carpen...@gmail.com
06/10/2011
Rolf,
I agree with the points that you have raised, we need to make more
efficient use of our time to address the real technical issues.
To expand on this point, one major factor that has not been considered in
this draft is that significant deployments (300,000+ nodes) of a second
solution
Brian,
I think that points that Huub is raising are:
a) The text quoted from page 113 RFC 5317 the architecture allows for a
single OAM technology for LSPs, PWs is being used as (part of) the
rational for only having a single OAM solution, however page 12 of RFC
5317 states that the
All,
From my personal knowledge, the comments from Huub are accurate. (I was
an active participant at the 1988 ITU meeting in Seoul where the SDH frame
format was agreed).
The IETF should not publish a consensus approved draft that contains
inaccurate information about a standard that was
Tom,
Please see in line below.
Regards,
Malcolm
Thomas Nadeau tnad...@lucidvision.com
Sent by: ietf-boun...@ietf.org
29/09/2011 07:48 AM
To
huubatw...@gmail.com
cc
The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce
ietf-annou...@ietf.org
Subject
Re: Last Call:
Tom,
Please see in line below.
Regards,
Malcolm
Thomas Nadeau tnad...@lucidvision.com
Sent by: ietf-boun...@ietf.org
29/09/2011 09:18 AM
To
huubatw...@gmail.com
cc
The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce
ietf-annou...@ietf.org
Subject
Re: Last Call:
26 matches
Mail list logo
