idnits 2.17.1 draft-ietf-mpls-tp-mip-mep-map-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-itu-t-identifiers-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-security-framework-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Informational H. Endo 5 Expires: January 17, 2013 Hitachi, Ltd. 6 R. Winter 7 NEC 8 Y. Koike 9 NTT 10 M. Paul 11 Deutsche Telekom 12 July 16, 2012 14 Handling MPLS-TP OAM Packets Targeted at Internal MIPs 15 draft-ietf-mpls-tp-mip-mep-map-02 17 Abstract 19 The Framework for Operations, Administration and Maintenance (OAM) 20 within the MPLS Transport Profile (MPLS-TP) describes how Maintenance 21 Entity Group Intermediate Points (MIPs) may be situated within 22 network nodes at the incoming and outgoing interfaces. 24 This document describes a way of forming OAM messages so that they 25 can be targeted at MIPs on incoming or MIPs on outgoing interfaces, 26 forwarded correctly through the forwarding engine, and handled 27 efficiently in node implementations where there is no distinction 28 between the incoming and outgoing MIP. 30 This document is a product of a joint Internet Engineering Task Force 31 (IETF) / International Telecommunication Union Telecommunication 32 Standardization Sector (ITU-T) effort to include an MPLS Transport 33 Profile within the IETF MPLS and PWE3 architectures to support the 34 capabilities and functionalities of a packet transport network. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 17, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5 74 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 76 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Previously considered solutions . . . . . . . . . . . 13 84 A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 A.2. A separate channel type for the out-MIP . . . . . . . . . 14 86 A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 14 87 A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 The Framework for Operations, Administration and Maintenance (OAM) 93 within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM 94 Framework, [RFC6371]) distinguishes two configurations for 95 Maintenance Entity Group Intermediate Points (MIPs) on a node. It 96 defines per-node MIPs and per-interface MIPs, where a per-node MIP is 97 a single MIP per node in an unspecified location within the node and 98 per-interface MIPs are two (or more) MIPs per node on both sides of 99 the forwarding engine. 101 In-band OAM messages are sent using the Generic Associated Channel 102 (G-ACh) [RFC5586]. OAM messages for the transit points of 103 pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using 104 the expiration of the MPLS shim header time-to-live (TTL) field. OAM 105 messages for the end points of PWs and LSPs are simply delivered as 106 normal. 108 OAM messages delivered to end points or transit points are 109 distinguished from other (data) packets so that they can be processed 110 as OAM. In LSPs, the mechanism used is the presence of the Generic 111 Associated Channel Label (GAL) in the Label Stack Entry (LSE) under 112 the top LSE [RFC5586]. In PWs, the mechanism used is the presence of 113 the PW Associated Channel Header (PWACH) [RFC4385] or the presence of 114 a GAL [RFC6423]. 116 In case multiple MIPs are present on a single node, these mechanisms 117 alone provide no way to address one particular MIP out of the set of 118 MIPs. 120 This document describes a way of forming OAM messages so that they 121 can be targeted at incoming MIPs and outgoing MIPs, forwarded 122 correctly through the forwarding engine, and handled efficiently in 123 node implementations where there is no distinction between the 124 incoming and outgoing MIP. 126 The material in this document is provided for discussion within the 127 MPLS-TP community in the expectation that this idea or some similar 128 mechanisms will be subsumed into a more general MPLS-TP OAM document. 130 This document is a product of a joint Internet Engineering Task Force 131 (IETF)/International Telecommunication Union Telecommunication 132 Standardization Sector (ITU-T) effort to include an MPLS Transport 133 Profile within the IETF MPLS and PWE3 architecture to support the 134 capabilities and functionalities of a packet transport network. 136 Note that the acronym "OAM" is used in conformance with [RFC6291]. 138 2. Requirements notation 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Terminology 146 In this document we use the term in-MIP (incoming MIP) to refer to 147 the MIP which processes OAM messages before they pass through the 148 forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM 149 messages after they have passed the forwarding engine of the node. 150 The two together are referred to as internal MIPs. 152 4. Summary of the Problem Statement 154 Figure 1 shows an abstract functional representation of an MPLS-TP 155 node. It is decomposed as an incoming interface, a forwarding engine 156 (FW), and an outgoing interface. As per the discussion in [RFC6371], 157 MIPs may be placed in each of the functional interface components. 159 ------------------------ 160 |----- -----| 161 | MIP | | MIP | 162 | | ---- | | 163 ----->-| In |->-| FW |->-| Out |->---- 164 | i/f | ---- | i/f | 165 |----- -----| 166 ------------------------ 168 Figure 1: Abstract Functional Representation of an MPLS-TP Node 170 Several distinct OAM functions are required within this architectural 171 model for both PWs and LSPs such as: 173 o CV between a MEP and a MIP 174 o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing 175 MIPs 176 o data-plane loopback configuration at a MIP 177 o diagnostic tests 179 The MIPs in these OAM functions may equally be the MIPs at the 180 incoming or outgoing interfaces. 182 Per-interface MIPs have the advantage that they enable a more 183 accurate localization and identification of faults and diagnostic 184 test. In particular, the identification of whether a problem is 185 located between nodes or on a particular node and where on that node 186 is greatly enhanced. For obvious reasons, it is important to narrow 187 the cause of a fault down quickly to initiate a timely, and well- 188 directed maintenance action to resume normal network operation. 190 The following two figures illustrate the fundamental difference of 191 using per-node and per-interface MEPs and MIPs for OAM. Figure 2 192 depicts OAM using per-node MIPs and MEPs. For reasons of exposition 193 we pick a location for the MIPs on the nodes but the standard does 194 not mandate the exact location for the per-node model. Figure 3 on 195 the other hand shows the same basic network but for OAM operations 196 per-interface maintenance points are configured. 198 Customer| Operator's administrative | Customer 199 Domain | Domain | Domain 200 ------> |<--------------------------------------->| <------ 201 CE1 | PE1 P1 PE2 | CE2 202 | <--------> <--------> <--------> | 203 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 204 | | | | | | | | | | | | | | | | | | | | | | | | 205 | | | | | | | | | | | | | | | | | | | | | | | | 206 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 207 | In FW Out In FW Out In FW Out | 208 | | 209 FWD LSP | o-------------------------- > | 210 | V-------------*-------------V | 211 | MEP1 MIP1 MEP2 | 212 BWD LSP | <---------------------------o | 213 | V-------------*-------------V | 214 | MEP1' MIP1' MEP2'| 215 (S1)<============> 216 (S2)<==========================> 218 Figure 2: Example of OAM relying on per-node MIPs and MEPs 220 To illustrate the difference between these two modes of operation, we 221 use fault detection as an example. Consider the case where the 222 client traffic between CE1 and CE2 experiences a fault. Also assume 223 that an on-demand CV test between PE1 and PE2 was successful. The 224 scenario in Figure 2 therefore leaves the forwarding engine (FW) of 225 PE2, the out-going interface of PE2, the transmission line between 226 PE2 and CE2 or CE2 itself as a potential location of the fault as on- 227 demand CV can only be performed on segment S2. 229 The per-interface model in Figure 3 allows more fine-grained OAM 230 operations to be performed. At first, CV on segment S'4 and in 231 addition CV on segment S'5 can help to rule out e.g. the forwarding 232 engine of PE2. This is of course only a single example, and other 233 OAM functions and scenarios are trivially conceivable. The basic 234 message is that with the per-interface OAM model, an operator can 235 configure smaller segments on a transport path to which OAM 236 operations apply. This enables a more fine-grained scoping of OAM 237 operations such as fault localization and performance monitoring 238 which gives operators better information to deal with adverse 239 networking conditions. 241 Customer Operator's administrative Customer 242 Domain Domain Domain 243 ------->|<--------------------------------------->|<------ 244 CE1 | PE1 P1 PE2 | CE2 245 | <--------> <--------> <--------> | 246 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 247 | | | | | | | | | | | | | | | | | | | | | | | | 248 | | | | | | | | | | | | | | | | | | | | | | | | 249 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 250 | In FW Out In FW Out In FW Out | 251 | | 252 FWD LSP | o-----------------------------------> | 253 | V-------*------*------*-----*-------V | 254 | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| 255 | | 256 BWD LSP | <-----------------------------------o | 257 | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| 258 (S'1)<======> 259 (S'2)<=============> 260 (S'3)<====================> 261 (S'4)<==========================> 262 (S'5)<==================================> 264 Figure 3: Example of OAM relying on per-interface MIPs and MEPs 266 5. Overview 268 In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP 269 LSPs and MPLS-TP PWs, respectively. OAM messages for the transit 270 points of PWs or LSPs are delivered using the expiration of the time- 271 to-live (TTL) field in the top LSE of the MPLS packet header. OAM 272 messages for the end points of PWs and LSPs are simply delivered as 273 normal. 275 OAM messages delivered to end points or transit points are 276 distinguished from other (data) packets so that they can be processed 277 as OAM. In LSPs, the mechanism used is the presence of the Generic 278 Associated Channel Label (GAL) in the LSE under the top LSE 279 [RFC5586]. In PWs, the mechanism used is the presence of the PW 280 Associated Channel Header [RFC4385] or the presence of a GAL 281 [RFC6423]. 283 Any solution for sending OAM to the in and out-MIPs must fit within 284 these existing models of handling OAM. 286 Additionally, many MPLS-TP nodes contain an optimization such that 287 all queuing and the forwarding function is performed at the incoming 288 interface. The abstract functional representation of such a node is 289 shown in Figure 4. As shown in the figure, the outgoing interfaces 290 are minimal and for this reason it may not be possible to include MIP 291 functions on those interfaces. This is in particular the case for 292 existing deployed implementations. 294 Any solution that attempts to send OAM to the outgoing interface of 295 an MPLS-TP node must not cause any problems when such implementations 296 are present. 298 ------------------ 299 |------------ | 300 | MIP | | 301 | ---- | | 302 ----->-| In | FW | |-->--|->--- 303 | i/f ---- | | 304 |------------ | 305 ------------------ 307 Figure 4: Abstract Functional Representation of an Optimized MPLS-TP 308 Node 310 Lastly, OAM must operate on MPLS-TP nodes that are branch points on 311 point-to-multipoint (P2MP) trees. That means that it must be 312 possible to target individual outgoing MIPs as well as all outgoing 313 MIPs in the abstract functional representation shown in Figure 5, as 314 well as to handle the optimized P2MP node as shown in Figure 6. 316 -------------------------- 317 | -----| 318 | | MIP | 319 | ->-| |->---- 320 | | | Out | 321 | | | i/f | 322 | | -----| 323 |----- | -----| 324 | MIP | ---- | | MIP | 325 | | | |- | | 326 ----->-| In |->-| FW |--->-| Out |->---- 327 | i/f | | |- | i/f | 328 |----- ---- | -----| 329 | | -----| 330 | | | MIP | 331 | | | | 332 | ->-| Out |->---- 333 | | i/f | 334 | -----| 335 -------------------------- 337 Figure 5: Abstract Functional Representation of an MPLS-TP Node 338 Supporting P2MP 340 ------------------ 341 | ->-|->---- 342 | | | 343 |------------ | | 344 | | | | 345 | MIP ---- | | | 346 | | | |- | 347 ----->-| In | FW | |--->-|->---- 348 | i/f | | |- | 349 | ---- | | | 350 | | | | 351 |------------ | | 352 | | | 353 | ->-|->---- 354 ------------------ 356 Figure 6: Abstract Functional Representation of an Optimized MPLS-TP 357 Node Supporting P2MP 359 In summary, the solution for OAM message delivery must support the 360 following features: 362 o Forwarding of OAM packets exactly as data packets. 363 o Delivery of OAM messages to the correct MPLS-TP node. 364 o Delivery of OAM instructions to the correct MIP within an MPLS-TP 365 node. 366 o Packet inspection at the incoming and outgoing interfaces must be 367 minimized. 369 Note that although this issue appears superficially to be an 370 implementation matter local to an individual node, the format of the 371 message needs to be standardised so that: 373 o A MEP can correctly target the outgoing MIP of a specific MPLS-TP 374 node. 375 o A node can correctly filter out any OAM messages that were 376 intended for its upstream neighbor's outgoing MIP, but which were 377 not handled there because the upstream neighbor is an optimized 378 implementation. 380 Note that the last bullet point describes a safety net and an 381 implementation should avoid that this situation ever arises. 383 5.1. Rejected Partial Solution 385 A rejected solution is depicted in Figure 7. All data and non-local 386 OAM is handled as normal. Local OAM is intercepted at the incoming 387 interface and delivered to the MIP at the incoming interface. If the 388 OAM is intended for the incoming MIP it is handled there with no 389 issue. If the OAM is intended for the outgoing MIP it is forwarded 390 to that MIP using some internal messaging system that is 391 implementation-specific. 393 ------------------------ 394 |----- -----| 395 local OAM ----->-| MIP |----->------| MIP | 396 | | ---- | | 397 data =====>=| In |=>=| FW |=>=| Out |=>==== data 398 non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM 399 |----- ---- -----| 400 ------------------------ 402 Figure 7: OAM Control Message Delivery Bypassing the Forwarding 403 Engine 405 This solution is fully functional for the incoming MIP. It also 406 supports control of data loopback for the outgoing MIP, and can 407 adequately perform some OAM features such as interface identity 408 reporting at the outgoing MIP. 410 However, because the OAM message is not forwarded through the 411 forwarding engine, this solution cannot correctly perform OAM 412 loopback, connectivity verification, LSP tracing, or performance 413 measurement. 415 6. Per-Interface MIP Message Handling 417 The preferred solution to per-interface MIP message handling is 418 presented in this section. The appendix of this document contains a 419 few solutions that the authors have discarded which have been left in 420 the document for informational purposes. 422 Per-interface MIP addressing should not require changes to existing 423 OAM solutions. Therefore, identification information that specific 424 OAM mechanisms already contain should be (re-)used to address the 425 MIPs on a node. Upcoming OAM solutions therefore need to 426 individually make sure that enough of that information is present to 427 support the per-interface model. In particular, the MIP identifiers 428 as described in [RFC6370] or [I-D.ietf-mpls-tp-itu-t-identifiers] 429 need to be present in OAM messages. [RFC6370] and 430 [I-D.ietf-mpls-tp-itu-t-identifiers] define formats that support the 431 per-interface model which is sufficient for this purpose. In 432 addition, some constraints must be agreed on. 434 Regarding the features we required earlier from a solution this 435 translates to: 437 o Feature 1: "Forwarding of OAM packets exactly as data packets" 438 * Using existing identification information in OAM messages for 439 internal-MIP addressing has no implications on the way data 440 packets and non-local OAM packets are handled as the label 441 stack is not altered for the purpose of MIP addressing. Also 442 the TTL processing remains untouched. This means that the TTL 443 will expire on the ingress. 444 o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node" 445 * The node itself is addresses using TTL expiry, comparable to 446 the per-node MIP addressing case. 447 o Feature 3: "Delivery of OAM instructions to the correct MIP within 448 an MPLS-TP node" 449 * The identification information containted in the OAM packet is 450 used to tell whether the packet is for the in-MIP or the out- 451 MIP. 452 o Feature 4: "Packet inspection at the incoming and outgoing 453 interfaces must be minimized" 454 * Additional packet inspection compared to the per-node case is 455 inevitably needed. The identification information indside the 456 OAM message needs to be considered in order to deliver the 457 packet to the correct MIP. 459 The above illustrates how in principle per-MIP addressing operates. 460 Another issue of concern was the correct filtering of OAM messages at 461 a downstream node, that were intended for an upstream node's outgoing 462 MIP. Since OAM messages expire on the ingress, the legacy upstream 463 neighbor will actually process the packet. Since the identification 464 information is not correct, the node should discard that packet. 465 Leakage should therefore not occur. 467 Note: For a static MPLS-TP LSP and PWs, there may be the case that 468 the MIP identifiers along the path are not known at the head-end 469 prior to performing route tracing. The resolution of this issue will 470 be covered in a future version of this document. 472 7. Security Considerations 474 OAM security is discussed in [RFC6371] and security aspects specific 475 to MPLS-TP in general are outlined in 476 [I-D.ietf-mpls-tp-security-framework]. 478 OAM can provide useful information for detecting and tracing security 479 attacks. 481 OAM can also be used to illicitly gather information or for denial of 482 service attacks and other types of attack. Implementations therefore 483 are required to offer security mechanisms for OAM. Deployments are 484 strongly advised to use such mechanisms. 486 Mixing of per-node and per-interface OAM on a single node is not 487 advised as OAM message leakage could be the result. 489 8. IANA Considerations 491 This revision of this document does not make any requests of IANA. 493 9. Acknowledgments 495 The authors gratefully acknowledge the substantial contributions of 496 Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros 497 for interesting input to this document through discussions. 499 10. References 500 10.1. Normative References 502 [I-D.ietf-mpls-tp-itu-t-identifiers] 503 Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP 504 Identifiers Following ITU-T Conventions", 505 draft-ietf-mpls-tp-itu-t-identifiers-03 (work in 506 progress), March 2012. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 512 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 513 Use over an MPLS PSN", RFC 4385, February 2006. 515 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 516 Associated Channel", RFC 5586, June 2009. 518 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 519 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 521 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 522 Maintenance Framework for MPLS-Based Transport Networks", 523 RFC 6371, September 2011. 525 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 526 Generic Associated Channel Label for Pseudowire in the 527 MPLS Transport Profile (MPLS-TP)", RFC 6423, 528 November 2011. 530 10.2. Informative References 532 [I-D.ietf-mpls-tp-security-framework] 533 Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP 534 Security Framework", 535 draft-ietf-mpls-tp-security-framework-01 (work in 536 progress), May 2011. 538 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 539 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 540 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 542 Appendix A. Previously considered solutions 543 A.1. GAL TTL 545 The use of the GAL TTL has been considered before. This transforms 546 the GAL TTL into some kind of node-internal TTL, i.e. a GAL TTL of 0 547 would address the in-MIP and a GAL TTL of 1 the out-MIP. The main 548 drawback of this approach is that it (as of now at least) would only 549 be applicable to LSPs and not to PWs. 551 A.2. A separate channel type for the out-MIP 553 This approach would require two channel types for the exact same OAM 554 type, one to address the in-MIP and another one to address the out- 555 MIP. This seems like a waste of channel types, however it appears 556 that there is no expected shortage of them. Legacy nodes will 557 discard the packets as the new channel types are unkonwn. Having two 558 channel types for the same OAM however feels a bit hacky. 560 A.3. Decrement TTL once per MIP 562 Decrementing the TTL more than once per node seems a "natural" way of 563 per-interface MIP addressing since TTL expiry is all that is needed 564 for the per-node MIP case. In other words, by decrementing the TTL 565 once per MIP (twice per node) no extra mechanism is needed to solve 566 the internal MIP addressing problem. The solution has been discarded 567 since it does not represent the typical mode of network operation 568 today (since also for normal data packets the TTL needs to be 569 decremented more than once). 571 A.4. Using an ACH reserved bit 573 The ACH contains eight reserved bits which currently all need to be 574 set to zero and ignored on reception. One bit could be reserved as 575 an out-MIP address flag. In other words, in case the bit is set, the 576 out-MIP is addressed. An advantage of this approach is that there is 577 no semantic overlap with anything that exists today, as the bits are 578 not in use. Existing implementations need to ignore it. That means 579 that existing implementations will process the OAM packets at the in- 580 MIP/per-node MIP. Identification information is still needed however 581 for the P2MP case as a single bit is not enough. 583 Authors' Addresses 585 Adrian Farrel 586 Juniper Networks 588 Email: adrian@olddog.co.uk 589 Hideki Endo 590 Hitachi, Ltd. 592 Email: hideki.endo.es@hitachi.com 594 Rolf Winter 595 NEC 597 Email: rolf.winter@neclab.eu 599 Yoshinori Koike 600 NTT 602 Email: koike.yoshinori@lab.ntt.co.jp 604 Manuel Paul 605 Deutsche Telekom 607 Email: Manuel.Paul@telekom.de