Subject: [mpls] Some comments on draft-yasukawa-mpls-p2mp-oam-reqs-00.txt

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 20 Aug 2005 13:04:40 +0200

looking at this doc some comments

in section 4.2 "These functions should allow an operator to stipulate 
the maximum amount of time to wait until responses are heard from all 
points along the path, as well a cut-offs for the number of paths tested."

-> not sure to understand what "all points" means in this context, also 
if you don't receive an answer what are you going to do (is not btw a 
situation which is susceptible to occur ?)

in section 4.3 " Note that path characterization should lead to the 
operator being able to deduce the full tree for a P2MP LSP. To achieve 
this, it is important that the branching points on that tree are clearly
identified."

-> does this sentence means that a mechanism should be made available to 
poll for specific branching point liveliness ?

in section 4.6 "As described in [MPLS-OAM], network elements MUST 
provide alarm suppression and aggregation to prevent the generation of 
superfluous alarms within or across network layers."

-> would it be possible to be a bit more specific in the P2MP context 
what does aggregation of alarms means ? (and which alarms ?) to which 
"network layers" is this sentence referring to ? in general, i find this 
section difficult to parse

in section 4.8 "As described in [MPLS-OAM], these procedures
will detect a broad range of defects, and SHOULD be operable where
Since MPLS P2MP LSPs span multiple routing areas, or multiple Service 
Provider domains."

-> would it be possible to clarify the beginning of the sentence refers 
to failure detection, the last part about multi-area/multi-AS ?

in section 4.11 "Fundamental to understanding traffic flows within a 
network that supports P2MP LSPs will be the knowledge of where the 
branch points exist within the network."

-> do you assume that the tree decomposition is unique ? it seems to me 
you need to also have the branch point relationship - clarifying what 
the term "where" means would help here

Network Working Group                                Seisho Yasukawa
Internet Draft                                       NTT Corp
Expires: December 2005
                                                     Adrian Farrel
                                                     Old Dog Consulting

                                                     Daniel King
                                                     DNNI Ltd.

                                                     Thomas D. Nadeau
                                                     Cisco Systems, Inc.

                                                     June 2005

        OAM Requirements for Point-to-Multipoint MPLS Networks

             draft-yasukawa-mpls-p2mp-oam-reqs-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   Multi-Protocol Label Switching (MPLS) has been extended to encompass
   point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with
   point-to-point MPLS LSPs the requirement to detect, handle and
   diagnose control and dataplane defects is critical.

   For operators deploying services based on P2MP MPLS LSPs the
   detection and specification of how to handle those defects is
   important because such defects may not only affect the fundamental
   of an MPLS network, but also because they MAY impact service level
   specification commitments for customers of their network.

Yasukawa et al.                                                 [Page 1]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   This document describes requirements for user and data plane
   operations and management for P2MP MPLS LSPs. These requirements
   apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic
   Engineered (TE) LSPs and multicast LSPs.

Table of Contents

   1. Introduction .................................................. 2
   2. Terminology ................................................... 3
     2.1 Conventions ................................................ 3
     2.2 Terminology ................................................ 3
     2.3 Acronyms ................................................... 3
   3. Motivations ................................................... 3
   4. General Requirements .......................................... 4
     4.1 Detection of Label Switch Path Defects ..................... 4
     4.2 Diagnosis of a Broken Label Switch Path .................... 5
     4.3 Path characterization ...................................... 5
     4.4 Service Level Agreement Measurement ........................ 5
     4.5 Frequency of OAM Execution ................................. 6
     4.6 Alarm Suppression, Aggregation and Layer Coordination ...... 6
     4.7 Support for OAM Interworking for Fault Notification ........ 6
     4.8 Error Detection and Recovery ............................... 7
     4.9 Standard Management Interfaces ............................. 7
     4.10  Detection of Denial of Service Attacks ................... 7
     4.11 Per-LSP Accounting Requirements ........................... 8
   5. Security Considerations ....................................... 8
   6. IANA Considerations ........................................... 8
   7. References .................................................... 9
     7.1 Normative References ....................................... 9
     7.2 Informative References ..................................... 9
   8. Acknowledgements ............................................. 10
   9. Authors' Addresses ........................................... 10
   10. Intellectual Property Statement ............................. 10
   11. Full Copyright Statement .................................... 11

1. Introduction

   This document describes requirements for user and data plane
   operations and management (OAM) for point-to-multipoint (P2MP)
   Multi-Protocol Label Switching (MPLS). These requirements have been
   gathered from network operators who have extensive experience
   deploying MPLS networks and from operators who are considering
   deploying P2MP MPLS networks. This draft specifies OAM requirements
   for P2MP MPLS, as well as for applications of P2MP MPLS.

   These requirements apply to all forms of P2MP MPLS LSPs, and include
   P2MP Traffic Engineered (TE) LSPs [P2MP-SIG-REQ] and [P2MP-RSVP], as
   well as multicast LDP LSPs [P2MP-LDP] and [MCAST-LDP].

Yasukawa et al.                                                 [Page 2]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   Note that the requirements for OAM for P2MP MPLS build heavily on the
   requirements for OAM for point-to-point MPLS. These latter are
   described in [MPLS-OAM] and are not repeated in this document.

2. Terminology

2.1 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2 Terminology

   Definitions of key terms for MPLS OAM are found in [MPLS-OAM] and
   the reader is assumed to be familiar with those definitions which
   are not repeated here.

   [P2MP-SIG-REQ] includes some important definitions and terms for use
   within the context of P2MP MPLS. The reader should be familiar with
   at least the terminology section of that document.

2.3 Acronyms

   The following list of acronyms is a repeat of common acronyms defined
   in many other documents, and is provided here for convenience.

   CE:   Customer Edge
   DoS:  Denial of service
   ECMP: Equal Cost Multipath
   LDP:  Label Distribution Protocol
   LSP:  Label Switch Path
   LSR:  Label Switch Router
   OAM:  Operations and Management
   OA&M: Operations, Administration and Maintenance.
   RSVP: Resource reSerVation Protocol
   P2MP: Point-to-Multipoint
   SP:   Service Provider
   TE:   Traffic Engineering

3. Motivations

   OAM for MPLS networks has been established as a fundamental
   requirement both through operational experience and through
   its documentation in numerous Internet drafts. Many such
   documents (for example, [LSP-PING], [RFC3812], [RFC3813], [RFC3814],
   and [RFC3815]) developed specific solutions to individual issues or
   problems. Coordination of the full OAM requirements for MPLS was
   achieved by [MPLS-OAM] in recognition of the fact that the previous
   piecemeal approach could lead to inconsistent and inefficient
   applicability of OAM techniques across the MPLS architecture, and

Yasukawa et al.                                                 [Page 3]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   might require significant modifications to operational procedures and
   systems in order to provide consistent and useful OAM functionality.

   This document builds on these realizations and extends the
   statements of MPLS OAM requirements to cover the new area of P2MP
   MPLS. That is, this document captures the requirements for P2MP
   MPLS OAM in advance of the development of specific solutions.

   Nevertheless, at the time of writing, some effort had already
   been expended to extend existing MPLS OAM solutions to cover P2MP
   MPLS (for example, [P2MP-LSP-PING]). While this approach of extending
   existing solutions may be reasonable, in order to ensure a consistent
   OAM framework it is necessary to articulate the full set of
   requirements in a single document. This will facilitate a uniform set
   of MPLS OAM solutions spanning multiple MPLS deployments and
   concurrent applications.

4. General Requirements

   The general requirements described in this section are closely
   similar to those described for point-to-point MPLS in [MPLS-OAM].
   The subsections below do not repeat material from [MPLS-OAM], but
   simply give references to that document.

   However, where the requirements for P2MP MPLS OAM differ from or are
   more extensive than those expressed in [MPLS-OAM], additional text is
   supplied.

   In general, it should be noted that P2MP LSPs introduce a scalability
   issue that is not present in point-to-point MPLS. That is, an
   individual P2MP LSP will have more than one egress and the path to
   those egresses will very probably not be linear (for example, it may
   have a tree structure). Since the number of egresses for a single
   P2MP LSP is unknown and not bounded by any small number, it follows
   that all mechanisms defined for OAM support must scale well with the
   number of egresses and the complexity of the path of the LSP.
   Mechanisms that are able to deal with individual egresses will scale
   no worse than similar mechanisms for point-to-point LSPs, but it is
   desirable to develop mechanisms that are able to leverage the fact
   that multiple egresses are associated with a single LSP, and so
   achieve better scaling.

4.1 Detection of Label Switch Path Defects

   The ability to detect defects in a broken Label Switch Path
   (LSP) SHOULD not require manual hop-by-hop troubleshooting of
   each LSR used to switch traffic for that P2MP LSP.  Any
   solutions should either extend or work in close conjunction
   with existing solutions developed for point-to-point MPLS, such as
   those specified in [LSP-PING]. This will leverage existing software
   and hardware deployments.

Yasukawa et al.                                                 [Page 4]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

4.2 Diagnosis of a Broken Label Switch Path

   The ability to diagnose a broken P2MP LSP and to isolate the
   failed component (i.e., link or node) in the path is required.
   These functions include a path connectivity test that
   can test all branches of a P2MP LSP for reachability, as
   well as a path tracing function.  These functions should
   allow an operator to stipulate the maximum amount of time to
   wait until responses are heard from all points along the
   path, as well a cut-offs for the number of paths tested.

   Any mechanism developed to perform these functions are subject to
   the scalability concerns expressed in section 4.

4.3 Path Characterization

   The path characterization function is the ability to reveal details
   of LSR forwarding operations for P2MP LSPs. These details can then
   be compared later during subsequent testing relevant to OAM
   functionality.  Therefore, LSRs supporting P2MP LSPs MUST
   provide mechanisms that allow operators to interogate and
   characterize P2MP paths.

   Since P2MP paths are more complex than the paths of point-to-point
   LSPs, the scaling concerns expressed in section 4 apply.

   Note that path characterization should lead to the operator being
   able to deduce the full tree for a P2MP LSP. To achieve this, it is
   important that the branching points on that tree are clearly
   identified.

4.4 Service Level Agreement Measurement

   Mechanisms are required to measure the diverse aspects of Service
   Level Agreements for services that utlize P2MP LSPs. The aspects are
   listed in [MPLS-OAM].

   Service Level Agreements are often measured in terms of the quality
   and rate of data delivery. In the context of P2MP MPLS, data is
   delivered to multiple egress nodes. The mechanisms MUST, therefore,
   be capable of measuring the aspects of Service Level Agreements as
   they apply to each of the egress points to a P2MP LSP. At the same
   time, in order to diagnose issues with meeting Service Level
   Agreements, mechanisms SHOULD be provided to measure the aspects of
   the agreements at key points within the network such as at branch
   nodes on the P2MP tree.

Yasukawa et al.                                                 [Page 5]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

4.5 Frequency of OAM Execution

   As stipulated in [MPLS-OAM], the operator MUST have the flexibility
   to configure OAM parameters to meet their specific operational
   requirements. This requirement is potentially more important in P2MP
   deployments where the effects of the execution of OAM functions can
   be potentially much greater than in a non-P2MP configuration. For
   example, a mechanism that causes each egress of a P2MP LSP to respond
   could result in a large burst of responses for a single OAM request.

   Therefore, solutions produced SHOULD NOT impose any fixed limitations
   on the frequency of the execution of any OAM functions.

4.6 Alarm Suppression, Aggregation and Layer Coordination

   As described in [MPLS-OAM], network elements MUST provide alarm
   suppression and aggregation to prevent the generation of superfluous
   alarms within or across network layers. The same time constraint
   issues identified in [MPLS-OAM] also exist for P2MP LSPs.

   A P2MP LSP also brings the possiblity of a single fault causing a
   larger number of alarms than for a point-to-point LSP. This can
   happen because there are a larger number of downstream LSRs (for
   example, a larger number of egresses). The resultant multiplier in
   the number of alarms could cause swamping of the alarm management
   systems to which the alarms are reported, and serves as a multiplier
   to the number of potentially duplicate alarms raised by the network.

   Alarm aggregation or limitation techniques MUST be applied within any
   solution, or be available within an implementation, so that this
   scaling issue can be reduced.

4.7 Support for OAM Interworking for Fault Notification

   [MPLS-OAM] specifies that an LSR supporting the interworking of
   one or more networking technologies over MPLS MUST be able to
   translate an MPLS defect into the native technology's error
   condition.  This also applies to any LSR supporting P2MP
   LSPs.  However, careful attention to the requirements for
   alarm suppression stipulated therein and in section 4.6 SHOULD
   be observed.

   Note that the time constraints for fault notification and alarm
   propagation impact upon the solutions that might be applied to the
   scalability problem inherent in certain OAM techniques applied to
   P2MP LSPs. For example, a solution to the issue of a large number
   of egresses all responding to some form of probe request at the
   same time, might be to make the probes less frequent - but this
   might impact on the ability to detect and/or report faults.

Yasukawa et al.                                                 [Page 6]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   Where fault notification to the egress is required, there is the
   possiblity that a single fault will give rise to multiple
   notifications, one to each egress node of the P2MP that is downstream
   of the fault. Any mechanisms MUST manage this scaling issue while
   still continuing to deliver fault notifications in a timely manner.

   Where fault notification to the ingress is required, the mechanisms
   MUST ensure that the notification identifies the egress nodes of the
   P2MP LSP that are impacted (that is, those downstream of the fault)
   and does not falsely imply that all egress nodes are impacted.

4.8 Error Detection and Recovery

   Recovery from a fault by a network element can be facilitated by
   MPLS OAM procedures. As described in [MPLS-OAM], these procesures
   will detect a broad range of defects, and SHOULD be operable where
   Since MPLS P2MP LSPs span multiple routing areas, or multiple Service
   Provider domains.

   The same requirements as those expressed in [MPLS-OAM] with respect
   to automatic repair and operator intervention ahead of customer
   detection of faults apply to P2MP LSPs.

4.9 Standard Management Interfaces

   The wide-spread deployment of MPLS requires common information
   modeling of management and control of OAM functionality. This is
   reflected in the the integration of standard MPLS-related MIBs
   [RFC3813][RFC3812][RFC3814][RFC3815] for fault, statistics
   and configuration management. These standard interfaces provide
   operators with common programmatic interface access to
   operations and management functions and their status.  These

   The standard MPLS-related MIB modules [RFC3812], [RFC3813],
   [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to
   support P2MP LSPs, the associated OAM functions on these LSPs, and
   the applications that utlize P2MP LSPs. Extending them will
   facillitate the reuse of existing management software both in LSRs
   and in management systems. In cases where the existing MIB modules
   cannot be extended, then new MIB modules MUST be created.

4.10  Detection of Denial of Service Attacks

   The ability to detect denial of service (DoS) attacks against the
   data or control planes which signal P2MP LSPs MUST be part of
   any security management related to MPLS OAM tools or techniques.

Yasukawa et al.                                                 [Page 7]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

4.11 Per-LSP Accounting Requirements

   In an MPLS network where P2MP LSPs are in use, Service Providers can
   measure traffic from an LSR to the egress of the network using some
   MPLS-related MIB modules (see section 4.9), for example. Other
   interfaces MAY exist as well and enable the creation of traffic
   matricies so that it is possible to know how much traffic is
   traveling from where to where within the network.

   Analysis of traffic flows to produce a traffic matrix is more
   complicated where P2MP LSPs are deployed becasue there is no simple
   pairing relationship between an ingress and a single egress.
   Fundamental to understanding traffic flows within a network that
   supports P2MP LSPs will be the knowledge of where the branch points
   exist within the network. Traffic flow and accounting tools MUST take
   this fact into account.

5. Security Considerations

   This document introduces no new security issues compared with
   [MPLS-OAM]. It is worth highlighting, however, that any tool designed
   to satisfy the requirements described in this document MUST include
   provisions to prevent its unauthorized use. Likewise, these tools
   MUST provide a means by which an operator can prevent denial of
   service attacks if those tools are used in such an attack.
   LSP mis-merging is described in [MPLS-OAM] where it is pointed out
   that it has security implications beyond simply being a network
   defect. It needs to be stressed that it is in the nature of P2MP
   traffic flows that any erroneous delivery (such as caused by LSP
   mis-merging) is likely to have more far reaching conseuqences since
   the traffic will be mis-delivered to multiple receivers.

   As with previous OAM function described in [MPLS-OAM], the
   performance of diagnostic functions and path characterization may
   involve the extraction of a significant amount of information about
   network construction. The network operator MAY consider this
   information private and wish to take steps to secure it, but further,
   the volume of this information may be considered as a threat to the
   integrity of the network if it is extacted in bulk. This issue may be
   greater in P2MP MPLS becuase of the potential for a large number of
   receivers on a single LSP and the consequent extensive path of the
   LSP.

6. IANA Considerations

   This document creates no new requirements on IANA namespaces.

Yasukawa et al.                                                 [Page 8]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

7. References

7.1 Normative References

   [MPLS-OAM]       T. Nadeau, Allan D., et al. Allan D.,
                    "OAM Requirements for MPLS Networks",
                    draft-ietf-mpls-oam-requirements-05.txt,
                    December 2004

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2 Informative References

   [LSP-PING]       Kompella, K., and Swallow, G., (Editors), "Detecting
                    MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping,
                    work in progress.

   [MCAST-LDP]      Wijnands, IJ., et al., " Multicast Extensions for
                    LDP", draft-wijnands-mpls-ldp-mcast-ext, work in
                    progress.

   [P2MP-LDP]       Minei, I., et al., "Label Distribution Protocol
                    Extensions for Point-to-Multipoint Label Switched
                    Paths", draft-minei-mpls-ldp-p2mp, work in progress.

   [P2MP-LSP-PING]  Yasukawa, S., Farrel, A., Ali, Z., and Fenner, B.,
                    "Detecting Data Plane Failures in
                    Point-to-Multipoint MPLS Traffic Engineering -
                    Extensions to LSP Ping",
                    draft-yasukawa-mpls-p2mp-lsp-ping, work in progress.

   [P2MP-RSVP]      Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
                    "Extensions to RSVP-TE for Point to Multipoint TE
                    LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in
                    progress.

   [P2MP-SIG-REQ]   Yasukawa, S. (Editor), "Signaling Requirements for
                    Point to Multipoint Traffic Engineered MPLS LSPs",
                    draft-ietf-mpls-p2mp-sig-requirement, work in
                    progress.

   [RFC3812]        Srinivasan, C., Viswanathan, A. and T.
                    Nadeau, "MPLS Traffic Engineering Management
                    Information Base Using SMIv2", RFC3812, June 2004.

   [RFC3813]        Srinivasan, C., Viswanathan, A. and T.
                    Nadeau, "MPLS Label Switch Router Management
                    Information Base Using SMIv2", RFC3813, June 2004.

Yasukawa et al.                                                 [Page 9]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   [RFC3814]        Nadeau, T., Srinivasan, C., and A.
                    Viswanathan, "Multiprotocol Label Switching
                    (MPLS) FEC-To-NHLFE (FTN) Management
                    Information Base", RFC3814, June 2004.

   [RFC3815]        Cucchiara, J., Sjostrand, H., and Luciani, J.,
                    "Definitions of Managed Objects for the
                    Multiprotocol Label Switching (MPLS), Label
                    Distribution Protocol (LDP)", RFC 3815, June 2004.

8. Acknowledgment

   The authors wish to acknowledge and thank the following
   individuals for their valuable comments to this document:

   TBD

9. Authors' Addresses

   Adrian Farrel
   Old Dog Consulting
   Phone: +44 (0) 1978 860944
   Email: [email-masked]

   Daniel King
   Darwinian Neural Network Industries Ltd.
   Phone: +44 (0)1249 665923
   Email: [email-masked]

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxboro, MA 01719
   Phone: +1-978-936-1470
   Email: [email-masked]

   Seisho Yasukawa
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585,
   Japan
   Phone: +81 422 59 4769
   Email: [email-masked]

10. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has

Yasukawa et al.                                                [Page 10]

Internet-Draft     draft-yasukawa-mpls-p2mp-oam-reqs-00.txt    June 2005

   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

11. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Yasukawa et al.                                                [Page 11]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 20 Aug 2005 21:02:00 +0100

Hi Dimitri,

Good of you to review...

> situation which is susceptible to occur ?)

Rereading this text I don't like it.

In answer to your question, it is exactly the case you raise that we are
trying to cover. That is, it must be possible for the operator (or
automated process) to stipulate a timeout after which the failure to see a
response shall be flagged as an error.

I don't like "as well a cut-offs for the number of paths tested." I think
this should say "branches" not "paths".

> poll for specific branching point liveliness ?

No.
It means that knowing the set of LSRs in a tree is not sufficient.
In order to construct the tree, it is important to know the order of LSPs
traversed and it must be possible to deduce the branch points.
Our point is that a diagnostic tool should collect information that is
easy to process rather than provide information that must be
post-processed with some complexity.
Finally, we should note that in some cases it may be possible for a branch
point to have two downstream branches (different labels) that run through
the same downstream LSR (downstream LSR is not branch capable in the data
plane) and that in this case, the branch point is not possible to deduce
from the sequence of LSRs, but must be clearly flagged.

I think we should capture some of these ideas in the I-D.

> section difficult to parse

I don't think we should clarify [MPLS-OAM] within this document, so many
of your questions need to be redirected to the authors of that I-D.

Yes, we should be careful with the term "alarm aggregation" because, while
[MPLS-OAM] means aggregation from layers, we can also have aggregation
from branches as set out in the paragraph after the one you quoted.

Please note that the whole I-D applies only to MPLS networks.

> to failure detection, the last part about multi-area/multi-AS ?

Hmmm. The text here seems to have been passed through our patent
Manglomatic (TM) text converter. It should read...
   Recovery from a fault by a network element can be facilitated by
   MPLS OAM procedures. As described in [MPLS-OAM], these procedures
   will detect a broad range of defects, and SHOULD be operable where
   MPLS P2MP LSPs span multiple routing areas, or multiple Service
   Provider domains.

However, I don't suppose this answers your point.
In fact, section 4.8 of [MPLS-OAM] talks about a broad range of defects
and the application to multiple routing areas and multiple SP domains, so
the text is intended to read as re-written above.

> the term "where" means would help here

OK. We can re-work this a bit.

Thanks,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 24 Aug 2005 08:49:41 +0200

hi adrian,

> response shall be flagged as an error.

ok - much clearer

> this should say "branches" not "paths".

shouldn't you also include a cut-off in terms of number of egresses then

> It means that knowing the set of LSRs in a tree is not sufficient.

ok - i understand the meaning behind the sentence - i would suggest to 
refine the notion of "path characterization" in this sentence (see 
section 4.3 of the P2P document) but more importantly to add "sequence 
of branching points" or equivalent

> post-processed with some complexity.

imho, this is a specific requirement that should normally be pointed as 
part of the text

> from the sequence of LSRs, but must be clearly flagged.

indeed, i would also suggest having an extended version of this for 
deducing more generic cross-over branching points

> I think we should capture some of these ideas in the I-D.

ok -

> of your questions need to be redirected to the authors of that I-D.

i understand your redirect and will do because the statement in the 
referenced doc is not indicated as being aggregation *from layers*

> from branches as set out in the paragraph after the one you quoted.

ok -

> Please note that the whole I-D applies only to MPLS networks.

noted

> the text is intended to read as re-written above.

ok - but how do you link this with the path characterization where there 
is a need to "being able to deduce the full tree for a P2MP LSP" are you 
sure across AS, or providers the full tree topology will be made possible ?

> OK. We can re-work this a bit.

ok - if you need some text/help let me know

> .