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 publication of draft-sprecher...
D
> MPLS Working Group,
>
> Please be aware of the IETF last call as shown below. The document was
> presented for publicat
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 de
Alessandro, Stewart and all,
I concur with Stewart: please write a draft detailing your major technical
concerns.
I'd like to add a quote from Malcolm's presentation at the IETF meeting in
Prague:
"Differences are close to invisible at the level of
the requirements in RFC5860".
Jus
06 418 639 07
-Messaggio originale-
Da: Stewart Bryant [mailto:stbry...@cisco.com]
Inviato: mercoledì 5 ottobre 2011 12:24
A: D'Alessandro Alessandro Gerardo
Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org
Oggetto: Re: [mpls] R: FW: Last Call:
(The Reasons for Selecting a
Sing
I concur with Dave's comment and support publication of the draft.
Dave
On Oct 5, 2011, at 7:06 PM, "David Allan I" 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 publication of draft-spre
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: considerations-01.txt> (The R
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 d
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
easons for Selecting a
Single Solution for MPLS-TP OAM) to Informational RFC
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 publication of draft-sprecher...
D
> MPLS Working Group,
>
> Please b
etc. That cannot
be "fixed" 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:
> 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 can
> 发件人: D'Alessandro Alessandro Gerardo
> 主题: [mpls] R: FW: Last Call:
> (The Reasons for Selecting
> a Single Solution for MPLS-TP OAM) to Informational RFC
> 收件人: "adr...@olddog.co.uk" , "m...@ietf.org"
> , "ietf@ietf.org"
> 日期: 2011年10月
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"
> wrote:
>
>> I think it is unfortunate that we are in a
andard.
Best regards,
Han Li
--- 11年10月5日，周三, D'Alessandro Alessandro Gerardo
写道：
> 发件人: D'Alessandro Alessandro Gerardo
> 主题: [mpls] R: FW: Last Call:
(The Reasons for
Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
> 收件人: "adr...@olddog.co.uk&
Hi Jian,
On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote:
> Dear All,
>
> I do not support either.
>
> In section 3.5:
> If two MPLS OAM protocols were to be deployed we would have to consider
> three possible scenarios:
> 1) Isolation of the network into two incompatible and unconnected islan
...@ietf.org
05/10/2011 04:16 PM
To
yang.jia...@zte.com.cn
cc
"m...@ietf.org" , D'Alessandro Alessandro Gerardo
, "ietf@ietf.org"
, larryli...@yahoo.com.cn, mpls-bounces@ietf.orgLarry,
"adr...@olddog.co.uk"
Subject
Re: 答复: [mpls] 回复： R: FW: Last Call:
(The Reasons f
cusses the elements of the choice of solutions.
> Current
> application and deployment should be considered. In China Mobile, more
> than
> 330,000 PTN box are/will based on G.8113.1.
>
> TDM PW gives a good example. G.8113.1 based OAM is relative simple
> and
> mat
If the MPLS WG had selected the OAM solution that was already existing (as
indicated multiple times by the operators which have already massively deployed
it), we would have had a single OAM solution both in the market and in the IETF
RFCs.
We now have "two" OAM solutions: one (which is not act
Alessandro,
Apparently, the advice given regarding the risks and costs associated with
deploying proprietary or pre-standard solutions didn't resonate with you. Do
you really expect the rest of us to clean up after you?
Thanks,
John
> -Original Message-
> From: mpls-boun...@ietf.org
: FW: Last Call:
(The Reasons for Selecting a
Single Solution for MPLS-TP OAM) to Informational RFC
Alessandro,
Apparently, the advice given regarding the risks and costs associated with
deploying proprietary or pre-standard solutions didn't resonate with you. Do
you really expect the r
20 matches
Mail list logo
