Eric, Don't you feel that uniformity should be maintained on AGI field representation for on-demand and proactive OAM operations? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | AGI Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-mpls-tp-cc-cv-rdi-06, section 3.5.3. PW Endpoint MEP-ID and draft-ietf-mpls-tp-on-demand-cv-06, section 2.3.2. Static Pseudowire Sub-TLV conflict in representing the AGI field. Why are we not following this generic format for representing the AGI field? Am I missing something? Thanks, Venkat. Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 To: binny jeshan <binnyjeshan at gmail.com>, "mpls at ietf.org" <mpls at ietf.org> Subject: Re: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 From: Eric Gray <eric.gray at ericsson.com> Date: Thu, 11 Aug 2011 07:03:09 -0400 Accept-language: en-US Acceptlanguage: en-US Cc: Ross Callon <rcallon at juniper.net>, MPLS-TP ad hoc team <ahmpls-tp at lists.itu.int>, "draft-ietf-mpls-tp-on-demand-cv at tools.ietf.org" <draft-ietf-mpls-tp-on-demand-cv at tools.ietf.org> Delivered-to: mpls at ietfa.amsl.com In-reply-to: <CAHcPYOzo1vO_ThspndrZwf-X8JAf2b0Mr1SGp7mL2HfN_OxRNw at mail.gmail.com> List-archive: <http://www.ietf.org/mail-archive/web/mpls> List-help: <mailto:mpls-request@xxxxxxxx?subject=help> List-id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-post: <mailto:mpls@xxxxxxxx> List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@xxxxxxxx?subject=subscribe> List-unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@xxxxxxxx?subject=unsubscribe> References: <CAHcPYOzo1vO_ThspndrZwf-X8JAf2b0Mr1SGp7mL2HfN_OxRNw at mail.gmail.com> Thread-index: AcxAZ8Iuor4OYFULT7mPiL+c0YrKTgXrKqiA Thread-topic: Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 Binny, We discussed this in detail. Superficially, this seemed like a great idea, with precedents in the CC/CV/RDI draft. The issues we ran into include: 1) the Static PW ID TLV is already a sub-TLV; there are issues and a very undesirable precedent associated with creating a sub-TLV for a sub-TLV. 2) the flexibility associated with inheriting the type code also poses a risk; we cannot know in advance what other AGI types might be invented in the future, and whether or not it would make sense in then existing TP implementations to support generally the new type(s) as part of the Static PW Identifier Sub-TLV. What we decided to do was to change the name of the field to "Service Identifier" - which will be an unsigned integer and which may contain a type 0x01 AGI, for example. Because it is an unsigned integer, it may also be used to contain anything smaller than 64 bits. The flexibility to support other AGI types still exists, should it become necessary to do so. In that event, we could define additional Static PW Sub-TLV type(s) to support any AGI type(s) that make sense at that time. Thanks for your thoughtful and thought-provoking input! We appreciate your putting time into reviewing our draft... -- Eric On Sun, Aug 21, 2011 at 1:48 PM, venkatesan mahalingam <venkatflex@xxxxxxxxx> wrote: > Hi, > > I don't see any TLVs defined for performing the on-demand CV operation > on MPLS -TP Sections. Is this intentional? > > and > > Co-routed bidirectional tunnel identifier: > A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: > Node_ID::Tunnel_Num}::LSP_Num > Associated bidirectional tunnel identifier: > A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: > Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} > > How does Static LSP Sub-TLV address the need of two LSP_Nums of > associated bidirectional tunnel? > > Am I missing something? > > Thanks, > Venkat. > > On Fri, Aug 19, 2011 at 5:50 AM, Mach Chen <mach.chen@xxxxxxxxxx> wrote: >> Hi, >> >> One question about the difference of the encapsulation modes between CV and Route Tracing. >> >> In Section 3, there are three encapsulation modes for on-demand CV: "LSP-Ping with IP encapsulation", "On-demand CV with IP encapsulation, over ACH" and "Non-IP based On-demand CV, using ACH", but for On-demand Route Tracing (in section 4), there are only two modes: "On-demand LSP Route Tracing with IP encapsulation" and "Non-IP based On-demand LSP Route Tracing, using ACH". Seems that there should be "On-demand LSP Route Tracing with IP encapsulation, over ACH" accordingly. What's reason behind this? Or maybe I missed something. >> >> Best regards, >> Mach >> >>> -----Original Message----- >>> From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of The >>> IESG >>> Sent: Thursday, August 11, 2011 9:46 PM >>> To: IETF-Announce >>> Cc: mpls@xxxxxxxx >>> Subject: [mpls] Last Call: <draft-ietf-mpls-tp-on-demand-cv-06.txt> (MPLS >>> On-demand Connectivity Verification and Route Tracing) to Proposed Standard >>> >>> >>> The IESG has received a request from the Multiprotocol Label Switching WG >>> (mpls) to consider the following document: >>> - 'MPLS On-demand Connectivity Verification and Route Tracing' >>> <draft-ietf-mpls-tp-on-demand-cv-06.txt> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@xxxxxxxx mailing lists by 2011-08-25. Exceptionally, comments may be >>> sent to iesg@xxxxxxxx instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> Label Switched Path Ping (LSP-Ping) is an existing and widely >>> deployed Operations, Administration and Maintenance (OAM) mechanism >>> for Multi-Protocol Label Switching (MPLS) Label Switched Paths >>> (LSPs). This document describes extensions to LSP-Ping so that LSP- >>> Ping can be used for On-demand Connectivity Verification of MPLS >>> Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also >>> clarifies procedures to be used for processing the related OAM >>> packets. Further, it describes procedures for using LSP-Ping to >>> perform Connectivity Verification and Route Tracing functions in >>> MPLS-TP networks. Finally this document updates RFC 4379 by adding a >>> new address type and requesting an IANA registry. >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> _______________________________________________ >>> mpls mailing list >>> mpls@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf