ietf
[Top] [All Lists]

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

2011-10-05 06:32:08
Hi Loa,

Let me answer with a counter-question. If the sole purpose of this document is 
to stop the development of two OAM solutions, do you think this RFC-to-be will 
achieve that? Seriously? The problem I see here is that we start a habit of 
writing "politically" motivated documents. We have this issue documented 
already all over the place in the form of minutes, web sites, press releases 
etc. I think this is enough and the right place. Let the I* and liaisons figure 
this out so that we all can go back to protocol design and development.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 
6BL | Registered in England 2832014 


-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: Mittwoch, 5. Oktober 2011 12:48
To: ietf(_at_)ietf(_dot_)org; 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)
to Informational 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(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of
Brian E Carpenter
Sent: Freitag, 30. September 2011 21:48
To: huubatwork(_at_)gmail(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

--


Loa Andersson                         email: 
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager            loa(_at_)pi(_dot_)nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>