Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    mpls mailing list <>,
    mpls chair <>
Subject: Document Action: 'Per-Interface MIP Addressing Requirements and Design Considerations' to Informational RFC (draft-ietf-mpls-tp-mip-mep-map-09.txt)

The IESG has approved the following document:
- 'Per-Interface MIP Addressing Requirements and Design Considerations'
  (draft-ietf-mpls-tp-mip-mep-map-09.txt) as Informational RFC

This document is the product of the Multiprotocol Label Switching Working

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:

Technical Summary

   The Framework for Operations, Administration and Maintenance (OAM)
   within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
   Entity Group Intermediate Points (MIPs) may be situated within
   network nodes at the incoming and outgoing interfaces.

   This document elaborates on important considerations for internal MIP
   addressing.  More precisely it describes important restrictions for
   any mechanism that specifies a way of forming OAM messages so that
   they can be targeted at MIPs on incoming or MIPs on outgoing
   interfaces and forwarded correctly through the forwarding engine.
   Furthermore, the document includes considerations for node
   implementations where there is no distinction between the incoming
   and outgoing MIP.

Working Group Summary

   This document has support in the working group and has been well

   There has been a comparatively long discussion that in the end
   converged on a widely accepted definition of pre-interface MIPs
   and MEPs.

Document Quality

    This an informational document, it discusses deployment of per-
   interface MIPs and MEPs.

   The document have had the review that is needed.

   No need for third party expert reviews.


    Loa Andersson is the document shepherd.

   Stewart Bryant is the responsible AD.

RFC Editor Note
Deployments are strongly advised to use such mechanisms.
Deployments are therefore strongly advised to follow the security advice provided in RFC6371 and RFC6941.