Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)
draft-ietf-mpls-tp-mip-mep-map-09

[Ballot comment]

What are the security mechanisms that are "required" to be
offered and that we are "strongly adivsed" to use? Don't
you need to say - if those are in RFCs 6371 or 6941 then
saying which sections you mean should be easy. If those
are not in those RFCs then how am I supposed to know what
to do?

[Ballot discuss]

This could be a trivial discuss that just needs a better
pointer, or else it could be a case where there's
arm-waving in the security considerations.  I'm not sure
which:-)

What are the security mechanisms that are "required" to be
offered and that we are "strongly adivsed" to use? Don't
you need to say - if those are in RFCs 6371 or 6941 then
saying which sections you mean should be easy. If those
are not in those RFCs then how am I supposed to know what
to do?

[Ballot comment]
I did have one (non-blocking) question on section 4.  Requirements and Design Considerations for Internal-MIP Adressing

  Any solution that attempts to send OAM messages to the outgoing
  interface of an MPLS-TP node must not cause any problems when such
  implementations are present (such as leaking OAM packets with a TTL
  of 0).

"... must not cause any problems (such as ..." with one example - is there somel reference that might provide a bit more guidance?

I'm looking at the bulleted list under Figure 6 as a very reasonable description of constraints on a solution - would some bullet in that list prohibit "leaking OAM packets with a TTL of 0"?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-tp-mip-mep-map-08, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Per-Interface MIP Addressing Requirements and Design Considerations) to Informational RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Per-Interface MIP Addressing Requirements and Design Considerations'
  as 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@ietf.org mailing lists by 2013-08-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map/ballot/


No IPR declarations have been submitted directly on this I-D.