draft-ietf-mpls-tp-mip-mep-map-03.txt   draft-ietf-mpls-tp-mip-mep-map-04.txt 
Network Working Group A. Farrel Network Working Group A. Farrel
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational H. Endo Intended status: Informational H. Endo
Expires: April 25, 2013 Hitachi, Ltd. Expires: May 16, 2013 Hitachi, Ltd.
R. Winter R. Winter
NEC NEC
Y. Koike Y. Koike
NTT NTT
M. Paul M. Paul
Deutsche Telekom Deutsche Telekom
October 22, 2012 November 12, 2012
Handling MPLS-TP OAM Packets Targeted at Internal MIPs Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-ietf-mpls-tp-mip-mep-map-03 draft-ietf-mpls-tp-mip-mep-map-04
Abstract Abstract
The Framework for Operations, Administration and Maintenance (OAM) The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how Maintenance within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
Entity Group Intermediate Points (MIPs) may be situated within Entity Group Intermediate Points (MIPs) may be situated within
network nodes at the incoming and outgoing interfaces. network nodes at the incoming and outgoing interfaces.
This document describes a way of forming OAM messages so that they This document describes a way of forming OAM messages so that they
can be targeted at MIPs on incoming or MIPs on outgoing interfaces, can be targeted at MIPs on incoming or MIPs on outgoing interfaces,
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on May 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10
6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Previously considered solutions . . . . . . . . . . . 14
A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.2. A separate channel type for the out-MIP . . . . . . . . . 14
A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 14
A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Framework for Operations, Administration and Maintenance (OAM) The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
Framework, [RFC6371]) distinguishes two configurations for Framework, [RFC6371]) distinguishes two configurations for
Maintenance Entity Group Intermediate Points (MIPs) on a node. It Maintenance Entity Group Intermediate Points (MIPs) on a node. It
defines per-node MIPs and per-interface MIPs, where a per-node MIP is defines per-node MIPs and per-interface MIPs, where a per-node MIP is
a single MIP per node in an unspecified location within the node and a single MIP per node in an unspecified location within the node and
skipping to change at page 13, line 14 skipping to change at page 13, line 14
Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros
for interesting input to this document through discussions. for interesting input to this document through discussions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-mpls-tp-itu-t-identifiers] [I-D.ietf-mpls-tp-itu-t-identifiers]
Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions", Identifiers Following ITU-T Conventions",
draft-ietf-mpls-tp-itu-t-identifiers-05 (work in draft-ietf-mpls-tp-itu-t-identifiers-06 (work in
progress), October 2012. progress), November 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
[I-D.ietf-mpls-tp-security-framework] [I-D.ietf-mpls-tp-security-framework]
Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS-TP Security Framework", Graveman, "MPLS-TP Security Framework",
draft-ietf-mpls-tp-security-framework-05 (work in draft-ietf-mpls-tp-security-framework-05 (work in
progress), October 2012. progress), October 2012.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011. Acronym in the IETF", BCP 161, RFC 6291, June 2011.
Appendix A. Previously considered solutions
A.1. GAL TTL
The use of the GAL TTL has been considered before. This transforms
the GAL TTL into some kind of node-internal TTL, i.e. a GAL TTL of 0
would address the in-MIP and a GAL TTL of 1 the out-MIP. The main
drawback of this approach is that it (as of now at least) would only
be applicable to LSPs and not to PWs.
A.2. A separate channel type for the out-MIP
This approach would require two channel types for the exact same OAM
type, one to address the in-MIP and another one to address the out-
MIP. This seems like a waste of channel types, however it appears
that there is no expected shortage of them. Legacy nodes will
discard the packets as the new channel types are unkonwn. Having two
channel types for the same OAM however feels a bit hacky.
A.3. Decrement TTL once per MIP
Decrementing the TTL more than once per node seems a "natural" way of
per-interface MIP addressing since TTL expiry is all that is needed
for the per-node MIP case. In other words, by decrementing the TTL
once per MIP (twice per node) no extra mechanism is needed to solve
the internal MIP addressing problem. The solution has been discarded
since it does not represent the typical mode of network operation
today (since also for normal data packets the TTL needs to be
decremented more than once).
A.4. Using an ACH reserved bit
The ACH contains eight reserved bits which currently all need to be
set to zero and ignored on reception. One bit could be reserved as
an out-MIP address flag. In other words, in case the bit is set, the
out-MIP is addressed. An advantage of this approach is that there is
no semantic overlap with anything that exists today, as the bits are
not in use. Existing implementations need to ignore it. That means
that existing implementations will process the OAM packets at the in-
MIP/per-node MIP. Identification information is still needed however
for the P2MP case as a single bit is not enough.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Hideki Endo Hideki Endo
Hitachi, Ltd. Hitachi, Ltd.
 End of changes. 7 change blocks. 
53 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/