Re: [mpls-tp] [PWE3] VCCV usage
<neil.2.harrison@bt.com> Wed, 01 December 2010 07:47 UTC
Return-Path: <neil.2.harrison@bt.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 04A2D3A6D03; Tue, 30 Nov 2010 23:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.189,
BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhtt808rWMv0;
Tue, 30 Nov 2010 23:47:18 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by
core3.amsl.com (Postfix) with ESMTP id DA1F23A6D00;
Tue, 30 Nov 2010 23:47:17 -0800 (PST)
Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by
RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP
Server (TLS) id 8.3.106.1; Wed, 1 Dec 2010 07:48:29 +0000
Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.123]) by
EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi;
Wed, 1 Dec 2010 07:48:29 +0000
From: <neil.2.harrison@bt.com>
To: <yaakov_s@rad.com>
Date: Wed, 1 Dec 2010 07:48:27 +0000
Thread-Topic: [PWE3] VCCV usage
Thread-Index: AQHLhgiDxE/GLhOI3kefbzvPaVR2G5N1DKwAgAARnICAAAFMAIAAaBKggBL67gCAArdUEIAACG0g
Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440039D57EF@EMV62-UKRD.domain1.systemhost.net>
References: <A3C5DF08D38B6049839A6F553B331C76D5CE389931@ILPTMAIL02.ecitele.com>,
<OFBC9BCFE0.4D1C5353-ON482577DE.0025FF7B-482577DE.00270EC4@zte.com.cn>
<A3C5DF08D38B6049839A6F553B331C76D5CE389932@ILPTMAIL02.ecitele.com>
<07F7D7DED63154409F13298786A2ADC9179B9C@EXRAD5.ad.rad.co.il>
<4CF3C348.4000602@cisco.com>
<07F7D7DED63154409F13298786A2ADC9186466@EXRAD5.ad.rad.co.il>
In-Reply-To: <07F7D7DED63154409F13298786A2ADC9186466@EXRAD5.ad.rad.co.il>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: pwe3@ietf.org, mpls-tp@ietf.org
Subject: Re: [mpls-tp] [PWE3] VCCV usage
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 07:47:19 -0000
Hi Yaakov...you may like to ponder on this point (I have raised it several times before, but for some reason it gets ignored...I wonder why? ;-)) .... Any layer network SHOULD (though this really ought to be MUST) have consistent CI (Characteristic Information). There are many reasons for this rather obvious requirement statement, but a key one is that if misconnectivity occurs, then wherever the misdirected DP traffic units and OAM arrive they can be correctly processed...this means that all the functional fields of DP traffic units and DP OAM MUST have unambiguous functional meaning. I think this statement is so obviously true that no sane person could disagree with it. Aside=> The above requirement is true for all 3 network modes, but it is most important in a co-ps mode network (as this has the richest potential set of misconnectivity defects) where short-cuts have been taken on child traffic unit labelling (ie omit SA label, DA label reduced to link significant, omit PID label) due to the a-priori-known single-source property of the parent connection. However, this a-priori-known single-source property of a parent connection is broken under misconnectivity defects and cannot, indeed MUST NOT, be assumed...ergo why child traffic units and OAM MUST have consistent CI. You are raising one case below where there is non-consistent CI.....but there are many more. Even the 'label' (there is only one) in an MPLS traffic unit is not consistent of its meaning. Then we have lots of choices for OAM. Now factor-in mixed cases of LSP sublayering and LSP layering...the former LSPs reside in the *same layer network* whilst the latter LSPs reside in *different layer networks* (this is a rather more serious self-inflicted consequential problem BTW). Do you think it is sensible given the above is 'known' (and for some time) that such mistakes should be carried over into MPLS-TP?....esp given this is supposed to be a transparent transport network (hint=> this should never have sublayering and esp not PWs as all clients MUST be treated equally...else we do not have a transparent transport network). Please excuse me copying this to the MPLS-TP list as my observation is clearly germane to that WG too. regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Yaakov Stein > Sent: 01 December 2010 06:49 > To: Carlos Pignataro > Cc: mustapha.aissaoui@alcatel-lucent.com; pwe3@ietf.org; > lizhong.jin@zte.com.cn; lmartini@cisco.com > Subject: Re: [PWE3] VCCV usage > > Carlos > > Sorry that it took me a bit of time to catch up on PWE emails. > > I don't think it would be useful for me to try to answer old > questions, as the water has already reached the sea. > However, there is one point I wanted to comment on. > > [YJS] So, type 2 requires negotiation. > [Carlos] I missed this part, why does this require > negotiation? It is from RFC 3032. > > I completely agree that an LSR recognizes the router alert label. > However, there are many situations where the PW interworking > is not performed by a device with full MPLS functionality. > For example, consider a PW setup with only the PW label over > IP according to RFC 4023. > > Here the receiving device would be quite surprised to find > the router alert label, were it not informed that this is a > possibility. > > Y(J)S > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >
- Re: [mpls-tp] [PWE3] VCCV usage neil.2.harrison
- Re: [mpls-tp] [PWE3] VCCV usage Yaakov Stein