just testing
As you may know ICM has recently finalized the 3rd MPLS event.
I would definitely be interested in continuing a working relationship for
the upcoming MPLS event. Following is some further information, I would be
happy to answer any specific questions you may have.
MPLS GL0BAL SUMMIT 2000
Hi,
Does anybody know how lengh is the header of MPLS, i mean how many bits
does the "tag-switching" add to the layer2 or layer3 ?
Thanks in advance.
Regards.
Hugo
Would the idiot who spammed every IETF mailing list with
a subscription solicitation for a Yahoo MPLS mailing list
kindly identify itself?
Melinda
Hello, and Happy Holidays!
ICM Conferences, Inc. is hosting the following event that will be of
much interest to followers of the IETF:
The MPLS Summit
Management Solutions for MPLS
Deployment and Network Efficiency
March 20-21, 2000
San Diego, CA
The following members of the IETF are
Hi,
I heard that some simulation part is available for MPLS combined with
OSPF/ISIS floods. Can anybody please tell where can I get it. If U have
a one, please send it to me.
And I want to know is there any MPLS simulation results available. If any
of U have these, please let me know.
Thanks
MPLS Global Summit taking place October 3-4, 2000 at the Fairmont Copley
Plaza in Boston, MA.
As you may know this is ICM's third MPLS event. The program has been
recognized as one of the leading industry events. The most recent gathering
in San Diego attracted approximatel
ined, are not uniquely associated
>with a MEG.
Sec 7.4 " At a cross-connect point, in order to automatically generate MIP_IDs
for MPLS-TP, we simply use the IF_IDs of the two interfaces which are
cross-connected"
> the above given definition refers to "intermediate node". It
Eric,
Eric Rosen wrote:
- Define requirements, mechanisms and protocol extensions for
point-to-multipoint (P2MP) MPLS
Should be P2MP and MP2MP (multipoint-to-multipoint) MPLS; we wouldn't want
to suddenly find out that half of draft-ietf-mpls-ldp-p2mp is &qu
Constraint-based Routed Label Distribution
Protocol (CR-LDP) Extensions", despite the fact that CR-LDP has been
deprecated by RFC 3468 ("The MPLS Working Group decision on MPLS signaling
protocols", February 2003). I don't think this is allowable; I interpret
RFC 3468 as req
Hi Eric,
Sorry for the delay. Please see below:
At this point, I believe the only change that is needed to draft-ietf-mpls-
ldp-upstream is to move the reference to RFC 3472 into the "Informational
References" section.
This is fine. I will make the change in the next update.
your question in regards to the
draft as the question you ask is not relevant within the scope of the draft.
Ben
From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of Shahram Davari
[dav...@broadcom.com]
Sent: Tuesday, September 22, 2009 12:
Hi,
Just for clarification, does this draft require using a PID for BFD and
LSP-ping? If not how are the various OAM types identified?
Thanks,
Shahram
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG
Sent: Monday, September 21, 2009 3
; ietf@ietf.org; ietf-annou...@ietf.org
Cc: m...@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network
Management Requirements) to Proposed Standard
Sharam,
The draft describes network management requirements and at most states that OAM
must be configurable by network
The primary motivation is to allow for a compact form for the Tunnel MEP_ID.
A secondary motivation is compatibility with existing MPLS/GMPLS Session
objects.
...George
On 7/1/11 9:07 AM, "Joel M. Halpern" wrote:
> In performing a gen-art review of this document, which seems quit
up End-point (MEP) or a Maintenance Entity Group
> Intermediate Point (MIP). Maintenance points are uniquely associated
> with a MEG."
>> This is true for MEP. MIP, as currently defined, are not uniquely associated
>> with a MEG.
>
> Sec 7.4 " At a cross-connec
Hi Barry,
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.
http://www.ietf.org/internet-drafts/draft-ietf
> 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 re
Barry,
Thanks again for your help and support!
Luyuan
-Original Message-
From: Barry Leiba
Date: Wednesday, February 6, 2013 1:47 PM
To: Luyuan Fang
Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org"
,
"m...@ietf.org" , IETF discussion list
Subject:
> Would the idiot who spammed every IETF mailing list with
> a subscription solicitation for a Yahoo MPLS mailing list
> kindly identify itself?
s/spammed/attempted to spam/ some are configured responsibly
for the sad but modern age.
and it is most likely that they just scraped the
At 12:46 PM 3/8/02 -0800, Randy Bush wrote:
>and it is most likely that they just scraped the ietf web pages and
>just blew it out. highly doubful that they are actual ietf clued.
What's annoying and/or funny about this is that it's an
MPLS spam. So far it hasn't sh
On Fri, 08 Mar 2002 12:46:05 PST, Randy Bush said:
> > Would the idiot who spammed every IETF mailing list with
> > a subscription solicitation for a Yahoo MPLS mailing list
> > kindly identify itself?
>
> s/spammed/attempted to spam/ some are configured responsibly
>
>> s/spammed/attempted to spam/ some are configured responsibly
>> for the sad but modern age.
> They also nailed the linux-ipv6 list, so it's not IETF-only.
probably
46 PM 3/8/02 -0800, Randy Bush wrote:
> >and it is most likely that they just scraped the ietf web pages and
> >just blew it out. highly doubful that they are actual ietf clued.
>
>What's annoying and/or funny about this is that it's an
>MPLS spam. So far it hasn'
i wonder if we know how to get the attention of a grown-up at yahoo
and just get this whole mess completely nuked. it should be a bit
of an embarrassment to yahoo that someone can use them to perp this
form of net abuse.
randy
Andrew G. Malis wrote:
> Melinda,
>
> I sent an email to the anonymous yahoo ID identified as the mplsissues
> list owner to please identify him or herself, and to cease spamming IETF
> and other lists.
>
> I also completely agree with Randy's point. Posting to IETF lists
> should be restri
Joe,
>>I also completely agree with Randy's point. Posting to IETF lists should
>>be restricted to list participants.
>
>That's often harder to do than it appears, esp. for those who have
>multiple mail addresses from which they might reply, or for those on local
>'exploder' lists that would
Andrew G. Malis wrote:
> Joe,
>
>>> I also completely agree with Randy's point. Posting to IETF lists
>>> should be restricted to list participants.
>>
>>
>> That's often harder to do than it appears, esp. for those who have
>> multiple mail addresses from which they might reply, or for those
At 05:58 PM 3/8/02 -0500, Andrew G. Malis wrote:
>I also completely agree with Randy's point. Posting to IETF lists should be
>restricted to list participants.
The midcom mailing list started out that way but there
were some very, very loud complaints from several quarters.
Because the whole
Title: MPLS and Private Network
Dear Friends,
A company consists of 2 remotely separated sites, A and B. A leased T1 line connects the networks on these 2 sites together. We generally call the company's network a private network since the connection between the 2 sites are private l
hello everyone,
I just can not understand what the RD (route distinguisher) means? when we assign
RDs to users, is it a good idea to use the network address assigned to the user as the
RD? Let's take the cisco MPLS-VPN as an example. we assign 1.1.1.0 mask 255.255.255.0
network addre
: Saturday, March 23, 2013 3:16 PM
To: "ietf@ietf.org"
Cc: "m...@ietf.org"
Subject: Re: [mpls] Last
Call:
>I wonder if the direction of Section 1.2 can be revised to make it more
>of an engineering document.
>
>It currently says:
>
> In recent years, t
ulation might be "since packet multiplexing of traffic from bursty
sources provides more efficient use of bandwidth than TDM technologies".
cheers,
pd
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext
Luyuan Fang (lufang)
Sent: Monday, April
Works for me. Thanks, Paul.
Luyuan
-Original Message-
From: , "Paul (NSN - US/Irving)"
Date: Tuesday, April 2, 2013 7:58 AM
To: Luyuan Fang , Russ Housley ,
"ietf@ietf.org"
Cc: "m...@ietf.org"
Subject: RE: [mpls] Last Call:
>Hi Luyuan,
>
H and Ethernet's OAM
paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST
allow equivalent OAM mechanisms.
Being more precise, we would like to use the same protocol messages, to
give/have
the same "touch&feel" we had in S
Rui,
While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP,
and quite understanding the reasoning behind reusing existing formats,
I am puzzled by two of your statements.
First, that Y.1731 CCMs "would ease more vendor's implementations to
converge to the 50ms
On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein wrote:
> Rui,
Hi all,
> While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP,
> and quite understanding the reasoning behind reusing existing formats,
> I am puzzled by two of your statements.
>
> First, that
Yaakov Stein
Cc: Rui Costa; ietf@ietf.org; Adrian Farrel
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein wrote:
> Rui,
Hi all,
> While a co-auth
[mailto:francesco.fonde...@gmail.com]
Sent: Thursday, October 08, 2009 09:33
To: Yaakov Stein
Cc: Rui Costa; ietf@ietf.org; Adrian Farrel
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
On Thu, Oct 8, 2009 at 8:43 AM
was mentioned at the IETF75
when draft-bhh-mpls-tp-oam-y1731 was discussed.
> The other main fault with Y.1731 is its fracturing of
> the capabilities among so many different OAM message types,
> rather than realizing that there are really only two OAM types
> (one way and refl
riginal Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub
van Helvoort
Sent: Saturday, October 10, 2009 23:15
To: ietf@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,>
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Stan
eed be a nightmare.
Best regards, Huub.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub
van Helvoort
Sent: Saturday, October 10, 2009 23:15
To: ietf@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,>
(R
Yaakov,
See inline...
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Yaakov Stein
Sent: zondag 11 oktober 2009 10:18
To: hhelvo...@huawei.com; ietf@ietf.org
Subject: RE: [mpls] Last Call:
draft-ietf-mpls-tp-oam-requirements,>(Requirements
reet London
EC1A 7AJ Registered in England no: 180
>> From: The IESG
>> Date: Thu, 30 Apr 2009 06:16:19 -0700 (PDT)
>> To: IETF-Announce
>> Subject: Last Call: draft-ietf-mpls-tp-gach-gal (MPLS Generic Associated
>>
>> Channel) to Proposed S
On Tue, 27 Oct 2009, The IESG wrote:
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Security Framework for MPLS and GMPLS Networks '
as an
Informational RFC
This is an assigned ops-dir review.
The d
Italo,
My original comment on SPME has been sent to the list on 07-Jul-10.
You can see it at
http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04369.html .
It has not been posted as an LC comment, presumably because the draft has not
been in any kind of LC at that moment.
Adrian,
Please
xander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
> Inviato: lunedì 15 novembre 2010 13.29
> A: BUSI, ITALO (ITALO)
> Cc: mpls...@ietf.org; adr...@olddog.co.uk; ietf@ietf.org
> Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
>
> Ital
I see some difficulties with the references in this I-D.
a) The security section of this I-D says
see[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
which is an informative reference.
I believe that security should be normative, not informative, even in this, a
requirements (as opposed to
Thanks for the input Tom,
I see some difficulties with the references in this I-D.
a) The security section of this I-D says
see[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
which is an informative reference.
I believe that security should be normative, not informative, even in
this
- Original Message -
From: "Adrian Farrel"
To: "Tom.Petch"
Cc: "ietf"
Sent: Monday, July 20, 2009 5:47 PM
Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP
Requirements)toProposed Standard
> Thanks for the input Tom,
>
> >I se
Hi Tom,
> a) The security section of this I-D says
> see[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
> which is an informative reference.
>
> I believe that security should be normative, not informative, even in
> this, a
> requirements (as opposed to a protoco
- Original Message -
From: "Adrian Farrel"
To: "Tom.Petch"
Cc: "ietf"
Sent: Tuesday, July 21, 2009 11:36 PM
Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP
Requirements)toProposed Standard
> Hi Tom,
>
> >> > a) The se
Hello,
Please note to the updated version of the MPLS-TP OAM analysis document.
The changes were made to resolve comments that were received during IETF
Last Call.
* A clarification was added in the abstract to show that
"MPLS-TP" and "MPLS based transport networks"
hi,
i have some doubts about when we implement L2 VPN over MPLS we SHOULD keep loop
free. See draft-lasserre-tls-mpls-00.txt. why?
why not just use such a simple algorithm described below?
1. if the L2 frames are received from a interface connecting to a CE, forward the
frames
It is my first time in IETF working group and i am
interested in this topic :
"However, to encourage the deployment of MPLS based
networks, and to deal with more advanced IP features in a
timely manner, there is a crucial need to enhance the
functional capabilities of IP/MPLS based net
Title: MPLS and Private Network
David
Wang writes:
A company consists of 2 remotely
separated sites, A and B. A leased T1 line connects the networks on these 2
sites together. We generally call the company's network a private network
since the connection between the 2 site
PROTECTED]]
Sent: Tuesday, May 16, 2000 7:22 AM
To: [EMAIL PROTECTED]
Subject: MPLS and IS-IS
Hi all,
I have been hearing IS-IS is a better protocol to be used than OSPF in a
MPLS
network for TE application. Is that a fair statement? What are the technical
reasons?
Appreciate if someone can shed some
>Hi all,
>
>IS-IS is defined to work with CLNP not for IP originally. Until today a lot
>of SONET and telecommunication equipment vendors still use IS-IS to route
>CLNP packets through the SONET Data communication channel(DCC) to carry
>management information and there is a great pressure to chang
PGP: 540E 4D84 C070 811C 2F49 3799 7E17 77EB
--
>
> Thanks
> David
>
>
> -Original Message-
> From: HANSEN CHAN [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 16, 2000 7:22 AM
> To: [EMAIL
That's because it is *so* much easier to just keep mumbling 'major unresolved
technical concerns'. I expect it is something learned in Yoga class.
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
> Luyuan Fang (l
Yep. We are going in circles again.
We need to see technical details on the issues documented in an I-D as Stewart
suggested.
Don't remember seeing such document either.
Luyuan
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
On Fri, 11 Apr 2008, The IESG wrote:
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
>
> - 'MPLS Multicast Encapsulations '
>as a Proposed Standard
>
> The IESG plans to make a decision in t
this should be done
differently from 4379.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
> The IE
IP encapsulation, over
ACH" accordingly. What's reason behind this? Or maybe I missed something.
Best regards,
Mach
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The
> IESG
> Sent: Thursday, August 11, 2011 9:46 PM
>
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 t
Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~AGI Value (contd.)~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-ietf-mpls-tp-cc-cv-rdi-06, section 3.5.
xiaolee wrote:
>
> hi,
>
> i have some doubts about when we implement L2 VPN over MPLS we SHOULD keep loop
>free. See draft-lasserre-tls-mpls-00.txt. why?
>
> why not just use such a simple algorithm described below?
>
> 1. if the L2 frames are received fro
> It is my first time in IETF working group and i am
> interested in this topic :
> "However, to encourage the deployment of MPLS based
> networks, and to deal with more advanced IP features in a
> timely manner, there is a crucial need to enhance the
> functional
Alessandro,
Most of the comments I remember reading were of the form "we don't like MPLS
OAM because it has 'major unresolved technical concerns' and draft-bhh is *so*
much better". I.e., they were neither constructive nor actionable.
Thanks,
John
> -
"Alexander Vainshtein", "D'Alessandro Alessandro Gerardo", "Stewart Bryant (stbryant)"
>Cc: "m...@ietf.org", "ietf@ietf.org"
>Ogg: Re: [mpls] unresolved technical concerns
>
>That's because it is *so* much easier to just keep mu
09 11:28 PM
To: ruiquan.j...@ties.itu.int
Cc: i...@ietf.org
Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements
(RequirementsforOAMin MPLS Transport Networks) to Proposed Standard
By the way, was there an exceptional circumstance driving you to send direct to
the IESG rather than to the
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
Hi,
I support publication of this document,
although I do have some comments on the composition of sections 4 & 5
that I will privately provide the editors.
Yaacov Weingarten
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
ext Luyuan
mp;t, NTT, and FT. They were involved in the development of the MPLS-TP
requirements documents and were part of the detailed review of this
document.
Of course, the MPLS-TP list contains participants from a larger number of
carriers, and they all took part in the working group last call.
You
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
Hi all,
I do not support approval of this draft either.
"3.1. MPLS-TP is an MPLS Technology"
MPLS-TP is also a transport technology and used to add connection oriented
packet transport capability which is deployed and operated in a manner
that is similar to the existing transpo
.
TDM PW gives a good example. G.8113.1 based OAM is relative simple and
mature and widely deployed and should be the standard.
Best regards,
Han Li
-Original Message-
From: HUANG Feng F
Sent: 2011年10月5日 7:56
To: 'ietf@ietf.org'
Subject: RE: [mpls] FW:
Same here.
I support publication of the draft.
Luyuan
> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
Of
> John E Drake
> Sent: Thursday, October 06, 2011 7:11 AM
> To: David Sinicrope; David Allan I
> Cc: m...@ietf.org; ietf@
MPLS and behaves a lot like MPLS with "better OAM" characteristics
and then standardizing that protocol. I will fully support that protocol
except that it cannot be called MPLS. It is a new protocol.
Regards,
Azhar Sayeed
Cisco Systems Inc.
__
for label swapping between providers. Our architecture group is talking
about using 10a versus 10b label swapping, and I'm trying to find
references on what this is and how it affects our backbone core network.
I've searched the IETF database, IESG, and vendors such as cisco.com, and
can find noth
ge of CV interleaved definition
BR,
Hideki
>
>>
>>The IESG has received a request from the Multiprotocol Label Switching WG
>>(mpls) to consider the following document:
>>- 'Proactive Connectivity Verification, Continuity Check and Remote
>> Defect indic
Hi Robert,
Thank you very much for your reply,
and I am sorry for my late response.
See inline, marked with [HE];
>
>
>From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of
>hideki.endo...@hitachi.com [hideki.endo...@hitach
: Malcolm Johnson
> Subject: Re: MPLS
>
> Dear Malcolm:
>
> http://www.itu.int/ITU-T/newslog/Statement+Ahead+Of+IETF+Meeting.aspx
>
> Thanks for getting this posted. It has already gotten a lot of visibility.
>
> Just to make sure that we are on the same page, I'd
as well as for CV.
In the context of this LC, we should focus now on the proposed solution.
Best regards,
Nurit
-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
ext Thomas Nadeau
Sent: Friday, July 08, 2011 6:27 PM
To: neil.2.harri...@bt.com
Cc: m
To the IETF area directors, MPLS and PWE3 working group chairs, document
authors and IETF community,
I've recently started looking at the MPLS-TP drafts and only this past week
have had an opportunity to review the OAM requirements draft for MPLS-TP. I
realize the IESG has requested Last
Sadler, Jonathan B. wrote:
ITU-T SG15 has a history of OAM protocol development for transport
technologies. This expertise has led to development of an OAM
methodology and definition approach as documented in G.806.
Jonathan
Unfortunately the latest version of G.806 is showing up as
pre-publ
All,
comments as the document shepherd.
We have comments on the draft-ietf-mpls-tp-oam-framework in IETF
last call from Yoshinori Koike, Jonathan Sadler and Ruiquan Jing.
All are subscribed to IETF lists that were included in the working
group last calls.
1. There are comments for the same
3.4.1 says
"The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. "
Without a reference, or any detail, I think this can only muddy the waters. How
do I know that your best practice is my best practice, or
Tom,
Thanks for your comment.
>
> 3.4.1 says
>
> "The data plane behaviour of MPLS-TP is the same as the best current
> practise for MPLS. This includes the setting of the S-Bit. "
>
> Without a reference, or any detail, I think this can only
> muddy th
Tom,
I'm acutely aware that I owe you a response to the procedural
issues on this, more so since the questions is relevant to
all the mpls-tp drafts currently being progressed to become
RFCs beginning of June. The mpls working group chairs to a
not insignificant extent share your concern
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:
(Proactive Connectivity
Verification, Continuity Check and Remote
FYI
- Forwarded message from ji...@ties.itu.ch -
Date: Fri, 2 Oct 2009 16:46:53 +0200
From: ji...@ties.itu.ch
Reply-To: ji...@ties.itu.ch
Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for
OAMin MPLS Transport Networks) to Proposed Standard
To
: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Varma, Eve L (Eve)
Sent: Wednesday, May 05, 2010 3:15 PM
To: ietf@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk
(MultiprotocolLabel Switching Transport Profile Survivability
Framework)to Informational RFC
Hi
In view of the several packet types we have similar naming and to avoid
confusion indicating
Similar fields for different packet types we need to have some
distinguishing factor
Indicating something like "Labelled Traffic Differentiator " or
"Labelled Traffic class" or
I am away from the office until April. My access to email will be
very sporadic during this time.
For LDP problems please mail [EMAIL PROTECTED]
For general LDP questions, please mail [EMAIL PROTECTED] and
[EMAIL PROTECTED]
For all other urgent matters, please contact my manager Andy
FYI ...
zhangp7
2011-10-05 19:47
收件人
,
抄送
主题
答复: [mpls] FW:
LastCall: (TheReasons
for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Hi, All:
I also don’t support this draft.
For MPLS-TP OAM solution as described in Section 3.6, we think it should
be good
F and major unresolved
technical concerns risen from some transport operators, the existence of this
draft is by itself the sure sign that MPLS-TP OAM is a case where a single
solution has not be found to meet all the different market requirements.
Otherwise, why are we still discussing abo
ot;If a previous design, in the Internet context or ELSEWHERE, has successfully
solved the same problem, choose the same solution unless there is a good
technical reason not to".
We didn't choose the elsewhere designs (ETH, T-MPLS; please check deployment
numbers in other e
ble to agree to develop a single, global
standard from the start.
For MPLS-TP, we have the coming together of the transport world with the
Internet world. We have succeeded in driving together many aspects of this
technology, but we shouldn't be too surprised that we can't get down to
;ietf@ietf.org"
cc
Subject
RE: [mpls] FW: Last Call:
(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. For the SONET/SDH example, it has been pointed out that
starti
1 - 100 of 479 matches
Mail list logo
