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(_at_)ietf(_dot_)org?subject=help>
List-id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-post: <mailto:mpls(_at_)ietf(_dot_)org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request(_at_)ietf(_dot_)org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/options/mpls>,
<mailto:mpls-request(_at_)ietf(_dot_)org?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(_at_)gmail(_dot_)com> 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(_dot_)chen(_at_)huawei(_dot_)com> 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(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of The
IESG
Sent: Thursday, August 11, 2011 9:46 PM
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org mailing lists by 2011-08-25. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf