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

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

 



----- Original Message -----
From: "Loa Andersson" <loa@xxxxx>
To: "t.petch" <daedulus@xxxxxxxxxxxxx>
Cc: <ietf@xxxxxxxx>
Sent: Wednesday, October 05, 2011 1:46 PM
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>
(TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC


> Tom,
>
> I don't think there is any objections to improving the document, the
> most straight-forward way of doing this is the time-honored IETF
> method "supply the text!"

Which I think belongs in a Working Group with a chair or two and an AD or two,
with the relevant expertise in the members, perhaps rtgwg.

In such a setting, I might comment that with OSPF and ISIS, the second half of
the last paragraph is wrong.  They are an example of islands, as described in
s.6, but they are required to interwork, in a manner of speaking and do so via
BGP, that is we have OSPF-BGP interworking and ISIS-BGP interworking, neither of
which are specified outside proprietary solutions, but both of which need to
work for the Internet work.  Which is a cost of having two solutions.

Tom Petch
>
> /Loa
>
> On 2011-10-05 10:01, t.petch wrote:
> > I oppose publication of this I-D in its present form.
> >
> > The idea of having an I-D that says two OAM solutions will cost is fine, but
> > there are too many technical errors, especially in sections 4 and 5 (better
as
> > Brian suggested as appendices), for it to go forward as it stands.  Huub,
> > Malcolm and Andy have pointed out the errors in SONET/SDH, I would take
issue
> > with OSPF/ISIS and IPv4/IPv6.  The errors aren't gross, but they add up to
too
> > many.
> >
> > The sponsoring AD has given his reasons why this is an individual submission
but
> > I think that the consequence is that the document quality is too low to be
> > published.  It needs the review of a wider body of expertise, the routing
area
> > perhaps, before it is published.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "The IESG"<iesg-secretary@xxxxxxxx>
> > To: "IETF-Announce"<ietf-announce@xxxxxxxx>
> > Sent: Monday, September 26, 2011 9:42 PM
> > Subject: Last Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>
> > (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational
RFC
> >>
> >> The IESG has received a request from an individual submitter to consider
> >> the following document:
> >> - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
> >>    <draft-sprecher-mpls-tp-oam-considerations-01.txt>  as an Informational
> >> RFC
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to the
> >> ietf@xxxxxxxx mailing lists by 2011-10-24. Exceptionally, comments may be
> >> sent to iesg@xxxxxxxx instead. In either case, please retain the
> >> beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>     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
> >>     operators of packet transport networks.
> >>
> >>     During the process of development of the profile, additions to the
> >>     MPLS toolset have been made to ensure that the tools available met
> >>     the requirements. These additions were motivated by MPLS-TP, but form
> >>     part of the wider MPLS toolset such that any of them could be used in
> >>     any MPLS deployment.
> >>
> >>     One major set of additions provides enhanced support for Operations,
> >>     Administration, and Maintenance (OAM). This enables fault management
> >>     and performance monitoring to the level needed in a transport
> >>     network. Many solutions and protocol extensions have been proposed to
> >>     address these OAM requirements, and this document sets out the
> >>     reasons for selecting a single, coherent set of solutions for
> >>     standardization.
> >>
> >>
> >> The file can be obtained via
> >> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
> >>
> >> IESG discussion can be tracked via
> >> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
> >>
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >> _______________________________________________
> >> IETF-Announce mailing list
> >> IETF-Announce@xxxxxxxx
> >> https://www.ietf.org/mailman/listinfo/ietf-announce
> >
> > _______________________________________________
> > 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]