From mpls-bounces@lists.ietf.org Thu Dec 01 08:54:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhotM-0004xQ-VU; Thu, 01 Dec 2005 08:54:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXoc-0007pz-Bb for mpls@megatron.ietf.org; Wed, 30 Nov 2005 14:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02675 for ; Wed, 30 Nov 2005 14:39:43 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhY8u-00089n-4Y for mpls@ietf.org; Wed, 30 Nov 2005 15:01:31 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 2DCBCE000AD6 for ; Wed, 30 Nov 2005 19:40:06 +0000 (GMT) Received: from Puppy ([217.158.132.251] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 19:39:37 +0000 Message-ID: <036f01c5f5e6$45af80a0$d9849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 30 Nov 2005 19:41:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 30 Nov 2005 19:39:39.0166 (UTC) FILETIME=[CD5CE3E0:01C5F5E5] X-Spam-Score: 2.9 (++) X-Scan-Signature: 2b4cda74907316ffcea8d92cb58fd6bc Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Dec 2005 08:54:31 -0500 Cc: Subject: [mpls] Fw: [Gen-art] Marked-up copy of draft-ietf-mpls-p2mp-sig-requirement-03 (fwd) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I didn't notice a copy of this added to the MPLS archive, so here it is. These are Harald's detailed comments in addition to the high-level points already discussed. Seisho and I have been working on responses which will show up soon. Cheers, Adrian ---------- Forwarded Message ---------- Date: 22. november 2005 16:10 +0100 From: Harald Tveit Alvestrand To: gen-art@ietf.org, yasukawa.seisho@lab.ntt.co.jp, Bill Fenner , Alex Zinin , swallow@cisco.com, loa@pi.se Cc: INVALID_ADDRESS Subject: [Gen-art] Marked-up copy of draft-ietf-mpls-p2mp-sig-requirement-03 I'm sending this to the editor, the WG chairs, the ADs and the gen-art list (for archiving). Feel free to circulate further. Most of the comments are "make this clearer, please", or "I can't see that this adds anything - suggest deleting". The main technical comments are repeats from my other message. Comments are marked with HTA: Network Working Group Seisho Yasukawa (NTT) Internet Draft Editor Category: Informational Expiration Date: December 2005 June 2005 Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs 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 This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution specific details nor application specific requirements in this document. The requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of Layer two Switching (L2SC), Time Division Multiplexing (TDM), lambda and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. HTA: The last para reads oddly. I'd start it: The requirements presented in this document cover provisioning of the P2MP service on packet switched networks, Layer Two Switching..... S. Yasukawa (Ed.) [Page 1] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Table of Contents 1. Introduction ................................................... 3 1.1 Non-Objectives ............................................. 5 2. Definitions .................................................... 6 2.1 Acronyms ................................................... 6 2.2 Terminology ................................................ 6 2.2.1 Terminology for Partial LSPs .......................... 7 2.3 Conventions ................................................ 8 3. Problem Statement .............................................. 8 3.1 Motivation ................................................. 8 3.2. Requirements Overview ..................................... 9 4. Detailed requirements for P2MP TE extensions .................. 11 4.1 P2MP LSP ................................................. 11 4.2 P2MP explicit routing ..................................... 11 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes . 12 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms ................................................ 13 4.5 Fragmentation ............................................. 14 4.6 Failure Reporting and Error Recovery ...................... 14 4.7 Record route of P2MP TE LSP .............................. 15 4.8 Call Admission Control (CAC) and QoS Control mechanism of P2MP TE LSPs ........................................... 16 4.9 Variation of LSP Parameters ............................... 16 4.10 Re-optimization of P2MP TE LSPs .......................... 16 4.11 Tree Remerge ............................................. 17 4.12 Data Duplication ......................................... 18 4.13 IPv4/IPv6 support ........................................ 19 4.14 P2MP MPLS Label .......................................... 19 4.15 Routing advertisement of P2MP capability ................. 19 4.16 Multi-access LANs ........................................ 20 4.17 P2MP MPLS OAM ............................................ 20 4.18 Scalability .............................................. 20 4.18.1 Absolute Limits ..................................... 21 4.19 Backwards Compatibility .................................. 23 4.20 GMPLS .................................................... 23 4.21 P2MP Crankback routing ................................... 24 5. Security Considerations ....................................... 24 6. IANA Considerations ........................................... 25 7. Acknowledgements .............................................. 25 8. References .................................................... 25 8.1 Normative References ...................................... 25 8.2 Informational References .................................. 26 9. Editor's Address .............................................. 27 10. Authors' Addresses ........................................... 27 11. Intellectual Property Consideration .......................... 28 12. Full Copyright Statement ..................................... 29 S. Yasukawa (Ed.) [Page 2] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 1. Introduction Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS guarantees, resources optimization, and fast failure recovery, but is limited to point-to-point (P2P) applications. Requirements have been expressed for the provision of point-to-multipoint (P2MP) services using traffic engineered LSPs and this clearly motivates enhancements of the base MPLS-TE tool box in order to support P2MP MPLS-TE LSPs. HTA: English unhappy. Are you trying to say "This document defines requiremnets" or "Some people have expressed requirements, therefore this document tries to specify some"? HTA: This would be an appropriate place to define what you mean by a P2MP service - what I said in my other note that I was missing. Note that huge chunks of this document use the term "tree" liberally - but in section 4.11 you talk about "tree remerge" - which makes the tree be not a tree. This is confusing; if you assume a tree-shaped pattern, with no merges, you should say so up front; if not, you should avoid the term "tree". [RFC2702] specifies requirements for traffic engineering over MPLS. It describes traffic engineering in some detail, and those definitions and objectives are equally applicable to traffic engineering in a point-to-multipoint service environment. They are not repeated here, but it is assumed that the reader is fully familiar with them. HTA: Not all definitions of 2702 are appropriate for P2MP. For instance, atomic establishment of bidirectional traffic trunks are not. I'd stick with "definitions" and drop "objectives". [RFC2702] also explains how MPLS is particularly suited to traffic engineering, and presents the following eight reasons. HTA: You might want to refer to section 3.0 of [RFC2702] - since the formatting in 2702 is messed up, it's hard to find it..... 1. Explicit label switched paths which are not constrained by the destination based forwarding paradigm can be easily created through manual administrative action or through automated action by the underlying protocols. 2. LSPs can potentially be efficiently maintained. 3. Traffic trunks can be instantiated and mapped onto LSPs. 4. A set of attributes can be associated with traffic trunks which modulate their behavioral characteristics. 5. A set of attributes can be associated with resources which constrain the placement of LSPs and traffic trunks across them. 6. MPLS allows for both traffic aggregation and disaggregation whereas classical destination only based IP forwarding permits only aggregation. 7. It is relatively easy to integrate a "constraint-based routing" framework with MPLS. 8. A good implementation of MPLS can offer significantly lower overhead than competing alternatives for Traffic Engineering. These points are equally applicable to point-to-multipoint traffic engineering. Points 1. and 7. are particularly important. Note that point 3. implies that the concept of a point-to-multipoint traffic trunk is defined and is supported (or mapped onto) P2MP LSPs. HTA: Supported or mapped onto? I think it wiser to stick to "mapped onto" only. That is, the traffic flow for a point-to-multipoint LSP is not constrained to the path or paths that it would follow during multicast routing or shortest path destination-based routing, but can be explicitly controlled through manual or automated action. Further, the explicit paths that are used may be computed using algorithms based on a variety of constraints to produce all manner of tree shapes. For example, an explicit path may be cost-based S. Yasukawa (Ed.) [Page 3] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 [STEINER], shortest path, QoS-based, or may use some fair-cost QoS algorithm. [RFC2702] also describes the functional capabilities required to fully support Traffic Engineering over MPLS in large networks. This document presents a set of requirements for Point-to-Multipoint (P2MP) Traffic Engineering (TE) extensions to Multiprotocol Label Switching (MPLS). It specifies functional requirements for solutions to deliver P2MP TE LSPs. Solutions that specify procedures for P2MP TE LSP setup MUST satisfy these requirements. There is no intent to specify solution specific details nor application specific requirements in this document. The requirements presented in this document are not limited to the requirements of packet switched networks, but also encompass the requirements of TDM, lambda and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document MUST attempt to be equally applicable to MPLS and GMPLS. HTA: Same comment as in abstract. Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE LSPs so new mechanisms need to be developed. This should be achieved with maximum re-use of existing MPLS protocols. Note that there is a separation between routing and signaling in MPLS TE. In particular, the path of the MPLS TE LSP is determined by performing a constraint-based computation (such as CSPF) on a traffic engineering database (TED). The contents of the TED may be collected through a variety of mechanisms. This document focuses on requirements for establishing and maintaining P2MP MPLS TE LSPs through signaling protocols; and routing protocols are out of scope. No assumptions are made about how the TED used as the basis for path computations for P2MP LSPs is formed. HTA: These three paragraphs add no information - neither make requirements nor make the problem easier to understand. Suggest removing. This requirements document assumes the following conditions for P2MP MPLS TE LSP establishment and maintenance: o A P2MP TE LSP will be set up with TE constraints and will allow efficient packet or data replication at various branching points in the network. Although replication is a data plane issue, it is the responsibility of the control plane (acting in conjunction with the path computation component) to install LSPs in the network such that replication can be performed efficiently. Note that the notion of "efficient" replication is relative and may have different meanings depending on the objectives (see section 4.2). S. Yasukawa (Ed.) [Page 4] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 o P2MP TE LSP setup mechanisms must include the ability to add/remove receivers to/from an existing P2MP TE LSP. o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing egress LSRs to/from an existing P2MP TE LSP. It is assumed that the HTA: English - "Tunnel endpoints" is different from "receivers" how? I can't see the difference between the first bullet and the first sentence of this bullet. Don't repeat if you can avoid it.... rate of change of leaves of a P2MP service (that is, the rate at which new egress LSRs join, or old egress LSRs are pruned) is "not so high" because P2MP TE LSPs are assumed to be utilized for TE applications. This issue is discussed at greater length in section 4.18.1. HTA: Since "TE applications" is undefined, this adds no information. I'd stick a number in here (10 join/leaves per day) and leave it at that. o A P2MP TE LSP will be protected by fast error recovery mechanisms HTA: "will be" or "may be"? I think "may be" is right(er). to minimize disconnection of a P2MP service. And a set of attributes of the P2MP TE LSP (e.g. bandwidth etc) will be modified by some mechanism (e.g. Make-before-break etc) to accommodate attribute changes to the P2MP service. HTA: I can't parse the sentence above, even though I think I know what it says. Please rewrite. These issues are discussed in section 4.6 and 4.10. It is this document's objective that a solution compliant to the requirements equips and operates these P2MP TE capabilities in a scalable fashion. HTA: This sentence says nothing. Remove? 1.1 Non-Objectives For clarity, this section lists some items that are out of scope of this document. It is assumed that some information elements describing the P2MP TE LSP are known to the ingress LSR prior to LSP establishment. For example, the ingress LSRs knows the IP addresses that identify the egress LSRs of the P2MP TE LSP. The mechanisms by which the ingress LSR obtains this information is outside the scope of P2MP TE signaling and so is not included in this document. Other documents may complete the description of this function by providing automated, protocol-based ways of passing this information to the ingress LSR. The following are non-objectives of this document. HTA: I don't understand this section. A "non-objective" may be understood in multiple ways: - This document places no requirement on the following things - This document doesn't care whether or not these things occur in a solution - This document doesn't describe the details for the following things I think it would be simpler if this section said "This document does not specify any requirements for the following functions". In that case, the "algorithms" point does not fit, and should be dropped. - Non-TE LSPs (such as per-hop, routing-based LSPs). - Discovery of egress leaves for a P2MP LSP - Hierarchical P2MP LSPs - OAM for P2MP LSPs - Inter-area and inter-AS P2MP TE LSPs - Applicability of P2MP MPLS TE LSPs to service scenarios - Specific application or application requirements - Algorithms for computing P2MP distribution trees S. Yasukawa (Ed.) [Page 5] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 - Multipoint-to-point LSPs - Multipoint-to-multipoint LSPs - Routing protocols - Construction of the traffic engineering database - Distribution of the information used to construct the traffic engineering database 2. Definitions 2.1 Acronyms P2P: Point-to-point P2MP: Point-to-multipoint 2.2 Terminology The reader is assumed to be familiar with the terminology in [RFC3031] and [RFC3209]. The following terms are defined for use in the context of TE LSPs only. HTA: you mean "P2MP TE LSPs", not any TE LSPs, I think. P2MP tree: The ordered set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. ingress LSR: The LSR that is responsible for initiating the signaling messages that set up the P2MP TE LSP. egress LSR: One of potentially many destinations of the P2MP TE LSP. Egress LSRs may also be referred to as leaf nodes or leaves. HTA: Is there a distinction between the term "egress" and "egress LSR"? The terms are used somewhat inconsistently. bud LSR: An LSR that is an egress, but also has one or more directly connected downstream LSRs. branch LSR: An LSR that has more than one directly connected downstream LSR. S. Yasukawa (Ed.) [Page 6] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 graft LSR: An LSR that is already a member of the P2MP tree and is in process of signaling a new sub-P2MP tree. HTA: I don't understand the term "signaling a new sub-P2MP tree". Do you mean "signaling LSRs that are not currently members of the P2MP tree in order to add a new subtree to the P2MP tree"? Note - the term is not used in this document. prune LSR: An LSR that is a member of the P2MP tree and is in process of tearing down an existing sub-P2MP tree. HTA: Also not clear. P2MP-ID (P2ID): A unique identifier of a P2MP TE LSP, that is constant for the whole LSP regardless of the number of branches and/or leaves. HTA: The term "receiver" is used, but does not appear to be defined. 2.2.1 Terminology for Partial LSPs It is convenient to sub-divide P2MP trees for functional and representational reasons. A tree may be divided in two dimensions: - A division may be made along the length of the tree. For example, the tree may be split into two components each running from the ingress LSR to a discrete set of egress LSRs HTA: This is unclear. Does the ingress LSR become a member of one division, or both? - A tree may be divided at a branch LSR (or any transit LSR) to produce a component of the tree that runs from the branch (or transit) LSR to all downstream egress LSRs. HTA: This is also unclear. Is the tree divided at the link, or is the LSR it's divided at become part of both subsections? These two methods of splitting the P2MP tree can be combined, so it is useful to introduce some terminology to allow the partitioned trees to be clearly described. Use the following designations: Source (ingress) LSR - S Leaf (egress) LSR - L Branch LSR - B Transit LSR - X HTA: The definition of X2X below seems to indicate that by "transit", you mean that a transit LSR does not branch the tree. This is, however, not stated anywhere. All - A Partial (i.e. not all) - P Define a new term: Sub-LSP A segment of a P2MP TE LSP that runs from one of the LSP's LSRs to one or more of its other LSRs. S. Yasukawa (Ed.) [Page 7] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Using these new concepts we can define any combination or split of the P2MP tree. For example: S2L sub-LSP The path from the source to one specific leaf. S2PL sub-LSP The path from the source to a set of leaves. B2AL sub-LSP The path from a branch LSR to all downstream leaves. X2X sub-LSP A component of the P2MP LSP that is a simple path with no branches. HTA: If true, it means that the X constrains the 2 to be only X LSRs. That's not described anywhere. Note that the S2AL sub-LSP is equivalent to the P2MP LSP. 2.3 Conventions 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 [RFC2119]. 3. Problem Statement 3.1 Motivation As described in section 1, Traffic Engineering and Constraint Based Routing, including Call Admission Control(CAC), explicit source routing and bandwidth reservation, are required to enable efficient resource usage and strict QoS guarantees. Such mechanisms also make HTA: The sentence above parses badly - I can't tell which level of subparagraph the various commas belong to. Rewrite? it possible to provide services across a congested network where conventional "shortest path first" forwarding paradigms would fail. Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms [RFC3473] only provide support for P2P TE LSPs. While it is possible to provide P2MP TE services using P2P TE LSPs, any such approach is potentially suboptimal since it may result in data replication at the ingress LSR, or in duplicate data traffic within the network. Hence, to provide P2MP MPLS TE services in a fully efficient manner it is necessary to specify specific requirements. These requirements can then be used to define mechanisms for the use of existing protocols and/or extensions to existing protocols and/or new protocols. HTA: I think the proper term is "when defining mechanisms", not "to define mechanisms". S. Yasukawa (Ed.) [Page 8] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 3.2. Requirements Overview This document states basic requirements for the setup of P2MP TE LSPs. The requirements apply to the signaling techniques only, and no assumptions are made about which routing protocols are run within the network, nor about how the information that is used to construct the Traffic Engineering Database (TED) is distributed. These factors are out of the scope of this document. HTA: The paragraph above repeats material from the introduction. Remove? A P2MP TE LSP path will be computed taking into account various constraints such as bandwidth, affinities, required level of protection and so on. HTA: I dislike passive voice. Do you mean "The traffic engineering solution will be used to compute a P2MP path ..."? The solution MUST allow for the computation of P2MP TE LSP paths satisfying constraints with the objective of supporting various optimization criteria such as delays, bandwidth consumption in the network, or any other combinations. This is likely to require the presence of a TED, as well as the ability to signal the explicit path of an LSP. A desired requirement is also to maximize the re-use of existing MPLS TE techniques and protocols where doing so does not adversely impact the function, simplicity or scalability of the solution. This document does not restrict the choice of signaling protocol used to set up a P2MP TE LSP, but it should be noted that [RFC3468] states ... the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signaling protocol for traffic engineering applications... The P2MP TE LSP setup mechanism MUST include the ability to add/remove egress LSRs to/from an existing P2MP TE LSP and MUST allow for the support of all the TE LSP management procedures HTA: Would like to say "all the applicable TE LSP.." - see comment about the establishment of bidirectional tunnels earlier. already defined for P2P TE LSP. Further, when new TE LSP procedures are developed for P2P TE LSPs equivalent or identical procedures SHOULD be developed for P2MP TE LSPs. HTA: I think there's a comma before "equivalent". Without it, the sentence is hard to parse. The computation of P2MP trees is implementation dependent and is beyond the scope of the solutions that are built with this document as a guideline. S. Yasukawa (Ed.) [Page 9] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Consider the following figure. Source 1 (S1) | I-LSR1 | | | | R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1) | : R3----E-LSR4 E-LSR5 | : | : R4 R5 Figure 1 Figure 1 shows a single ingress (I-LSR1), and four egresses(E-LSR2, E-LSR3, E-LSR4 and E-LSR5). I-LSR1 is attached to a traffic source that is generating traffic for a P2MP application. Receivers R1, R2, R3 and R4 are attached to E-LSR2, E-LSR3 and E-LSR4. The following are the objectives of P2MP LSP establishment and use. a) A P2MP tree which satisfies various constraints is pre-determined and supplied to ingress I-LSR1. HTA: A description of a P2MP tree is supplied.. the tree itself is established.... Note that no assumption is made on whether the tree is provided to I-LSR1 or computed by I-LSR1. Note that the solution SHOULD also allow for the support of partial path by means of loose routing. HTA: Delete "Note that" in the last sentence. You don't want to have requirements language (SHOULD) inside a "Note that" sentence. Typical constraints are bandwidth requirements, resource class affinities, fast rerouting, preemption, to mention a few of them. There should not be any restriction on the possibility to support the set of constraints already defined for point to point TE LSPs. A new constraint may specify which LSRs should be used as branch points for the P2MP LSR in order to take into account some LSR capabilities or network constraints. b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3 and E-LSR4 using the tree information. c) In this case, the branch LSR1 should replicate incoming packets or data and send them to E-LSR3 and E-LSR4. d) If a new receiver (R5) expresses an interest in receiving traffic, a new tree is determined and a B2L sub-LSP from LSR2 to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a branch LSR. HTA: It's unclear to me whether the requirements want to say anything about who does this - is it envisioned that R5 expresses the interest to either S1 or I-LSR1, and that I-LSR1 initiates the change, or is it envisioned that R5 can express interest straigtht to LSR2 or E-LSR5, without involving S1 or I-LSR1 in the process? The model in this document seems to tend towards the first alternative, but the language does not rule out the second - which I find highly confusing. S. Yasukawa (Ed.) [Page 10] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 4. Detailed requirements for P2MP TE extensions 4.1 P2MP LSP The P2MP TE extensions MUST be applicable to the signaling of LSPs for different switching types. For example, it MUST be possible to signal a P2MP TE LSP in any switching medium being packet or non-packet based (including frame, cell, TDM, lambda, etc.) As with P2P MPLS technology [RFC3031], traffic is classified with a FEC in this extension. All packets which belong to a particular FEC and which travel from a particular node MUST follow the same P2MP tree. In order to scale to a large number of branches, P2MP TE LSPs SHOULD be identified by a unique identifier (the P2MP ID or P2ID) that is constant for the whole LSP regardless of the number of branches and/or leaves. Therefore, the identification of the P2MP session by its destination addresses is not adequate. HTA: Suggest deleting the last sentence. It adds nothing, and confuses. 4.2 P2MP explicit routing Various optimizations in P2MP tree formation need to be applied to meet various QoS requirements and operational constraints. Some P2MP applications may request a bandwidth guaranteed P2MP tree which satisfies end-to-end delay requirements. And some operators may want to set up a cost minimum P2MP tree by specifying branch LSRs explicitly. The P2MP TE solution therefore MUST provide a means of establishing arbitrary P2MP trees under the control of an external tree computation process or path configuration process or dynamic tree computation process located on the ingress LSR. Figure 2 shows two typical examples. A A | / \ B B C | / \ / \ C D E F G | / \ / \/ \ / \ D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O Steiner P2MP tree SPF P2MP tree Figure 2 Examples of P2MP TE LSP topology One example is the Steiner P2MP tree (Cost minimum P2MP tree) [STEINER]. This P2MP tree is suitable for constructing a cost S. Yasukawa (Ed.) [Page 11] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 minimum P2MP tree so as to minimize the bandwidth consumption in the core. To realize this P2MP tree, several intermediate LSRs must be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, H, I, J and K in the figure 2). Therefore, the P2MP TE solution MUST support a mechanism that can setup this kind of bud LSR between an ingress LSR and egress LSRs. Note that this includes constrained Steiner trees that allow for the computation of a minimal cost trees with some other constraints such as a bounded delay between the source and every receiver. Another example is a CSPF (Constraint Shortest Path First) P2MP tree. By some metric (which can be set upon any specific criteria like the delay, bandwidth, a combination of those), one can calculate a shortest path P2MP tree. This P2MP tree is suitable for carrying real time traffic. The solution MUST allow the operator to make use of any tree computation technique. In the former case an efficient/optimal tree is defined as a minimal cost tree (Steiner tree) whereas in the later case it is defined as the tree that provides shortest path between the source and any receiver. To support explicit setup of any reasonable P2MP tree shape, a P2MP TE solution MUST support some form of explicit source-based control of the P2MP tree which can explicitly include particular LSRs as branch nodes. This can be used by the ingress LSR to setup the P2MP TE LSP. For instance, a P2MP TE LSP can be simply represented as a whole tree or by its individual branches. 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes A P2MP tree is completely specified if all of the required branches and hops between a sender and leaf LSR are indicated. A P2MP tree is partially specified if only a subset of intermediate branches and hops are indicated. This may be achieved using loose hops in the explicit path, or using widely scoped abstract nodes (that is, abstract nodes that are not simple [RFC3209]) such as IPv4 prefixes shorter than 32 bits, or AS numbers. A partially specified P2MP tree might be particularly useful in inter-area and inter-AS situations although P2MP requirements for inter-area and inter-AS are beyond the scope of this document. Protocol solutions SHOULD include a way to specify loose hops and widely scoped abstract nodes in the explicit source-based control of the P2MP tree as defined in the previous section. Where this support is provided, protocol solutions MUST allow downstream LSRs to apply further explicit control to the P2MP tree to resolve a partially specified tree into a (more) completely specified tree. S. Yasukawa (Ed.) [Page 12] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Protocol solutions MUST allow the P2MP tree to be completely specified at the ingress where sufficient information exists to allow the full tree to be computed and where policies along the path (such as at domain boundaries) support full specification. In all cases, the egress nodes of the P2MP TE LSP must be fully specified either individually or through some collective identifier. Without this information, it is impossible to know to where the TE LSP should be routed. In case of a tree being computed by some downstream LSRs (e.g. the case of hops specified as loose hops), the solution MUST provide protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn the full P2MP tree. Note that this information may not always be obtainable owing to policy considerations, but where part of the path remains confidential it MUST be reported through aggregation (for example, using an AS number). 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms The P2MP TE solution MUST support establishment, maintenance and teardown of P2MP TE LSPs in a manner that is at least scalable in a linear way. This MUST include both the existence of very many LSPs at once, and the existence of very many destinations for a single P2MP LSP. HTA: "scalable in a linear way" is an awkward phrase. No suggested rephrase. In addition to P2MP TE LSP establishment and teardown mechanism, it SHOULD implement partial P2MP tree modification mechanism. HTA: The document varies between "support" and "implement". I suggest sticking with "support". Also, it should be "a partial" since "mechanism" is singular. For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE LSP, the extensions SHOULD support a grafting mechanism. For the purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, the extensions SHOULD support a pruning mechanism. It is RECOMMENDED that these grafting and pruning operations do not cause any additional processing in nodes except along the path to the grafting and pruning node and its downstream nodes. Moreover, both grafting and pruning operations MUST not be traffic disruptive for the traffic currently forwarded along the P2MP tree. HTA: Suggest "that are not along the path" instead of "except along the path". Also, capitalize MUST NOT - and "MUST NOT disrupt traffic" is better than "MUST not be traffic disruptive". There is no assumption that the explicitly routed P2MP LSP remains on an optimal path after several grafts and prunes have occurred. In this context, scalable refers to the signaling process for the P2MP TE LSP. The TE nature of the LSP allows that re-optimization may take place from time to time to restore the optimality of the LSP. S. Yasukawa (Ed.) [Page 13] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 4.5 Fragmentation The P2MP TE solution MUST handle the situation where a single protocol message cannot contain all of the information necessary to signal the establishment of the P2MP LSP. It MUST be possible to establish the LSP in these circumstances. This situation may arise in either of the following circumstances. a. The ingress LSR cannot signal the whole tree in a single message. b. The information in a message expands to be too large (or is discovered to be too large) at some transit node. This may occur because of some increase in the information that needs to be signaled or because of a reduction in the size of signaling message that is supported. The solution to these problems SHOULD NOT rely on IP fragmentation of protocol messages and it is RECOMMENDED to rely on some protocol procedures specific to the signaling solution. In the event that fragmented IP packets containing protocol messages are received, it is NOT RECOMMENDED that they are reassembled at the receiving LSR. HTA: This section is extremely strange, in that it seems to warn against a particular choice in a particular solution - not stating the requirement at all. I'd suggest just saying The solution MUST allow the establishing of large P2MP LSPs (with a large number of LSRs and recipients being identified). Note that the set of identified LSRs can grow at transit nodes. and leave the packet sizes out of it entirely. 4.6 Failure Reporting and Error Recovery Failure events may cause egress nodes or sub-P2MP LSPs to become detached from the P2MP TE LSP. These events MUST be reported upstream as for a P2P LSP. The solution SHOULD provide recovery techniques such as protection and restoration allowing recovery of any impacted sub-P2MP TE LSPs. In particular, a solution MUST provide fast protection mechanisms applicable to P2MP TE LSP similar to the solutions specified in [RFC4090] for P2P TE LSPs. Note also that no assumption is made on whether backup paths for P2MP TE LSPs should or should not be shared with P2P TE LSPs backup paths. Note that the functions specified in [RFC4090] are currently specific to packet environments and do not apply to non-packet environments. Thus, while solutions MUST provide fast protection mechanisms similar to those specified in [RFC4090], this requirement is limited to the subset of the solution space that applies to packet switched networks only. Note that the requirements expressed in this document are general to all MPLS TE P2MP signaling, and any solution that meets them will therefore be general. Specific applications may have additional requirements, or may want to relax some requirements stated in this S. Yasukawa (Ed.) [Page 14] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 document. This may lead to variations in the solution. The solution SHOULD also support the ability to meet other network recovery requirements such as bandwidth protection and bounded propagation delay increase along the backup path during failure. A P2MP TE solution MUST support P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption. If the ingress is informed of the failure of delivery to fewer than all of the egress nodes this SHOULD NOT cause automatic teardown of the P2MP TE LSP. That is, while some egress nodes remain connected to the P2MP tree it SHOULD be a matter of local policy at the ingress whether the P2MP LSP is retained. When all egress nodes downstream of a branch node have become disconnected from the P2MP tree, and the some branch node is unable HTA: "the some branch" does not parse. to restore connectivity to any of them by means of some recovery or protection mechanisms, the branch node MAY remove itself from the P2MP tree provided that it is not also an egress LSR (that is, a bud). Since the faults that severed the various downstream egress nodes from the P2MP tree may be disparate, the branch node MUST report all such errors to its upstream neighbor. An upstream LSR or the ingress node can then decide to re-compute the path to those particular egress nodes, around the failure point. Solutions MAY include the facility for transit LSRs and particularly branch nodes to recompute sub-P2MP trees to restore them after failures. In the event of successful repair, error notifications SHOULD NOT be reported to upstream nodes, but the new paths are reported if route recording is in use. Crankback requirements are discussed in Section 4.21. 4.7 Record route of P2MP TE LSP Being able to identify the established topology of P2MP TE LSP is very important for various purposes such as management and operation of some local recovery mechanisms like Fast Reroute [RFC4090]. A network operator uses this information to manage P2MP TE LSPs. Therefore the P2MP TE solution MUST support a mechanism which can collect and update P2MP tree topology information after P2MP LSP establishment and modification process. It is RECOMMENDED that the information is collected in a data format which allows easy recognition of the P2MP tree topology. The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids. S. Yasukawa (Ed.) [Page 15] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 The solution MUST gracefully handle scaling issues concerned with the collection of P2MP tree information including the case where the collected information is too large to be carried in a single protocol message. 4.8 Call Admission Control (CAC) and QoS Control mechanism of P2MP TE LSPs P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore it is important to use CAC and QoS in the same way as P2P TE LSPs for easy and scalable operation. P2MP TE solutions MUST support both resource sharing and exclusive resource utilization to facilitate co-existence with other LSPs to the same destination(s). P2MP TE solution MUST be applicable to DiffServ-enabled networks that can provide consistent QoS control in P2MP LSP traffic. Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and interoperate smoothly with current P2P DS-TE protocol specifications. Note that this requirement document does not make any assumption on the type of bandwidth pool used for P2MP TE LSPs which can either be shared with P2P TE LSP or be dedicated for P2MP use. 4.9 Variation of LSP Parameters Certain parameters (such as priority and bandwidth) are associated with an LSP. The parameters are installed by the signaling exchanges associated with establishing and maintaining the LSP. Any solution MUST NOT allow for variance of these parameters within a single P2MP LSP. That is: - No attributes set and signaled by the ingress of a P2MP LSP may be varied by downstream LSRs. - There MUST be homogeneous QoS from the root to all leaves of a single P2MP LSP. Variation of parameters may be allowed so long as it applies to the whole LSP from ingress to all egresses. HTA: The term "variation of parameters" is unclear to me. This paragraph seems to say MUST NOT do one definition (value differs in different parts of the tree) and MAY do another definition (value changes for a whole tree over time). Using the same term for both is not a good idea; stating the last sentence as "Changing the parameters for the whole tree may be supported; the change applies to the whole tree from ingress to all egresses" avoids this. 4.10 Re-optimization of P2MP TE LSPs The detection of a more optimal path (for example, one with a lower overall cost) is an example of a situation where P2MP TE LSP re-routing may be required. While re-routing is in progress, an important requirement is avoiding double bandwidth reservation (over the common parts between the old and new LSP) thorough the use S. Yasukawa (Ed.) [Page 16] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 of resource sharing. Make-before-break MUST be supported for a P2MP TE LSP to ensure that there is minimal traffic disruption when the P2MP TE LSP is re-routed. It is possible to achieve make-before-break that only applies to a sub-P2MP tree without impacting the data on all of the other parts of the P2MP tree. HTA: is this a requirement or not? I think the document says the same thing if this paragraph is deleted. The solution SHOULD allow for make-before-break re-optimization of any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L sub-LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree). Further it SHOULD do so minimizing the signaling impact on the rest of the P2MP LSP, and without affecting the ability of the management plane to manage the LSP. The solution SHOULD also provide the ability for the ingress LSR to have a strict control on the re-optimization process. The ingress HTA: control on -> control of LSR SHOULD be able to limit all re-optimization to be source-initiated. Where sub-LSP re-optimization is allowed by the ingress LSR, such re-optimization MAY be initiated by a downstream LSR that is the root of the sub-LSP that is to be re-optimized. Sub-LSP re-optimization initiated by a downstream LSR MUST be carried out with the same regard to minimizing the hit on active traffic as HTA: hit on -> impact on (or) disruption of was described above for other re-optimization. 4.11 Tree Remerge HTA: The term "remerge" is confusing. "Merging of tree branches"? It is possible for a single transit LSR to receive multiple signaling messages for the same P2MP LSP but for different sets of destinations. These messages may be received from the same or different upstream nodes and may need to be passed on to the same or different downstream nodes. This situation may arise as the result of the signaling solution definition or implementation options within the signaling solution. Further, it may happen during make-before-break reoptimization (section 4.10), or as a result of signaling message fragmentation (section 4.5). HTA: Section 4.5 doesn't say that..... suggest deleting this paragraph. It is even possible that it is necessary to construct distinct upstream branches in order to achieve the correct label choices in certain switching technologies managed by GMPLS (for example, photonic cross-connects where the selection of a particular lambda for the downstream branches is only available on different upstream switches). S. Yasukawa (Ed.) [Page 17] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 The solution MUST support the case where of multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to the same upstream interface. In this case the result of the protocol procedures SHOULD be a single data flow on the upstream interface. HTA: The more interesting question is whether there's a single data flow on the downstream interfaces - I think the answer is "yes". The solution SHOULD support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where each signaling message results in the use of different downstream interfaces. This case represents data flows that cross at the LSR but which do not merge. The solution MAY support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where the downstream interfaces are shared across the received signaling messages. This case represents the merging of data flows. A solution that supports this case MUST ensure that data is not replicated on the downstream interfaces. HTA: The more interesting case here is where the two data streams from upstream are almost, but not completely, identical - for instance, exhibiting different patterns of packet loss or signal bit errors. The other interesting case is where the set of recipients is overlapping, but not identical. I suspect that this will become the source of headaches. An alternative to supporting this last case is for the signaling protocol to indicate an error such that the merge may be resolved by the upstream LSRs. HTA: And I think it's a preferred alternative..... 4.12 Data Duplication Data duplication refers to the receipt by any recipient of duplicate instances of the data. In a packet environment this means the receipt of duplicate packets. Although small-scale packet duplication HTA: small-scale = duplicate all packets in a short interval, or duplicate occasional packets at random? Different problems.... should be a benign (if inefficient) situation, certain existing and HTA: benign -> harmless deployed applications will not tolerate packet duplication. Long-term HTA: term "Long-term" is not the best one.... packet duplication is, at best, a waste of network and processing resources, and at worst may cause congestion and the inability to process the data correctly. In a non-packet environment data duplication means the duplication in time of some part of the signal that may lead to the replication of data or to the scrambling of data. HTA: I didn't understand that one...... perhaps delete? Data duplication may legitimately arise in various scenarios including re-optimization of active LSPs as described in the previous section, and protection of LSPs. Thus, it is impractical to regulate against data duplication in this document. Instead, the solution: - SHOULD limit to bounded transitory conditions the cases where network bandwidth is wasted by the existence of duplicate delivery paths. S. Yasukawa (Ed.) [Page 18] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 - MUST limit the cases where duplicate data is delivered to an application to bounded transitory conditions. 4.13 IPv4/IPv6 support Any P2MP TE solution MUST support IPv4 and IPv6 addressing. 4.14 P2MP MPLS Label A P2MP TE solution MUST allow the continued use of existing techniques to establish P2P LSPs (TE and otherwise) within the same network, and MUST allow the co-existence of P2P LSPs within the same network as P2MP TE LSPs. A P2MP TE solution MUST be specified in such a way that it allows P2MP and P2P TE LSPs to be signaled on the same interface. 4.15 Routing advertisement of P2MP capability HTA: I find the term "routing" in the title confusing. Just "Advertising" would be enough. Several high-level requirements have been identified to determine the capabilities of LSRs within a P2MP network. The aim of such information is to facilitate the computation of P2MP trees using TE constraints within a network that contains LSRs that do not all have the same capabilities levels with respect to P2MP signaling and data forwarding. These capabilities include, but are not limited to: - the ability of an LSR to support branching. - the ability of an LSR to act as an egress and a branch for the same LSP. - the ability of an LSR to support P2MP MPLS-TE signaling. 4.16 Multi-access LANs P2MP MPLS TE may be used to traverse network segments that are provided by multi-access media such as Ethernet. In these cases, it is also possible that the entry point to the network segment is a branch point of the P2MP LSP. Two options clearly exist: - the branch point replicates the data and transmits multiple copies onto the segment - the branch point sends a single copy of the data to the segment and relies on the exit points to discriminate the reception of the data. HTA: discriminate the reception of -> select which data to receive The first option has a significant data plane scaling issue since all replicated data must be sent through the same port and carried on the same segment. Thus, a solution SHOULD provide a mechanism for a S. Yasukawa (Ed.) [Page 19] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 branch node to send a single copy of the data onto a multi-access network and reach multiple (adjacent) downstream nodes. The second option may have control plane scaling issues. 4.17 P2MP MPLS OAM The MPLS and GMPLS MIB modules will be enhanced to provide P2MP TE LSP management in line with whatever signaling solutions are developed. HTA: This sentence seems out of place. Remove? If not - reformulate as "A solution should specify extensions to the MPLS and GMPLS MIB modules to provide...." In order to facilitate correct management, P2MP TE LSPs MUST have unique identifiers since otherwise it is impossible to determine which LSP is being managed. Further discussions of OAM are out of scope for this document. See [P2MP-OAM] for more details. 4.18 Scalability Scalability is a key requirement in P2MP MPLS systems. Solutions MUST be designed to scale well with an increase in the number of any of the following: - the number of recipients - the number of branch points - the number of branches. Both scalability of control plane operation (setup, maintenance, modification and teardown) MUST be considered. Key considerations MUST include: - the amount of refresh processing associated with maintaining a P2MP TE LSP. - the amount of protocol state that must be maintained by ingress and transit LSRs along a P2MP tree. - the number of protocol messages required to set up or tear down a P2MP LSP as a function of the number of egress LSRs. - the number of protocol messages required to repair a P2MP LSP after failure or perform make-before-break. - the amount of protocol information transmitted to manage a P2MP TE LSP (i.e. the message size). - the amount of additional data distributed in potential routing extensions. - the amount of additional control plane processing required in the network to detect whether an add/delete of a new branch is required, and in particular, the amount of processing in steady state when no add/delete is requested - the amount of control plane processing required by the ingress, transit and egress LSRs to add/delete a branch LSP to/from an existing P2MP LSP. S. Yasukawa (Ed.) [Page 20] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria. 4.18.1 Absolute Limits In order to achieve the best solution for the problem space it is helpful to clarify the boundaries for P2MP TE LSPs. - Number of recipients. A scaling bound is placed on the solution mechanism such that a P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP when the number of recipients reduces to one. HTA: Is this a convoluted way of saying "Establishing a P2MP TE LSP to a single recipient should cost approximately as much as establishing a P2P LSP"? If not, I don't understand it.... It is important to classify the issues of scaling within the context of Traffic Engineering. It is anticipated that the initial deployments of P2MP TE LSPs will be limited to a maximum of around a hundred recipients, but that medium term deployments may increase this to several hundred, and that future deployments may require significantly larger numbers. HTA: Define "medium term"? A year? Five years? An acceptable upper bound for a solution, therefore, is one that scales linearly with the number of recipients. It is expected that solutions will scale better than linearly. Solutions that scale worse than linear (that is, exponential or polynomial) are not acceptable whatever the number of recipients they could support. - Number of branch points. Solutions MUST support all possibilities from one extreme of a single branch point that forks to all leaves on a separate branch, to the greatest number of branch points which is (n-1) for n recipients. Assumptions MUST NOT be made in the solution regarding which topology is more common, and the solution MUST be designed to ensure scalability in all topologies. HTA: "branch point" is not well defined. Use "branch LSR"? - Dynamics of P2MP tree. Recall that the mechanisms for determining which recipients should be added to an LSP, and for adding and removing recipients from that group are out of the scope of this document. Nevertheless, it is useful to understand the expected rates of arrival and departure of recipients since this can impact the selection of solution techniques. Again, it must be recalled that this document is limited to Traffic Engineering, and in this model the rate of change of LSP egresses may be expected to be lower than the rate of change of recipients in an IP multicast group. S. Yasukawa (Ed.) [Page 21] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Although the absolute number of recipients coming and going is the important element for determining the scalability of a solution, it may be noted that a percentage may be a more comprehensible measure but that this is not as significant for LSPs with a small number of recipients. A working figure for an established P2MP TE LSP is less than 10% churn per day. That is, a relatively slow rate of churn. We could say that a P2MP LSP would be shared by multiple multicast groups and so the dynamics of the P2MP LSP would be relatively small. Solutions MUST optimize around such relatively low rates of change and are NOT REQUIRED to optimize for significantly higher rates of change. HTA: "optimize around" is not well defined, so it's dangerous to have a MUST there. Suggest "work well with" instead. "NOT REQUIRED" is a hard-to-parse use of RFC 2119 language (logically it means the same as MAY). I suggest downcasing it. - Rate of change within the network. It is also important to understand the scaling with regard to changes within the network. That is, one of the features of a P2MP TE LSP is that it can be robust or protected against network failures, and can be re-optimized to take advantage of newly available network resources. It is more important that a solution be optimized for scaling with respect to recovery and re-optimization of the LSP, than for change HTA: I don't think there should be a comma on the line above. in the recipients, because P2MP is used as a TE tool. The solution MUST follow this distinction. HTA: Not clear that this has meaning. Suggest deleting the sentence. 4.19 Backwards Compatibility It SHOULD be an aim of any P2MP solution to offer as much backward compatibility as possible. An ideal which is probably impossible to achieve would be to offer P2MP services across legacy MPLS networks without any change to any LSR in the network. If this ideal cannot be achieved, the aim SHOULD be to use legacy nodes as both transit non-branch LSRs and egress LSRs. It is a further requirement for the solution that any LSR that implements the solution SHALL NOT be prohibited by that act from supporting P2P TE LSPs using existing signaling mechanisms. That is, unless administratively prohibited, P2P TE LSPs MUST be supported through a P2MP network. Also, it is a requirement that P2MP TE LSPs MUST be able to co-exist with IP unicast and IP multicast networks. S. Yasukawa (Ed.) [Page 22] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 4.20 GMPLS The requirement for P2MP services for non-packet switch interfaces is similar to that for Packet-Switch Capable (PSC) interfaces. Therefore, it is a requirement that reasonable attempts must be made to make all the features/mechanisms (and protocol extensions) that will be defined to provide MPLS P2MP TE LSPs equally applicable to P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks over-complicate the PSC solution a decision may be taken to separate the solutions. Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or non-PSC TE-LSPs MUST be backward and forward compatible with the other features of GMPLS including: HTA: The term "backward and forward compatible" is, IMHO, meaningless. The long list of specific RSVP-TE constructs below is, IMHO, inappropriate. - control and data plane separation (IF_ID RSVP_HOP and IF_ID ERROR_SPEC), - full support of numbered and unnumbered TE links (see [RFC 3477] and [GMPLS-ROUTE]), - use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL (C-Type 2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL, in conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET object, - processing of the ADMIN_STATUS object, - processing of the PROTECTION object, - support of Explicit Label Control, - processing of the Path_State_Removed Flag, - handling of Graceful Deletion procedures, - E2E and Segment Recovery procedures, - support of Graceful Restart. In addition, since non-PSC TE-LSPs may have to be processed in environments where the "P2MP capability" could be limited, specific constraints may also apply during the P2MP TE Path computation. Being technology specific, these constraints are outside the scope of this document. However, technology independent constraints (i.e. constraints that are applicable independently of the LSP class) SHOULD be allowed during P2MP TE LSP message processing. It has to be emphasized that path computation and management techniques shall be as close as possible to those being used for PSC P2P TE LSPs and P2MP TE LSPs. 4.21 P2MP Crankback routing P2MP solutions SHOULD support crankback requirements as defined in [CRANKBACK]. In particular, they SHOULD provide sufficient information to a branch LSR from downstream LSRs to allow the branch LSR to re-route a sub-LSP around any failures or problems in the network. S. Yasukawa (Ed.) [Page 23] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 5. Security Considerations This requirements document does not define any protocol extensions and does not, therefore, make any changes to any security models. It should be noted that P2MP signaling mechanisms built on P2P RSVP-TE signaling are likely to inherit all of the security techniques and problems associated with RSVP-TE. These problems may be exacerbated in P2MP situations where security relationships may need to maintained between an ingress and multiple egresses. Such issues are similar to security issues for IP multicast. It is a requirement that documents offering solutions for P2MP LSPs MUST have detailed security sections. HTA: I think this section needs more work. It doesn't say anything about what the security requirements are for solutions in this space. 6. IANA Considerations This informational draft does not introduce any new encodings or code points. It requires no action from IANA. 7. Acknowledgements The authors would like to thank George Swallow, Ichiro Inoue, Dean Cheng, Lou Berger and Eric Rosen for their review and suggestions. Thanks to Loa Andersson for his help resolving the final issues in this document. 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC2702, September 1999. S. Yasukawa (Ed.) [Page 24] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 8.2 Informational References [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] K. Kompella, Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)", RFC3477, January 2003. [RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC3630] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4090] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [GMPLS-ROUTE] K. Kompella, Y. Rekhter, Editor, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-gmpls-routing, work in progress. S. Yasukawa (Ed.) [Page 25] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 [STEINER] H. Salama, et al., "Evaluation of Multicast Routing Algorithm for Real-Time Communication on High-Speed Networks," IEEE Journal on Selected Area in Communications, pp.332-345, 1997. [IS-IS-TE] Henk Smit, Tony Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G. Ash, S. Marshall, "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, work in progress. [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM Requirements for Point-to-Multipoint MPLS Networks", draft-yasukawa-mpls-p2mp-oam-reqs, work in progress. 9. Editor's Address Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 Email: yasukawa.seisho@lab.ntt.co.jp 10. Authors' Addresses Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 Email: dimitri.papadimitriou@alcatel.be JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719, USA Email: jpv@cisco.com S. Yasukawa (Ed.) [Page 26] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan Email: y.kamite@ntt.com Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Alan Kullberg Motorola Computer Group 120 Turnpike Rd. Southborough, MA 01772 Email: alan.kullberg@motorola.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 Email: adrian@olddog.co.uk Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803 EMail: mjork@quarrytech.com Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 Email: andy.malis@tellabs.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: jeanlouis.leroux@francetelecom.com 11. Intellectual Property Consideration 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 S. Yasukawa (Ed.) [Page 27] Internet Draft draft-ietf-mpls-p2mp-sig-requirement-03.txt June 2005 under such rights might or might not be available; nor does it represent that it has 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 ietf-ipr@ietf.org. 12. 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. S. Yasukawa (Ed.) [Page 28] ---------- End Forwarded Message ---------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Dec 01 15:50:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNa-0000By-El; Thu, 01 Dec 2005 15:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNS-00005k-9Y for mpls@megatron.ietf.org; Thu, 01 Dec 2005 15:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25872 for ; Thu, 1 Dec 2005 15:49:14 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNR-0006bX-N8; Thu, 01 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-11.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-11.txt Pages : 43 Date : 2005-12-1 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1114512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1114512.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Dec 01 15:50:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNc-0000Cs-Tu; Thu, 01 Dec 2005 15:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNS-00005u-Dg for mpls@megatron.ietf.org; Thu, 01 Dec 2005 15:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25870 for ; Thu, 1 Dec 2005 15:49:14 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNR-0006bE-K9; Thu, 01 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-frmwk-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for MPLS Operations and Management (OAM) Author(s) : D. Allan, T. Nadeau Filename : draft-ietf-mpls-oam-frmwk-04.txt Pages : 10 Date : 2005-12-1 This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching. The document is structured to outline how Operations and Management functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-frmwk-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-oam-frmwk-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1113848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-frmwk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1113848.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Dec 01 15:50:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNe-0000DK-Dz; Thu, 01 Dec 2005 15:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNS-00005w-Ft for mpls@megatron.ietf.org; Thu, 01 Dec 2005 15:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25866 for ; Thu, 1 Dec 2005 15:49:14 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNR-0006ar-El; Thu, 01 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-nodeid-subobject-07.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definition of an RRO node-id subobject Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-nodeid-subobject-07.txt Pages : 8 Date : 2005-12-1 In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an IGP area or an Autonomous System. Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id subobject in order to solve this issue. The MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-nodeid-subobject-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1113001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-nodeid-subobject-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1113001.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Dec 01 15:50:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNs-0000It-Hc; Thu, 01 Dec 2005 15:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNT-00006S-Dt for mpls@megatron.ietf.org; Thu, 01 Dec 2005 15:50:05 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25881 for ; Thu, 1 Dec 2005 15:49:15 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNR-0006bb-O5; Thu, 01 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-11.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-11.txt Pages : 43 Date : 2005-12-1 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1114521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1114521.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Dec 06 07:11:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbfE-0006oj-95; Tue, 06 Dec 2005 07:11:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbfC-0006od-60 for mpls@megatron.ietf.org; Tue, 06 Dec 2005 07:11:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18492 for ; Tue, 6 Dec 2005 07:10:27 -0500 (EST) Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejc0f-0007OF-J9 for mpls@ietf.org; Tue, 06 Dec 2005 07:33:31 -0500 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id jB6C79Ac032737 for ; Tue, 6 Dec 2005 13:07:09 +0100 Received: from [127.0.0.1] ([172.16.2.233]) by mail1.imc.kth.se; Tue, 06 Dec 2005 13:10:47 +0100 Message-ID: <43957FC4.7010209@pi.se> Date: Tue, 06 Dec 2005 13:10:44 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, George Swallow Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, when aksing the room about the consensus on making it a working group document, there were good support for making it a working group document. We said that we wanted to confirm this on the list. Please send response to this mail to the MPLS mailing list stating whether you think it should become a working group document or not. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 07:38:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejc5P-0006d6-0Q; Tue, 06 Dec 2005 07:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejc5N-0006cs-6n for mpls@megatron.ietf.org; Tue, 06 Dec 2005 07:38:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21484 for ; Tue, 6 Dec 2005 07:37:29 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjcQq-0008Gv-5O for mpls@ietf.org; Tue, 06 Dec 2005 08:00:33 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 06 Dec 2005 04:38:10 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB6Cc2QO027022; Tue, 6 Dec 2005 04:38:07 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 07:38:04 -0500 Received: from [192.168.1.101] ([10.86.240.93]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 07:38:03 -0500 In-Reply-To: <43957FC4.7010209@pi.se> References: <43957FC4.7010209@pi.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EEA5207-B7D3-4EE9-A103-97831C0365C5@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 07:37:32 -0500 To: Loa Andersson X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 06 Dec 2005 12:38:03.0977 (UTC) FILETIME=[E6BBDB90:01C5FA61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org definitely in favor. JP. On Dec 6, 2005, at 7:10 AM, Loa Andersson wrote: > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam- > reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 07:48:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcFa-0001Ir-Ej; Tue, 06 Dec 2005 07:48:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcFY-0001IN-Rf for mpls@megatron.ietf.org; Tue, 06 Dec 2005 07:48:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22768 for ; Tue, 6 Dec 2005 07:48:01 -0500 (EST) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejcb2-0000Gv-BK for mpls@ietf.org; Tue, 06 Dec 2005 08:11:05 -0500 Received: from du-069-0004.access.clara.net ([217.158.132.4] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1EjcFI-0002hJ-6c for mpls@ietf.org; Tue, 06 Dec 2005 12:48:37 +0000 Message-ID: <09f801c5fa63$e0c21810$d9849ed9@Puppy> From: "Adrian Farrel" To: References: <43957FC4.7010209@pi.se> Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 12:50:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes please. > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 07:55:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcLm-0002pO-87; Tue, 06 Dec 2005 07:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjcLk-0002pI-Oi for mpls@megatron.ietf.org; Tue, 06 Dec 2005 07:55:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23574 for ; Tue, 6 Dec 2005 07:54:25 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjchC-0000Tl-Pp for mpls@ietf.org; Tue, 06 Dec 2005 08:17:30 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 13:55:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 13:55:09 +0100 Message-ID: Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Thread-Index: AcX6Xp41WzvFR8zRQWeeDq2WyiPM4QABaUtQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" , , "George Swallow" X-OriginalArrivalTime: 06 Dec 2005 12:55:10.0160 (UTC) FILETIME=[4A62F500:01C5FA64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org In favor JL=20 > -----Message d'origine----- > De : mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] De la part de Loa Andersson > Envoy=E9 : mardi 6 d=E9cembre 2005 13:11 > =C0 : mpls@ietf.org; George Swallow > Objet : [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto=20 > become a working group document? >=20 > All, >=20 > In Vancouver we discussed the=20 > draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a=20 > working group document, there were good support for making it=20 > a working group document. >=20 > We said that we wanted to confirm this on the list. Please=20 > send response to this mail to the MPLS mailing list stating=20 > whether you think it should become a working group document or not. >=20 > /Loa > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 08:12:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejccs-0001pQ-1b; Tue, 06 Dec 2005 08:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejccp-0001oJ-UU for mpls@megatron.ietf.org; Tue, 06 Dec 2005 08:12:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26540 for ; Tue, 6 Dec 2005 08:12:04 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjcyI-0001HL-LZ for mpls@ietf.org; Tue, 06 Dec 2005 08:35:09 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 14:12:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? Date: Tue, 6 Dec 2005 14:12:50 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0874249C@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? Thread-Index: AcX6Xp3Yd7Tzm4DaQq2wFuOx/VYllAACBqfQ From: "JACQUENET Christian RD-TCH-REN" To: "Loa Andersson" , , "George Swallow" X-OriginalArrivalTime: 06 Dec 2005 13:12:51.0707 (UTC) FILETIME=[C31E2CB0:01C5FA66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This should be a WG document. Cheers, Christian.=20 -----Message d'origine----- De : mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] De = la part de Loa Andersson Envoy=E9 : mardi 6 d=E9cembre 2005 13:11 =C0 : mpls@ietf.org; George Swallow Objet : [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a = workinggroup document? All, In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, when aksing the room about the consensus on making it a working group = document, there were good support for making it a working group = document. We said that we wanted to confirm this on the list. Please send response = to this mail to the MPLS mailing list stating whether you think it = should become a working group document or not. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 08:18:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejci4-0003BX-OY; Tue, 06 Dec 2005 08:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejci3-0003Al-6l for mpls@megatron.ietf.org; Tue, 06 Dec 2005 08:18:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27477 for ; Tue, 6 Dec 2005 08:17:27 -0500 (EST) Received: from tcmail21.telekom.de ([217.6.95.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejd3X-0001VG-Cp for mpls@ietf.org; Tue, 06 Dec 2005 08:40:32 -0500 Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP; Tue, 6 Dec 2005 14:18:08 +0100 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Dec 2005 14:18:07 +0100 Message-Id: <97A461F3EE5284469E41ED3728202F41E3B885@S4DE9JSAAMW.ost.t-com.de> From: "Leymann, Nicolai" To: loa@pi.se, mpls@ietf.org, swallow@cisco.com Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a wo rking group document? Date: Tue, 6 Dec 2005 14:17:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, > Please > send response to this mail to the MPLS mailing list stating > whether you think it should become a working group document or not. > In favor! Nic _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 08:47:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjdAD-0003i0-6D; Tue, 06 Dec 2005 08:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjdAB-0003hH-61 for mpls@megatron.ietf.org; Tue, 06 Dec 2005 08:47:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01130 for ; Tue, 6 Dec 2005 08:46:31 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjdVg-0002ZF-KM for mpls@ietf.org; Tue, 06 Dec 2005 09:09:37 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 14:47:20 +0100 Received: from l-at8613.rd.francetelecom.fr ([10.193.15.134]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 14:47:20 +0100 Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? From: Thomas Morin To: Loa Andersson In-Reply-To: <43957FC4.7010209@pi.se> References: <43957FC4.7010209@pi.se> Content-Type: text/plain Organization: France Telecom R&D Date: Tue, 06 Dec 2005 14:47:02 +0100 Message-Id: <1133876822.17962.21.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2005 13:47:20.0276 (UTC) FILETIME=[9414C140:01C5FA6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I'm for it! Cheers, -Thomas Loa Andersson: > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 08:54:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjdGn-0005Nv-5G; Tue, 06 Dec 2005 08:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjdGl-0005Nn-JA for mpls@megatron.ietf.org; Tue, 06 Dec 2005 08:54:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02018 for ; Tue, 6 Dec 2005 08:53:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjdcG-0002nv-32 for mpls@ietf.org; Tue, 06 Dec 2005 09:16:25 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 05:53:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,221,1131350400"; d="scan'208"; a="16656479:sNHT21291400" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id jB6DrG4Z009758; Tue, 6 Dec 2005 08:53:57 -0500 (EST) In-Reply-To: <43957FC4.7010209@pi.se> References: <43957FC4.7010209@pi.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BE72BBC-CE67-41CF-AEC7-F2662491CB51@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 08:53:56 -0500 To: Loa Andersson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes. > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam- > reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 10:04:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjeN2-0001Y5-JO; Tue, 06 Dec 2005 10:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjeN0-0001Xk-NA for mpls@megatron.ietf.org; Tue, 06 Dec 2005 10:04:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10292 for ; Tue, 6 Dec 2005 10:03:50 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjeiW-0005EE-2y for mpls@ietf.org; Tue, 06 Dec 2005 10:26:57 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2005 10:04:32 -0500 X-IronPort-AV: i="3.99,221,1131339600"; d="scan'208"; a="77198853:sNHT31238908" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB6F43Up004142; Tue, 6 Dec 2005 10:04:30 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 10:04:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 10:04:27 -0500 Message-ID: Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Thread-Index: AcX6XsaSD60ebwioRI+Bw+6C2xkWXgAF4uWw From: "Zafar Ali \(zali\)" To: "Loa Andersson" , , "George Swallow \(swallow\)" X-OriginalArrivalTime: 06 Dec 2005 15:04:29.0328 (UTC) FILETIME=[5B360900:01C5FA76] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes,=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-bounces@lists.ietf.org=20 > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, December 06, 2005 7:11 AM > To: mpls@ietf.org; George Swallow (swallow) > Subject: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto=20 > become a working group document? >=20 > All, >=20 > In Vancouver we discussed the=20 > draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a=20 > working group document, there were good support for making it=20 > a working group document. >=20 > We said that we wanted to confirm this on the list. Please=20 > send response to this mail to the MPLS mailing list stating=20 > whether you think it should become a working group document or not. >=20 > /Loa > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 13:57:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eji0l-0002BA-Tm; Tue, 06 Dec 2005 13:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eji0k-0002B5-0k for mpls@megatron.ietf.org; Tue, 06 Dec 2005 13:57:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08410 for ; Tue, 6 Dec 2005 13:57:06 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjiMG-0005Oc-4X for mpls@ietf.org; Tue, 06 Dec 2005 14:20:14 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jB6Ivhmx011024; Tue, 6 Dec 2005 19:57:43 +0100 To: Loa Andersson MIME-Version: 1.0 Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Date: Tue, 6 Dec 2005 19:57:41 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/06/2005 19:57:43 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0453974907==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0453974907== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmluIGZhdm9yIC0gPC9GT05UPjxCUj48 QlI+PEZPTlQgU0laRT0yPjxCPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5zZSZndDs8L0I+PC9G T05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogbXBscy1ib3VuY2VzQGxpc3RzLmlldGYub3Jn PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MTIvMDYvMjAwNSAxMzoxMDwvRk9OVD48QlI+PEJSPiA8 Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+bXBsc0BpZXRmLm9yZywgR2Vvcmdl IFN3YWxsb3cgJmx0O3N3YWxsb3dAY2lzY28uY29tJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9 Mj5jYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0la RT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+W21wbHNdIGRyYWZ0LXlhc3VrYXdhLW1w bHMtcDJtcC1vYW0tcmVxcy0wMS50eHR0byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 PzwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij5BbGwsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkluIFZh bmNvdXZlciB3ZSBkaXNjdXNzZWQgdGhlIGRyYWZ0LXlhc3VrYXdhLW1wbHMtcDJtcC1vYW0tcmVx cy0wMS50eHQsPEJSPndoZW4gYWtzaW5nIHRoZSByb29tIGFib3V0IHRoZSBjb25zZW5zdXMgb24g bWFraW5nIGl0IGEgd29ya2luZyBncm91cDxCUj5kb2N1bWVudCwgdGhlcmUgd2VyZSBnb29kIHN1 cHBvcnQgZm9yIG1ha2luZyBpdCBhIHdvcmtpbmcgZ3JvdXA8QlI+ZG9jdW1lbnQuPEJSPjwvRk9O VD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPldlIHNhaWQgdGhhdCB3ZSB3YW50 ZWQgdG8gY29uZmlybSB0aGlzIG9uIHRoZSBsaXN0LiBQbGVhc2U8QlI+c2VuZCByZXNwb25zZSB0 byB0aGlzIG1haWwgdG8gdGhlIE1QTFMgbWFpbGluZyBsaXN0IHN0YXRpbmcgd2hldGhlcjxCUj55 b3UgdGhpbmsgaXQgc2hvdWxkIGJlY29tZSBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgb3Igbm90 LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4vTG9hPEJSPi0t PEJSPkxvYSBBbmRlcnNzb248QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291 cmllciI+UHJpbmNpcGFsIE5ldHdvcmtpbmcgQXJjaGl0ZWN0PEJSPkFjcmVvIEFCICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwaG9uZTogJm5ic3A7KzQ2IDggNjMyIDc3IDE0PEJS PklzYWZqb3Jkc2dhdGFuIDIyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPktpc3Rh LCBTd2VkZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VtYWlsOiAmbmJzcDtsb2EuYW5kZXJzc29uQGFj cmVvLnNlPC9GT05UPjwvUD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+ PFVMPjxVTD48VUw+PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+bG9hQHBp LnNlPEJSPjwvRk9OVD48L1VMPjwvVUw+PC9VTD48L1VMPjwvVUw+PC9VTD48L1VMPjwvVUw+PC9V TD48L1VMPjwvVUw+PC9VTD48L1VMPjwvVUw+PC9VTD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+bXBscyBtYWlsaW5nIGxpc3Q8QlI+bXBsc0BsaXN0cy5pZXRmLm9yZzwvRk9OVD48QlI+PEZP TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxBIEhSRUY9aHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscz5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzPC9BPjwvRk9OVD48L1A+ --===============0453974907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0453974907==-- From mpls-bounces@lists.ietf.org Tue Dec 06 17:23:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlE7-0003R5-Ur; Tue, 06 Dec 2005 17:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlE5-0003Nv-Tu for mpls@megatron.ietf.org; Tue, 06 Dec 2005 17:23:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29631 for ; Tue, 6 Dec 2005 17:22:58 -0500 (EST) Received: from mail1.optus.com.au ([203.13.126.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjlZV-0003oW-I5 for mpls@ietf.org; Tue, 06 Dec 2005 17:46:07 -0500 Received: from CHOW2KE003.optus.com.au ([161.43.32.10]) by mail1.optus.com.au with InterScan Messaging Security Suite; Wed, 07 Dec 2005 09:23:25 +1100 Received: from shqw2ke001.optus.com.au ([10.17.224.13]) by CHOW2KE003.optus.com.au with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 09:23:24 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? Date: Wed, 7 Dec 2005 09:23:24 +1100 Message-ID: <799B0CDA650143429C5EA103965B59F8011B61BF@shqw2ke001.optus.com.au> Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? Thread-Index: AcX6Xo/s2iEQPwZnR6a0FsebWptIdQASVv/A From: "Fil Dickinson" To: "Loa Andersson" , X-OriginalArrivalTime: 06 Dec 2005 22:23:24.0712 (UTC) FILETIME=[AC52BA80:01C5FAB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org a good work and very important. It should be a working group doc. -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, 6 December 2005 11:11 PM To: mpls@ietf.org; George Swallow Subject: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? All, In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, when aksing the room about the consensus on making it a working group document, there were good support for making it a working group document. We said that we wanted to confirm this on the list. Please send response to this mail to the MPLS mailing list stating whether you think it should become a working group document or not. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 06 20:53:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjoUW-0006VO-F0; Tue, 06 Dec 2005 20:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjoUU-0006UL-FC for mpls@megatron.ietf.org; Tue, 06 Dec 2005 20:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20582 for ; Tue, 6 Dec 2005 20:52:14 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejoq4-0002I9-7H for mpls@ietf.org; Tue, 06 Dec 2005 21:15:26 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qx6E000542 for ; Wed, 7 Dec 2005 10:52:59 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qwYJ001870 for ; Wed, 7 Dec 2005 10:52:58 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qvhO011157 for ; Wed, 7 Dec 2005 10:52:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qvrm021830 for ; Wed, 7 Dec 2005 10:52:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qvcw019235 for ; Wed, 7 Dec 2005 10:52:57 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jB71qu6k019228 for ; Wed, 7 Dec 2005 10:52:56 +0900 (JST) Received: from INOUE-LETS-CFW2.lab.ntt.co.jp ([129.60.80.247]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jB71qunf004439 for ; Wed, 7 Dec 2005 10:52:56 +0900 (JST) Message-Id: <6.0.0.20.2.20051207101628.05e28398@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 07 Dec 2005 10:18:01 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become aworking group document? In-Reply-To: <09f801c5fa63$e0c21810$d9849ed9@Puppy> References: <43957FC4.7010209@pi.se> <09f801c5fa63$e0c21810$d9849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes, it should become a WG doc. >> In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, >> when aksing the room about the consensus on making it a working group >> document, there were good support for making it a working group >> document. >> >> We said that we wanted to confirm this on the list. Please >> send response to this mail to the MPLS mailing list stating whether >> you think it should become a working group document or not. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 07 02:18:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjtZn-0001sR-1m; Wed, 07 Dec 2005 02:18:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjtZk-0001sE-R6 for mpls@megatron.ietf.org; Wed, 07 Dec 2005 02:18:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24364 for ; Wed, 7 Dec 2005 02:17:58 -0500 (EST) Received: from smtp1.iitb.ac.in ([202.68.145.249]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjtvK-00047t-V8 for mpls@ietf.org; Wed, 07 Dec 2005 02:41:12 -0500 Received: (qmail 15487 invoked from network); 7 Dec 2005 12:48:20 +0530 Received: from unknown (HELO ldns2.iitb.ac.in) (10.200.12.2) by smtp1.iitb.ac.in with SMTP; 7 Dec 2005 12:48:20 +0530 Received: (qmail 5961 invoked by uid 509); 7 Dec 2005 07:18:20 -0000 Received: from 10.107.1.1 by ldns2 (envelope-from , uid 501) with qmail-scanner-1.25st (clamdscan: 0.87.1/1204. spamassassin: 3.1.0. Clear:RC:1(10.107.1.1):. Processed in 0.014486 secs); 07 Dec 2005 07:18:20 -0000 Received: from unknown (HELO ee.iitb.ac.in) (10.107.1.1) by ldns2.iitb.ac.in with SMTP; 7 Dec 2005 07:18:20 -0000 Received: from director.ee.iitb.ac.in (sharada.ee.iitb.ac.in [10.107.1.2]) by ee.iitb.ac.in (8.12.4/8.12.4) with ESMTP id jB77IHPC029253; Wed, 7 Dec 2005 12:48:18 +0530 (IST) Received: from arya.ee.iitb.ac.in (arya.ee.iitb.ac.in [10.107.1.7]) by director.ee.iitb.ac.in (8.12.8/8.12.8) with ESMTP id jB77L3vP029816; Wed, 7 Dec 2005 12:51:04 +0530 Date: Wed, 7 Dec 2005 12:47:43 +0530 (IST) From: "Sheetal A. Vispute_p05274" To: Loa Andersson Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? In-Reply-To: <43957FC4.7010209@pi.se> Message-ID: References: <43957FC4.7010209@pi.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Loa, yes it very important to become a WG doc cheers Sheetal On Tue, 6 Dec 2005, Loa Andersson wrote: > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 07 02:23:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejted-00036v-Sw; Wed, 07 Dec 2005 02:23:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejtec-00036n-0k for mpls@megatron.ietf.org; Wed, 07 Dec 2005 02:23:54 -0500 Received: from smtp1.iitb.ac.in (smtp1.iitb.ac.in [202.68.145.249]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24842 for ; Wed, 7 Dec 2005 02:22:59 -0500 (EST) From: ketkeeda@ee.iitb.ac.in Received: (qmail 16419 invoked from network); 7 Dec 2005 12:53:17 +0530 Received: from unknown (HELO ldns1.iitb.ac.in) (10.200.12.1) by smtp1.iitb.ac.in with SMTP; 7 Dec 2005 12:53:17 +0530 Received: (qmail 28775 invoked by uid 509); 7 Dec 2005 07:23:17 -0000 Received: from 10.107.1.1 by ldns1 (envelope-from , uid 501) with qmail-scanner-1.25 (clamdscan: 0.87.1/1204. spamassassin: 3.1.0. Clear:RC:1(10.107.1.1):. Processed in 0.017471 secs); 07 Dec 2005 07:23:17 -0000 Received: from unknown (HELO ee.iitb.ac.in) (10.107.1.1) by ldns1.iitb.ac.in with SMTP; 7 Dec 2005 07:23:17 -0000 Received: from sandesh.ee.iitb.ac.in ([10.107.1.20]) by ee.iitb.ac.in (8.12.4/8.12.4) with SMTP id jB77NEPC029751 for ; Wed, 7 Dec 2005 12:53:17 +0530 (IST) Received: (qmail 24091 invoked from network); 7 Dec 2005 07:23:57 -0000 Received: from localhost (HELO sandesh.ee.iitb.ac.in) (127.0.0.1) by sandesh.ee.iitb.ac.in with SMTP; 7 Dec 2005 07:23:57 -0000 Received: from 10.107.1.1 (SquirrelMail authenticated user ketkeeda); by sandesh.ee.iitb.ac.in with HTTP; Wed, 7 Dec 2005 12:53:57 +0530 (IST) Message-ID: <52175.10.107.1.1.1133940237.squirrel@10.107.1.1> Date: Wed, 7 Dec 2005 12:53:57 +0530 (IST) To: mpls@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: 8bit Cc: Subject: [mpls] doubt regarding SNMP query X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, I want to go about searching as to how is the SNMP query done in order to retreive information such as reservable bandwidth for any particular class of traffic for DIFFSERV, maximum reservable bandwidth for any class of traffic and information pertaining to bandwidth,delay,etc.. for diffserv treatment to be given to any packet. Could you plzzz tell me how I go about doing this??Also ,I would like to know about various standard APIs available to make SNMP queries.Plzzz do reply.Regards, Ketkee. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 07 09:17:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek07A-0007Uo-PO; Wed, 07 Dec 2005 09:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek078-0007Tr-6g for mpls@megatron.ietf.org; Wed, 07 Dec 2005 09:17:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11218 for ; Wed, 7 Dec 2005 09:16:53 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek0Sp-0001eb-6x for mpls@ietf.org; Wed, 07 Dec 2005 09:40:12 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2005 06:17:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,225,1131350400"; d="scan'208"; a="16769001:sNHT22817860" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id jB7EHTUS005803; Wed, 7 Dec 2005 09:17:29 -0500 (EST) In-Reply-To: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> References: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AFC08F3-2DBB-4329-8B66-B87C4F803D1D@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Comments for fastreroute-mib-04 Date: Wed, 7 Dec 2005 09:17:23 -0500 To: Ken Nagami X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org On Nov 29, 2005, at 9:06 PM, Ken Nagami wrote: > Dear authors and all, > > I have a following comment for the FRR MIB (draft-ietf-mpls- > fastreroute-mib-04). > Could you reflect this comment in the document? > > Comment: > I would like to get a 2nd label of a bypass tunnel at a PLR in the > facility backup. > I think a pointer of 1st (top) label of the bypass tunnel at a PLR > can be get from the FRR MIB. > But the 2nd label can not be get. > > Because I would like to check a 2nd label of a bypass tunnel and an > incoming label at the MP. > In the case of the node protection, two label values are normally > the same. > But if a router has a bug, the value might be different. > So, we would like to check those values before local repair from a > network management box. The MPLS-FRR-MIB provides a reference back to the TE tunnel in the MPLS-TE-STD-MIB which can be used to find the LSP that is in use for that tunnel head. From the tunnelEntry in the MPLS-TE- STD-MIB you can get the Cross-Connect (XCindex) of the LSP that is in use for that tunnel head from the MPLS-LSR-STD-MIB, which will have a corresponding mplsLabelStackTable entry that should have the extra label shown under the top label shown in the mplsInSegmentTable. --Tom > Regards, > > Ken Nagami > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 07 10:16:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek11c-0003sZ-Ch; Wed, 07 Dec 2005 10:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek11Z-0003rE-Iv for mpls@megatron.ietf.org; Wed, 07 Dec 2005 10:16:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18356 for ; Wed, 7 Dec 2005 10:15:13 -0500 (EST) Received: from yahoobb218136010008.bbtec.net ([218.136.10.8] helo=chappy.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek1NG-0003ZT-KK for mpls@ietf.org; Wed, 07 Dec 2005 10:38:32 -0500 Received: from nagami-T42.wide.ad.jp (nt-23 [172.16.2.1]) by chappy.inetcore.com (8.13.3/8.13.3) with ESMTP id jB7FFmwP011320; Thu, 8 Dec 2005 00:15:49 +0900 (JST) (envelope-from nagami@wide.ad.jp) Message-Id: <6.2.3.4.2.20051207232950.082ce6f0@inc.inetcore.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Thu, 08 Dec 2005 00:15:42 +0900 To: "Thomas D. Nadeau" From: Ken Nagami Subject: Re: [mpls] Comments for fastreroute-mib-04 In-Reply-To: <2AFC08F3-2DBB-4329-8B66-B87C4F803D1D@cisco.com> References: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> <2AFC08F3-2DBB-4329-8B66-B87C4F803D1D@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Tom, Thnak you for your reply. I agree that your method can get a 2nd label during a local repair in use. However, before using a local repair, I do not understand why your method can get a 2nd label. A Cross-Connect in the MPLS-LSR-STD-MIB for the 2nd label is only created during the local repair in use. So, before using a local repair, I think I can not get the 2nd label. Is this correct? Regards, Ken Nagami At 23:17 05/12/07, Thomas D. Nadeau wrote: >On Nov 29, 2005, at 9:06 PM, Ken Nagami wrote: > >>Dear authors and all, >> >>I have a following comment for the FRR MIB (draft-ietf-mpls- >>fastreroute-mib-04). >>Could you reflect this comment in the document? >> >>Comment: >>I would like to get a 2nd label of a bypass tunnel at a PLR in the >>facility backup. >>I think a pointer of 1st (top) label of the bypass tunnel at a PLR >>can be get from the FRR MIB. >>But the 2nd label can not be get. >> >>Because I would like to check a 2nd label of a bypass tunnel and an >>incoming label at the MP. >>In the case of the node protection, two label values are normally >>the same. >>But if a router has a bug, the value might be different. >>So, we would like to check those values before local repair from a >>network management box. > > The MPLS-FRR-MIB provides a reference back to the TE tunnel >in the MPLS-TE-STD-MIB which can be used to find the LSP that >is in use for that tunnel head. From the tunnelEntry in the MPLS-TE- STD-MIB >you can get the Cross-Connect (XCindex) of the LSP that is in use for >that >tunnel head from the MPLS-LSR-STD-MIB, which will have a corresponding >mplsLabelStackTable entry that should have the extra label >shown under the top label shown in the mplsInSegmentTable. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 07 11:11:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1t8-0007sy-AM; Wed, 07 Dec 2005 11:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1t6-0007rQ-3P for mpls@megatron.ietf.org; Wed, 07 Dec 2005 11:11:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24462 for ; Wed, 7 Dec 2005 11:10:31 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek2En-0005Mt-HH for mpls@ietf.org; Wed, 07 Dec 2005 11:33:51 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2005 08:11:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="16777129:sNHT24036756" Received: from [161.44.71.153] ([161.44.71.153]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB7GBA4X020538; Wed, 7 Dec 2005 11:11:11 -0500 (EST) In-Reply-To: <6.2.3.4.2.20051207232950.082ce6f0@inc.inetcore.com> References: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> <2AFC08F3-2DBB-4329-8B66-B87C4F803D1D@cisco.com> <6.2.3.4.2.20051207232950.082ce6f0@inc.inetcore.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Comments for fastreroute-mib-04 Date: Wed, 7 Dec 2005 11:11:05 -0500 To: Ken Nagami X-Mailer: Apple Mail (2.746.2) X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [161.44.71.153] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org On Dec 7, 2005, at 10:15 AM, Ken Nagami wrote: > Hi Tom, > > Thnak you for your reply. > > I agree that your method can get a 2nd label during a local repair > in use. > However, before using a local repair, I do not understand why your > method can get a 2nd label. > A Cross-Connect in the MPLS-LSR-STD-MIB for the 2nd label > is only created during the local repair in use. > So, before using a local repair, I think I can not get the 2nd label. > Is this correct? That is correct. However, since the backup/protection tunnel is signaled at the time you configure protection, the LSP (i.e.: label) should be active. The LFIB should just not be moving any traffic onto that tunnel at the PLR. --Tom > > Regards, > > Ken Nagami > > > At 23:17 05/12/07, Thomas D. Nadeau wrote: > >> On Nov 29, 2005, at 9:06 PM, Ken Nagami wrote: >> >>> Dear authors and all, >>> >>> I have a following comment for the FRR MIB (draft-ietf-mpls- >>> fastreroute-mib-04). >>> Could you reflect this comment in the document? >>> >>> Comment: >>> I would like to get a 2nd label of a bypass tunnel at a PLR in the >>> facility backup. >>> I think a pointer of 1st (top) label of the bypass tunnel at a PLR >>> can be get from the FRR MIB. >>> But the 2nd label can not be get. >>> >>> Because I would like to check a 2nd label of a bypass tunnel and an >>> incoming label at the MP. >>> In the case of the node protection, two label values are normally >>> the same. >>> But if a router has a bug, the value might be different. >>> So, we would like to check those values before local repair from a >>> network management box. >> >> The MPLS-FRR-MIB provides a reference back to the TE tunnel >> in the MPLS-TE-STD-MIB which can be used to find the LSP that >> is in use for that tunnel head. From the tunnelEntry in the MPLS- >> TE- STD-MIB >> you can get the Cross-Connect (XCindex) of the LSP that is in use for >> that >> tunnel head from the MPLS-LSR-STD-MIB, which will have a >> corresponding >> mplsLabelStackTable entry that should have the extra label >> shown under the top label shown in the mplsInSegmentTable. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Dec 08 17:14:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkU1v-0004RR-OX; Thu, 08 Dec 2005 17:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkU1s-0004Mz-2D for mpls@megatron.ietf.org; Thu, 08 Dec 2005 17:14:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28632 for ; Thu, 8 Dec 2005 17:13:26 -0500 (EST) Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkU1u-0007bk-JU for mpls@ietf.org; Thu, 08 Dec 2005 17:14:24 -0500 Received: from 57-97.dsl.data.net.uk ([80.68.57.97] helo=dnni.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1EkU1t-0003Rz-00 for mpls@ietf.org; Thu, 08 Dec 2005 22:14:21 +0000 Content-class: urn:content-classes:message Subject: RE: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Dec 2005 22:13:58 -0000 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? Thread-Index: AcX6Xr/RR/mlzldOQXyoyheUvas+wAB2sjVw From: "Daniel King" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes, I think the document should become a WG doc. Thanks, Dan=20 -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, December 06, 2005 12:11 PM To: mpls@ietf.org; George Swallow Subject: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? All, In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, when aksing the room about the consensus on making it a working group document, there were good support for making it a working group document. We said that we wanted to confirm this on the list. Please send response to this mail to the MPLS mailing list stating whether you think it should become a working group document or not. /Loa --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Dec 08 22:09:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYdt-0001BQ-9r; Thu, 08 Dec 2005 22:09:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYds-0001Al-DG for mpls@megatron.ietf.org; Thu, 08 Dec 2005 22:09:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26838 for ; Thu, 8 Dec 2005 22:08:51 -0500 (EST) Received: from jens246.inetcore.com ([202.33.8.246] helo=chappy.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkYdn-0008QQ-RE for mpls@ietf.org; Thu, 08 Dec 2005 22:09:51 -0500 Received: from nagami-T42.wide.ad.jp (nt-23 [172.16.2.1]) by chappy.inetcore.com (8.13.3/8.13.3) with ESMTP id jB939N8I013482; Fri, 9 Dec 2005 12:09:24 +0900 (JST) (envelope-from nagami@wide.ad.jp) Message-Id: <6.2.3.4.2.20051209112835.0b6b8eb0@inc.inetcore.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Fri, 09 Dec 2005 12:09:18 +0900 To: "Thomas D. Nadeau" From: Ken Nagami Subject: Re: [mpls] Comments for fastreroute-mib-04 In-Reply-To: References: <6.2.0.14.2.20051130102315.08cf25f0@gw.inetcore.com> <2AFC08F3-2DBB-4329-8B66-B87C4F803D1D@cisco.com> <6.2.3.4.2.20051207232950.082ce6f0@inc.inetcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org At 01:11 05/12/08, Thomas D. Nadeau wrote: >On Dec 7, 2005, at 10:15 AM, Ken Nagami wrote: > >>Hi Tom, >> >>Thnak you for your reply. >> >>I agree that your method can get a 2nd label during a local repair >>in use. >>However, before using a local repair, I do not understand why your >>method can get a 2nd label. >>A Cross-Connect in the MPLS-LSR-STD-MIB for the 2nd label >>is only created during the local repair in use. >>So, before using a local repair, I think I can not get the 2nd label. >>Is this correct? > > That is correct. However, since the backup/protection >tunnel is signaled at the time you configure protection, >the LSP (i.e.: label) should be active. The LFIB should >just not be moving any traffic onto that tunnel at the PLR. I understand that the bypass LSP is active when I configure protection. Before using a local repair, we can not get the 2nd label on the bypass LSP, because the protected LSP is not on the bypass LSP. This is an issue. It is important to check whether the 2nd label of the bypass LSP and the top label of the protected LSP are the same BEFORE a local repair is working. We can check the above label values when the local repair is working. But this check is too late. If the check is fail, the customer traffic goes to wrong direction. I think the FRR-MIB is better place to get the 2nd label of the bypass LSP before a local repair is working. Regards, Ken Nagami > --Tom > > >> >>Regards, >> >>Ken Nagami >> >> >>At 23:17 05/12/07, Thomas D. Nadeau wrote: >> >>>On Nov 29, 2005, at 9:06 PM, Ken Nagami wrote: >>> >>>>Dear authors and all, >>>> >>>>I have a following comment for the FRR MIB (draft-ietf-mpls- >>>>fastreroute-mib-04). >>>>Could you reflect this comment in the document? >>>> >>>>Comment: >>>>I would like to get a 2nd label of a bypass tunnel at a PLR in the >>>>facility backup. >>>>I think a pointer of 1st (top) label of the bypass tunnel at a PLR >>>>can be get from the FRR MIB. >>>>But the 2nd label can not be get. >>>> >>>>Because I would like to check a 2nd label of a bypass tunnel and an >>>>incoming label at the MP. >>>>In the case of the node protection, two label values are normally >>>>the same. >>>>But if a router has a bug, the value might be different. >>>>So, we would like to check those values before local repair from a >>>>network management box. >>> >>> The MPLS-FRR-MIB provides a reference back to the TE tunnel >>>in the MPLS-TE-STD-MIB which can be used to find the LSP that >>>is in use for that tunnel head. From the tunnelEntry in the MPLS- TE- STD-MIB >>>you can get the Cross-Connect (XCindex) of the LSP that is in use for >>>that >>>tunnel head from the MPLS-LSR-STD-MIB, which will have a >>>corresponding >>>mplsLabelStackTable entry that should have the extra label >>>shown under the top label shown in the mplsInSegmentTable. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Dec 09 07:33:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkhR7-0004ur-NZ; Fri, 09 Dec 2005 07:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkhR5-0004uK-QQ for mpls@megatron.ietf.org; Fri, 09 Dec 2005 07:33:15 -0500 Received: from mail2.zte.com.cn ([202.103.147.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27107 for ; Fri, 9 Dec 2005 07:32:09 -0500 (EST) From: jiang.weilian@zte.com.cn Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 95265.356981843; Fri, 9 Dec 2005 21:31:16 +0800 (CST) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Date: Fri, 9 Dec 2005 20:33:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-12-09 20:33:13, Serialize complete at 2005-12-09 20:33:13 Cc: Subject: [mpls] Hello everybody. Would you give me some advices about the draft "draft-jian-ccamp-multinodes-rsvp-restart-00"? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317174659==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1317174659== Content-Type: multipart/alternative; boundary="=_alternative 0044AAC6482570D2_=" This is a multipart message in MIME format. --=_alternative 0044AAC6482570D2_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id HAA27107 SGVsbG8gZXZlcnlib2R5LA0KDQpJIGNvbWUgZm9ybSBaVEUgQ29ycG9yYXRpb24gaW4gQ2hp bmEuIE5vdyBJJ20gd29ya2luZyBhdCB0aGUgc3R1ZHkgDQpvZiBSU1ZQLVRFLiANCg0KSSBz dWJtaXR0ZWQgYSBkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5vZGVzLXJzdnAtcmVz dGFydC0wMCIgDQp0byBJRVRGIHNvbWUgdGltZSBhZ28uIFRoaXMgaXMgbXkgZmlyc3Qgc3Vi bWlzc2lvbi4NCg0KU28gSSBzaW5jZXJlbHkgZXhwZWN0IHRoYXQgc29tZW9uZSBjYW4gaGVs cCBtZSBhbmQgZ2ltZSBtZSBzb21lIA0KYWR2aWNlcy4NCg0KVGhhbmtzIGluIGFkdmFuY2Uu DQoNCkppYW5nIFdlaWxpYW4NClpURSBDb3Jwb3JhdGlvbg0KMjAwNS0xMi0wOQ0KDQoNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQrkv6Hmga/l ronlhajlo7DmmI7vvJrmnKzpgq7ku7bljIXlkKvkv6Hmga/lvZJaVEXmiYDmnInvvIwNClpU ReWvueivpemCruS7tuaLpeacieaJgOacieadg+WIqeOAguivt+aOpeaUtuiAheazqOaEjw0K 5L+d5a+G77yM5pyq57uP5Y+R5Lu25Lq65Lmm6Z2i6K645Y+v77yM5LiN5b6X5ZCR5Lu75L2V 56ysDQrkuInmlrnnu4Tnu4flkozkuKrkurrpgI/pnLLmnKzpgq7ku7bmiYDlkKvkv6Hmga/n moTlhajpg6gNCuaIlumDqOWIhuOAguS7peS4iuWjsOaYjuS7hemAgueUqOS6juW3peS9nOmC ruS7tuOAgg0KSW5mb3JtYXRpb24gU2VjdXJpdHkgIE5vdGljZe+8mg0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMNCnNvbGVseSBwcm9wZXJ0eSBvZiAgWlRF IENvcnBvcmF0aW9uLiANClRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4NClJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0bw0KbWFpbnRhaW4g c2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8NCmRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24NCnRvIG90aGVycy4NCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --=_alternative 0044AAC6482570D2_= Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id HAA27107 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIGV2ZXJ5Ym9keSw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgY29t ZSBmb3JtIFpURSBDb3Jwb3JhdGlvbiBpbiBDaGluYS4NCk5vdyBJJ20gd29ya2luZyBhdCB0 aGUgc3R1ZHkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5v ZiBSU1ZQLVRFLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkkgc3VibWl0dGVkIGEgZHJhZnQgJnF1b3Q7ZHJhZnQtamlhbi1jY2FtcC1tdWx0 aW5vZGVzLXJzdnAtcmVzdGFydC0wMCZxdW90Ow0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj50byBJRVRGIHNvbWUgdGltZSBhZ28uIFRoaXMgaXMgbXkg Zmlyc3QNCnN1Ym1pc3Npb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5TbyBJIHNpbmNlcmVseSBleHBlY3QgdGhhdCBzb21lb25lIGNhbg0K aGVscCBtZSBhbmQgZ2ltZSBtZSBzb21lIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+YWR2aWNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBpbiBhZHZhbmNlLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmlhbmcgV2VpbGlhbjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WlRFIENvcnBvcmF0aW9uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yMDA1LTEyLTA5PC9m b250Pjxicj48YnI+PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKio8YnI+DQrkv6Hmga/lronlhajlo7DmmI7vvJrmnKzpgq7ku7bljIXlkKvk v6Hmga/lvZJaVEXmiYDmnInvvIw8YnI+DQpaVEXlr7nor6Xpgq7ku7bmi6XmnInmiYDmnInm nYPliKnjgILor7fmjqXmlLbogIXms6jmhI88YnI+DQrkv53lr4bvvIzmnKrnu4/lj5Hku7bk urrkuabpnaLorrjlj6/vvIzkuI3lvpflkJHku7vkvZXnrKw8YnI+DQrkuInmlrnnu4Tnu4fl kozkuKrkurrpgI/pnLLmnKzpgq7ku7bmiYDlkKvkv6Hmga/nmoTlhajpg6g8YnI+DQrmiJbp g6jliIbjgILku6XkuIrlo7DmmI7ku4XpgILnlKjkuo7lt6XkvZzpgq7ku7bjgII8YnI+DQpJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Jm5ic3A7Tm90aWNl77yaPGJyPg0KVGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXM8YnI+DQpzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 Jm5ic3A7WlRFJm5ic3A7Q29ycG9yYXRpb24uJm5ic3A7PGJyPg0KVGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuPGJyPg0KUmVj aXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0bzxicj4NCm1haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvPGJyPg0KZGlzY2xvc2UmbmJzcDt0aGUm bmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb248YnI+ DQp0byZuYnNwO290aGVycy48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKjxicj4NCg== --=_alternative 0044AAC6482570D2_=-- --===============1317174659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1317174659==-- From mpls-bounces@lists.ietf.org Fri Dec 09 10:53:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkYd-0007uT-MI; Fri, 09 Dec 2005 10:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkYX-0007ts-BR for mpls@megatron.ietf.org; Fri, 09 Dec 2005 10:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22045 for ; Fri, 9 Dec 2005 10:52:05 -0500 (EST) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkkYY-0000If-J0 for mpls@ietf.org; Fri, 09 Dec 2005 10:53:12 -0500 Received: from du-069-0023.access.clara.net ([217.158.132.23] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1EkkYF-000EuR-6s; Fri, 09 Dec 2005 15:52:52 +0000 Message-ID: <03f501c5fcd9$1951c820$9d849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [mpls] Hello everybody. Would you give me some advices about thedraft "draft-jian-ccamp-multinodes-rsvp-restart-00"? Date: Fri, 9 Dec 2005 15:55:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA22045 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Jiang, Your best approach is to send an email to the CCAMP mailing list. Your email should: - introduce the draft (draft name and title) - summarise the purpose of the draft - invite comments and discussion (perhaps there are some areas where you would like to request specific help?) Regards, Adrian ----- Original Message -----=20 From: To: Sent: Friday, December 09, 2005 12:33 PM Subject: [mpls] Hello everybody. Would you give me some advices about thedraft "draft-jian-ccamp-multinodes-rsvp-restart-00"? > Hello everybody, > > I come form ZTE Corporation in China. Now I'm working at the study > of RSVP-TE. > > I submitted a draft "draft-jian-ccamp-multinodes-rsvp-restart-00" > to IETF some time ago. This is my first submission. > > So I sincerely expect that someone can help me and gime me some > advices. > > Thanks in advance. > > Jiang Weilian > ZTE Corporation > 2005-12-09 > > > *********************************************** > =E4=BF=A1=E6=81=AF=E5=AE?=E5.=A8=E5=A3=B0=E6~Z=EF=BCs=E6o=AC=E9,=AE=E4=BB= =B6=E5O.=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD'ZTE=E6??=E6o?=EF=BCO > ZTE=E5=AF=B9=E8=AF=A5=E9,=AE=E4=BB=B6=E6<=A5=E6o?=E6??=E6o?=E6=9Df=E5^=A9= =E3?,=E8=AF=B7=E6Z=A5=E6"=B6=E8?.=E6=B3=A8=E6"=8F > =E4=BF=9D=E5=AF?=EF=BCO=E6o=AA=E7=BB=8F=E5=8F'=E4=BB=B6=E4=BA=BA=E4=B9=A6= =E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BCO=E4=B8=8D=E5=BE-=E5=90'=E4=BB=BB=E4=BD.= =E7=AC=AC > =E4=B8?=E6-=B9=E7=BB"=E7=BB?=E5'O=E4=B8=AA=E4=BA=BA=E9?=8F=E9o=B2=E6o=AC= =E9,=AE=E4=BB=B6=E6??=E5=90=AB=E4=BF=A1=E6=81=AF=E7s"=E5.=A8=E9f=A8 > =E6^-=E9f=A8=E5^?=E3?,=E4=BB=A5=E4=B8S=E5=A3=B0=E6~Z=E4=BB.=E9?,=E7"=A8= =E4=BAZ=E5=B7=A5=E4=BDo=E9,=AE=E4=BB=B6=E3?, > Information Security Notice=EF=BCs > The information contained in this mail is > solely property of ZTE Corporation. > This mail communication is confidential. > Recipients named above are obligated to > maintain secrecy and are not permitted to > disclose the contents of this communication > to others. > *********************************************** > -------------------------------------------------------------------------= - ------ > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Dec 09 22:38:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvYz-0001zs-DV; Fri, 09 Dec 2005 22:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvYx-0001z9-2u for mpls@megatron.ietf.org; Fri, 09 Dec 2005 22:38:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04784 for ; Fri, 9 Dec 2005 22:37:15 -0500 (EST) From: jiang.weilian@zte.com.cn Received: from [202.103.147.144] (helo=mail2.zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkvZ5-0006Re-6i for mpls@ietf.org; Fri, 09 Dec 2005 22:38:28 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 95265.916384670; Sat, 10 Dec 2005 12:36:49 +0800 (CST) In-Reply-To: <03f501c5fcd9$1951c820$9d849ed9@Puppy> To: "Adrian Farrel" Subject: =?GB2312?B?tPC4tDogUmU6IFttcGxzXSBIZWxsbyBldmVyeWJvZHkuIFdvdWxkIHlvdQ==?= =?GB2312?B?IGdpdmUgbWUgc29tZSBhZHZpY2VzIGFib3V0IHRoZWRyYWZ0ICI=?= =?GB2312?B?ZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5vZGVzLXJzdnAtcmVzdGFydC0wMCI/?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Date: Sat, 10 Dec 2005 10:27:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-12-10 11:40:54, Serialize complete at 2005-12-10 11:40:54 X-Spam-Score: 0.3 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542099270==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0542099270== Content-Type: multipart/alternative; boundary="=_alternative 000D2B8E482570D3_=" This is a multipart message in MIME format. --=_alternative 000D2B8E482570D3_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Adrian, I'm very glad to receive reply from you.Thank you ever so much. I will try to do as you told to me. Regards, Jiang Weilian 2005-12-10 "Adrian Farrel" 09/12/2005 23:55 ??? ? "Adrian Farrel" =20 ???? ??? ??? Re: [mpls] Hello everybody. Would you give me some advices=20 about thedraft "draft-jian-ccamp-multinodes-rsvp-restart-00"? Hi Jiang, Your best approach is to send an email to the CCAMP mailing list. Your email should: - introduce the draft (draft name and title) - summarise the purpose of the draft - invite comments and discussion (perhaps there are some areas where you would like to request specific help?) Regards, Adrian ----- Original Message -----=20 From: To: Sent: Friday, December 09, 2005 12:33 PM Subject: [mpls] Hello everybody. Would you give me some advices about thedraft "draft-jian-ccamp-multinodes-rsvp-restart-00"? > Hello everybody, > > I come form ZTE Corporation in China. Now I'm working at the study > of RSVP-TE. > > I submitted a draft "draft-jian-ccamp-multinodes-rsvp-restart-00" > to IETF some time ago. This is my first submission. > > So I sincerely expect that someone can help me and gime me some > advices. > > Thanks in advance. > > Jiang Weilian > ZTE Corporation > 2005-12-09 > > > *********************************************** > =E4=BF=A1=E6=81=AF=E5=AE?=E5.=A8=E5=A3=B0=E6~Z=EF=BCs=E6o=AC=E9,=AE=E4=BB= =B6=E5O.=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD'ZTE=E6??=E6o?=EF=BCO > ZTE=E5=AF=B9=E8=AF=A5=E9,=AE=E4=BB=B6=E6<=A5=E6o?=E6??=E6o?=E6=9Df=E5^=A9= =E3?,=E8=AF=B7=E6Z=A5=E6"=B6=E8?.=E6=B3=A8=E6"=8F > =E4=BF=9D=E5=AF?=EF=BCO=E6o=AA=E7=BB=8F=E5=8F'=E4=BB=B6=E4=BA=BA=E4=B9=A6= =E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BCO=E4=B8=8D=E5=BE-=E5=90'=E4=BB=BB=E4=BD.= =E7=AC=AC > =E4=B8?=E6-=B9=E7=BB"=E7=BB?=E5'O=E4=B8=AA=E4=BA=BA=E9?=8F=E9o=B2=E6o=AC= =E9,=AE=E4=BB=B6=E6??=E5=90=AB=E4=BF=A1=E6=81=AF=E7s"=E5.=A8=E9f=A8 > =E6^-=E9f=A8=E5^?=E3?,=E4=BB=A5=E4=B8S=E5=A3=B0=E6~Z=E4=BB.=E9?,=E7"=A8= =E4=BAZ=E5=B7=A5=E4=BDo=E9,=AE=E4=BB=B6=E3?, > Information Security Notice=EF=BCs > The information contained in this mail is > solely property of ZTE Corporation. > This mail communication is confidential. > Recipients named above are obligated to > maintain secrecy and are not permitted to > disclose the contents of this communication > to others. > *********************************************** > -------------------------------------------------------------------------- ------ > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > ************************************************ The email has been scanned by Anti-Spam system, if you find Spam or Virus in this mail, please forward it to: helpdesk@zte.com.cn ************************************************ =0A=0A=0A***********************************************=0A=E4=BF=A1=E6=81= =AF=E5=AE=89=E5=85=A8=E5=A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC=E9=82=AE=E4=BB=B6= =E5=8C=85=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD=92ZTE=E6=89=80=E6=9C=89=EF=BC=8C= =0AZTE=E5=AF=B9=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=8B=A5=E6=9C=89=E6=89=80=E6=9C= =89=E6=9D=83=E5=88=A9=E3=80=82=E8=AF=B7=E6=8E=A5=E6=94=B6=E8=80=85=E6=B3=A8= =E6=84=8F=0A=E4=BF=9D=E5=AF=86=EF=BC=8C=E6=9C=AA=E7=BB=8F=E5=8F=91=E4=BB=B6= =E4=BA=BA=E4=B9=A6=E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BC=8C=E4=B8=8D=E5=BE=97=E5= =90=91=E4=BB=BB=E4=BD=95=E7=AC=AC=0A=E4=B8=89=E6=96=B9=E7=BB=84=E7=BB=87=E5= =92=8C=E4=B8=AA=E4=BA=BA=E9=80=8F=E9=9C=B2=E6=9C=AC=E9=82=AE=E4=BB=B6=E6=89= =80=E5=90=AB=E4=BF=A1=E6=81=AF=E7=9A=84=E5=85=A8=E9=83=A8=0A=E6=88=96=E9=83= =A8=E5=88=86=E3=80=82=E4=BB=A5=E4=B8=8A=E5=A3=B0=E6=98=8E=E4=BB=85=E9=80=82= =E7=94=A8=E4=BA=8E=E5=B7=A5=E4=BD=9C=E9=82=AE=E4=BB=B6=E3=80=82=0AInformati= on Security Notice=EF=BC=9A=0AThe information contained in this mail is=0A= solely property of ZTE Corporation.=20=0AThis mail communication is confid= ential.=0ARecipients named above are obligated to=0Amaintain secrecy and ar= e not permitted to=0Adisclose the contents of this communication=0Ato other= s.=0A***********************************************=0A --=_alternative 000D2B8E482570D3_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Adria= n,

I'm very glad to receive reply from you.Thank you ever so much.

I will try to do as you told to me.<= /font>

Regards,
Jiang Weilian
2005-12-10




"Adrian Farrel" <adr= ian@olddog.co.uk>

09/12/2005 23:55
请答复 给 &q= uot;Adrian Farrel"

       
        收= 件人：        <jiang.weilian@zte.com.cn>
        抄= 送：        <mpls@ietf.org>
        主= 题：        Re: [mpls] Hello everybody. Would you give me some advices about thedraft "draft-jian-ccamp-multinodes-rsvp-= restart-00"?



Hi Jiang,

Your best approach is to send an email to the CCAMP mailing list.

Your email should:
- introduce the draft (draft name and title)
- summarise the purpose of the draft
- invite comments and discussion
  (perhaps there are some areas where you would like to
   request specific help?)

Regards,
Adrian
----- Original Message -----
From: <jiang.weilian@zte.com.cn>
To: <mpls@ietf.org>
Sent: Friday, December 09, 2005 12:33 PM
Subject: [mpls] Hello everybody. Would you give me some advices about
thedraft "draft-jian-ccamp-multinodes-rsvp-restart-00"?


> Hello everybody,
>
> I come form ZTE Corporation in China. Now I'm working at the study
> of RSVP-TE.
>
> I submitted a draft "draft-jian-ccamp-multinodes-rsvp-restart-00&= quot;
> to IETF some time ago. This is my first submission.
>
> So I sincerely expect that someone can help me and gime me some
> advices.
>
> Thanks in advance.
>
> Jiang Weilian
> ZTE Corporation
> 2005-12-09
>
>
> ***********************************************
> =E4=BF=A1=E6=81=AF=E5=AE?=E5.=A8=E5=A3=B0=E6~Z=EF=BCs=E6o=AC=E9,=AE=E4= =BB=B6=E5O.=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD'ZTE=E6??=E6o?=EF=BCO
> ZTE=E5=AF=B9=E8=AF=A5=E9,=AE=E4=BB=B6=E6<=A5=E6o?=E6??=E6o?=E6=9Df= =E5^=A9=E3?,=E8=AF=B7=E6Z=A5=E6"=B6=E8?.=E6=B3=A8=E6"=8F
> =E4=BF=9D=E5=AF?=EF=BCO=E6o=AA=E7=BB=8F=E5=8F'=E4=BB=B6=E4=BA=BA=E4=B9= =A6=E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BCO=E4=B8=8D=E5=BE-=E5=90'=E4=BB=BB=E4=BD= .=E7=AC=AC
> =E4=B8?=E6-=B9=E7=BB"=E7=BB?=E5'O=E4=B8=AA=E4=BA=BA=E9?=8F=E9o=B2= =E6o=AC=E9,=AE=E4=BB=B6=E6??=E5=90=AB=E4=BF=A1=E6=81=AF=E7s"=E5.=A8=E9= f=A8
> =E6^-=E9f=A8=E5^?=E3?,=E4=BB=A5=E4=B8S=E5=A3=B0=E6~Z=E4=BB.=E9?,=E7&qu= ot;=A8=E4=BAZ=E5=B7=A5=E4=BDo=E9,=AE=E4=BB=B6=E3?,
> Information Security  Notice=EF=BCs
> The information contained in this mail is
> solely property of  ZTE Corporation.
> This mail communication is confidential.
> Recipients named above are obligated to
> maintain secrecy and are not permitted to
> disclose the contents of this communication
> to others.
> ***********************************************
>


--------------------------------------------------------------------------<= br> ------


> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>




************************************************
The email has  been scanned by Anti-Spam
system,  if you find Spam or Virus in this mail,
please forward it to: helpdesk@zte.com.cn
************************************************



=0A***********************************************
=0A= =E4=BF=A1=E6=81=AF=E5=AE=89=E5=85=A8=E5=A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC=E9= =82=AE=E4=BB=B6=E5=8C=85=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD=92ZTE=E6=89=80=E6= =9C=89=EF=BC=8C
=0AZTE=E5=AF=B9=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=8B=A5=E6= =9C=89=E6=89=80=E6=9C=89=E6=9D=83=E5=88=A9=E3=80=82=E8=AF=B7=E6=8E=A5=E6=94= =B6=E8=80=85=E6=B3=A8=E6=84=8F
=0A=E4=BF=9D=E5=AF=86=EF=BC=8C=E6=9C=AA= =E7=BB=8F=E5=8F=91=E4=BB=B6=E4=BA=BA=E4=B9=A6=E9=9D=A2=E8=AE=B8=E5=8F=AF=EF= =BC=8C=E4=B8=8D=E5=BE=97=E5=90=91=E4=BB=BB=E4=BD=95=E7=AC=AC
=0A=E4=B8= =89=E6=96=B9=E7=BB=84=E7=BB=87=E5=92=8C=E4=B8=AA=E4=BA=BA=E9=80=8F=E9=9C=B2= =E6=9C=AC=E9=82=AE=E4=BB=B6=E6=89=80=E5=90=AB=E4=BF=A1=E6=81=AF=E7=9A=84=E5= =85=A8=E9=83=A8
=0A=E6=88=96=E9=83=A8=E5=88=86=E3=80=82=E4=BB=A5=E4=B8= =8A=E5=A3=B0=E6=98=8E=E4=BB=85=E9=80=82=E7=94=A8=E4=BA=8E=E5=B7=A5=E4=BD=9C= =E9=82=AE=E4=BB=B6=E3=80=82
=0AInformation Security  Noti= ce=EF=BC=9A
=0AThe information contained in this&nbs= p;mail is
=0Asolely property of  ZTE Corpo= ration. 
=0AThis mail communication is confiden= tial.
=0ARecipients named above are obligated t= o
=0Amaintain secrecy and are not permitted&nbs= p;to
=0Adisclose the contents of this communica= tion
=0Ato others.
=0A******************************************= *****
=0A --=_alternative 000D2B8E482570D3_=-- --===============0542099270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0542099270==-- From mpls-bounces@lists.ietf.org Sun Dec 11 14:18:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElWiP-0008Li-B3; Sun, 11 Dec 2005 14:18:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElWiM-0008Jg-Ch for mpls@megatron.ietf.org; Sun, 11 Dec 2005 14:18:31 -0500 Received: from WS0005.indiatimes.com (smtp5.indiatimes.com [203.199.93.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26583 for ; Sun, 11 Dec 2005 14:17:33 -0500 (EST) Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id AAA01923 for ; Mon, 12 Dec 2005 00:36:52 +0530 From: "chasey_ch" Message-Id: <200512111906.AAA01923@WS0005.indiatimes.com> To: Subject: Re:[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become aworking group document? Date: Mon, 12 Dec 2005 00:56:53 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chasey_ch List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org few humble questions (tell me if am wrong fundamentally): 1. why the draft doesnt talk about segment OAM though for PMP scalability as an issue? 2. why there is no mention of OAM procedure for backup tunnel (especially for facility protection when one path can backup multiple paths, hence should never go down ideally) thanks, chasey [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become aworking group document? From: "Sheetal A. Vispute_p05274" Date: Wed, 7 Dec 2005 12:47:43 +0530 (IST) Cc: mpls@ietf.org Hi Loa, yes it very important to become a WG doc cheers Sheetal On Tue, 6 Dec 2005, Loa Andersson wrote: > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls References: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? From: Loa Andersson [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? From: Loa Andersson _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Dec 12 06:40:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elm36-0007hj-Mg; Mon, 12 Dec 2005 06:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elm2z-0007gZ-Pq for mpls@megatron.ietf.org; Mon, 12 Dec 2005 06:40:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08840 for ; Mon, 12 Dec 2005 06:39:44 -0500 (EST) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elm3b-0008Rl-SZ for mpls@ietf.org; Mon, 12 Dec 2005 06:41:29 -0500 Received: from du-069-0198.access.clara.net ([217.158.132.198] helo=Puppy) by relay3.mail.uk.clara.net with esmtp (Exim 4.46) id 1Elm2g-000KUq-DZ; Mon, 12 Dec 2005 11:40:31 +0000 Message-ID: <057601c5ff11$5bb78d50$9d849ed9@Puppy> From: "Adrian Farrel" To: "chasey_ch" , References: <200512111906.AAA01923@WS0005.indiatimes.com> Subject: Re: Re:[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txt to become a working group document? Date: Mon, 12 Dec 2005 11:44:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi Chasey, Thanks for the comments. > Subject: Re:[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txt to become > a working group document? > > few humble questions > (tell me if am wrong fundamentally): > > 1. why the draft doesnt talk about segment OAM though for PMP scalability > as an issue? Scalability is as much a requirement for P2MP as for P2P. In fact, since the nature of P2MP is that there are more egresses per LSP, scalability must be given considerably more attention. You specifically ask about "segment OAM" so I wondered if you were referring to a technique already described in draft-ietf-mpls-oam-requirements, but I can't find any reference there. So perhaps you are suggesting some new behaviors and requirements specific to P2MP? Maybe if you could spell out what you are thinking about in a little more detail we could consider incorporating it into a future version of the draft. > 2. why there is no mention of OAM procedure for backup tunnel > (especially for facility protection when one path can backup multiple > paths, hence should never go down ideally) I am not clear why your question is specific to P2MP. But I am also not clear why you single out facility backup tunnels as being more critical than other tunnels. The importance of a tunnel depends on the use to which it is put, and it is quite possible that many tunnels are more critical than facility backup tunnels. Further, your comment says that a facility backup tunnel "should never go down ideally". But you must observe that we are talking about OAM. OAM does not prevent tunnels from going down. It simply allows you to detect and isolate faults (conversely to monitor the continued absence of faults). Again, perhaps you could indicate what you would like to see described in the draft so that we can look at how to include it. Thanks, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 13 18:50:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJuI-0004r1-41; Tue, 13 Dec 2005 18:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJuE-0004pf-J0 for mpls@megatron.ietf.org; Tue, 13 Dec 2005 18:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15374 for ; Tue, 13 Dec 2005 18:49:04 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EmJuE-0003Zn-6v; Tue, 13 Dec 2005 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Dec 2005 18:50:02 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs Author(s) : S. Yasukawa Filename : draft-ietf-mpls-p2mp-sig-requirement-04.txt Pages : 28 Date : 2005-12-13 This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution specific details nor application specific requirements in this document. The requirements presented in this document apply equally to packet switched networks under the control of MPLS protocols and to but also encompass the requirements of Layer two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-p2mp-sig-requirement-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-13161422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-sig-requirement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-13161422.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Dec 14 06:32:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmUs7-00009W-LV; Wed, 14 Dec 2005 06:32:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmUs6-000081-7Y for mpls@megatron.ietf.org; Wed, 14 Dec 2005 06:32:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08802 for ; Wed, 14 Dec 2005 06:31:35 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmUtH-0001xd-GM for mpls@ietf.org; Wed, 14 Dec 2005 06:33:48 -0500 Received: from du-069-0161.access.clara.net ([217.158.132.161] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EmUrt-0005ao-Gy; Wed, 14 Dec 2005 11:32:22 +0000 Message-ID: <09b101c600a2$897b50e0$9d849ed9@Puppy> From: "Adrian Farrel" To: , "Bill Fenner" , "Loa Andersson" , "George Swallow" , "Brian E Carpenter" Date: Wed, 14 Dec 2005 11:35:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: [mpls] Updated draft-ietf-mpls-p2mp-sig-requirement-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi, Seisho and I have produced an update to this draft as per our emails to the mailing list. This revision addresses the comments made by Harald in GenArt review. Looking at the status in the I-D tracker, this appears to handle all of the comments raised by IESG members during review. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, December 13, 2005 11:50 PM Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs > Author(s) : S. Yasukawa > Filename : draft-ietf-mpls-p2mp-sig-requirement-04.txt > Pages : 28 > Date : 2005-12-13 > > This document presents a set of requirements for the establishment > and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) > Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). > > There is no intent to specify solution specific details nor > application specific requirements in this document. > > The requirements presented in this document apply equally to packet > switched networks under the control of MPLS protocols and to but also > encompass the requirements of Layer two Switching (L2SC), Time > Division Multiplexing (TDM), lambda, and port switching networks > managed by Generalized MPLS (GMPLS) protocols. Protocol solutions > developed to meet the requirements set out in this document must > attempt to be equally applicable to MPLS and GMPLS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-04.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 14 06:50:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmV9f-0005PT-GF; Wed, 14 Dec 2005 06:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmV9d-0005PM-3I for mpls@megatron.ietf.org; Wed, 14 Dec 2005 06:50:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11170 for ; Wed, 14 Dec 2005 06:49:39 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmVAi-0002gy-Dg for mpls@ietf.org; Wed, 14 Dec 2005 06:51:51 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id DAA05419; Wed, 14 Dec 2005 03:50:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Dec 2005 17:20:21 +0530 Message-ID: Thread-Topic: Doubt regarding the MPLS TE tunnel bandwidth Thread-Index: AcYApI+WEkeqxGAiT2SisUyHKESkSQ== From: "Balaji, Hemanth" To: X-Spam-Score: 3.0 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Subject: [mpls] Doubt regarding the MPLS TE tunnel bandwidth X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936207483==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0936207483== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C600A4.8AB2DFB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C600A4.8AB2DFB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 I have a doubt regarding the MPLS TE tunnel bandwidth. My doubt is, if the tunnel interface is shut down, should the bandwidth allocated to it be released?. What does the standard say?=20 =20 =20 Thanks, Hemanth. =20 =20 =20 S.Hemanth Balaji. Member-Technical Staff Riverstone Networks India Pvt Ltd, (Present Location ph: 25502703 extn: 210) Ph: +91-80-51131932 extn 292 hbalaji@riverstonenet.com =20 ------_=_NextPart_001_01C600A4.8AB2DFB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

         I = have a doubt regarding the MPLS TE tunnel bandwidth. My doubt is, if the tunnel interface is shut down, should the bandwidth allocated = to

it be released?. What does the standard say? =

         =

 

Thanks,

Hemanth.

 

 

 

S.Hemanth = Balaji.

Member-Technical Staff

Riverstone Networks India Pvt Ltd,

(Present Location ph: 25502703 extn: = 210)

Ph: +91-80-51131932 extn 292

hbalaji@riverstonenet.com

 

------_=_NextPart_001_01C600A4.8AB2DFB4-- --===============0936207483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0936207483==-- From mpls-bounces@lists.ietf.org Wed Dec 14 06:57:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmVG0-0007FC-7R; Wed, 14 Dec 2005 06:57:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmVFs-0007E6-6Z for mpls@megatron.ietf.org; Wed, 14 Dec 2005 06:57:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12437 for ; Wed, 14 Dec 2005 06:56:01 -0500 (EST) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmVGt-00033o-F4 for mpls@ietf.org; Wed, 14 Dec 2005 06:58:14 -0500 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 14 Dec 2005 16:52:11 -0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBEBubKe025705; Wed, 14 Dec 2005 11:56:40 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Dec 2005 17:26:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Doubt regarding the MPLS TE tunnel bandwidth Date: Wed, 14 Dec 2005 17:26:38 +0530 Message-ID: Thread-Topic: [mpls] Doubt regarding the MPLS TE tunnel bandwidth thread-index: AcYApI+WEkeqxGAiT2SisUyHKESkSQAANMug From: "Kasu Venkat Reddy \(kvreddy\)" To: "Balaji, Hemanth" , X-OriginalArrivalTime: 14 Dec 2005 11:56:40.0491 (UTC) FILETIME=[71C3F7B0:01C600A5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966913809==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0966913809== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C600A5.71A6219E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C600A5.71A6219E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes its released. ________________________________ From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Balaji, Hemanth Sent: Wednesday, December 14, 2005 5:20 PM To: mpls@ietf.org Subject: [mpls] Doubt regarding the MPLS TE tunnel bandwidth =20 Hi, =20 I have a doubt regarding the MPLS TE tunnel bandwidth. My doubt is, if the tunnel interface is shut down, should the bandwidth allocated to it be released?. What does the standard say?=20 =20 =20 Thanks, Hemanth. =20 =20 =20 S.Hemanth Balaji. Member-Technical Staff Riverstone Networks India Pvt Ltd, (Present Location ph: 25502703 extn: 210) Ph: +91-80-51131932 extn 292 hbalaji@riverstonenet.com =20 ------_=_NextPart_001_01C600A5.71A6219E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes its released.

From: mpls-bounces@lists.ietf.org=20 [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Balaji,=20 Hemanth
Sent: Wednesday, December 14, 2005 5:20 = PM
To:=20 mpls@ietf.org
Subject: [mpls] Doubt regarding the MPLS TE = tunnel=20 bandwidth

 

Hi,

 

        =20 I have a doubt regarding the MPLS TE tunnel bandwidth. My doubt is, if = the=20 tunnel interface is shut down, should the bandwidth allocated=20 to

it be released?. What does = the=20 standard say?

        =20

 

Thanks,

Hemanth.

 

 

 

S.Hemanth=20 Balaji.

Member-Technical=20 Staff

Riverstone=20 Networks India Pvt Ltd,

(Present=20 Location ph: 25502703 extn: = 210)

Ph:=20 +91-80-51131932 extn 292

hbalaji@riverstonenet.com

 

------_=_NextPart_001_01C600A5.71A6219E-- --===============0966913809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0966913809==-- From mpls-bounces@lists.ietf.org Wed Dec 14 07:27:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmVj6-0006aT-JB; Wed, 14 Dec 2005 07:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmVj1-0006Zu-0c for mpls@megatron.ietf.org; Wed, 14 Dec 2005 07:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16287 for ; Wed, 14 Dec 2005 07:26:06 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmVk2-00047y-4R for mpls@ietf.org; Wed, 14 Dec 2005 07:28:19 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jBECQHQg095562 for ; Wed, 14 Dec 2005 12:26:21 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBECQH8x180348 for ; Wed, 14 Dec 2005 12:26:17 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jBECQHDc025510 for ; Wed, 14 Dec 2005 12:26:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jBECQHlY025501; Wed, 14 Dec 2005 12:26:17 GMT Received: from zurich.ibm.com (sig-9-145-128-35.de.ibm.com [9.145.128.35]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA17464; Wed, 14 Dec 2005 13:26:15 +0100 Message-ID: <43A00F63.4020804@zurich.ibm.com> Date: Wed, 14 Dec 2005 13:26:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Adrian Farrel References: <09b101c600a2$897b50e0$9d849ed9@Puppy> In-Reply-To: <09b101c600a2$897b50e0$9d849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Bill Fenner , mpls@ietf.org Subject: [mpls] Re: Updated draft-ietf-mpls-p2mp-sig-requirement-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org I'm just waiting for Harald to glance at it. Thanks. Brian Adrian Farrel wrote: > Hi, > > Seisho and I have produced an update to this draft as per our emails to > the mailing list. > > This revision addresses the comments made by Harald in GenArt review. > > Looking at the status in the I-D tracker, this appears to handle all of > the comments raised by IESG members during review. > > Thanks, > Adrian > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, December 13, 2005 11:50 PM > Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-sig-requirement-04.txt > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>This draft is a work item of the Multiprotocol Label Switching Working > > Group of the IETF. > >>Title : Signaling Requirements for Point to Multipoint Traffic > > Engineered MPLS LSPs > >>Author(s) : S. Yasukawa >>Filename : draft-ietf-mpls-p2mp-sig-requirement-04.txt >>Pages : 28 >>Date : 2005-12-13 >> >>This document presents a set of requirements for the establishment >> and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) >> Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). >> >> There is no intent to specify solution specific details nor >> application specific requirements in this document. >> >> The requirements presented in this document apply equally to packet >> switched networks under the control of MPLS protocols and to but also >> encompass the requirements of Layer two Switching (L2SC), Time >> Division Multiplexing (TDM), lambda, and port switching networks >> managed by Generalized MPLS (GMPLS) protocols. Protocol solutions >> developed to meet the requirements set out in this document must >> attempt to be equally applicable to MPLS and GMPLS. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-04.txt > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 14 09:35:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXil-0007pz-6T; Wed, 14 Dec 2005 09:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXic-0007nm-Tp for mpls@megatron.ietf.org; Wed, 14 Dec 2005 09:35:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02943 for ; Wed, 14 Dec 2005 09:33:54 -0500 (EST) Received: from evita3.cs.fredonia.edu ([141.238.30.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmXji-0000vK-Or for mpls@ietf.org; Wed, 14 Dec 2005 09:36:07 -0500 Received: from zubairi (zubairi.cs.fredonia.edu [141.238.30.211]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id jBEEYVC07116 for ; Wed, 14 Dec 2005 09:34:34 -0500 Message-ID: <008101c600bb$aa4aa1e0$d31eee8d@ad.fredonia.edu> From: "Junaid Ahmed Zubairi" To: Date: Wed, 14 Dec 2005 09:35:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Please join X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junaid Ahmed Zubairi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org CALL FOR PAPERS The 2006 International Symposium on Collaborative Technologies and Systems (CTS'06) May 14-17, 2005 Luxor Hotel and Resort, Las Vegas, Nevada, USA http://www.engr.udayton.edu/faculty/wsmari/cts06/ Special Session on Collaborative Networking Infrastructure Submission Deadline: January 15, 2006 Brief Description: A Special Session on collaborative networking infrastructure is being organized under the 2006 Collaborative Technologies Symposium (CTS'06) to be held May 14-17, 2006, Luxor Hotel, Las Vegas, Nevada, USA. This special session is planned to bring together people from industry, government and academia who are working to innovate, develop and use networking infrastructure for the purpose of collaborative work in various fields of knowledge. Some of the recent examples of collaborative work via networking include SPARC that researchers in upper atmospheric and space physics from around the world are able to use. SPARC provides the users with a set of online collaboration tools and workspaces that link together scientific instruments, data, and models. Work is in progress to design and test portable mobile collaborative networks that can be created to deal with emergencies. This special session looks at all hardware and software issues that are involved in providing a reliable, robust and ubiquitous networking infrastructure to build collaborative tools and services and the state of the art as well as experimental results and posters about ongoing work in this direction. We invite original contributions on these emerging and important areas of information technology. Topics include, but not limited to: * High Speed Networking for Collaboration * Collaborative Sensory Networks * Group and Cooperative Communications * Event Detection, Classification and Tracking * Wireless, Mobile and Portable Collaborative Networking and Issues * Protocols for Collaborative Ad Hoc and Sensor Networks * Data Transport in Wireless Ad Hoc and Sensor Networks * Power-aware and Energy-efficient Designs * Localization and Synchronization in Wireless Sensor Networks * Data Gathering, Fusion, and Dissemination in Collaborative Wireless Sensors * Routing Protocols and Routing Metrics * Cross-layer Design and Optimization Methods * Application, Operating System and Middleware Support * Reliability, Security, and Trustworthiness in Ad Hoc and Sensor Networks * Fault-tolerance, Self-healing, and Reliability of Networks * Location Discovery and Time Synchronization Techniques * Network Coverage and Connectivity * Topology Discovery, Management and Self-organization * Network Scalability and Limitations * Building Community Networks Issues * Performance Modeling and Analysis * Quality of Service Issues * Query Processing and Data Aggregation * Design, Implementation and Management of Collaborative Websites and Services * Tools and Techniques for Web based Collaborative Multimedia Communications * Software Development for Data Visualization from Distributed Data Centers Paper Submission: Papers reporting original and unpublished research results on above and any other related networking topics are solicited. Submission should include a cover page with authors' names, affiliations, addresses, fax and phone numbers, and email addresses. Please indicate clearly the corresponding author and the name of the special session. Include up to 6 keywords and an abstract of no more than 300 words. Please submit an electronic copy of your full manuscript (not to exceed 15 double-spaced pages including figures, tables, and references or not exceeding 7 pages in length in single-space, two columns IEEE format) for consideration, to session organizer at zubairi@fredonia.edu by January 15, 2006. Consistent with standard practice, each submitted paper will receive three reviews. Papers will be selected based on their originality, timeliness, significance, relevance, and clarity of presentation. Initial selection will be based on full papers. Submission implies the willingness of at least one of the authors to register and present the paper, if accepted. All accepted papers in the Symposium are expected to be presented and will be included in the conference proceedings. It is our intent to have the proceedings formally published in hard and soft copies and be available at the time of the conference. Important Dates: Paper Submission Deadline: ........ January 15, 2006 Notification of Acceptance: ........ February 13, 2006 Registration & Camera-Ready Paper Due: ... March 10, 2006 Session Organizer: Dr. Junaid Ahmed Zubairi Department of Computer Science State University of New York at Fredonia Fredonia, NY 14063, USA Tel: +1-716-673-4694 Fax: +1-508-256-8324 Email: zubairi@fredonia.edu WWW: http://www.cs.fredonia.edu/~zubairi If you have questions concerning session paper submission or session content, please contact the Special Session organizer at the address above. If you have questions concerning symposium paper submissions or the symposium program, please contact the symposium co-chairs: Bill McQuay at AFRL/IFSD, WPAFB (William.McQuay@wpafb.af.mil) or Waleed Smari at the Dept. of Electrical and Computer Engineering, University of Dayton (Waleed.Smari@notes.udayton.edu), or consult the conference web site at URL: http://www.engr.udayton.edu/faculty/wsmari/cts06/. *********************************************************** Dr. Junaid Ahmed Zubairi Department of Computer Science SUNY at Fredonia, Fredonia, NY 14063, USA. Tel: (716)673-4694 WWW: http://www.cs.fredonia.edu/~zubairi Email: zubairi@fredonia.edu *********************************************************** _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 14 10:50:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYtU-0003lZ-G4; Wed, 14 Dec 2005 10:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYtQ-0003iA-JJ for mpls@megatron.ietf.org; Wed, 14 Dec 2005 10:50:12 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13403 for ; Wed, 14 Dec 2005 10:49:14 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EmYtF-0004gX-Fm; Wed, 14 Dec 2005 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Dec 2005 10:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-lsp-ping-12.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting MPLS Data Plane Failures Author(s) : K. Kompella, G. Swallow Filename : draft-ietf-mpls-lsp-ping-12.txt Pages : 50 Date : 2005-12-14 This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-ping-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-ping-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-14103345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-ping-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-14103345.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Dec 15 16:24:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En03G-00064T-3G; Thu, 15 Dec 2005 15:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En038-000626-T8 for mpls@megatron.ietf.org; Thu, 15 Dec 2005 15:50:03 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03236 for ; Thu, 15 Dec 2005 15:49:02 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1En038-0001OQ-5B; Thu, 15 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Dec 2005 15:50:02 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Operations and Management Requirements for Multi-Protocol Label Switched Networks Author(s) : T. Nadeau, et al. Filename : draft-ietf-mpls-oam-requirements-07.txt Pages : 16 Date : 2005-12-15 This document specifies Operations and Management requirements for Multi-Protocol Label Switching, as well as for applications of Multi-Protocol Label Switching such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying Multi-Protocol Label Switching networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-oam-requirements-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-oam-requirements-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-15131335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-requirements-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-requirements-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-15131335.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Dec 15 20:47:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En4hF-00041X-2P; Thu, 15 Dec 2005 20:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En4hD-00041S-F3 for mpls@megatron.ietf.org; Thu, 15 Dec 2005 20:47:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14097 for ; Thu, 15 Dec 2005 20:46:43 -0500 (EST) Received: from mail2.xl.co.id ([202.152.224.5] helo=JKTGRHXMAV01.intra.excelcom.co.id) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En4iZ-00083h-3z for mpls@ietf.org; Thu, 15 Dec 2005 20:49:17 -0500 Received: from JKTGRHXMXC01.intra.excelcom.co.id ([10.21.106.238]) by JKTGRHXMAV01.intra.excelcom.co.id with Microsoft SMTPSVC(6.0.3790.175); Fri, 16 Dec 2005 08:46:46 +0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Dec 2005 08:46:45 +0700 Message-ID: <375717D43A849E438D7A6498F9E1659289E6@JKTGRHXMXC01.intra.excelcom.co.id> Thread-Topic: Same vpn to the same CE Thread-Index: AcXwEP0h2phjQiJyTP+NI/WkETn3xwR0IieA From: "Very Exton" To: X-OriginalArrivalTime: 16 Dec 2005 01:46:46.0822 (UTC) FILETIME=[9310B460:01C601E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Subject: [mpls] Same vpn to the same CE X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0801627156==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0801627156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C601E2.926CD7A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C601E2.926CD7A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I'm new in MPLS. Is that any problem if I connect 2 CE (with the same network behind CE) to the 2 PE with the same VRF? 1 CE connects to the 1 PE and another CE connect to another PE, those PE's in the same MPLS network. And the PE - CE connection use BGP. =20 =20 Regards, V e r y E x t o n =20 =20 ------_=_NextPart_001_01C601E2.926CD7A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

I’m new in = MPLS.

Is that any problem if I connect 2 = CE (with the same network behind CE) to the 2 PE with the same = VRF?

1 CE connects to the 1 PE and = another CE connect to another PE, those PE’s in the same = MPLS network.

And the PE – CE connection = use BGP.  

 

Regards,

V e r y   E x t o n

 

 

=00 ------_=_NextPart_001_01C601E2.926CD7A7-- --===============0801627156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0801627156==-- From mpls-bounces@lists.ietf.org Thu Dec 15 23:50:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En7Xl-0000N6-Mo; Thu, 15 Dec 2005 23:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En7Xi-0000Lv-7C for mpls@megatron.ietf.org; Thu, 15 Dec 2005 23:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02613 for ; Thu, 15 Dec 2005 23:49:07 -0500 (EST) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En7ZE-0006iV-Le for mpls@ietf.org; Thu, 15 Dec 2005 23:51:42 -0500 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 16 Dec 2005 09:45:41 -0800 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBG4nCL4019186; Fri, 16 Dec 2005 04:49:47 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Dec 2005 10:19:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Same vpn to the same CE Date: Fri, 16 Dec 2005 10:19:36 +0530 Message-ID: Thread-Topic: [mpls] Same vpn to the same CE thread-index: AcXwEP0h2phjQiJyTP+NI/WkETn3xwR0IieAAAZmeKA= From: "Kasu Venkat Reddy \(kvreddy\)" To: "Very Exton" , X-OriginalArrivalTime: 16 Dec 2005 04:49:37.0944 (UTC) FILETIME=[1E5D1180:01C601FC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1562879698==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1562879698== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C601FC.1E364E9E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C601FC.1E364E9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 If both CEs belong to same location connecting to 2 different PEs-then u have to use SOO(site of origin) & as-override features(for bgp as CE-PE protocol) =20 Thanks=20 Kasu Venkat Reddy. ________________________________ From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Very Exton Sent: Friday, December 16, 2005 7:17 AM To: mpls@ietf.org Subject: [mpls] Same vpn to the same CE Hi All, =20 I'm new in MPLS. Is that any problem if I connect 2 CE (with the same network behind CE) to the 2 PE with the same VRF? 1 CE connects to the 1 PE and another CE connect to another PE, those PE's in the same MPLS network. And the PE - CE connection use BGP. =20 =20 Regards, V e r y E x t o n =20 =20 ------_=_NextPart_001_01C601FC.1E364E9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
  
 If both CEs belong to = same location=20 connecting to 2 different PEs-then u have to use SOO(site of = origin) &=20 as-override features(for bgp as CE-PE protocol)
 
Thanks
Kasu Venkat Reddy.

From: mpls-bounces@lists.ietf.org=20 [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Very=20 Exton
Sent: Friday, December 16, 2005 7:17 AM
To:=20 mpls@ietf.org
Subject: [mpls] Same vpn to the same=20 CE

Hi=20 All,

 

I’m new = in=20 MPLS.

Is that any = problem if=20 I connect 2 CE (with the same network behind CE) to the 2 PE with the = same=20 VRF?

1 CE connects = to the 1=20 PE and another CE connect to another PE, = those PE’s in=20 the same MPLS network.

And the PE = – CE=20 connection use BGP.  

 

Regards,

V e=20 r y   E x t o n

 

 

------_=_NextPart_001_01C601FC.1E364E9E-- --===============1562879698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1562879698==-- From mpls-bounces@lists.ietf.org Fri Dec 16 05:23:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnCkG-0005zg-VB; Fri, 16 Dec 2005 05:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnCkF-0005ym-4b for mpls@megatron.ietf.org; Fri, 16 Dec 2005 05:23:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27983 for ; Fri, 16 Dec 2005 05:22:24 -0500 (EST) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnClo-0008If-6m for mpls@ietf.org; Fri, 16 Dec 2005 05:25:01 -0500 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.233]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EnCjy-00012m-Uz; Fri, 16 Dec 2005 11:23:09 +0100 Message-ID: <43A2957B.3040808@pi.se> Date: Fri, 16 Dec 2005 11:22:51 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a working group document? References: <43957FC4.7010209@pi.se> In-Reply-To: <43957FC4.7010209@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org All, we have a consensus to make draft-yasukawa-mpls-p2mp-oam-reqs-01.txt a working group document. Authors, could you please publish the doc as draft-ietf-mpls-p2mp-oam-reqs-01.txt /Loa Loa Andersson wrote: > All, > > In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt, > when aksing the room about the consensus on making it a working group > document, there were good support for making it a working group > document. > > We said that we wanted to confirm this on the list. Please > send response to this mail to the MPLS mailing list stating whether > you think it should become a working group document or not. > > /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Dec 19 11:08:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoNZ2-0007Vs-R3; Mon, 19 Dec 2005 11:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoNZ0-0007Vk-Nt for mpls@megatron.ietf.org; Mon, 19 Dec 2005 11:08:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05617 for ; Mon, 19 Dec 2005 11:07:36 -0500 (EST) From: benjamin.niven-jenkins@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoNbE-0002bA-CP for mpls@ietf.org; Mon, 19 Dec 2005 11:10:57 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 16:08:08 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 15:45:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt Date: Mon, 19 Dec 2005 15:45:40 -0000 Message-ID: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt Thread-Index: AcYBuccCGxsp5RaDQCKcJcZzN+3DOgC9jTHw To: X-OriginalArrivalTime: 19 Dec 2005 15:45:41.0802 (UTC) FILETIME=[444A60A0:01C604B3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Authors, Cc Colleagues, I made several comments on the -06 version of this draft to the MPLS mailing list on 22nd July 2005. I believe some, but not all, of my original comments have been addressed (at least in part). So, I list below some follow-up comments: (1) In the introduction the document refers to "requirements for user and data plane operations and management", however the term "user plane" is never used in the rest of the document. So I would suggest removing the term user plane from the introduction, unless the intention is to emphasise that user plane =3D=3D data plane in which case I think this intention needs to be made more explicit. (2) Section 4.1 refers to "customer traffic" and Section 4.4 refers to "user traffic". Is customer traffic synonymous with user traffic, in which case I would suggest that the document standardises on one term. 3) Throughout the document, I am not sure that the use of customer is consistent or its meaning clear - It would appear that sometimes what is meant is an actual customer of a service provider and at other times what is meant is the client layer of the MPLS (server) layer, in which case I would comment that this client layer does not necessarily belong to a "customer". A definition of what is meant by customer in the terminology section would help, but I would also suggest replacing customer with a term such as client or client layer in those cases where what you are discussing is not necessarily owned by a customer in a business relationship sense (e.g. a SP may use a label stack to help scaling/aggregation, but the same SP owns the client & server MPLS layers, so who is the customer?). 4) Section 4.5, insofar-as =3D> insofar as (According to The Columbia Guide to Standard American English) Thanks Ben -- Ben Niven-Jenkins Networking Specialist, BT Exact =20 E-mail: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Dec 19 12:26:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoOmH-0006sd-Cv; Mon, 19 Dec 2005 12:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoOmF-0006sU-Qd for mpls@megatron.ietf.org; Mon, 19 Dec 2005 12:26:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15533 for ; Mon, 19 Dec 2005 12:25:21 -0500 (EST) From: benjamin.niven-jenkins@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoOoU-0005Mt-Be for mpls@ietf.org; Mon, 19 Dec 2005 12:28:43 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 17:26:08 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Dec 2005 17:26:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt Date: Mon, 19 Dec 2005 17:26:07 -0000 Message-ID: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt Thread-Index: AcYBuccCGxsp5RaDQCKcJcZzN+3DOgC9jTHwAAPvVqA= To: X-OriginalArrivalTime: 19 Dec 2005 17:26:08.0203 (UTC) FILETIME=[4C4E31B0:01C604C1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org mpls-bounces@lists.ietf.org <> wrote: > Authors, > Cc Colleagues, >=20 > I made several comments on the -06 version of this draft to > the MPLS mailing list on 22nd July 2005. I believe some, but > not all, of my original comments have been addressed (at least in > part).=20 >=20 > So, I list below some follow-up comments: >=20 One further comment. The abstract talks of "applications of Multi-Protocol Label Switching such as pseudo-wire voice and virtual private network services.". I am not sure what is meant by pseudo-wire voice and can find no reference to it anywhere and draft-ietf-pwe3-iana-allocation-15 does not list a voice type. It should be clarified what is meant by pseudo-wire voice. Thanks Ben _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 20 00:35:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoa9V-0000oo-BV; Tue, 20 Dec 2005 00:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoa9T-0000og-G5 for mpls@megatron.ietf.org; Tue, 20 Dec 2005 00:35:07 -0500 Received: from smail.alcatel.fr (smail.alcatel.fr [62.23.212.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11747 for ; Tue, 20 Dec 2005 00:34:03 -0500 (EST) Received: from bemail02.netfr.alcatel.fr (bemail02.netfr.alcatel.fr [155.132.251.36]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBK5YZB3019005 for ; Tue, 20 Dec 2005 06:34:35 +0100 Received: from alcatel.com ([172.21.130.87]) by bemail02.netfr.alcatel.fr (Lotus Domino Release 6.5.4FP2HF150) with ESMTP id 2005122006343361-2543 ; Tue, 20 Dec 2005 06:34:33 +0100 Message-ID: <43A798BD.6070307@alcatel.com> Date: Tue, 20 Dec 2005 11:08:05 +0530 From: Karthikeyan.Kaliyamurthy@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF150 | December 5, 2005) at 12/20/2005 06:34:33, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF150 | December 5, 2005) at 12/20/2005 06:34:35, Serialize complete at 12/20/2005 06:34:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Next to MPLS, GMPLS ???? X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hello all, I'm new to this MPLS and L3 world. I have been working in L2 and voip protocols for past 4 years and also having good knowledge in ATM and basic rouitng (CCNA certified) . I want to update my profile up to the current trend in L3 and MPLS switching. 1.Could you please say what are the current trends in datacom ( As per my knowledge MPLS and GMPLS)?? Is it any new area of research?? 2. Could you please guide me what are the minimum rfc I have to read to make my profile upto date . 3 . Is it compulsory to read all routing protocols* rfc* like rip v1,v2 ,ospf, ISIS,BGP to understand MPLS and traffic engineering Please guide me Thanks in advance, Regards, K.Karthikeyan Senior Software engineer _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 20 15:50:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooR6-0006y0-Oc; Tue, 20 Dec 2005 15:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooQr-0006mN-Nw for mpls@megatron.ietf.org; Tue, 20 Dec 2005 15:50:03 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04270 for ; Tue, 20 Dec 2005 15:48:57 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008Qc-Ax; Tue, 20 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Dec 2005 15:50:01 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : OAM Requirements for Point-to-Multipoint MPLS Networks Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-p2mp-oam-reqs-00.txt Pages : 12 Date : 2005-12-20 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-p2mp-oam-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-20120528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-oam-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20120528.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Dec 21 09:24:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep4tg-0006eL-0m; Wed, 21 Dec 2005 09:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep4te-0006eA-7I for mpls@megatron.ietf.org; Wed, 21 Dec 2005 09:24:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19041 for ; Wed, 21 Dec 2005 09:23:45 -0500 (EST) From: benjamin.niven-jenkins@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep4wG-0006f7-89 for mpls@ietf.org; Wed, 21 Dec 2005 09:27:33 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 14:24:38 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Dec 2005 14:24:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-00.txt Date: Wed, 21 Dec 2005 14:24:36 -0000 Message-ID: Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-00.txt Thread-Index: AcYFq3zVe618uGqtT3q/aIDWx0V0VQAhevUw To: X-OriginalArrivalTime: 21 Dec 2005 14:24:37.0799 (UTC) FILETIME=[45F1EB70:01C6063A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Authors, Colleagues, I have just read draft-ietf-mpls-p2mp-oam-reqs-00 for the first time and have the following suggested edits/corrections. Abstract - dataplane =3D> data plane The abstract states "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." This sentence doesn't make sense - may not only affect the fundamental of an MPLS network. Also I'm not sure why the second MAY is capitalised. In the introduction the document refers to "requirements for user and data plane operations and management", however the term "user plane" is never used in the rest of the document. So I would suggest removing the term user plane from the introduction, unless the intention is to emphasise that user plane =3D=3D data plane in which case I think this intention needs to be made more explicit. The introduction states "These latter are described in [MPLS-OAM] and are not repeated in this document." Guess this should be "These latter requirements" Section 4 states "The general requirements described in this section are closely similar to those described for point-to-point MPLS in [MPLS-OAM]." closely similar makes no sense to me - would suggest either "closely related" or just "similar". Section 4 states "In general, it should be noted that P2MP LSPs introduce a scalability issue that is not present in point-to-point MPLS." Is this scalability issue a general one or a OAM scaling issue? If the latter the I think you should make this explicit in the sentence e.g. "In general, it should be noted that P2MP LSPs introduce a scalability issue with respect to OAM that is not present in point-to-point MPLS." Section 4.1 states "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." I don't like "detect defects in a broken LSP" or "for that P2MP LSP" as the first part of sentence doesn't mention a P2MP LSP. Would suggest either: "The ability to detect defects in a P2MP Label Switch Path (LSP) SHOULD not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that P2MP LSP.", or "The ability to detect defects in a Label Switch Path (LSP) SHOULD not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for a P2MP LSP." Section 4.1 states "As the number of leaves of the P2MP LSP increases so it becomes potentially more expensive to inspect the LSP to detect defects." I don't like this sentence and would suggest "As the number of leaves of a P2MP LSP increases it potentially becomes more expensive to inspect the LSP to detect defects." In section 4.9 remove the superfluous "These" from the end of the first paragraph. Section 4.9, second paragraph - facillitate =3D> facilitate Section 4.11, first paragraph - matricies =3D> matrices Section 4.11, second paragraph - becasue =3D> because In section 4.11, second paragraph remove the superfluous "The" at the beginning of the last sentence. Section 5, first paragraph - conseuqences =3D> consequences Section 5, second paragraph sates "As with previous OAM function described in [MPLS-OAM]," which doesn't read very well to me, suggest "As with the OAM functions described in [MPLS-OAM]" Section 5, second paragraph - becuase =3D> because Ben --=20 Ben Niven-Jenkins Network Architect, BT Exact =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 21 10:35:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5zd-0002jt-CZ; Wed, 21 Dec 2005 10:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5zb-0002iP-00 for mpls@megatron.ietf.org; Wed, 21 Dec 2005 10:35:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01391 for ; Wed, 21 Dec 2005 10:33:58 -0500 (EST) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep62D-0001jH-Mc for mpls@ietf.org; Wed, 21 Dec 2005 10:37:47 -0500 Received: from du-069-0011.access.clara.net ([217.158.132.11] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1Ep5zW-000E65-Gf; Wed, 21 Dec 2005 15:35:00 +0000 Message-ID: <072401c60644$9ac3e4f0$99849ed9@Puppy> From: "Adrian Farrel" To: , References: Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-oam-reqs-00.txt Date: Wed, 21 Dec 2005 15:38:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Ben, How nice to have such a detailed review so early in the process. Thanks! Comments bellow. Look out for these fixes in the next revision. Cheers, Adrian > Abstract - dataplane => data plane Ack > The abstract states "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." This sentence doesn't make > sense - may not only affect the fundamental of an MPLS network. s/fundamental/fundamentals/ > Also I'm not sure why the second MAY is capitalised. You are right. We shouldn't use RFC 2119 language in the abstract. > In the introduction the document refers to "requirements for user and > data plane operations and management", however the term "user plane" is > never used in the rest of the document. So I would suggest removing the > term user plane from the introduction, unless the intention is to > emphasise that user plane == data plane in which case I think this > intention needs to be made more explicit. Good point. Deleted user plane from Intro and Abstract. > The introduction states "These latter are described in [MPLS-OAM] and > are not repeated in this document." Guess this should be "These latter > requirements" Ack > Section 4 states "The general requirements described in this section are > closely similar to those described for point-to-point MPLS in > [MPLS-OAM]." closely similar makes no sense to me - would suggest either > "closely related" or just "similar". Hah! I bet it makes some sense to you! One of the joys of being human is that we can extract sense from our parsing of natural language ;-) Changed to "similar". > Section 4 states "In general, it should be noted that P2MP LSPs > introduce a scalability issue that is not present in point-to-point > MPLS." Is this scalability issue a general one or a OAM scaling issue? > If the latter the I think you should make this explicit in the sentence > e.g. "In general, it should be noted that P2MP LSPs introduce a > scalability issue with respect to OAM that is not present in > point-to-point MPLS." Well, both OAM and other areas. Basically, P2MP LSPs necessarily require more of everything because they have more egresses. But, given the scope of the I-D, your change is correct. > Section 4.1 states "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." I don't like "detect defects in a broken LSP" or "for that > P2MP LSP" as the first part of sentence doesn't mention a P2MP > LSP. Would suggest either: > > "The ability to detect defects in a P2MP Label Switch Path (LSP) > SHOULD not require manual hop-by-hop troubleshooting of each > LSR used to switch traffic for that P2MP LSP.", > or > "The ability to detect defects in a Label Switch Path (LSP) > SHOULD not require manual hop-by-hop troubleshooting of > each LSR used to switch traffic for a P2MP LSP." Good point. Changed to the following as LSP is already defined. The ability to detect defects in a P2MP LSP SHOULD not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP. > Section 4.1 states "As the number of leaves of the P2MP LSP > increases so it becomes potentially more expensive to inspect the > LSP to detect defects." I don't like this sentence and would suggest > "As the number of leaves of a P2MP LSP increases it potentially > becomes more expensive to inspect the LSP to detect defects." You don't like my split infinitives? Good suggestion. > In section 4.9 remove the superfluous "These" from the end of the first > paragraph. Ack > Section 4.9, second paragraph - facillitate => facilitate Ack > Section 4.11, first paragraph - matricies => matrices Ack > Section 4.11, second paragraph - becasue => because Ack > In section 4.11, second paragraph remove the superfluous "The" at the > beginning of the last sentence. Ack > Section 5, first paragraph - conseuqences => consequences Ack > Section 5, second paragraph sates "As with previous OAM function > described in [MPLS-OAM]," which doesn't read very well to me, suggest > "As with the OAM functions described in [MPLS-OAM]" Ack > Section 5, second paragraph - becuase => because Ack _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Dec 21 15:50:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuS-0006Ku-Sn; Wed, 21 Dec 2005 15:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuQ-0006Hz-GG for mpls@megatron.ietf.org; Wed, 21 Dec 2005 15:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19443 for ; Wed, 21 Dec 2005 15:48:57 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EpAuQ-0005XJ-3C; Wed, 21 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Dec 2005 15:50:02 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-frmwk-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for MPLS Operations and Management (OAM) Author(s) : D. Allan, T. Nadeau Filename : draft-ietf-mpls-oam-frmwk-05.txt Pages : 11 Date : 2005-12-21 This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching. The document is structured to outline how Operations and Management functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-frmwk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-oam-frmwk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-21114821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-oam-frmwk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-oam-frmwk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-21114821.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed Dec 21 18:56:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpDon-0007Hb-Ue; Wed, 21 Dec 2005 18:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpDok-0007HG-Qb for mpls@megatron.ietf.org; Wed, 21 Dec 2005 18:56:23 -0500 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29129 for ; Wed, 21 Dec 2005 18:55:17 -0500 (EST) Received: by wproxy.gmail.com with SMTP id i14so260475wra for ; Wed, 21 Dec 2005 15:56:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Xrk7emMi94aOju6MmBs+4qYdSSiXcFQBz0l3yLduBxeOhMHdcba/kZLmj8AliMTrQPuBPtTajPWOVsiMe7JCry9PV2zN/vZXJY+YvkovIQFSr9tP48PlhaKpjn9PzJQr2HHQ4KbXy3h3O8FXqtsEE0CkzqDOnvFG/b9vutuyWf8= Received: by 10.64.96.16 with SMTP id t16mr516qbb; Wed, 21 Dec 2005 15:56:21 -0800 (PST) Received: by 10.64.24.2 with HTTP; Wed, 21 Dec 2005 15:56:21 -0800 (PST) Message-ID: <6280db520512211556w32a0fd9yecb078c00eb8aaaa@mail.gmail.com> Date: Wed, 21 Dec 2005 15:56:21 -0800 From: Alia Atlas To: IETF MPLS List , jiang.weilian@zte.com.cn, kong.yong@zte.com.cn, luo.jian@zte.com.cn, Feng.jun99@zte.com.cn MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] draft-weilian-mpls-fast-reroute-ext-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org On reading the introduction of this draft, I am unclear about the motivation and problem that it is trying to solve. The draft says: "However, for N:1 backup, after the protected tunnel switches to the backup tunnel, the protocol state should still be refreshed through sending protocol messages of the protected tunnel along the path of backup tunnel. Once FRR switchover occurs, abundant Refresh messages of the protected tunnel are transmitted along the path of backup tunnel, intermediate and tail nodes of the backup tunnel will allocate abundant useless labels." As I understand the bypass tunnel mechanism, the Refresh messages for the protected tunnels are sent to the merge node via the backup tunnel; this means that the Refresh messages are encapsulated and not seen by the intermediate nodes of the backup tunnel. When the refresh message is seen by the tail node of the backup tunnel (which is the MP), the MP will look-up the state and label assigned to the associated protected LSP and refresh the state and provide the label back. I don't see that there is any allocation of useless labels. Could you clarify an example where this happens? In particular, could you pull the problem from RFC4090? Thanks, Alia _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Dec 27 00:49:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er7i7-0001FT-IH; Tue, 27 Dec 2005 00:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er7i5-0001FK-1I for mpls@megatron.ietf.org; Tue, 27 Dec 2005 00:49:21 -0500 Received: from mail2.zte.com.cn ([202.103.147.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23448 for ; Tue, 27 Dec 2005 00:48:07 -0500 (EST) From: jiang.weilian@zte.com.cn Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 79206.2009593765; Tue, 27 Dec 2005 14:51:24 +0800 (CST) In-Reply-To: <6280db520512211556w32a0fd9yecb078c00eb8aaaa@mail.gmail.com> To: Alia Atlas MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Date: Tue, 27 Dec 2005 13:50:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-12-27 13:51:38, Serialize complete at 2005-12-27 13:51:38 Cc: luo.jian@zte.com.cn, IETF MPLS List , Feng.jun99@zte.com.cn, kong.yong@zte.com.cn Subject: [mpls] Reply: draft-weilian-mpls-fast-reroute-ext-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1967766873==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1967766873== Content-Type: multipart/alternative; boundary="=_alternative 001FBB5C482570E4_=" This is a multipart message in MIME format. --=_alternative 001FBB5C482570E4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IGZvciBBbGlhoa9zIG9waW5pb25zIQ0KDQpUaGVyZSBhcmUgdHdvIHB1cnBv c2VzIGluIG91ciBwcm9wb3NhbDoNCjEuIFdlIHRoaW5rIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCBm b3IgZXN0YWJsaXNoaW5nIFBTQqGiUlNCIGFuZCANCmFsbG9jYXRpbmcgbGFiZWxzIGZvciB0aGUg cHJvdGVjdGVkIHR1bm5lbCBhbG9uZyB0aGUgcGF0aCBvZiB0aGUgDQpieXBhc3MgdHVubmVsLiBB bmQgaXQgbG9va3MgbGlrZSBib3RoIG9mIHVzIGFncmVlIG9uIHRoaXMgcG9pbnQgDQpmcm9tIEFs aWGhr3MgZW1haWwuIEluIFJGQyA0MDkwLCBpdCBzYXlzIFBMUiBzZW5kcyB0aGUgY29udHJvbCAN CnRyYWZmaWMgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIG9udG8gdGhlIGJ5cGFzcyB0dW5uZWwsIGFu ZCB0aGUgDQppbnRlcm1lZGlhdGUgbm9kZXMgb2YgdGhlIGJhY2t1cCB0dW5uZWwgd2lsbCBub3Qg YWxsb2NhdGUgbGFiZWxzIA0KZm9yIHRoZSBwcm90ZWN0ZWQgdHVubmVsLiBTbyB3ZSBoYXZlIG1p c3Rha2VzIGFib3V0IHRoZSBieXBhc3MgDQp0dW5uZWwgbWVjaGFuaXNtLCB3ZSB3aWxsIGNvcnJl Y3QgdGhlbS4NCg0KMi4gV2UgYWxzbyB0aGluayB0aGVyZSBpcyBubyBuZWVkIGZvciB0cmFuc21p dHRpbmcgdGhlIFJlZnJlc2ggDQptZXNzYWdlcyBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWxzIHRo cm91Z2ggdGhlIGJ5cGFzcyB0dW5uZWwuIFdlIA0Ka25vdyB0aGF0IGluIFJGQzQwOTAsIGl0IHNh eXMgUExSIG5lZWRzIHRvIHNlbmQgdGhlIGNvbnRyb2wgDQp0cmFmZmljIGZvciB0aGUgcHJvdGVj dGVkIExTUCBvbnRvIHRoZSBieXBhc3MgdHVubmVsLiBNYXliZSB0aGUgDQpSZWZyZXNoIG1lc3Nh Z2VzIGFyZSBlbmNhcHN1bGF0ZWQgYXMgbm9ybWFsIGxhYmVsZWQgZGF0YSBhbmQgDQp0cmFuc21p dHRlZCBpbiB0aGUgYnlwYXNzIHR1bm5lbC4gQnV0IGFzIGluIG91ciBleHRlbnNpb25zIHRvIHRo ZSANCkZhc3QgUmVyb3V0ZSAoRlJSKSBtZWNoYW5pc20gb2YgRmFjaWxpdHkgQmFja3VwIGRlZmlu ZWQgaW4gUkZDNDA5MCwgDQpQTFIgYW5kIE1QIG5vZGVzIGNhbiByZWZyZXNoIHRoZSBwcm90b2Nv bCBzdGF0ZSBvZiBwcm90ZWN0ZWQgdHVubmVsIA0KYnkgdGhlIFJlZnJlc2ggbWVzc2FnZXMgb2Yg YnlwYXNzIHR1bm5lbCwgc28gdGhlcmUgaXMgbm90IGFueSBleHRyYSANCnNwZW5kaW5nIG9uIHNl bmRpbmcgdGhlIGNvbnRyb2wgdHJhZmZpYyBmb3IgdGhlIHByb3RlY3RlZCBMU1Agb250byANCnRo ZSBieXBhc3MgdHVubmVsLg0KDQpJbiB0aGUgcHJlc2VudCBkcmFmdCwgb3VyIGV4dGVuc2lvbnMg b25seSBjb25zaWRlciB0aGUgZ2xvYmFsIGxhYmVsIA0Kc3BhY2VzIG1vZGUuIEJ1dCB3aXRoIGEg bGl0dGxlIG1vZGlmaWNhdGlvbiwgd2UgY2FuIGFsc28gc3VwcG9ydCANCnBlci1pbnRlcmZhY2Ug bGFiZWwgc3BhY2VzIG1vZGUuIEJhc2VkIG91ciBwcmVzZW50IGV4dGVuc2lvbnMsIGFmdGVyIA0K dGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIHByb3RlY3RlZCB0dW5uZWwgYW5kIHRoZSBieXBhc3Mg dHVubmVsIGJlaW5nIA0KY29uZmlybWVkIGF0IE1QIG5vZGUsIE1QIG5vZGUgd2lsbCBoYXZlIHRo ZSBpbnB1dC0gaW50ZXJmYWNlIG9mIHRoZSANCnByb3RlY3RlZCB0dW5uZWwgd2hpbGUgbGluayBv ci9hbmQgbm9kZSBmYWlsdXJlIG9jY3Vyc6OodGhhdCBpcywgdGhlIA0KaW5wdXQtIGludGVyZmFj ZSBvZiB0aGUgYnlwYXNzIHR1bm5lbKOpLiBJZiB0aGUgTVAgbm9kZSBpcyBwZXItaW50ZXJmYWNl IA0KbGFiZWwgc3BhY2VzIG1vZGUsIHdlIHdhbnQgdGhlIE1QIG5vZGUgdG8gZmlsbCB0aGUgbGFi ZWwgZm9yIHRoZSANCmNvcnJlc3BvbmRpbmcgaW50ZXJmYWNlIGludG8gTVBfTk9USUZZX0FDSyBv YmplY3QsIGFuZCBpdCB3aWxsIGJlIGNhcnJpZWQgDQpieSB0aGUgUkVTViBtZXNzYWdlcyBzZW50 IHRvIHRoZSBQTFIgbm9kZS4gVGhlbiBQTFIgbm9kZSBjYW4gZGlzY292ZXIgdGhlIA0KYXBwcm9w cmlhdGUgTVAgbGFiZWwuIE5vdywgd2UgY2FuIGFsc28gc3VwcG9ydCBwZXItaW50ZXJmYWNlIGxh YmVsIHNwYWNlcyANCm1vZGUuDQoNClJlZ2FyZCwNCkppYW5nIFdlaWxpYW4NCg0KDQoNCg0KDQpB bGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbT4NCg0KMjAwNS0xMi0yMiAwNzo1Ng0KIA0KICAg ICAgICDK1bz+yMujuiAgICAgICAgSUVURiBNUExTIExpc3QgPG1wbHNAbGlzdHMuaWV0Zi5vcmc+ LCANCmppYW5nLndlaWxpYW5AenRlLmNvbS5jbiwga29uZy55b25nQHp0ZS5jb20uY24sIGx1by5q aWFuQHp0ZS5jb20uY24sIA0KRmVuZy5qdW45OUB6dGUuY29tLmNuDQogICAgICAgILOty82juiAN CiAgICAgICAg1vfM4qO6ICBkcmFmdC13ZWlsaWFuLW1wbHMtZmFzdC1yZXJvdXRlLWV4dC0wMA0K DQoNCk9uIHJlYWRpbmcgdGhlIGludHJvZHVjdGlvbiBvZiB0aGlzIGRyYWZ0LCBJIGFtIHVuY2xl YXIgYWJvdXQgdGhlDQptb3RpdmF0aW9uIGFuZCBwcm9ibGVtIHRoYXQgaXQgaXMgdHJ5aW5nIHRv IHNvbHZlLiAgVGhlIGRyYWZ0IHNheXM6DQoNCiJIb3dldmVyLCBmb3IgTjoxIGJhY2t1cCwgYWZ0 ZXIgdGhlIHByb3RlY3RlZCB0dW5uZWwgc3dpdGNoZXMgdG8gdGhlDQpiYWNrdXAgdHVubmVsLCB0 aGUgcHJvdG9jb2wgc3RhdGUgc2hvdWxkIHN0aWxsIGJlIHJlZnJlc2hlZCB0aHJvdWdoDQpzZW5k aW5nIHByb3RvY29sIG1lc3NhZ2VzIG9mIHRoZSBwcm90ZWN0ZWQgdHVubmVsIGFsb25nIHRoZSBw YXRoIG9mDQpiYWNrdXAgdHVubmVsLiBPbmNlIEZSUiBzd2l0Y2hvdmVyIG9jY3VycywgYWJ1bmRh bnQgUmVmcmVzaCBtZXNzYWdlcw0Kb2YgdGhlIHByb3RlY3RlZCB0dW5uZWwgYXJlIHRyYW5zbWl0 dGVkIGFsb25nIHRoZSBwYXRoIG9mIGJhY2t1cA0KdHVubmVsLCBpbnRlcm1lZGlhdGUgYW5kIHRh aWwgbm9kZXMgb2YgdGhlIGJhY2t1cCB0dW5uZWwgd2lsbCBhbGxvY2F0ZQ0KYWJ1bmRhbnQgdXNl bGVzcyBsYWJlbHMuIg0KDQpBcyBJIHVuZGVyc3RhbmQgdGhlIGJ5cGFzcyB0dW5uZWwgbWVjaGFu aXNtLCB0aGUgUmVmcmVzaCBtZXNzYWdlcyBmb3INCnRoZSBwcm90ZWN0ZWQgdHVubmVscyBhcmUg c2VudCB0byB0aGUgbWVyZ2Ugbm9kZSB2aWEgdGhlIGJhY2t1cA0KdHVubmVsOyB0aGlzIG1lYW5z IHRoYXQgdGhlIFJlZnJlc2ggbWVzc2FnZXMgYXJlIGVuY2Fwc3VsYXRlZCBhbmQgbm90DQpzZWVu IGJ5IHRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgb2YgdGhlIGJhY2t1cCB0dW5uZWwuDQpXaGVuIHRo ZSByZWZyZXNoIG1lc3NhZ2UgaXMgc2VlbiBieSB0aGUgdGFpbCBub2RlIG9mIHRoZSBiYWNrdXAg dHVubmVsDQood2hpY2ggaXMgdGhlIE1QKSwgdGhlIE1QIHdpbGwgbG9vay11cCB0aGUgc3RhdGUg YW5kIGxhYmVsIGFzc2lnbmVkIHRvDQp0aGUgYXNzb2NpYXRlZCBwcm90ZWN0ZWQgTFNQIGFuZCBy ZWZyZXNoIHRoZSBzdGF0ZSBhbmQgcHJvdmlkZSB0aGUNCmxhYmVsIGJhY2suDQoNCkkgZG9uJ3Qg c2VlIHRoYXQgdGhlcmUgaXMgYW55IGFsbG9jYXRpb24gb2YgdXNlbGVzcyBsYWJlbHMuICBDb3Vs ZCB5b3UNCmNsYXJpZnkgYW4gZXhhbXBsZSB3aGVyZSB0aGlzIGhhcHBlbnM/ICBJbiBwYXJ0aWN1 bGFyLCBjb3VsZCB5b3UgcHVsbA0KdGhlIHByb2JsZW0gZnJvbSBSRkM0MDkwPw0KDQpUaGFua3Ms DQpBbGlhDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNClRoZSBlbWFpbCBoYXMgIGJlZW4gc2Nhbm5lZCBieSBBbnRpLVNwYW0NCnN5c3RlbSwg IGlmIHlvdSBmaW5kIFNwYW0gb3IgVmlydXMgaW4gdGhpcyBtYWlsLA0KcGxlYXNlIGZvcndhcmQg aXQgdG86IGhlbHBkZXNrQHp0ZS5jb20uY24NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KDQoNCg0KCgoKKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioK0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpWlRFy/nT 0KOsClpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uIKsaPD3KOszrS+rbeivP7I y8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoKyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6rNDFz6K1 xMirsr8Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6howpJbmZvcm1hdGlvbiBTZWN1 cml0eSAgTm90aWNlo7oKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMK c29sZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uIApUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuClJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0bwptYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0bwpkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uCnRvIG90aGVycy4KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --=_alternative 001FBB5C482570E4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBhIGxvdCBmb3IgQWxp YaGvcyBvcGluaW9ucyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoZXJlIGFyZSB0d28gcHVycG9zZXMgaW4gb3VyIHByb3Bvc2FsOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gV2UgdGhpbmsgdGhhdCB0aGVyZSBp cyBubyBuZWVkIGZvcg0KZXN0YWJsaXNoaW5nIFBTQqGiUlNCIGFuZCA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFsbG9jYXRpbmcgbGFiZWxzIGZvciB0aGUgcHJv dGVjdGVkDQp0dW5uZWwgYWxvbmcgdGhlIHBhdGggb2YgdGhlIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YnlwYXNzIHR1bm5lbC4gQW5kIGl0IGxvb2tzIGxpa2Ug Ym90aA0Kb2YgdXMgYWdyZWUgb24gdGhpcyBwb2ludCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmZyb20gQWxpYaGvcyBlbWFpbC4gSW4gUkZDIDQwOTAsIGl0DQpz YXlzIFBMUiBzZW5kcyB0aGUgY29udHJvbCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPnRyYWZmaWMgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIG9udG8gdGhlDQpieXBh c3MgdHVubmVsLCBhbmQgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+aW50ZXJtZWRpYXRlIG5vZGVzIG9mIHRoZSBiYWNrdXAgdHVubmVsDQp3aWxsIG5vdCBh bGxvY2F0ZSBsYWJlbHMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5mb3IgdGhlIHByb3RlY3RlZCB0dW5uZWwuIFNvIHdlIGhhdmUNCm1pc3Rha2VzIGFib3V0IHRo ZSBieXBhc3MgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50dW5u ZWwgbWVjaGFuaXNtLCB3ZSB3aWxsIGNvcnJlY3QgdGhlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIFdlIGFsc28gdGhpbmsgdGhlcmUgaXMgbm8g bmVlZCBmb3INCnRyYW5zbWl0dGluZyB0aGUgUmVmcmVzaCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm1lc3NhZ2VzIGZvciB0aGUgcHJvdGVjdGVkIHR1bm5lbHMg dGhyb3VnaA0KdGhlIGJ5cGFzcyB0dW5uZWwuIFdlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+a25vdyB0aGF0IGluIFJGQzQwOTAsIGl0IHNheXMgUExSIG5lZWRz DQp0byBzZW5kIHRoZSBjb250cm9sIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+dHJhZmZpYyBmb3IgdGhlIHByb3RlY3RlZCBMU1Agb250byB0aGUNCmJ5cGFzcyB0 dW5uZWwuIE1heWJlIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlJlZnJlc2ggbWVzc2FnZXMgYXJlIGVuY2Fwc3VsYXRlZCBhcw0Kbm9ybWFsIGxhYmVsZWQg ZGF0YSBhbmQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50cmFu c21pdHRlZCBpbiB0aGUgYnlwYXNzIHR1bm5lbC4gQnV0DQphcyBpbiBvdXIgZXh0ZW5zaW9ucyB0 byB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GYXN0IFJl cm91dGUgKEZSUikgbWVjaGFuaXNtIG9mIEZhY2lsaXR5DQpCYWNrdXAgZGVmaW5lZCBpbiBSRkM0 MDkwLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBMUiBhbmQg TVAgbm9kZXMgY2FuIHJlZnJlc2ggdGhlIHByb3RvY29sDQpzdGF0ZSBvZiBwcm90ZWN0ZWQgdHVu bmVsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YnkgdGhlIFJl ZnJlc2ggbWVzc2FnZXMgb2YgYnlwYXNzIHR1bm5lbCwNCnNvIHRoZXJlIGlzIG5vdCBhbnkgZXh0 cmEgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zcGVuZGluZyBv biBzZW5kaW5nIHRoZSBjb250cm9sIHRyYWZmaWMNCmZvciB0aGUgcHJvdGVjdGVkIExTUCBvbnRv IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGJ5cGFzcyB0 dW5uZWwuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5J biB0aGUgcHJlc2VudCBkcmFmdCwgb3VyIGV4dGVuc2lvbnMNCm9ubHkgY29uc2lkZXIgdGhlIGds b2JhbCBsYWJlbCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNw YWNlcyBtb2RlLiBCdXQgd2l0aCBhIGxpdHRsZSBtb2RpZmljYXRpb24sDQp3ZSBjYW4gYWxzbyBz dXBwb3J0IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cGVyLWlu dGVyZmFjZSBsYWJlbCBzcGFjZXMgbW9kZS4gQmFzZWQNCm91ciBwcmVzZW50IGV4dGVuc2lvbnMs IGFmdGVyIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHJl bGF0aW9uIGJldHdlZW4gdGhlIHByb3RlY3RlZCB0dW5uZWwNCmFuZCB0aGUgYnlwYXNzIHR1bm5l bCBiZWluZyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNvbmZp cm1lZCBhdCBNUCBub2RlLCBNUCBub2RlIHdpbGwgaGF2ZQ0KdGhlIGlucHV0LSBpbnRlcmZhY2Ug b2YgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cHJvdGVj dGVkIHR1bm5lbCB3aGlsZSBsaW5rIG9yL2FuZCBub2RlDQpmYWlsdXJlIG9jY3Vyc6OodGhhdCBp cywgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW5wdXQt IGludGVyZmFjZSBvZiB0aGUgYnlwYXNzIHR1bm5lbKOpLg0KSWYgdGhlIE1QIG5vZGUgaXMgcGVy LWludGVyZmFjZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxh YmVsIHNwYWNlcyBtb2RlLCB3ZSB3YW50IHRoZSBNUCBub2RlDQp0byBmaWxsIHRoZSBsYWJlbCBm b3IgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29ycmVz cG9uZGluZyBpbnRlcmZhY2UgaW50byBNUF9OT1RJRllfQUNLDQpvYmplY3QsIGFuZCBpdCB3aWxs IGJlIGNhcnJpZWQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5i eSB0aGUgUkVTViBtZXNzYWdlcyBzZW50IHRvIHRoZSBQTFINCm5vZGUuIFRoZW4gUExSIG5vZGUg Y2FuIGRpc2NvdmVyIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmFwcHJvcHJpYXRlIE1QIGxhYmVsLiBOb3csIHdlIGNhbiBhbHNvDQpzdXBwb3J0IHBlci1p bnRlcmZhY2UgbGFiZWwgc3BhY2VzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+bW9kZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlJlZ2FyZCw8YnI+DQpKaWFuZyBXZWlsaWFuPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+QWxpYSBBdGxhcyAmbHQ7YWthdGxhc0Bn bWFpbC5jb20mZ3Q7PC9iPjwvZm9udD4NCjxicj4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDA1LTEyLTIyIDA3OjU2PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IMrVvP7Iy6O6 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJRVRGIE1QTFMgTGlzdCAmbHQ7bXBsc0BsaXN0 cy5pZXRmLm9yZyZndDssDQpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24sIGtvbmcueW9uZ0B6dGUu Y29tLmNuLCBsdW8uamlhbkB6dGUuY29tLmNuLCBGZW5nLmp1bjk5QHp0ZS5jb20uY248L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 INb3zOKjug0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtd2VpbGlhbi1tcGxzLWZh c3QtcmVyb3V0ZS1leHQtMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0Pk9uIHJlYWRpbmcgdGhlIGludHJvZHVjdGlvbiBvZiB0aGlzIGRyYWZ0LCBJIGFt IHVuY2xlYXINCmFib3V0IHRoZTxicj4NCm1vdGl2YXRpb24gYW5kIHByb2JsZW0gdGhhdCBpdCBp cyB0cnlpbmcgdG8gc29sdmUuICZuYnNwO1RoZSBkcmFmdCBzYXlzOjxicj4NCjxicj4NCiZxdW90 O0hvd2V2ZXIsIGZvciBOOjEgYmFja3VwLCBhZnRlciB0aGUgcHJvdGVjdGVkIHR1bm5lbCBzd2l0 Y2hlcyB0byB0aGU8YnI+DQpiYWNrdXAgdHVubmVsLCB0aGUgcHJvdG9jb2wgc3RhdGUgc2hvdWxk IHN0aWxsIGJlIHJlZnJlc2hlZCB0aHJvdWdoPGJyPg0Kc2VuZGluZyBwcm90b2NvbCBtZXNzYWdl cyBvZiB0aGUgcHJvdGVjdGVkIHR1bm5lbCBhbG9uZyB0aGUgcGF0aCBvZjxicj4NCmJhY2t1cCB0 dW5uZWwuIE9uY2UgRlJSIHN3aXRjaG92ZXIgb2NjdXJzLCBhYnVuZGFudCBSZWZyZXNoIG1lc3Nh Z2VzPGJyPg0Kb2YgdGhlIHByb3RlY3RlZCB0dW5uZWwgYXJlIHRyYW5zbWl0dGVkIGFsb25nIHRo ZSBwYXRoIG9mIGJhY2t1cDxicj4NCnR1bm5lbCwgaW50ZXJtZWRpYXRlIGFuZCB0YWlsIG5vZGVz IG9mIHRoZSBiYWNrdXAgdHVubmVsIHdpbGwgYWxsb2NhdGU8YnI+DQphYnVuZGFudCB1c2VsZXNz IGxhYmVscy4mcXVvdDs8YnI+DQo8YnI+DQpBcyBJIHVuZGVyc3RhbmQgdGhlIGJ5cGFzcyB0dW5u ZWwgbWVjaGFuaXNtLCB0aGUgUmVmcmVzaCBtZXNzYWdlcyBmb3I8YnI+DQp0aGUgcHJvdGVjdGVk IHR1bm5lbHMgYXJlIHNlbnQgdG8gdGhlIG1lcmdlIG5vZGUgdmlhIHRoZSBiYWNrdXA8YnI+DQp0 dW5uZWw7IHRoaXMgbWVhbnMgdGhhdCB0aGUgUmVmcmVzaCBtZXNzYWdlcyBhcmUgZW5jYXBzdWxh dGVkIGFuZCBub3Q8YnI+DQpzZWVuIGJ5IHRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgb2YgdGhlIGJh Y2t1cCB0dW5uZWwuPGJyPg0KV2hlbiB0aGUgcmVmcmVzaCBtZXNzYWdlIGlzIHNlZW4gYnkgdGhl IHRhaWwgbm9kZSBvZiB0aGUgYmFja3VwIHR1bm5lbDxicj4NCih3aGljaCBpcyB0aGUgTVApLCB0 aGUgTVAgd2lsbCBsb29rLXVwIHRoZSBzdGF0ZSBhbmQgbGFiZWwgYXNzaWduZWQgdG88YnI+DQp0 aGUgYXNzb2NpYXRlZCBwcm90ZWN0ZWQgTFNQIGFuZCByZWZyZXNoIHRoZSBzdGF0ZSBhbmQgcHJv dmlkZSB0aGU8YnI+DQpsYWJlbCBiYWNrLjxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIHRoYXQgdGhl cmUgaXMgYW55IGFsbG9jYXRpb24gb2YgdXNlbGVzcyBsYWJlbHMuICZuYnNwO0NvdWxkDQp5b3U8 YnI+DQpjbGFyaWZ5IGFuIGV4YW1wbGUgd2hlcmUgdGhpcyBoYXBwZW5zPyAmbmJzcDtJbiBwYXJ0 aWN1bGFyLCBjb3VsZCB5b3UgcHVsbDxicj4NCnRoZSBwcm9ibGVtIGZyb20gUkZDNDA5MD88YnI+ DQo8YnI+DQpUaGFua3MsPGJyPg0KQWxpYTxicj4NCjxicj4NCjxicj4NCjxicj4NCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoZSBlbWFpbCBo YXMgJm5ic3A7YmVlbiBzY2FubmVkIGJ5IEFudGktU3BhbTxicj4NCnN5c3RlbSwgJm5ic3A7aWYg eW91IGZpbmQgU3BhbSBvciBWaXJ1cyBpbiB0aGlzIG1haWwsPGJyPg0KcGxlYXNlIGZvcndhcmQg aXQgdG86IGhlbHBkZXNrQHp0ZS5jb20uY248YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxi cj48YnI+PGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kjxicj4K0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpWlRFy/nT0KOsPGJyPgpaVEW21LjD 08q8/tO109DL+dPQyKjA+6Gjx+u908rV1d/XotLiPGJyPgqxo8Pco6zOtL6tt6K8/sjLyunD5tDt v8mjrLK7tcPP8sjOus612jxicj4KyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6rNDFz6K1xMir sr88YnI+Crvysr+31qGj0tTJz8n5w/e99srK08PT2rmk1/fTyrz+oaM8YnI+CkluZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDsmbmJzcDtOb3RpY2Wjujxicj4KVGhlJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXM8YnI+ CnNvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDsmbmJzcDtaVEUmbmJzcDtDb3Jwb3Jh dGlvbi4mbmJzcDs8YnI+ClRoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lz Jm5ic3A7Y29uZmlkZW50aWFsLjxicj4KUmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0bzxicj4KbWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG88YnI+CmRp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uPGJyPgp0byZuYnNwO290aGVycy48YnI+CioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqPGJyPgo= --=_alternative 001FBB5C482570E4_=-- --===============1967766873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1967766873==-- From mpls-bounces@lists.ietf.org Tue Dec 27 12:01:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErICr-00025V-FB; Tue, 27 Dec 2005 12:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErICp-00025L-KF for mpls@megatron.ietf.org; Tue, 27 Dec 2005 12:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13423 for ; Tue, 27 Dec 2005 12:00:37 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErIGf-000376-No for mpls@ietf.org; Tue, 27 Dec 2005 12:05:48 -0500 Received: by wproxy.gmail.com with SMTP id i14so1132177wra for ; Tue, 27 Dec 2005 09:01:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FxT/VgquHZ34jgG+Chbivvq4heRK0m2JdwFbOtlpFZXz2vunuwbmpYZXOZUB2nAqDvbx+apDmcF/Cv/XyVJJHlizrrABUrPtz4z/C20gaenl7l+mFSu2rbTVnCSGWEmyV3bx/A9I87YD2o5bmmA5dc/AZnWQUfMtTWeVuOqnCok= Received: by 10.54.131.11 with SMTP id e11mr6935892wrd; Tue, 27 Dec 2005 09:01:37 -0800 (PST) Received: by 10.54.139.11 with HTTP; Tue, 27 Dec 2005 09:01:37 -0800 (PST) Message-ID: <428faf140512270901h78573bcqdc194efee64e149e@mail.gmail.com> Date: Tue, 27 Dec 2005 12:01:37 -0500 From: Vishnu Pavan Beeram To: "jiang.weilian@zte.com.cn" Subject: Re: [mpls] Reply: draft-weilian-mpls-fast-reroute-ext-00 In-Reply-To: MIME-Version: 1.0 References: <6280db520512211556w32a0fd9yecb078c00eb8aaaa@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: luo.jian@zte.com.cn, IETF MPLS List , kong.yong@zte.com.cn, Feng.jun99@zte.com.cn X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0388278254==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org --===============0388278254== Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Transfer-Encoding: base64 SmlhbmcsCgpZb3UgbWVudGlvbmVkIHR3byBwdXJwb3NlcyBmb3IgbWFraW5nIGNoYW5nZXMgdG8g dGhlCiJmYWNpbGl0eSBiYWNrdXAiIHRlY2huaXF1ZS4KKDEpIFRvIHJlbW92ZSB0aGUgbmVlZCBm b3IgZXN0YWJsaXNoaW5nIHN0YXRlIGJsb2NrcwphbmQgYWxsb2NhdGluZyBsYWJlbHMgZm9yIHRo ZSBwcm90ZWN0ZWQgdHVubmVsIGFsb25nCnRoZSBwYXRoIG9mIHRoZSBieXBhc3MgdHVubmVsLgoo MikgVG8gcmVtb3ZlIHRoZSBuZWVkIGZvciB0cmFuc21pdHRpbmcgUmVmcmVzaAptZXNzYWdlcyBm b3IgdGhlIHByb3RlY3RlZCB0dW5uZWwgdGhyb3VnaCB0aGUKYnlwYXNzIHR1bm5lbC4KCkluIHRo ZSAiZmFjaWxpdHkgYmFja3VwIiB0ZWNobmlxdWUsIChhcyBBbGlhIG1lbnRpb25lZCkKdGhlIGNv bnRyb2wgbWVzc2FnZXMgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQcyBhcmUgc2VudAp0aHJvdWdoIHRo ZSBieXBhc3MgdHVubmVsIGFuZCBhcmUgbm90IHZpc2libGUgb24gdGhlCnRyYW5zaXQgbm9kZXMg YWxvbmcgdGhlIHBhdGggb2YgdGhlIGJ5cGFzcyB0dW5uZWwuClRoZXJlIGFyZSBubyB1bm5lY2Vz c2FyeSBQU0JzL1JTQnMvTGFiZWxzIGJlaW5nCmFsbG9jYXRlZCBhbG9uZyB0aGUgcGF0aCBvZiB0 aGUgYnlwYXNzIHR1bm5lbC4gVGhpcwplZmZlY3RpdmVseSBtZWFucyB0aGF0IHB1cnBvc2UgKDEp IGRvZXMgbm90CnJlYWxseSBzZXJ2ZSBhbnl0aGluZy4KCkknbSBhbHNvIG5vdCBzdXJlIGlmIEkg dW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbiBiZWhpbmQKdGhlIHNlY29uZCBwdXJwb3NlICh0byBy ZW1vdmUgdGhlIG5lZWQgdG8gdHJhbnNtaXQKUmVmcmVzaCBtZXNzYWdlcyBmb3IgdGhlIHByb3Rl Y3RlZCB0dW5uZWwgdGhyb3VnaCB0aGUKYnlwYXNzIHR1bm5lbCkuIFRoZSBiYXNpYyBpZGVhIGJl aGluZCB0aGUgY29uY2VwdApvZiBieXBhc3MgdHVubmVscyBpcyB0byBpbXByb3ZlIHNjYWxhYmls aXR5LiBBcyBwZXIKUkZDNDA5MCwgdGhlIHRyYW5zaXQgbm9kZXMgYWxvbmcgdGhlIHBhdGggb2Yg dGhlIGJ5cGFzcwp0dW5uZWwgYXJlIG9ibGl2aW91cyBvZiBhbGwgdGhlIHByb3RlY3RlZCBMU1Bz IHRoYXQgdGhlCmJ5cGFzcyB0dW5uZWwgaXMgcHJvdGVjdGluZy4gV2l0aCB5b3VyIHByb3Bvc2Fs LAp0aGVzZSB0cmFuc2l0IG5vZGVzIGNvbWUgaW50byBwbGF5IHdoZW4gYSBmYWlsb3ZlcgpvY2N1 cnMgYW5kIHRoZXkgaGF2ZSB0byBwcm9jZXNzIGFsbCB0aGUgdHJpZ2dlciBtZXNzYWdlcwp0aGF0 IGFyZSBnZW5lcmF0ZWQgYnkgdGhlIFBMUiB3aGVuZXZlciB0aGUgRlJSX1NXSVRDSApvYmplY3Qg Z2V0cyB1cGRhdGVkIChpZiB0aGUgYnlwYXNzIHByb3ZpZGVzIHByb3RlY3Rpb24KZm9yIG4gTFNQ cywgdGhlIEZSUl9TV0lUQ0ggb2JqZWN0IHdvdWxkIGhhdmUgbiBzdWItb2JqZWN0cwphbmQgYW55 IGNoYW5nZSB0byBhbnkgb2YgdGhlc2Ugc3ViLW9iamVjdHMgd291bGQgaGF2ZSB0bwpiZSBwcm9j ZXNzZWQgYWxsIGFsb25nIHRoZSBwYXRoIG9mIHRoZSBieXBhc3MgdHVubmVsKS4KClRoZSBvbmx5 IGRvd25zaWRlICB0byB0aGUgImZhY2lsaXR5IGJhY2t1cCIgdGVjaG5pcXVlCmRpc2N1c3NlZCBp biBSRkM0MDkwIGlzIHRoYXQgdGhlIG1lcmdlIG5vZGUKbWlnaHQgZW5kIHVwIHJlY2VpdmluZyBs b3RzIG9mIG1lc3NhZ2VzIG9uIG9uZSBpbnRlcmZhY2UKKGFzIG9wcG9zZWQgdG8gYmVpbmcgZGlz dHJpYnV0ZWQgb24gbXVsdGlwbGUpIGFmdGVyIHRoZQpmYWlsb3Zlci4gSSBkb250IHRoaW5rIHRo aXMgaXMgYW4gaXNzdWUgYnV0IGlzIG9uZSBhcmVhCndoZXJlIHNvbWUgb3B0aW1pemF0aW9uIHdv dWxkIGJlIHVzZWZ1bC4gWW91ciBkcmFmdCBzY29yZXMKaGVyZSBidXQgaXQgZG9lcyBjb21lIHdp dGggYW4gb3ZlcmhlYWQgb2YgaXRzIG93biBhbmQgdGhhdApzb3J0IG9mIHVuZGVybWluZXMgaXRz IHV0aWxpdHkuCgpMZXQgbWUga25vdyBpZiBJIG1pc3NlZCBhbnl0aGluZy4KCi0gVmlzaG51IFBh dmFuCk1vdmF6IE5ldHdvcmtzCgpPbiAxMi8yNy8wNSwgamlhbmcud2VpbGlhbkB6dGUuY29tLmNu IDxqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+IHdyb3RlOgo+Cj4gVGhhbmtzIGEgbG90IGZvciBB bGlhJ3Mgb3BpbmlvbnMhCj4KPiBUaGVyZSBhcmUgdHdvIHB1cnBvc2VzIGluIG91ciBwcm9wb3Nh bDoKPiAxLiBXZSB0aGluayB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yIGVzdGFibGlzaGluZyBQ U0KholJTQiBhbmQKPiBhbGxvY2F0aW5nIGxhYmVscyBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWwg YWxvbmcgdGhlIHBhdGggb2YgdGhlCj4gYnlwYXNzIHR1bm5lbC4gQW5kIGl0IGxvb2tzIGxpa2Ug Ym90aCBvZiB1cyBhZ3JlZSBvbiB0aGlzIHBvaW50Cj4gZnJvbSBBbGlhJ3MgZW1haWwuIEluIFJG QyA0MDkwLCBpdCBzYXlzIFBMUiBzZW5kcyB0aGUgY29udHJvbAo+IHRyYWZmaWMgZm9yIHRoZSBw cm90ZWN0ZWQgTFNQIG9udG8gdGhlIGJ5cGFzcyB0dW5uZWwsIGFuZCB0aGUKPiBpbnRlcm1lZGlh dGUgbm9kZXMgb2YgdGhlIGJhY2t1cCB0dW5uZWwgd2lsbCBub3QgYWxsb2NhdGUgbGFiZWxzCj4g Zm9yIHRoZSBwcm90ZWN0ZWQgdHVubmVsLiBTbyB3ZSBoYXZlIG1pc3Rha2VzIGFib3V0IHRoZSBi eXBhc3MKPiB0dW5uZWwgbWVjaGFuaXNtLCB3ZSB3aWxsIGNvcnJlY3QgdGhlbS4KPgo+IDIuIFdl IGFsc28gdGhpbmsgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdHJhbnNtaXR0aW5nIHRoZSBSZWZyZXNo Cj4gbWVzc2FnZXMgZm9yIHRoZSBwcm90ZWN0ZWQgdHVubmVscyB0aHJvdWdoIHRoZSBieXBhc3Mg dHVubmVsLiBXZQo+IGtub3cgdGhhdCBpbiBSRkM0MDkwLCBpdCBzYXlzIFBMUiBuZWVkcyB0byBz ZW5kIHRoZSBjb250cm9sCj4gdHJhZmZpYyBmb3IgdGhlIHByb3RlY3RlZCBMU1Agb250byB0aGUg YnlwYXNzIHR1bm5lbC4gTWF5YmUgdGhlCj4gUmVmcmVzaCBtZXNzYWdlcyBhcmUgZW5jYXBzdWxh dGVkIGFzIG5vcm1hbCBsYWJlbGVkIGRhdGEgYW5kCj4gdHJhbnNtaXR0ZWQgaW4gdGhlIGJ5cGFz cyB0dW5uZWwuIEJ1dCBhcyBpbiBvdXIgZXh0ZW5zaW9ucyB0byB0aGUKPiBGYXN0IFJlcm91dGUg KEZSUikgbWVjaGFuaXNtIG9mIEZhY2lsaXR5IEJhY2t1cCBkZWZpbmVkIGluIFJGQzQwOTAsCj4g UExSIGFuZCBNUCBub2RlcyBjYW4gcmVmcmVzaCB0aGUgcHJvdG9jb2wgc3RhdGUgb2YgcHJvdGVj dGVkIHR1bm5lbAo+IGJ5IHRoZSBSZWZyZXNoIG1lc3NhZ2VzIG9mIGJ5cGFzcyB0dW5uZWwsIHNv IHRoZXJlIGlzIG5vdCBhbnkgZXh0cmEKPiBzcGVuZGluZyBvbiBzZW5kaW5nIHRoZSBjb250cm9s IHRyYWZmaWMgZm9yIHRoZSBwcm90ZWN0ZWQgTFNQIG9udG8KPiB0aGUgYnlwYXNzIHR1bm5lbC4K Pgo+IEluIHRoZSBwcmVzZW50IGRyYWZ0LCBvdXIgZXh0ZW5zaW9ucyBvbmx5IGNvbnNpZGVyIHRo ZSBnbG9iYWwgbGFiZWwKPiBzcGFjZXMgbW9kZS4gQnV0IHdpdGggYSBsaXR0bGUgbW9kaWZpY2F0 aW9uLCB3ZSBjYW4gYWxzbyBzdXBwb3J0Cj4gcGVyLWludGVyZmFjZSBsYWJlbCBzcGFjZXMgbW9k ZS4gQmFzZWQgb3VyIHByZXNlbnQgZXh0ZW5zaW9ucywgYWZ0ZXIKPiB0aGUgcmVsYXRpb24gYmV0 d2VlbiB0aGUgcHJvdGVjdGVkIHR1bm5lbCBhbmQgdGhlIGJ5cGFzcyB0dW5uZWwgYmVpbmcKPiBj b25maXJtZWQgYXQgTVAgbm9kZSwgTVAgbm9kZSB3aWxsIGhhdmUgdGhlIGlucHV0LSBpbnRlcmZh Y2Ugb2YgdGhlCj4gcHJvdGVjdGVkIHR1bm5lbCB3aGlsZSBsaW5rIG9yL2FuZCBub2RlIGZhaWx1 cmUgb2NjdXJzo6h0aGF0IGlzLCB0aGUKPiBpbnB1dC0gaW50ZXJmYWNlIG9mIHRoZSBieXBhc3Mg dHVubmVso6kuIElmIHRoZSBNUCBub2RlIGlzIHBlci1pbnRlcmZhY2UKPiBsYWJlbCBzcGFjZXMg bW9kZSwgd2Ugd2FudCB0aGUgTVAgbm9kZSB0byBmaWxsIHRoZSBsYWJlbCBmb3IgdGhlCj4gY29y cmVzcG9uZGluZyBpbnRlcmZhY2UgaW50byBNUF9OT1RJRllfQUNLIG9iamVjdCwgYW5kIGl0IHdp bGwgYmUgY2FycmllZAo+IGJ5IHRoZSBSRVNWIG1lc3NhZ2VzIHNlbnQgdG8gdGhlIFBMUiBub2Rl LiBUaGVuIFBMUiBub2RlIGNhbiBkaXNjb3ZlciB0aGUKPiBhcHByb3ByaWF0ZSBNUCBsYWJlbC4g Tm93LCB3ZSBjYW4gYWxzbyBzdXBwb3J0IHBlci1pbnRlcmZhY2UgbGFiZWwgc3BhY2VzCj4gbW9k ZS4KPgo+IFJlZ2FyZCwKPiAgSmlhbmcgV2VpbGlhbgo+Cj4KPgo+Cj4KPiBBbGlhIEF0bGFzIDxh a2F0bGFzQGdtYWlsLmNvbT4KPgo+Cj4gMjAwNS0xMi0yMiAwNzo1Ngo+ICAgICAgICAgytW8/sjL o7ogICAgICAgIElFVEYgTVBMUyBMaXN0IDxtcGxzQGxpc3RzLmlldGYub3JnPiwgamlhbmcud2Vp bGlhbkB6dGUuY29tLmNuLCBrb25nLnlvbmdAenRlLmNvbS5jbiwgbHVvLmppYW5AenRlLmNvbS5j biwgRmVuZy5qdW45OUB6dGUuY29tLmNuCj4gICAgICAgICCzrcvNo7oKPiAgICAgICAgINb3zOKj uiAgICAgICAgZHJhZnQtd2VpbGlhbi1tcGxzLWZhc3QtcmVyb3V0ZS1leHQtMDAKPgo+Cj4gT24g cmVhZGluZyB0aGUgaW50cm9kdWN0aW9uIG9mIHRoaXMgZHJhZnQsIEkgYW0gdW5jbGVhciBhYm91 dCB0aGUKPiAgbW90aXZhdGlvbiBhbmQgcHJvYmxlbSB0aGF0IGl0IGlzIHRyeWluZyB0byBzb2x2 ZS4gIFRoZSBkcmFmdCBzYXlzOgo+Cj4gICJIb3dldmVyLCBmb3IgTjoxIGJhY2t1cCwgYWZ0ZXIg dGhlIHByb3RlY3RlZCB0dW5uZWwgc3dpdGNoZXMgdG8gdGhlCj4gIGJhY2t1cCB0dW5uZWwsIHRo ZSBwcm90b2NvbCBzdGF0ZSBzaG91bGQgc3RpbGwgYmUgcmVmcmVzaGVkIHRocm91Z2gKPiAgc2Vu ZGluZyBwcm90b2NvbCBtZXNzYWdlcyBvZiB0aGUgcHJvdGVjdGVkIHR1bm5lbCBhbG9uZyB0aGUg cGF0aCBvZgo+ICBiYWNrdXAgdHVubmVsLiBPbmNlIEZSUiBzd2l0Y2hvdmVyIG9jY3VycywgYWJ1 bmRhbnQgUmVmcmVzaCBtZXNzYWdlcwo+ICBvZiB0aGUgcHJvdGVjdGVkIHR1bm5lbCBhcmUgdHJh bnNtaXR0ZWQgYWxvbmcgdGhlIHBhdGggb2YgYmFja3VwCj4gIHR1bm5lbCwgaW50ZXJtZWRpYXRl IGFuZCB0YWlsIG5vZGVzIG9mIHRoZSBiYWNrdXAgdHVubmVsIHdpbGwgYWxsb2NhdGUKPiAgYWJ1 bmRhbnQgdXNlbGVzcyBsYWJlbHMuIgo+Cj4gIEFzIEkgdW5kZXJzdGFuZCB0aGUgYnlwYXNzIHR1 bm5lbCBtZWNoYW5pc20sIHRoZSBSZWZyZXNoIG1lc3NhZ2VzIGZvcgo+ICB0aGUgcHJvdGVjdGVk IHR1bm5lbHMgYXJlIHNlbnQgdG8gdGhlIG1lcmdlIG5vZGUgdmlhIHRoZSBiYWNrdXAKPiAgdHVu bmVsOyB0aGlzIG1lYW5zIHRoYXQgdGhlIFJlZnJlc2ggbWVzc2FnZXMgYXJlIGVuY2Fwc3VsYXRl ZCBhbmQgbm90Cj4gIHNlZW4gYnkgdGhlIGludGVybWVkaWF0ZSBub2RlcyBvZiB0aGUgYmFja3Vw IHR1bm5lbC4KPiAgV2hlbiB0aGUgcmVmcmVzaCBtZXNzYWdlIGlzIHNlZW4gYnkgdGhlIHRhaWwg bm9kZSBvZiB0aGUgYmFja3VwIHR1bm5lbAo+ICAod2hpY2ggaXMgdGhlIE1QKSwgdGhlIE1QIHdp bGwgbG9vay11cCB0aGUgc3RhdGUgYW5kIGxhYmVsIGFzc2lnbmVkIHRvCj4gIHRoZSBhc3NvY2lh dGVkIHByb3RlY3RlZCBMU1AgYW5kIHJlZnJlc2ggdGhlIHN0YXRlIGFuZCBwcm92aWRlIHRoZQo+ ICBsYWJlbCBiYWNrLgo+Cj4gIEkgZG9uJ3Qgc2VlIHRoYXQgdGhlcmUgaXMgYW55IGFsbG9jYXRp b24gb2YgdXNlbGVzcyBsYWJlbHMuICBDb3VsZCB5b3UKPiAgY2xhcmlmeSBhbiBleGFtcGxlIHdo ZXJlIHRoaXMgaGFwcGVucz8gIEluIHBhcnRpY3VsYXIsIGNvdWxkIHlvdSBwdWxsCj4gIHRoZSBw cm9ibGVtIGZyb20gUkZDNDA5MD8KPgo+ICBUaGFua3MsCj4gIEFsaWEKPgo+Cj4KPiAgKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4gIFRoZSBlbWFpbCBo YXMgIGJlZW4gc2Nhbm5lZCBieSBBbnRpLVNwYW0KPiAgc3lzdGVtLCAgaWYgeW91IGZpbmQgU3Bh bSBvciBWaXJ1cyBpbiB0aGlzIG1haWwsCj4gIHBsZWFzZSBmb3J3YXJkIGl0IHRvOiBoZWxwZGVz a0B6dGUuY29tLmNuCj4gICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgo+Cj4KPgo+Cj4KPiAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioKPiAg0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpWlRFy/nT0KOsCj4g IFpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uIKPiAgsaPD3KOszrS+rbeivP7I y8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoKPiAgyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6rNDF z6K1xMirsr8KPiAgu/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6howo+ICBJbmZvcm1h dGlvbiBTZWN1cml0eSAgTm90aWNlo7oKPiAgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMKPiAgc29sZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uCj4gIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4KPiAgUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvCj4gIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvCj4gIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24KPiAgdG8gb3RoZXJzLgo+ICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBtcGxzIG1haWxpbmcgbGlzdAo+IG1wbHNAbGlzdHMuaWV0Zi5vcmcKPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzCj4KPgo+Cg== --===============0388278254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0388278254==-- From mpls-bounces@lists.ietf.org Wed Dec 28 12:52:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfTY-0000JZ-GB; Wed, 28 Dec 2005 12:52:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfTW-0000JP-1e for mpls@megatron.ietf.org; Wed, 28 Dec 2005 12:52:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17767 for ; Wed, 28 Dec 2005 12:51:23 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErfXa-00046K-39 for mpls@ietf.org; Wed, 28 Dec 2005 12:56:47 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1135792266!11066831!23 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25666 invoked from network); 28 Dec 2005 17:52:21 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 28 Dec 2005 17:52:21 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 43AED14A00039245 for mpls@ietf.org; Wed, 28 Dec 2005 12:52:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Dec 2005 11:52:21 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9846@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-02.txt Thread-Index: AcYLyFsejL/BjwjESlW0JP3AZZAcJwACpOMQAAETXkAAAAT34AAABAaA From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: Subject: [mpls] RE: I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Hi All, Please review and comment on the updated draft "Protocol Extensions for Header Compression over MPLS" (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protoco l-02.txt). The updates are based primarily on comments from Colin Perkins and Magnus Westerlund, see http://www1.ietf.org/mail-archive/web/avt/current/msg05911.html http://www1.ietf.org/mail-archive/web/avt/current/msg05920.html http://www1.ietf.org/mail-archive/web/avt/current/msg06022.html http://www1.ietf.org/mail-archive/web/avt/current/msg06043.html http://www1.ietf.org/mail-archive/web/avt/current/msg06052.html The main changes include the following: 1. Section 3 'Header Compression over MPLS Protocol Overview' re-written to not overlap with Section 4 'Protocol Specifications' 2. Section 4 re-written to use normative language for specifications 3. Section 4.2, all relevant TLVs from RFC3241 and RFC3544 included 4. Section 4.3, PW control word is now 2 octets, one for the length value 5. Section 7 IANA Considerations, PW type values and sub-TLV values defined per discussions with Allison Mankin, Luca Martini on AVT and PWE3 lists Once again, please review and comment on the updated draft. =20 Thanks, Jerry=20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, December 28, 2005 10:50 AM To: i-d-announce@ietf.org Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-hc-over-mpls-protocol-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Protocol Extensions for Header Compression over MPLS Author(s) : J. Ash Filename : draft-ietf-avt-hc-over-mpls-protocol-02.txt Pages : 23 Date : 2005-12-28 =09 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define one or more point-to-point instances corresponding to each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protocol -02.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls