Subject: Fwd: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard

From: [email-masked]
Date: Tue, 6 Oct 2009 15:36:46 +0200

FYI

----- Forwarded message from [email-masked] -----
    Date: Fri,  2 Oct 2009 16:46:53 +0200
    From: [email-masked]
Reply-To: [email-masked]
 Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for 
OAMin MPLS Transport Networks) to Proposed Standard
      To: [email-masked]

hi,

As a carrier, we think it is very important to operate MPLS-TP OAM with a 
behavior that is consistent with transport network operations. So we propose 
the following requirement to be added to MPLS-TP OAM requirements draft:

"
It MUST be possible to operate the MPLS-TP OAM protocols, which satisfy 
functional requirements that are common to general transport layer network 
(i.e., independent of technology), in a way that is similar to the way 
equivalent mechanisms are operated in other transport layer technologies (e.g., 
SONET/SDH, OTN and Ethernet).
"
Best regards

Jing Ruiquan

China Telecom

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Monday, September 21, 2009 4:31 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: draft-ietf-mpls-tp-oam-requirements
> (Requirements for OAMin MPLS Transport Networks) to Proposed Standard
> 
> The IESG has received a request from the Multiprotocol Label Switching 
> WG
> (mpls) to consider the following document:
> 
> - 'Requirements for OAM in MPLS Transport Networks '
>    <draft-ietf-mpls-tp-oam-requirements-03.txt> as a Proposed Standard
> 
> 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 [email-masked] mailing lists by 2009-10-05. Exceptionally, comments 
> may be sent to [email-masked] instead. In either case, please retain 
> the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-req
uirements-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=18036&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

----- End forwarded message -----

---

From: Loa Andersson <[email-masked]>
Date: Thu, 08 Oct 2009 10:30:57 +0200

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 the look and feel for operations
across different networks based on different technologies, on
OAM interoperability between different technologies.

2. There are comments on interworking/ineroperability/translation
between networks based on different technologies.

3. There is a comment that the involvement (awarness) of the MPLS-TP
work is not good enough on the ITU-T side.

4. There is a requirement to change the MEP/MIP architecture.

5. There is a comment that wants to add new information that is not
technical in it character to the document.

For comments on (1), this is a bit unclear, I assume that we are not
talking about look and feel of bits on the wire but look and feel for
the operational interfaces and procedures. This is captured in the
overall MPLS-TP requirements:

    "To realize these goals, it
    is essential that packet-transport technology be available that can
    support the same high benchmarks for reliability and operational
    simplicity set by SDH/SONET and OTN technologies."

and

    "Furthermore, for carriers it is important that operation of such
    packet transport networks should preserve the look-and-feel to which
    carriers have become accustomed in deploying their optical transport
    networks, while providing common, multi-layer operations, resiliency,
    control, and multi-technology management."

So this is taken care of.

For comments on (2).
This was discussed during working group last call and prior, and it was
discussed on the ITU-T ad hoc team list during the period when a
response was written in response to the MPLS WG last call.
The IESG position is that interworking different technologies is out
of scope for the MPLS-TP project.

The ITU-T did not make a request to include this requirement
within MPLS-TP.

In liaison https://datatracker.ietf.org/documents/LIAISON/file706.pdf
from the ITU-T it was agreed that if and when ITU-T converges on such
requirements they will be taken to the IETF through the MPLS change
process (RFC4929).

This comment should also be resolved.

Comment 3, on ITU-T participation in the MPLS-TP project and in the
review of the MPLS-TP documents I strongly object to to this comment,
the entire project has been set up to guarantee that we have a good
flow of information between the two organizations. Tthere are plenty
of opportunities for the ITU-T to provide input both through their
own procedures and through normal IETF procedures.

Comments 4.

The maintenance architecture as it is defined operates with
functional groups that could be "attached" to e.g. an LSP at
different points. MEPs are Maintenance End Points and can actively
generate e.g. OAM flows and traffic to localize failures. MIPs are
Maintenance Intermediate Points, which are passive and can only
respond if a request are sent to them. The requirements involves
a total re-wrap of the Maintenance architecture, it was discussed
in Q10/15 and turned down as not aligned with the rest of the
requirements we received form other operators.

The MPLS-TP maintenace architecture is further explained and
expanded upon in draft-ietf-mpls-tp-oam-framework. Further discussion
on the maintenance architecture should take place in the
context of that document, rather han in the context of the requirements
document that should focus on functional requirements.

Comment 5.

This is a bit trickier since it asks for substantial additions,
that is not requirements but descriptive text and tables.
Given the nature of the information I'd would like to take it as
an input to the MPLS-TP OAM Framework where it would fit nicely.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13