Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA853A6E81; Fri, 18 Feb 2011 01:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] 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 eMwjF7K2DcqV; Fri, 18 Feb 2011 01:17:27 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id B9C183A6E0C; Fri, 18 Feb 2011 01:17:26 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 18 Feb 2011 09:17:58 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.15]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 18 Feb 2011 09:17:58 +0000 From: To: , Date: Fri, 18 Feb 2011 09:17:54 +0000 Thread-Topic: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFMAAQ7z9A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440145CA70F@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: 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: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, HUANG@core3.amsl.com, Rotem@core3.amsl.com, lmartini@cisco.com, mpls-tp@ietf.org, Mishael.Wexler@ecitele.com, lihan@chinamobile.com, pwe3@ietf.org, Feng.f.Huang@alcatel-sbell.com.cn, Robert.Rennison@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:17:29 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha/Greg, I would certainly agree that the use of the GAL with PWs is wrong....but th= e reason for that is simply that PWs per se violate the whole purpose of MP= LS-TP as a *transparent* transport network, noting that a true transport ne= twork must treat all client symbols equally...that is just a fact. However, given PWs are being carried forward into MPLS-TP then we also have= to deal with the issue that CP/MP of a transport network needs to logicall= y OOB wrt to the DP traffic. The GAL provides this function for the MPLS-T= P layer network itself (though it also gets this a wee bit wrong by asking = it to play a DP OAM role too,) but what about the PW layer network? MS PWs for sure are their own/different layer network....so they will need = their own access point addressing, OAM, routing, signalling, etc. I asked = some time ago why we were not using RSVP signalling here but T-LDP instead.= ..and I was told that RSVP cannot handle the PW signalling messages (nor th= e access addressing formats I assume...and we will of course need a new ins= tance of routing that will). So how is T-LDP being taken OOB wrt to the PW DP? regards, Neil Neil Harrison BT Design Tel: +44 (0) 1 803 812 545 Email: neil.2.harrison@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 18 February 2011 07:05 To: Greg Mirsky Cc: Robert Rennison; mpls@ietf.org; Luca Martini; mpls-tp@ietf.org; Mishael= Wexler; lihan@chinamobile.com; pwe3; Rotem@core3.amsl.com; HUANG@core3.ams= l.com; Feng F; Cohen Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Greg, and all, I concur with Greg. Using GAL with PWs is highly problematic, and all the related issues (raise= d during the poll on accepting this draft as a WG item) have not, AFAIK, be= en resolved. Regards, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 18, 2011 8:47 AM To: Luca Martini Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Fen= g F Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: Greg, You are correct , the proposed update does not propose any changes to VCCV. However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA. Given the good amount of discussion on this point, we should probably have = a discussion in Beijing. Luca On 10/29/2010 05:07 PM, Greg Mirsky wrote: Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha/Greg,

 

I would certainly agree that the use of the GAL wit= h PWs is wrong....but the reason for that is simply that PWs per se violate the w= hole purpose of MPLS-TP as a *transparent* transport network, noting that a true transport network must treat all client symbols equally...that is just a fact. 

 

However, given PWs are being carried forward into M= PLS-TP then we also have to deal with the issue that CP/MP of a transport network needs to logically OOB wrt to the DP traffic.  The GAL provides this function for the MPLS-TP layer network itself (though it also gets this a w= ee bit wrong by asking it to play a DP OAM role too,) but what about the PW la= yer network?

 

MS PWs for sure are their own/different layer network....so they will need their own access point addressing, OAM, routin= g, signalling, etc.  I asked some time ago why we were not using RSVP signalling here but T-LDP instead...and I was told that RSVP cannot handle = the PW signalling messages (nor the access addressing formats I assume...and we will of course need a new instance of routing that will).

 

So how is T-LDP being taken OOB wrt to the PW DP?

 

regards, Neil

 

Neil Harrison
BT Design

Tel: +44 (0) 1 803 812 545
Email: neil.2.harrison@bt.com
Web: www.bt.com

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not = the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.<= /p>

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 18 February 2011 07:05
To: Greg Mirsky
Cc: Robert Rennison; mpls@ietf.org; Luca Martini; mpls-tp@ietf.org; Mishael Wexler; lihan@chinamobile.com; pwe3; Rotem@core3.amsl.com; HUANG@core3.amsl.com; Feng F; Cohen
Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

 

Greg, and all,<= /span>

I concur with Greg.

Using GAL with PWs is high= ly problematic, and all the related issues (raised during the poll on acceptin= g this draft as a WG item) have not, AFAIK, been resolved.<= /p>

 

Regards,=

     S= asha

 

From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsk= y [gregimirsky@gmail.com]
Sent: Friday, February 18, 2011 8:47 AM
To: Luca Martini
Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HU= ANG Feng F
Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Authors and All,
prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem.
I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my view= , this document updates not only RFC 5586
but RFC 5085 too.

Regards,
Greg

Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

On Sat, Oct 30, 2010 at 10= :14 AM, Luca Martini <lmartini@cisco.com> wrote:

Greg,

You are correct , the proposed update does not propose any changes to VCCV.=
However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA.
Given the good amount of discussion on this point, we should probably have = a discussion in Beijing.

Luca




On 10/29/2010 05:07 PM, Greg Mirsky wrote: 

Dear Authors,
= 
I think that proposed update of the Section 4.2. RFC =
5586 makes it possible
to use GAL on MPLS-TP PW that uses Control Word. I co=
nsider it to be
conflict between PW VCCV CC types because use of GAL =
is not negotiated
through PW VCCV negotiation. To avoid such situation =
I propose:
 
   - in Section 5 request IANA to assign new CC Type &q=
uot;MPLS Generic
   Associated Channel Label"
   - assign precedence to new CC Type that =
affects Section 7 RFC 5085
 
Regards,
Greg
 
 
_______________________________________________<=
/o:p>
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=

 

 

--_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_--