...@vigilsec.com
Date: Saturday, March 23, 2013 3:16 PM
To: ietf@ietf.org ietf@ietf.org
Cc: m...@ietf.org m...@ietf.org
Subject: Re: [mpls] Last
Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
I wonder if the direction of Section 1.2 can be revised to make it more
of an engineering document
@ietf.org
Cc: m...@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Russ,
Thanks for your comments, very good points.
Sorry for the delay in replying, I was out of office.
The following is my proposed text for replacing the current first
paragraph of section
: RE: [mpls] Last Call:
draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Luyuan,
You wrote (in part):
..since multiplexing of bursty sources is far more efficient over
traditional circuit-based
TDM technologies.
Which is not true and probably not what you meant.
A better formulation might
@tools.ietf.org,
m...@ietf.org m...@ietf.org, IETF discussion list ietf@ietf.org
Subject: Re: [mpls] Last Call:
draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security
Framework) to Informational RFC
Thank you very much for your review and detailed comments/suggestions,
and
thanks
...@ietf.org, IETF discussion list ietf@ietf.org
Subject: Re: [mpls] Last Call:
draft-ietf-mpls-tp-security-framework-07.txt (MPLS-TP Security
Framework) to Informational RFC
The IESG has received a request from the Multiprotocol Label Switching
WG
(mpls) to consider the following document
Thank you very much for your review and detailed comments/suggestions, and
thanks for your discussion.
I uploaded the new version that addressed all your comments, as well as
Dan's Gen-ART review comments, and acknowledged your help.
Thanks for the reply, Luyuan. I'm happy with all the
More thoughts inline tp three times (and apologies for the slow
response).
- Original Message -
From: Mach Chen mach.c...@huawei.com
To: t.p. daedu...@btconnect.com; ietf@ietf.org
Sent: Wednesday, November 07, 2012 12:24 PM
Hi Tom,
Many thanks for your comments!
Please see my reply
Subject: Re: [mpls] Last Call: draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt
(LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs)toProposed
Standard
I worry about the allocation of sub-TLVs in this I-D.
It calls for
The following Sub-TLV changes, which comprise three updates and two
I worry about the allocation of sub-TLVs in this I-D.
It calls for
The following Sub-TLV changes, which comprise three updates and two
additions, are made for two TLV Types in the aforementioned sub-
registry: TLV Type 1 for Target FEC Stack, and TLV Type 21 for
Reply Path.
and it is the
Tom,
On Nov 2, 2012, at 2:05 PM, t.p. daedu...@btconnect.com wrote:
I worry about the allocation of sub-TLVs in this I-D.
Thanks for the comments. I share worries about keeping synchronicity between
sub-registries in this fashion.
It calls for
The following Sub-TLV changes, which
All (taking chair hat off),
I agree with Ross's comments below that if the document is last called
it should go through a wg last call (pwe3 and mpls) and through an IETF
last call.
I agree that these last calls could be in parallel is necessary, but I
believe that running the wg last call
Also taking my chair hat off ... as Malcolm stated that G.8113.1
applies to PWs, and the requested allocation is in a registry that
originated in the PWE3 working group, I agree that a PWE3 WG last call
is warranted. This could certainly take place in parallel with the
MPLS WG last call.
Cheers,
Inline tp
Tom Petch
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
ext Thomas Nadeau
Sent: Thursday, January 12, 2012 10:30 PM
To: John E Drake
Cc: m...@ietf.org; draft-betts-itu-oam-ach-code-po...@tools.ietf.org;
ietf@ietf.org; ietf-boun...@ietf.org
On Jan 12, 2012, at
, January 12, 2012 10:30 PM
To: John E Drake
Cc: m...@ietf.org; draft-betts-itu-oam-ach-code-po...@tools.ietf.org;
ietf@ietf.org; ietf-boun...@ietf.org
Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point
On Jan 12, 2012, at 3:18 PM, John E Drake wrote:
Snipped, comments
: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it]
Sent: Wednesday, October 19, 2011 1:50 PM
To: John E Drake; Luyuan Fang (lufang); Alexander Vainshtein;
D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant)
Cc: m...@ietf.org; ietf@ietf.org
Subject: R: Re: [mpls] unresolved technical
: brian.e.carpen...@gmail.com
Data: 5-ott-2011 22.16
A: yang.jia...@zte.com.cn
Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org,
mpls-
bounces@ietf.orgLarry
Ogg: Re: [mpls] 答复: 回复： R: FW: Last Call: lt;draft-sprecher-
mpls-tp-oam-
considerations-01.txtgt; (The Reasons for Selecting
Hi,
Same here: Yes/Support.
Cyril
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
Of
ext John E Drake
Sent: Thursday, October 06, 2011 1:11 PM
To: David Sinicrope; David Allan I
Cc: m...@ietf.org; ietf@ietf.org
Subject: RE: [mpls] R: FW
(lufang)
Sent: Thursday, October 06, 2011 5:24 PM
To: John E Drake; David Sinicrope; David Allan I
Cc: m...@ietf.org; ietf@ietf.org
Subject: Re: [mpls] R: FW:LastCall:
draft-sprecher-mpls-tp-oam-considerations-01.txt(TheReasons for
Selecting a Single Solution for MPLS-TP OAM)toInformational RFC
Same
Dave,
could you be more precise about what you think the utility of this document is
in this particular situation. I mean, what will its effect be in the current
situation. What will change after this document has been published. It seems
everybody believes the situation will be resolved once
While it is not perfect, I too support publication...
W
On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote:
I concur with Dave's comment and support publication of the draft.
Dave
On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com
wrote:
I think it is unfortunate
Hi all,
I concur with both parts of Dave's message :-( and support publication of the
draft.
I have an editorial/factual comment regarding Section 4.2 of the draft.
Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard,
it is a Proposed Standard RFC.
Further, I am not
either, but I do not believe in rewarding it.
Dave
-Original Message-
From: Rolf Winter [mailto:rolf.win...@neclab.eu]
Sent: Friday, October 07, 2011 6:39 AM
To: David Allan I; ietf@ietf.org; m...@ietf.org
Subject: RE: [mpls] R: FW: Last Call:
draft-sprecher-mpls-tp-oam-considerations
IMO it is a statement of principle going forward. As such it does not
fix or make go away the current situation, but it would be an IETF
consensus position on a way forward. And I agree with that position.
Lots of folks do proprietary deployments, squat on code points
etc. That cannot be
As do I
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
David Sinicrope
Sent: Wednesday, October 05, 2011 7:11 PM
To: David Allan I
Cc: m...@ietf.org; ietf@ietf.org
Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam
PM
To
ietf@ietf.org ietf@ietf.org
cc
Subject
RE: [mpls] FW: Last Call:
draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for
Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Sometimes when two worlds come together, you don't get common standards
right away
the ietf, and i hope all sdos, are supposed to provide users with
interoperable multi-vendor choice, not non-interoperable multi-standard
incompatibility.
from a sic year old broadside https://archive.psg.com/051000.ccr-ivtf.pdf
The IETF’s vendor/market approach has engendered a ‘let the
Jian,
See in-line.
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
yang.jia...@zte.com.cn
Sent: Wednesday, October 05, 2011 10:54 AM
To: ietf@ietf.org; m...@ietf.org; mpls-bounces@ietf.orgLarry
Subject: [mpls] 答复: 回复： R: FW: Last Call:
Vainshtein
Sent: Wednesday, October 05, 2011 4:18 PM
To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant)
Cc: ietf@ietf.org; m...@ietf.org
Subject: Re: [mpls] unresolved technical concerns
Dear Alessandro,
Lots of thanks for a prompt response.
Unfortunately your response does
Yes/support
Regards,
Jeff
MPLS Working Group,
Please be aware of the IETF last call as shown below. The document was
presented for publication as an individual RFC with IETF consensus and
AD sponsorship.
This draft is clearly close and relevant to the work you do, but after
: Wednesday, October 05, 2011 7:11 PM
To: David Allan I
Cc: m...@ietf.org; ietf@ietf.org
Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-
considerations-01.txt (The Reasons for Selecting a Single Solution
for
MPLS-TP OAM) to Informational RFC
I concur with Dave's comment
This document provides a factual and concise summary of work, events,
and points of view that have developed since the JWT, a summary that's
timely and sorely needed as few in the industry outside the project (or
even inside the project) can make sense of it.
It also provides a thorough and
On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote:
major unresolved technical concerns
Alessandro
Please can I suggest that you write an internet draft detailing
these major unresolved technical concerns so that we
can all understand them.
Such a draft needs to be technical, and
3) The global wide application of Ethernet services requires that the
operator’s network must support Y.1731 Ethernet OAM, to guaranteeing
the SLA for customers. Although many operators had expressed their
requirements for MPLS-TP OAM using draft-bhh/G.8113.1 in IETF meetings
and mail-list,
Gerardo
Cc: ietf@ietf.org; m...@ietf.org
Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-
considerations-01.txt (The Reasons for Selecting a Single Solution for
MPLS-TP OAM) to Informational RFC
On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote:
major unresolved
, October 05, 2011 5:11 PM
To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart
Bryant (stbryant)
Cc: m...@ietf.org; ietf@ietf.org
Subject: Re: [mpls] unresolved technical concerns
Yep. We are going in circles again.
We need to see technical details on the issues documented in an I-D
I concur with Dave's comment and support publication of the draft.
Dave
On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote:
I think it is unfortunate that we are in a situation where such a document
has utility. But ultimately it does.
Therefore I support the
I do not support this draft.
a) Its SONET and SDH section is wrong. (Please refer to H. van Helvoort's, A.
Reid's, M. Betts's comments.)
b) It doesn't really add anything to RFC 1958. (Please refer to R. Winter's
comments.) In RFC1958:
If a previous design, in the Internet context
Sometimes when two worlds come together, you don't get common standards right
away. For the SONET/SDH example, it has been pointed out that starting from
digital voice, we had different regions of the world choosing A-law or mu-law
encoding, then 24-channel vs 30-channel PDH hierarchies. SONET
Hi,
1.
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
for use in transport network deployments. That is, MPLS-TP is a set
of functions and features selected from the wider MPLS toolset and
applied in a consistent way to meet the needs and requirements of
11:35 PM
To: Yoshinori Koike; ietf@ietf.org
Cc: m...@ietf.org; 'IETF-Announce'
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt
(MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Yoshinori,
The DSMAP/DDMAP was explicitly added to make
- is clearly
sufficient to identify the per-interface MIP.
--
Eric
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Zhenlong Cui
Sent: Thursday, August 25, 2011 2:17 AM
To: ietf@ietf.org; 'IETF-Announce'
Cc: m...@ietf.org
Subject: Re: [mpls] Last
for this draft.
--
Eric
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Yoshinori Koike
Sent: Thursday, August 25, 2011 12:35 PM
To: i...@ietf.org
Cc: m...@ietf.org; 'IETF-Announce'
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt
- is clearly
sufficient to identify the per-interface MIP.
--
Eric
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Zhenlong Cui
Sent: Thursday, August 25, 2011 2:17 AM
To: i...@ietf.org; 'IETF-Announce'
Cc: m...@ietf.org
Subject: Re: [mpls] Last
for this draft.
--
Eric
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Yoshinori Koike
Sent: Thursday, August 25, 2011 12:35 PM
To: ietf@ietf.org
Cc: m...@ietf.org; 'IETF-Announce'
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt
Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point that I've raised in my IETF LC comment
...@ietf.org;
pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org;
pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha,
On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made
the distinction
...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Stewart
Was this email meant to address my email to the IETF discussion list (from Tues
16 Aug)
or just the discussion on MPLS and PWE lists ?
It does to SOME
...@cisco.com; Luca Martini; IETF Discussion
Cc: m...@ietf.org; pwe3; i...@ietf.org; pwe3-cha...@tools.ietf.org
Subject: Re: [mpls] [PWE3] IETF Last Call comment on
draft-ietf-pwe3-gal-in-pw
Stewart
Was this email meant to address my email to the IETF discussion list (from
Tues 16 Aug
On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP
domain
This is exactly the point that I've raised in my IETF LC comment on
the draft (for MS-PW) - please see my email (to several lists) that
Reviewing this discussion there are three components.
1) The update of RFC5586 to allow PW to use the GAL.
2) The PW OAM application that is to use the GAL.
3) The label stack structure when teh GAL is used with a PW
This draft is only concerned with point 1 above. Points
2 and 3 need to be
Martini; IETF Discussion
Cc: John E Drake; m...@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladimir
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem
Cohen; pwe3-cha...@tools.ietf.org; i...@ietf.org
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal
Sasha
On 30/08/2011 13:22, Alexander Vainshtein wrote:
Stewart,
I believe that your item #1 is presumably addressed by
draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed),
draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and
your item #3 is not yet addressed. Is
Hi,
I would like to propose that this draft explicitly stipulate whether or
not it covers per-interface model. I think it is essential to avoid
confusion and clarify the appropriate I-D to discuss OAM solutions for
the per-interface model.
Per-interface model is one of the two OAM
Hi,
I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like
to make sure it is not lost.
2.1. New address type for Downstream Mapping TLV
The new address type indicates that no address is present in the
DSMAP or DDMAP TLV. However, IF_Num information (see
[mailto:mpls-boun...@ietf.org] On Behalf Of
Alexander Vainshtein
Sent: Wednesday, August 17, 2011 9:52 PM
To: Luca Martini
Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment
...@cisco.com]
Sent: Friday, August 19, 2011 1:17 PM
To: John E Drake
Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal
; Vladimir
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal-in-pw
John,
I would like to let applications decide how they design the use of the
gal.
So I would propose a simple change
, 2011 1:17 PM
To: John E Drake
Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal-in-pw
John,
I would like to let
Hi,
I don't see any TLVs defined for performing the on-demand CV operation
on MPLS -TP Sections. Is this intentional?
and
Co-routed bidirectional tunnel identifier:
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num
Associated bidirectional tunnel
Endpoint MEP-ID and
draft-ietf-mpls-tp-on-demand-cv-06, section 2.3.2. Static Pseudowire
Sub-TLV conflict in representing the AGI field.
Why are we not following this generic format for representing the AGI field?
Am I missing something?
Thanks,
Venkat.
Re: [mpls] Need clarification on draft
Hi,
I have made this comment before, I just want to make sure it is not lost. This
draft is proposing a way to specify the length of sub-TLVs that is inconsistent
with RFC 4379. I believe it would be better to align this with 4379 as the
draft is updating it and I see no technical reason why
: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit;
Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal-in-pw
Luca and all,
I have not found the statement you've proposed in draft-ietf-pwe3-fat-
pw-06
To: Alexander Vainshtein
Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael
Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain
Of
*Pablo Frank
*Sent:* Tuesday, August 16, 2011 2:18 PM
*To:* Alexander Vainshtein
*Cc:* m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael
Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
*Subject:* Re: [mpls] [PWE3] IETF Last Call comment on
draft-ietf-pwe3-gal-in-pw
To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa
Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile
On 07/13/2011 09:57 PM, Greg Mirsky wrote:
Dear Erminio,
I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is
even more narrow then of the document being discussed. The G.8113.1
addresses only bi-directional co-routed LSP and has no model to handle
bi-directional associated
-Announceietf-annou...@ietf.org
Cc: m...@ietf.orgm...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification, Continuity Check and Remote
Defect
indication for MPLSTransport Profile) to Proposed
Data: 6-lug-2011 19.35
A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu
l...@pi.nu, Rui Costarco...@ptinovacao.pt
Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-
Announceietf-annou...@ietf.org
Ogg: RE: [mpls] R: Re: Last Call:
lt;draft-ietf-mpls-tp-cc-cv
-lug-2011 11.59
A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org,
IETF-Announceietf-annou...@ietf.org
Cc: m...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification,Continuity Check and Remote
, mpls@ietf.
orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile
.
Messaggio originale
Da: david.i.al...@ericsson.com
Data: 8-lug-2011 18.13
A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com
Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf.
orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE
...@pi.nu; Rui Costa
Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile) to Proposed Standard
Do you mean that ITU-T
11.59
A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, ietf@ietf.org
,
IETF-Announceietf-annou...@ietf.org
Cc: m...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification,Continuity Check and Remote
Defect
Bryantstbry...@cisco.com
Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it,
mpls@ietf.
orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive Connectivity Verification, Continuity
...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-
annou...@ietf.org
Cc: m...@ietf.orgm...@ietf.org
Ogg: RE: [mpls] R: RE: R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.
txtgt; (Proactive ConnectivityVerification, Continuity Check and
Remote
Defect indication
[mailto:david.i.al...@ericsson.com]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: erminio.ottone...@libero.it; m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive
Connectivity Verification
Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Rui Costa
Sent: Thursday, July 14, 2011 8:33 PM
To: David Allan I
Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: RE: [mpls] Last Call:
draft-ietf-mpls-tp-cc-cv-rdi-05.txt(Proactive Connectivity
To the extent that this particular debate (that of the nature scope and success
or failure of the liaison effort) has been going on for some time:
* it's not going to be resolved.
* rehashing the history of how we came to this point it advances what agenda?
It would seems timely in the IETF
-Announceietf-announce@ietf.org
Cc: m...@ietf.orgm...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification, Continuity Check and Remote
Defect
indication for MPLSTransport Profile) to Proposed
Data: 6-lug-2011 19.35
A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu
l...@pi.nu, Rui Costarco...@ptinovacao.pt
Cc: m...@ietf.orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-
Announceietf-announce@ietf.org
Ogg: RE: [mpls] R: Re: Last Call:
lt;draft-ietf-mpls-tp-cc-cv
-lug-2011 11.59
A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, i...@ietf.org,
IETF-Announceietf-announce@ietf.org
Cc: m...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification,Continuity Check and Remote
, mpls@ietf.
orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile
.
Messaggio originale
Da: david.i.al...@ericsson.com
Data: 8-lug-2011 18.13
A: Rui Costarco...@ptinovacao.pt, Stewart Bryantstbry...@cisco.com
Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it, mpls@ietf.
orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE
...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF-Announceietf-
annou...@ietf.org
Cc: m...@ietf.orgm...@ietf.org
Ogg: RE: [mpls] R: RE: R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.
txtgt; (Proactive ConnectivityVerification, Continuity Check and
Remote
Defect indication
-Announce
Cc: m...@ietf.org
Subject: R: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-
cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check
and Remote Defect indication for MPLS Transport Profile) to Proposed
Standard
The JWT report is aligned with my statement.
JD
11.59
A: erminio.ottone...@libero.it, rco...@ptinovacao.pt, i...@ietf.org
,
IETF-Announceietf-announce@ietf.org
Cc: m...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive ConnectivityVerification,Continuity Check and Remote
Defect
Bryantstbry...@cisco.com
Cc: erminio.ottone...@libero.iterminio.ottone...@libero.it,
mpls@ietf.
orgm...@ietf.org, i...@ietf.orgi...@ietf.org, IETF-Announceietf-
annou...@ietf.org
Ogg: RE: [mpls] Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;
(Proactive Connectivity Verification, Continuity
,
IETF-Announceietf-annou...@ietf.org
Cc: m...@ietf.orgm...@ietf.org
Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-
05.txtgt;
(ProactiveConnectivityVerification, Continuity Check and
Remote Defect
indicationfor MPLSTransport Profile) to Proposed
-Announce
Cc: m...@ietf.org
Subject: R: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-
cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check
and Remote Defect indication for MPLS Transport Profile) to Proposed
Standard
The JWT report is aligned with my statement.
JD
-Announce; ietf@ietf.org
Subject: Re: [mpls] R: RE: R: Re: LastCall:
draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity
Verification, Continuity Check and Remote Defect indicationfor MPLS
Transport Profile) to Proposed Standard
Dear Erminio,
even though I'm not an operator but I think
: quarta-feira, 6 de Julho de 2011 19:25
To: erminio.ottone...@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce
Cc: m...@ietf.org
Subject: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS
...@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard
On Jul 8, 2011, at 3:15 AM, neil.2.harri...@bt.com wrote:
Got to say I agree
Message-
From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
Sent: Friday, July 08, 2011 8:27 AM
To: neil.2.harri...@bt.com
Cc: rco...@ptinovacao.pt; David Allan I; stbry...@cisco.com; m...@ietf.org;
ietf@ietf.org; ietf-annou...@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv
: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org;
ietf@ietf.org; ietf-annou...@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard
...@lucidvision.com
Cc: rco...@ptinovacao.pt; stbry...@cisco.com; m...@ietf.org; ietf@ietf.org;
ietf-annou...@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive
Connectivity Verification, Continuity Check and Remote Defect indication for
MPLS Transport Profile
; stbry...@cisco.com; m...@ietf.org;
ietf@ietf.org; ietf-annou...@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard
Hi Neil:
As a result
: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
neil.2.harri...@bt.com
Sent: Friday, July 08, 2011 12:16 AM
To: rco...@ptinovacao.pt; david.i.al...@ericsson.com;
stbry...@cisco.com
Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org
Subject: Re: [mpls] Last Call: draft
-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Rui Costa
Sent: 08 July 2011 01:15
To: David Allan I; Stewart Bryant
Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity
, July 08, 2011 12:16 AM
To: rco...@ptinovacao.pt; david.i.al...@ericsson.com;
stbry...@cisco.com
Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt
(Proactive Connectivity Verification, Continuity Check and Remote
1 - 100 of 154 matches
Mail list logo
