RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Loa,
   YES, but there are only someone (not organization-that's a individual draft and MEAD team-not ietf mpls group or ietf group, which has been disbanded by themselves one years ago) make decision to done a single solution!
B.R.
Feng
 

-----Original Message-----
From: Loa Andersson [mailto:loa@xxxxx] 
Sent: 2011年10月5日 19:53
To: HUANG Feng F
Cc: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

Feng,

there were only one organization invbolved in the decision to develop two OAM solutions!

/Loa

On 2011-10-05 13:29, HUANG Feng F wrote:
> Dear Loa,
>     Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it is complicated, the decision should be done by two orgnizations.
>     There are many errors about in this draft as many, for example, Rolf, Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it should be stop.
> B.R.
> Feng
>
>
> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf 
> Of Loa Andersson
> Sent: 2011年10月5日 18:48
> To: ietf@xxxxxxxx; Rolf Winter
> Subject: Re: Last 
> Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons 
> for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
>
> Rolf,
>
> are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS?
>
> Sometimes the life is simple, though I doubt that it is this simple.
>
> My 2c's is that this a good draft and should be progressed.
>
> /Lao
>
> On 2011-10-04 11:16, Rolf Winter wrote:
>> Hi,
>>
>> I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later.
>>
>> Best,
>>
>> Rolf
>>
>>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>> London W3 6BL | Registered in England 2832014
>>
>>
>>> -----Original Message-----
>>> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf 
>>> Of Brian E Carpenter
>>> Sent: Freitag, 30. September 2011 21:48
>>> To: huubatwork@xxxxxxxxx
>>> Cc: ietf@xxxxxxxx
>>> Subject: Re: Last Call:<draft-sprecher-mpls-tp-oam-considerations-
>>> 01.txt>   (The Reasons for Selecting a Single Solution for MPLS-TP
>>> OAM) to Informational RFC
>>>
>>> Huub,
>>>
>>> On 2011-09-30 20:19, Huub van Helvoort wrote:
>>>> All,
>>>>
>>>> Section 1,1 also contains the text:
>>>>      [RFC5317] includes the analysis that "it is technically 
>>>> feasible
>>> that
>>>>      the existing MPLS architecture can be extended to meet the
>>>>      requirements of a Transport profile, and that the architecture
>>> allows
>>>>      for a single OAM technology for LSPs, PWs, and a deeply nested
>>>>      network."
>>>>
>>>> This is a quote from slide 113 in the PDF version of RFC5317 and
>>> should
>>>> be read in realtion to the statement on slide 12 of the same RFC:
>>>>
>>>> "This presentation is a collection of assumptions, discussion points
>>>>    and decisions that the combined group has had during the months of
>>>>    March and April, 2008
>>>>    This represents the *agreed upon starting point* for the technical
>>>>    analysis of the T-MPLS requirements from the ITU-T and the MPLS
>>>>    architecture to meet those requirements"
>>>>
>>>> So the quoted text in the draft is one of the assumptions.
>>>>
>>>> The fact that there are currently *two* OAM mechanisms (and not a 
>>>> *single*), i.e. one for PW and one for LSP proves that the 
>>>> assumption was not correct.
>>>
>>> I'm sorry, I don't understand your logic. You seem to be saying that 
>>> the fact that two solutions have been designed proves that the 
>>> assumption that a single solution is possible was false. That 
>>> doesn't follow at all. The engineering profession has a long history 
>>> of producing multiple solutions where a single one was possible, and 
>>> this seems to be just another such case.
>>>
>>> This isn't news. I quote from RFC 1958 (June 1996):
>>>
>>> "  3.2 If there are several ways of doing the same thing, choose one.
>>>      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.  Duplication of the same
>>>      protocol functionality should be avoided as far as possible, without
>>>      of course using this argument to reject improvements."
>>>
>>>           Brian
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/ietf
>> _______________________________________________
>> Ietf mailing list
>> Ietf@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf
>

-- 


Loa Andersson                         email: loa.andersson@xxxxxxxxxxxx
Sr Strategy and Standards Manager            loa@xxxxx
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]