From michelg@upperside.fr Tue Jan 5 08:30:47 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1DF3A6803 for ; Tue, 5 Jan 2010 08:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 3LApKsWKzhxS for ; Tue, 5 Jan 2010 08:30:44 -0800 (PST) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by core3.amsl.com (Postfix) with ESMTP id 27CD928C118 for ; Tue, 5 Jan 2010 08:30:43 -0800 (PST) Received: from nbMichelvst ([195.6.217.229]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id o05GUdlE005417 for ; Tue, 5 Jan 2010 17:30:40 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 5 Jan 2010 17:29:35 +0100 Message-ID: <2DF4111AC100414ABE6E433083203E94@UPPERSIDECONFERENCES.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CA8E2C.A684D9B0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqOJEQ0wMRXLAvSQFmBxLiAzuL7nw== X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.1.5.161824 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Congress Paris 2010 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:30:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CA8E2C.A684D9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The MPLS & Ethernet World Congress 2010 will start next February 9. Particular attention will be paid to MPLS-TP standards and mechanisms, multicasting and cloud computing. The traditional debate will address OAM issues for MPLS-TP. Remind that a second conference, Ethernet Wholesale, will be organized same place, same time. More info: http://www.upperside.fr/ ------=_NextPart_000_0006_01CA8E2C.A684D9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MPLS & Ethernet World Congress 2010 = will start next February 9.

Particular attention will be paid to MPLS-TP standards and mechanisms, multicasting and cloud = computing.

The traditional debate will address OAM issues = for MPLS-TP.

 

Remind that a second conference, Ethernet = Wholesale, will be organized same place, same time.

 

More info: http://www.upperside.fr/

 

------=_NextPart_000_0006_01CA8E2C.A684D9B0-- From root@core3.amsl.com Wed Jan 6 07:30:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AFE2C3A6817; Wed, 6 Jan 2010 07:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100106153001.AFE2C3A6817@core3.amsl.com> Date: Wed, 6 Jan 2010 07:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:30:01 -0000 --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 : Requirements for Label Edge Router Forwarding of IPv4 Option Packets Author(s) : W. Jaeger, et al. Filename : draft-ietf-mpls-ip-options-03.txt Pages : 10 Date : 2010-01-06 This document imposes a new requirement on Label Edge Routers (LER) specifying that when determining whether to MPLS encapsulate an IP packet, the determination is made independent of any IP options that may be carried in the IP packet header. Lack of a formal standard has resulted in different LER forwarding behaviors for IP packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IP option packets that belong to a prefix-based FEC but fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IP packets with header options cannot operate in certain MPLS environments. This new requirement will reduce the risk of IP options-based security attacks against LSRs as well as assist LER operation across MPLS networks which minimize the IP routing information carried by LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ip-options-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-ip-options-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-06072455.I-D@ietf.org> --NextPart-- From mach@huawei.com Wed Jan 6 17:31:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C00728C0EA; Wed, 6 Jan 2010 17:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 oFKWowJi1sDI; Wed, 6 Jan 2010 17:31:02 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9B0463A695E; Wed, 6 Jan 2010 17:31:02 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVU00FYJS7C8F@szxga04-in.huawei.com>; Thu, 07 Jan 2010 09:30:49 +0800 (CST) Received: from m55527c ([10.111.12.102]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVU0021VS7CEV@szxga04-in.huawei.com>; Thu, 07 Jan 2010 09:30:48 +0800 (CST) Date: Thu, 07 Jan 2010 09:30:48 +0800 From: Mach Chen To: mpls@ietf.org Message-id: <41E15F95D518452B8D0C019A4E5A3A98@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal Cc: mpls-tp@ietf.org Subject: [mpls] Ask for comments on draft-chen-mpls-return-path-specified-lsp-ping-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 01:31:03 -0000 Hi MPLSers, As said at the last IETF meeting, we'd appreciate to receive any comments and suggestion on the draft(http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txt). This draft defines extensions to the LSP Ping that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by BFD for MPLS bootstrap signaling thereby making BFD for MPLS more robust. Looking forward to receive your comments! Best regards and Happy New Years! Mach From wwwrun@core3.amsl.com Thu Jan 7 09:33:49 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3925D3A68A6; Thu, 7 Jan 2010 09:33:48 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100107173349.3925D3A68A6@core3.amsl.com> Date: Thu, 7 Jan 2010 09:33:49 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS120 - Response to MPLS-TP NM Framework-02 WG Last Call (ref # 013.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:33:49 -0000 Title: LS120 - Response to MPLS-TP NM Framework-02 WG Last Call (ref # 013.02) Submission Date: 2010-01-07 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=627 Please reply by 2010-05-31 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Kam.Lam@alcatel-lucent.com Purpose: For action Body: Thank you for your liaison statement (ref # 013.01) soliciting last call comments by ITU-T of the MPLS-TP NM Framework draft. The experts of Q14/15 have reviewed draft-ietf-mpls-tp-nm-framework-02.txt by correspondence. We found our previous comments on the -01 draft have been adequately addressed. Therefore, we have no concerns with the IETF proceeding with the publication of the -02 draft. Should there be any further technical changes to the draft, we would appreciate the opportunity to provide additional review and comments. Attachment(s): LS120 - Response to MPLS-TP NM Framework-02 WG Last Call (ref # 013.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file746.pdf) From rfc-editor@rfc-editor.org Thu Jan 7 16:52:50 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844143A68BB; Thu, 7 Jan 2010 16:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.299 X-Spam-Level: X-Spam-Status: No, score=-17.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 bAsNH0la2Uno; Thu, 7 Jan 2010 16:52:49 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C8DD53A6826; Thu, 7 Jan 2010 16:52:49 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 4B32839B487; Thu, 7 Jan 2010 16:50:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100108005025.4B32839B487@bosco.isi.edu> Date: Thu, 7 Jan 2010 16:50:25 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 5718 on An In-Band Data Communication Network For the MPLS Transport Profile X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:52:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5718 Title: An In-Band Data Communication Network For the MPLS Transport Profile Author: D. Beller, A. Farrel Status: Standards Track Date: January 2010 Mailbox: dieter.beller@alcatel-lucent.com, adrian@olddog.co.uk Pages: 8 Characters: 18997 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-gach-dcn-06.txt URL: http://www.rfc-editor.org/rfc/rfc5718.txt The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ostokes@extremenetworks.com Fri Jan 8 14:29:27 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A093A67A2 for ; Fri, 8 Jan 2010 14:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QO3RbbEFZwpX for ; Fri, 8 Jan 2010 14:29:26 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id BB2FA3A659B for ; Fri, 8 Jan 2010 14:29:26 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Fri, 8 Jan 2010 14:29:24 -0800 From: Olen Stokes To: "'mpls@ietf.org'" Date: Fri, 8 Jan 2010 14:29:23 -0800 Thread-Topic: Question on draft-ietf-mpls-ip-options-03.txt Thread-Index: AcqQsgdbt2csiL26Sge4p0h7m3vhjA== Message-ID: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6738A78F51650A4FAEDCF6844B26C21443410E1943USEXCHANGEcor_" MIME-Version: 1.0 Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 22:29:27 -0000 --_000_6738A78F51650A4FAEDCF6844B26C21443410E1943USEXCHANGEcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following specific type of IP option-based security attack is cited in = Section 5.1 of the draft: Crafted IP strict and loose source route option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at a ingress LER may allow an attacker to specify explicit IP forwarding path(s) across an MPLS network and, thereby, target specific LSRs with any of the DoS attacks outlined above. This assumes, of course, that the MPLS network is enabled to process IP strict and loose source route options. What is the intended action to be taken in cases where source routing is pe= rmitted? Cheers, Olen --_000_6738A78F51650A4FAEDCF6844B26C21443410E1943USEXCHANGEcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The following specific type of IP option-based security attack is cite= d in Section 5.1 of the draft:
 
       Crafted IP strict and loose sourc= e route option packets that
       belong to a prefix-based FEC yet = bypass MPLS encapsulation at a
       ingress LER may allow an attacker= to specify explicit IP
       forwarding path(s) across an MPLS= network and, thereby, target
       specific LSRs with any of the DoS= attacks outlined above.  This
       assumes, of course, that the MPLS= network is enabled to process
       IP strict and loose source route = options.
 
What is the intended action to be taken in cases where source routing = is permitted?
 
Cheers,
Olen
 
 
 
--_000_6738A78F51650A4FAEDCF6844B26C21443410E1943USEXCHANGEcor_-- From loa@pi.nu Mon Jan 11 04:51:24 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9DF3A67C1; Mon, 11 Jan 2010 04:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 c6tvsiZNwSmD; Mon, 11 Jan 2010 04:51:23 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id BD1163A6403; Mon, 11 Jan 2010 04:51:23 -0800 (PST) Received: from [192.36.158.110] (wdhcp-158-110.verkstad.net [192.36.158.110]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 9C509D403E; Mon, 11 Jan 2010 13:51:17 +0100 (CET) Message-ID: <4B4B1EC0.8050100@pi.nu> Date: Mon, 11 Jan 2010 13:51:12 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: mpls@ietf.org, mpls-tp@ietf.org Content-Type: multipart/alternative; boundary="------------020801020508020605080306" Subject: [mpls] important dates for IETF77 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 12:51:24 -0000 This is a multi-part message in MIME format. --------------020801020508020605080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, plese find the "important dates" for IETF77 at: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 /Loa --------------020801020508020605080306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

plese find the "important dates" for IETF77 at:

http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77

/Loa

--------------020801020508020605080306-- From prabhu.ashwin@gmail.com Tue Jan 12 01:24:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66AD3A67BE for ; Tue, 12 Jan 2010 01:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 uTpLeJK-0Vkj for ; Tue, 12 Jan 2010 01:24:54 -0800 (PST) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id F2F8E3A6765 for ; Tue, 12 Jan 2010 01:24:53 -0800 (PST) Received: by qyk26 with SMTP id 26so11344907qyk.5 for ; Tue, 12 Jan 2010 01:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=cdgPd7fdng8lqGnFBY0k9jYseQaP0N8q5eGQ7NhRhOc=; b=vIiCGDKmsN0d9D7Z04J5T3fTyc0r6/7cIAWv0axAtsGKdA6hjRS4/uxQqddjb+tH0b 7cBESpgcWulQpO78GiNJee7QHI7lyPZo2TYyQy/Oy3tLh4WECmzewYkGPZ9ggL8sVii0 x1WswiILKOAPyEKZG+3e9HRdXZKTZ6N9ussWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MKYQPxca8GW9D4Lpom8YjNj11sOWSaooECK+j1S9OZx81+hLjE5nKIntkJgVhmrX0H rxWt8XamstOekhPRZBTPD2AxJOMjOI8r6DqRiC62DQw7mn8TCz5FZbayTEl8Icbmzpgb Gn22iivWQM9R6w9Qprt/rCya3fkPYFyqENczE= MIME-Version: 1.0 Received: by 10.220.123.2 with SMTP id n2mr5008030vcr.71.1263288287210; Tue, 12 Jan 2010 01:24:47 -0800 (PST) In-Reply-To: <20091214221501.72E203A6826@core3.amsl.com> References: <20091214221501.72E203A6826@core3.amsl.com> Date: Tue, 12 Jan 2010 14:54:47 +0530 Message-ID: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> From: "Ashwin C. Prabhu" To: mpls@ietf.org Content-Type: multipart/alternative; boundary=001636920c139bad22047cf439bb Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 09:24:56 -0000 --001636920c139bad22047cf439bb Content-Type: text/plain; charset=ISO-8859-1 Hello, Need following clarifications in the below mentioned draft. 1. In the page 8 it is mentioned that "The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That is, the information is used by the *ingress* to check that the data plane forwarding, matches what is signaled by the control plane" The ingress referes to what? The ingress lsr or the ingress interface of the transit lsr? Its not very clear from the above statement. I think it should be ingress interface? 2. Section 3.5 page 15 of the draft sates "Downstream Detailed Mapping TLV is described in [DDMT]. A transit, branch or bud node *can use* the Downstream Detailed Mapping TLV to return multiple Return Codes" ... "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in [RFC4379] is being deprecated" " Therefore for P2MP, a node MUST support Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and SHOULD NOT be included in an Echo Request message" Does this mean that the p2mp ingress node can still receive Downstream Mapping TLV? If so should the ingress process it? Or is it that the responding node MUST reply back with DDMT? 3. Section 7.2 New TLV's refers to Section 3.2.4 which doesn't exist. 4. Say A is ingress and D and F are 2 egresses of the p2mp lsp. A ------------ B --------------C --------- D \----------------E ---------- F When A sends a echo request with TTL 1, B replies back with 2 instances of DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for 2 different egresses? 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F. 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain both the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be multicast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indentifier TLV. 4.4 Do we need B to send back more information such as the egress to which the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path to multiple egress? May be adding a egress address in DDMT will solve these? Or is it that it is taken care in some other ways. Please let me know. Thanks, Ashwin On Tue, Dec 15, 2009 at 3:45 AM, wrote: > 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 Data Plane Failures in > Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP > Ping > Author(s) : S. Yasukawa, et al. > Filename : draft-ietf-mpls-p2mp-lsp-ping-09.txt > Pages : 28 > Date : 2009-12-14 > > Recent proposals have extended the scope of Multiprotocol Label > Switching (MPLS) Label Switched Paths (LSPs) to encompass > point-to-multipoint (P2MP) LSPs. > > The requirement for a simple and efficient mechanism that can be used > to detect data plane failures in point-to-point (P2P) MPLS LSPs has > been recognized and has led to the development of techniques for > fault detection and isolation commonly referred to as "LSP Ping". > > The scope of this document is fault detection and isolation for P2MP > MPLS LSPs. This documents does not replace any of the mechanisms of > LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and > extends the techniques and mechanisms of LSP Ping to the MPLS P2MP > environment.Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001636920c139bad22047cf439bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
Need following clarifications in the below mentioned draft.
=A0
1. In the page 8 it is mentioned that
=A0=A0=A0"The transit LSR also returns information on an echo res= ponse that helps verify the control plane against the data plane.=A0 That <= /div>
=A0=A0 is,=A0the information is used by the ingress t= o check that the data plane forwarding, matches what is signaled by the con= trol plane"
=A0
=A0 The ingress referes to what? The ingress lsr or the ingress interf= ace of the transit lsr? Its not very clear from the above statement.
=A0=A0 I think it should be ingress interface?
=A0
=A0
2. Section 3.5 page 15 of the draft sates
=A0=A0=A0"Downstream Detailed Mapping TLV is described in [DDMT].= =A0 A transit,
=A0 branch or bud node can use the Downs= tream Detailed Mapping TLV to
=A0 return multiple Return Codes" ...=
=A0=A0"As per Section 4.3 of [DDMT], the Downstream Mapping TLV a= s described in
=A0 [RFC4379] is being deprecated"
"=A0 Therefore for P2MP, a node MUST support Downstream Detailed = Mapping
=A0 TLV.=A0 The Downstream Mapping TLV [RFC4379] is not appropri= ate for P2MP
=A0 traceroute functionality and SHOULD NOT be included in = an Echo Request
=A0 message"
=A0=A0
=A0=A0Does this mean that the p2mp ingress node can still receive Down= stream Mapping TLV? If so should the ingress process it?
=A0 Or is it that the responding node MUST reply back with DDMT?
=A0
3.=A0 Section 7.2 New TLV's refers to Section 3.2.4 which doesn= 9;t exist.
=A0
4.=A0=A0
=A0=A0=A0 Say=A0=A0 A is ingress and D and F are 2 egresses of the p2m= p lsp.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A ------------ B --------------C ---= ------ D=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \----------------E ---------- F
=A0
When A sends a echo request with TTL 1, B replies back with 2 instance= s of DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to egress.
=A0
=A04.1 How does A distinguish whether the BC and BE are ECMP paths or = path for 2 different egresses?
=A04.2 How does node A, corelate the links BC and BE to egress D or F?= (Basically how does the topology formed at ingress)
=A0=A0=A0=A0=A0=A0 In the above topology, B is transit for both C &= ; E, where as C is part of only D and E is part of only F.
=A04.3 How should the node A's next mpls echo request (TTL 2) look= like?
=A0=A0=A0=A0=A0 If A is adding the DDMT in its echo Request then shoul= d it contain both the links received BC and BE?
=A0=A0=A0=A0=A0 If so, then how does C or E verify which link is upstr= eam?
=A0=A0=A0=A0 The draft mentions in some place that the interface addre= ss can be multicast address. But with this way we will be skipping
=A0=A0=A0=A0=A0 the interface validation altogether.
=A0=A0=A0=A0 I am considering the fact that we are not adding the Resp= onder Indentifier TLV.
=A0=A0=A0=A0
4.4 Do we need B to send back more information such as the egress to w= hich the downstream link is being added.
=A0=A0=A0=A0=A0 Also do we need B to differentiate between a ECMP path= with the path to multiple egress?
=A0=A0=A0=A0 May be adding a egress address in DDMT will solve these? = Or is it that it is taken care in some other ways.
=A0
Please let me know.
=A0
=A0
Thanks,
Ashwin
=A0
=A0
=A0=A0=A0=A0



On Tue, Dec 15, 2009 at 3:45 AM, <Internet-Drafts@ietf.org= > wrote:
A New Internet-Draft is availabl= e from the on-line Internet-Drafts directories.
This draft is a work ite= m of the Multiprotocol Label Switching Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Detecting Data Plane Fai= lures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensi= ons to LSP Ping
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : S. Yasukawa, et a= l.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-p2mp-lsp-pin= g-09.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0Date =A0 = =A0 =A0 =A0 =A0 =A0: 2009-12-14

Recent proposals have extended the s= cope of Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs)= to encompass
point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be usedto detect data plane failures in point-to-point (P2P) MPLS LSPs has
be= en recognized and has led to the development of techniques for
fault det= ection and isolation commonly referred to as "LSP Ping".

The scope of this document is fault detection and isolation for P2MPMPLS LSPs. =A0This documents does not replace any of the mechanisms of
= LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
exten= ds the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment.Copyright Notice

Copyright (c) 2009 IETF Trust and the p= ersons identified as the
document authors. =A0All rights reserved.
A URL for this Internet-Draft is:
http://w= ww.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

Below is the data which will enable a MIME compli= ant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.


_______________________________________________
mpl= s mailing list
mpls@ietf.org
https= ://www.ietf.org/mailman/listinfo/mpls


--001636920c139bad22047cf439bb-- From root@core3.amsl.com Tue Jan 12 08:30:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3C64E3A6804; Tue, 12 Jan 2010 08:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100112163002.3C64E3A6804@core3.amsl.com> Date: Tue, 12 Jan 2010 08:30:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-framework-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 16:30:02 -0000 --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 : MPLS-TP Network Management Framework Author(s) : S. Mansfield, et al. Filename : draft-ietf-mpls-tp-nm-framework-03.txt Pages : 17 Date : 2010-01-12 This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 16, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-nm-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-12081838.I-D@ietf.org> --NextPart-- From RKunze@telekom.de Wed Jan 6 06:12:04 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A4E3A6882 for ; Wed, 6 Jan 2010 06:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ce8sOFD+SKIS for ; Wed, 6 Jan 2010 06:12:00 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 9A76F3A6866 for ; Wed, 6 Jan 2010 06:11:57 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 06 Jan 2010 15:11:52 +0100 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 15:11:51 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA8EDA.314D88C8" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 6 Jan 2010 15:11:50 +0100 Message-ID: <1064ACAB129E654386C2FDEFADC51F3A01917C7D@S4DE9JSAANL.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bishnoi-mpls-ldp-node-group-00 Thread-Index: AcqO2i+Pjz6wzWGdQMe/jtlDaD4XOQ== From: To: X-OriginalArrivalTime: 06 Jan 2010 14:11:51.0874 (UTC) FILETIME=[318BCA20:01CA8EDA] X-Mailman-Approved-At: Tue, 12 Jan 2010 10:02:28 -0800 Subject: [mpls] draft-bishnoi-mpls-ldp-node-group-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:14:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8EDA.314D88C8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sandeep, I think the mLDP (draft-mpls-ldp-p2mp) draft from Ice and others = addresses the upstream node selection in section 2.4.1.1. Determining = one's 'upstream LSR'. I think furthermore your method goes more into the = direction of contraint-based routing. Is this right? If yes, then my = question is why not using RSVP-TE to setup a constraint based P2MP-LSP. Best regards R=FCdiger ------_=_NextPart_001_01CA8EDA.314D88C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bishnoi-mpls-ldp-node-group-00

Hi Sandeep,

I think the mLDP (draft-mpls-ldp-p2mp) = draft from Ice and others addresses the upstream node selection in = section 2.4.1.1. Determining one's 'upstream LSR'. I think furthermore = your method goes more into the direction of contraint-based routing. Is = this right? If yes, then my question is why not using RSVP-TE to setup a = constraint based P2MP-LSP.


Best regards

R=FCdiger

------_=_NextPart_001_01CA8EDA.314D88C8-- From nitinb@juniper.net Tue Jan 12 10:46:15 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D157F3A6A08 for ; Tue, 12 Jan 2010 10:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ocWmys5XVooX for ; Tue, 12 Jan 2010 10:46:14 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B766F3A67E7 for ; Tue, 12 Jan 2010 10:46:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS0zDbgH5Q9FxcNjr11mxndgy8vJAjpjy@postini.com; Tue, 12 Jan 2010 10:46:12 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 12 Jan 2010 10:44:25 -0800 From: Nitin Bahadur To: "Ashwin C. Prabhu" , "mpls@ietf.org" Date: Tue, 12 Jan 2010 10:43:53 -0800 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaTbjNK+n3QOITF+rJr1V/bbIxgATflLm Message-ID: In-Reply-To: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:46:15 -0000 Hi Ashwin, See responses to some of your questions below... On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: 4. Say A is ingress and D and F are 2 egresses of the p2mp lsp. A ------------ B --------------C --------- D \----------------E ---------- F When A sends a echo request with TTL 1, B replies back with 2 instances of = DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. NB> you can trace each sub-tree at a time using the "Node Address P2M= P Responder Identifier Sub-TLV" and increasing ttl. So for TTL=3D2, A will send 2 messages: 1 with DDMT= for C and one for DDMT for E. This approach is similar to how you do tracert for LDP ECMP (wherein we= use different dest-ip). If you want to trace paths in parallel....there is a way ...at expense of r= educed functionality.... Each pkt that ingress A sends, it's DDMT always sets the Address = Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. As = per RFC 4379 "If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided." For TTL=3D1, B will respond with 2 DDMT TLV (one for C and one f= or E). A can now create a tree containing A, B, C, E. Now on TTL=3D2, A will get a response = from C and E. Based on IP addr of responding node, A will know if it's C or E and can graft the information = regarding D or F into the tree. 4.1 How does A distinguish whether the BC and BE are ECMP paths or path fo= r 2 different egresses? NB> Ingress "does not care". A is building a topology during the trace and = it will realize which nodes are egresses when the topology build-up completes. Note that for P2MP RSVP-TE, = there is no concept of ECMP. For mLDP, there is ECMP...but "A" can do post-tree-computation analysis to d= etermine ECMP paths. 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basic= ally how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is pa= rt of only D and E is part of only F. NB> See above. 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain bo= th the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be mul= ticast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indenti= fier TLV. 4.4 Do we need B to send back more information such as the egress to which = the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path = to multiple egress? May be adding a egress address in DDMT will solve these? Or is it that= it is taken care in some other ways. NB> I don't think any of this is needed. Thanks Nitin From nitinb@juniper.net Tue Jan 12 11:13:46 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD113A6858 for ; Tue, 12 Jan 2010 11:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DdKbl6N5xylq for ; Tue, 12 Jan 2010 11:13:45 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id A02243A683B for ; Tue, 12 Jan 2010 11:13:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKS0zJ5Ypb/99YGBij0cdLZ96RSms6P7lt@postini.com; Tue, 12 Jan 2010 11:13:42 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Tue, 12 Jan 2010 11:09:59 -0800 From: Nitin Bahadur To: Nitin Bahadur , "Ashwin C. Prabhu" , "mpls@ietf.org" Date: Tue, 12 Jan 2010 11:09:28 -0800 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaTbjNK+n3QOITF+rJr1V/bbIxgATflLmAADku48= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 19:13:46 -0000 NB> Ingress "does not care". A is building a topology during the trace and = it will realize which nodes are egresses when the topology build-up completes. Note that for P2MP RSVP-TE, = there is no concept of ECMP. For mLDP, there is ECMP...but "A" can do post-tree-computation analysis to d= etermine ECMP paths. NNB> There is no ECMP for mLDP either.... From djsmith@cisco.com Tue Jan 12 18:13:57 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA8D3A68C2 for ; Tue, 12 Jan 2010 18:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 x3vKmB0vnJG8 for ; Tue, 12 Jan 2010 18:13:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 468C03A6866 for ; Tue, 12 Jan 2010 18:13:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+6TEtAZnwN/2dsb2JhbADCDpR/hDAE X-IronPort-AV: E=Sophos;i="4.49,265,1262563200"; d="scan'208";a="79766821" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2010 02:13:53 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.170]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0D2DrLa016580; Wed, 13 Jan 2010 02:13:53 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 20:13:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jan 2010 20:13:51 -0600 Message-ID: In-Reply-To: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question on draft-ietf-mpls-ip-options-03.txt Thread-Index: AcqQsgdbt2csiL26Sge4p0h7m3vhjADPbqqw References: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> From: "David Smith (djsmith)" To: "Olen Stokes" , X-OriginalArrivalTime: 13 Jan 2010 02:13:52.0978 (UTC) FILETIME=[0D6A2B20:01CA93F6] Subject: Re: [mpls] Question on draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 02:13:57 -0000 >What is the intended action to be taken in cases where source routing is permitted? =20 If the next address in the source route (which replaces the address in the destination address) belongs to a prefix-based FEC, the LSR/SSR packet should be MPLS encapsulated with the associated MPLS label. Conversely, if the next address in the source route does not belong to a prefix-based FEC, the LSR/SSR packet should be IP source routed. =20 These behaviors are consistent with the ingress LER requirements described in Section 4 of the draft.=20 =20 Regards, =20 /dave=20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Olen Stokes Sent: Friday, January 08, 2010 5:29 PM To: 'mpls@ietf.org' Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt The following specific type of IP option-based security attack is cited in Section 5.1 of the draft: =20 Crafted IP strict and loose source route option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at a ingress LER may allow an attacker to specify explicit IP forwarding path(s) across an MPLS network and, thereby, target specific LSRs with any of the DoS attacks outlined above. This assumes, of course, that the MPLS network is enabled to process IP strict and loose source route options. =20 What is the intended action to be taken in cases where source routing is permitted? =20 Cheers, Olen =20 =20 From prabhu.ashwin@gmail.com Wed Jan 13 04:26:21 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B273A3A69AC for ; Wed, 13 Jan 2010 04:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gFtrLPksOfSD for ; Wed, 13 Jan 2010 04:26:20 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id E64893A6919 for ; Wed, 13 Jan 2010 04:26:19 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so200373qwe.31 for ; Wed, 13 Jan 2010 04:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aqIID46eW/fQb7zBqIClbapFbGARTygLz3lP3P96oVw=; b=Y5HBbImHkDl+6RMNO4vmeaKoaFcWHlT5dtCZWCcQesxo+jl46Dv4LQ6VOB3+jfAKiZ vzd8eqmnORJCSVKYOqlvhS170Y+owPlSFsEHPF2JlHWZYtkIz7vcwIYQChuiSRJMlYGe /299o0s8gLoQVV4Ff1IXQieiCrMGB89BSFrkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aKxn2CH79c2orvIT7kJIMqmf09mi1eWX3vDH4URiWEWNJqQukIyugelO02zUVgccOb OcrEO10BOonHggbV8afNeEJ7CX9bEL9ICkkrGJk0I2jRVXCosa+6veGzs9rhtqXJ2yRX MeYLMmkH5R0SuZvnoqhTSWj2ePD/9+kH6JXJg= MIME-Version: 1.0 Received: by 10.220.122.86 with SMTP id k22mr415532vcr.51.1263385572248; Wed, 13 Jan 2010 04:26:12 -0800 (PST) In-Reply-To: References: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> Date: Wed, 13 Jan 2010 17:56:12 +0530 Message-ID: <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> From: "Ashwin C. Prabhu" To: Nitin Bahadur Content-Type: multipart/alternative; boundary=001636c5bd793f8b35047d0ae0ab Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 12:26:21 -0000 --001636c5bd793f8b35047d0ae0ab Content-Type: text/plain; charset=ISO-8859-1 Hello Nitin, Thanks a lot for the reply. I still have some more clarifications; 1. In the case of tracing node by node using the node address responder id TLV, only way to map C to node B would be to take the help of the IGP. I am assuming that the node C's address is going to be a loopback address. Do we need to consider the case of a lsp spanning accross the Autonomous System? Does the p2mp lsp span across different AS? Or can we have lsp stitching for the p2mp lsp? If we already support any of these at present or in future then we may not be able to map node C to its upstream node B. 2. I still didn't get how the tree is formed for tracing parallely, Extending the above topology adding a node G and H in the previous topology. A ------------ B --------------C ----------- G -------------- D \----------------E ---------- H -------------- F Now considering that there is no DDMT in label request message or DDMT with unnumbered type (interface address is multicast address) With TTL 1 Node B replies back Wih TTL 2 Node C and E replies back, With TTL 3 Node G and H replies back With TTL 4 Node D and F replies with return code. So say at instance with TTL 3 replies received, the tree could be A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B ----E--- H The sender address of G or H doesn't indicate who is upstream? I think i am missing something here. By attaching something similar to "Node address responder id TLV" to each instance of DDMT in the echo Request message can we not do the interface validation even in the case of parallel trace? Basically instead of sending multiple messages for each node i am sugesting to club those messages and the corresponding node will pick only required information. Best Regds, Ashwin On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur wrote: > Hi Ashwin, > > See responses to some of your questions below... > > > On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: > 4. > Say A is ingress and D and F are 2 egresses of the p2mp lsp. > > A ------------ B --------------C --------- D > \----------------E ---------- F > > When A sends a echo request with TTL 1, B replies back with 2 instances of > DDMT depicitng interface BC and BE. > Now at node A we know that there are 2 outgoing links to egress. > > NB> you can trace each sub-tree at a time using the "Node Address > P2MP Responder Identifier Sub-TLV" > and increasing ttl. So for TTL=2, A will send 2 messages: 1 with DDMT > for C and one for DDMT for E. > This approach is similar to how you do tracert for LDP ECMP (wherein we > use different dest-ip). > > If you want to trace paths in parallel....there is a way ...at expense of > reduced functionality.... > Each pkt that ingress A sends, it's DDMT always sets the Address > Type to either IPv4 Unnumbered or IPv6 Unnumbered. > For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. As > per RFC 4379 > > "If an LSR receives an Echo Request packet with the all-routers > multicast address, then this indicates that it MUST bypass both > interface and label stack validation, but return Downstream > Mapping TLVs using the information provided." > > For TTL=1, B will respond with 2 DDMT TLV (one for C and one for > E). A can now > create a tree containing A, B, C, E. Now on TTL=2, A will get a response > from C and E. Based on IP addr of > responding node, A will know if it's C or E and can graft the information > regarding D or F into the tree. > > 4.1 How does A distinguish whether the BC and BE are ECMP paths or path > for 2 different egresses? > > NB> Ingress "does not care". A is building a topology during the trace and > it will realize which nodes are > egresses when the topology build-up completes. Note that for P2MP RSVP-TE, > there is no concept of ECMP. For > mLDP, there is ECMP...but "A" can do post-tree-computation analysis to > determine ECMP paths. > > 4.2 How does node A, corelate the links BC and BE to egress D or F? > (Basically how does the topology formed at ingress) > In the above topology, B is transit for both C & E, where as C is > part of only D and E is part of only F. > > NB> See above. > > 4.3 How should the node A's next mpls echo request (TTL 2) look like? > If A is adding the DDMT in its echo Request then should it contain > both the links received BC and BE? > If so, then how does C or E verify which link is upstream? > The draft mentions in some place that the interface address can be > multicast address. But with this way we will be skipping > the interface validation altogether. > I am considering the fact that we are not adding the Responder > Indentifier TLV. > > > 4.4 Do we need B to send back more information such as the egress to which > the downstream link is being added. > Also do we need B to differentiate between a ECMP path with the path > to multiple egress? > May be adding a egress address in DDMT will solve these? Or is it that > it is taken care in some other ways. > > NB> I don't think any of this is needed. > > Thanks > Nitin > --001636c5bd793f8b35047d0ae0ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Nitin,
=A0
Thanks a lot for the reply.

I still have some more clarifications;
=A0
1. In the case of tracing node by node using the node address responde= r id TLV, only way to map C to node B would be to take the help of the IGP.=
=A0=A0=A0=A0I am assuming that the node C's address is going to be= a loopback address.
=A0=A0 Do we need to consider the case of a lsp spanning accross the A= utonomous System? Does the p2mp lsp span across different AS? Or can we hav= e
=A0=A0 lsp stitching for the p2mp lsp? If we already support any of th= ese at present or in future then we may not be able to map node C to its up= stream node
=A0=A0 B.
=A0
2. I still didn't get how the tree is formed for tracing parallely= ,
=A0=A0=A0 Extending the above topology adding a node G and H in the pr= evious topology.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A ------------ B --------------C ------= ----- G -------------- D
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \----------------E ---------- H ---= ----------- F
=A0
=A0=A0 Now considering that there is no DDMT in label request message = or DDMT with unnumbered type (interface address is multicast address)
=A0=A0 With TTL 1=A0 Node B replies back
=A0=A0 Wih TTL 2 Node C and E replies back,
=A0=A0 With TTL 3 Node G and H replies back
=A0=A0 With TTL 4 Node D and F replies with return code.
=A0
=A0 So say at instance with TTL 3 replies received, the tree could be= =A0 A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or= A --- B ----E--- H
=A0 The sender address of G or H doesn't indicate who is upstream?=
=A0 I think i am missing something here.
=A0
=A0By attaching something similar to "Node address responder id T= LV" to each instance of DDMT in the echo Request message can we not do= the interface validation even in the case of parallel trace? Basically ins= tead of sending multiple messages for each node i am sugesting to club thos= e messages and the corresponding node will pick only required information.<= /div>
=A0
Best Regds,
Ashwin
=A0
=A0
=A0=A0

On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur = <nitinb@juniper.= net> wrote:
Hi Ashwin,

=A0See respons= es to some of your questions below...


On 1/12/10 1:24 AM, "Ashwin C. Prabhu" = <prabhu.ashwin@gmail.com&= gt; wrote:
4.
=A0 =A0Say =A0 A is ingress and D and F are 2 egresses = of the p2mp lsp.

=A0 =A0 =A0 =A0 =A0 =A0A ------------ B --------------C --------- D
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\---------------= -E ---------- F

When A sends a echo request with TTL 1, B replies ba= ck with 2 instances of DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to egress.

NB> =A0 =A0 =A0 you can trace each sub-tree at a time using the "= ;Node Address P2MP Responder Identifier Sub-TLV"
=A0 =A0and increas= ing ttl. So for TTL=3D2, A will send 2 messages: 1 with DDMT for C and one = for DDMT for E.
=A0 =A0This approach is similar to how you do tracert for LDP ECMP (wherein= we use different dest-ip).

If you want to trace paths in parallel..= ..there is a way ...at expense of reduced functionality....
=A0 =A0 =A0 = =A0 Each pkt that ingress A sends, it's DDMT always sets =A0the Address= Type to either IPv4 Unnumbered or IPv6 Unnumbered.
=A0 =A0 =A0 =A0 =A0For IPv4, it MUST set the Downstream IP Address to 224.0= .0.2. As per RFC 4379

=A0 =A0 =A0 =A0 =A0"If an LSR receives an= Echo Request packet with the all-routers
=A0 =A0 =A0 =A0 =A0 multicast = address, then this indicates that it MUST bypass both
=A0 =A0 =A0 =A0 =A0 =A0interface and label stack validation, but return Dow= nstream
=A0 =A0 =A0 =A0 =A0 Mapping TLVs using the information provided.= "

=A0 =A0 =A0 =A0 =A0 For TTL=3D1, B will respond with 2 DDMT T= LV (one for C and one for E). A can now
create a tree containing A, B, C, E. Now on TTL=3D2, A will get a response = from C and E. Based on IP addr of
=A0responding node, A will know if it&= #39;s C or E and can graft the information regarding D or F into the tree.<= br>

=A04.1 How does A distinguish whether the BC and BE a= re ECMP paths or path for 2 different egresses?

NB> Ingress= "does not care". A is building a topology during the trace and i= t will realize which nodes are
egresses when the topology build-up completes. Note that for P2MP RSVP-TE, = there is no concept of ECMP. For
=A0mLDP, there is ECMP...but =A0"A= " can do post-tree-computation analysis to determine ECMP paths.

=A04.2 How does node A, corelate the links BC and BE = to egress D or F? (Basically how does the topology formed at ingress)
= =A0 =A0 =A0 In the above topology, B is transit for both C & E, where a= s C is part of only D and E is part of only F.

NB> See above.

=A04.3 How should the node A's next mpls echo req= uest (TTL 2) look like?
=A0 =A0 =A0If A is adding the DDMT in its echo R= equest then should it contain both the links received BC and BE?
=A0 =A0= =A0If so, then how does C or E verify which link is upstream?
=A0 =A0 The draft mentions in some place that the interface address can be = multicast address. But with this way we will be skipping
=A0 =A0 =A0the = interface validation altogether.
=A0 =A0 I am considering the fact that = we are not adding the Responder Indentifier TLV.


4.4 Do we need B to send back more information such as the egress t= o which the downstream link is being added.
=A0 =A0 =A0Also do we need B= to differentiate between a ECMP path with the path to multiple egress?
= =A0 =A0 May be adding a egress address in DDMT will solve these? Or is it t= hat it is taken care in some other ways.

NB> I don't think any of this is needed.

Thanks
= Nitin

--001636c5bd793f8b35047d0ae0ab-- From prabhu.ashwin@gmail.com Wed Jan 13 04:34:15 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913773A69A7 for ; Wed, 13 Jan 2010 04:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 x59TnvRtzADO for ; Wed, 13 Jan 2010 04:34:14 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id B7B1F3A6919 for ; Wed, 13 Jan 2010 04:34:13 -0800 (PST) Received: by qyk13 with SMTP id 13so11243826qyk.31 for ; Wed, 13 Jan 2010 04:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vVpa5vZdiI+P7uQE7c8SXPOrfe4YFEZZo0ZsA+xLOoM=; b=tD1jqI2GewGJTvQMbnoSsygL6O55WElck3id9F7s+h5q39Cya6pgj+JmrhKz6eBdu6 6ZUsR5o3GHI+2czrkPf+2zlwZ4EJQ4KIgIaEQj47HTX38pL7gHZj9sLDZETBxTFR5JlH r0IF+zWZ9/33a7aj8JJFYrnWboYcVKL2QNOgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s0UrCm7wOin3PS8NMIGQotom1Pkxq+1GpnXAML/v4fwYf+Kv/Sov9Sot7aJuPNOAeQ cnTcQAztmntLGp7VQDOjemS0/26h4W6vtl+qoY8+gq3cKbULqCJBWNaws5yC4PoGjHpf ch54lyJz50K+pD7o48CzersFE2yK4WG8uznH4= MIME-Version: 1.0 Received: by 10.220.122.86 with SMTP id k22mr416294vcr.51.1263386047425; Wed, 13 Jan 2010 04:34:07 -0800 (PST) In-Reply-To: <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> References: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> Date: Wed, 13 Jan 2010 18:04:07 +0530 Message-ID: <3c33c551001130434g2bf48b82r738903784135df3@mail.gmail.com> From: "Ashwin C. Prabhu" To: Nitin Bahadur Content-Type: multipart/alternative; boundary=001636c5bd79922c21047d0afcbd Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 12:34:15 -0000 --001636c5bd79922c21047d0afcbd Content-Type: text/plain; charset=ISO-8859-1 Hi, I think i got the part of the answer for question 2, i was assuming the echo reply too contains DDMT with 224.0.0.2, i think the reply should contain the appropriate values. So i got further questions, how do the ingress form topology if DDMT is not added in the echo request (Is this a valid case?) How do we support this for the unnumbered interface case (Where the echo reply actually contains the 224.0.0.2) ? Best Regds Ashwin On Wed, Jan 13, 2010 at 5:56 PM, Ashwin C. Prabhu wrote: > Hello Nitin, > > Thanks a lot for the reply. > > I still have some more clarifications; > > 1. In the case of tracing node by node using the node address responder id > TLV, only way to map C to node B would be to take the help of the IGP. > I am assuming that the node C's address is going to be a loopback > address. > Do we need to consider the case of a lsp spanning accross the Autonomous > System? Does the p2mp lsp span across different AS? Or can we have > lsp stitching for the p2mp lsp? If we already support any of these at > present or in future then we may not be able to map node C to its upstream > node > B. > > 2. I still didn't get how the tree is formed for tracing parallely, > Extending the above topology adding a node G and H in the previous > topology. > > A ------------ B --------------C ----------- G -------------- D > \----------------E ---------- H -------------- > F > > Now considering that there is no DDMT in label request message or DDMT > with unnumbered type (interface address is multicast address) > With TTL 1 Node B replies back > Wih TTL 2 Node C and E replies back, > With TTL 3 Node G and H replies back > With TTL 4 Node D and F replies with return code. > > So say at instance with TTL 3 replies received, the tree could be A ---- > B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B > ----E--- H > The sender address of G or H doesn't indicate who is upstream? > I think i am missing something here. > > By attaching something similar to "Node address responder id TLV" to each > instance of DDMT in the echo Request message can we not do the interface > validation even in the case of parallel trace? Basically instead of sending > multiple messages for each node i am sugesting to club those messages and > the corresponding node will pick only required information. > > Best Regds, > Ashwin > > > > > On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur wrote: > >> Hi Ashwin, >> >> See responses to some of your questions below... >> >> >> On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: >> 4. >> Say A is ingress and D and F are 2 egresses of the p2mp lsp. >> >> A ------------ B --------------C --------- D >> \----------------E ---------- F >> >> When A sends a echo request with TTL 1, B replies back with 2 instances of >> DDMT depicitng interface BC and BE. >> Now at node A we know that there are 2 outgoing links to egress. >> >> NB> you can trace each sub-tree at a time using the "Node Address >> P2MP Responder Identifier Sub-TLV" >> and increasing ttl. So for TTL=2, A will send 2 messages: 1 with DDMT >> for C and one for DDMT for E. >> This approach is similar to how you do tracert for LDP ECMP (wherein we >> use different dest-ip). >> >> If you want to trace paths in parallel....there is a way ...at expense of >> reduced functionality.... >> Each pkt that ingress A sends, it's DDMT always sets the Address >> Type to either IPv4 Unnumbered or IPv6 Unnumbered. >> For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. As >> per RFC 4379 >> >> "If an LSR receives an Echo Request packet with the all-routers >> multicast address, then this indicates that it MUST bypass both >> interface and label stack validation, but return Downstream >> Mapping TLVs using the information provided." >> >> For TTL=1, B will respond with 2 DDMT TLV (one for C and one for >> E). A can now >> create a tree containing A, B, C, E. Now on TTL=2, A will get a response >> from C and E. Based on IP addr of >> responding node, A will know if it's C or E and can graft the information >> regarding D or F into the tree. >> >> 4.1 How does A distinguish whether the BC and BE are ECMP paths or path >> for 2 different egresses? >> >> NB> Ingress "does not care". A is building a topology during the trace and >> it will realize which nodes are >> egresses when the topology build-up completes. Note that for P2MP RSVP-TE, >> there is no concept of ECMP. For >> mLDP, there is ECMP...but "A" can do post-tree-computation analysis to >> determine ECMP paths. >> >> 4.2 How does node A, corelate the links BC and BE to egress D or F? >> (Basically how does the topology formed at ingress) >> In the above topology, B is transit for both C & E, where as C is >> part of only D and E is part of only F. >> >> NB> See above. >> >> 4.3 How should the node A's next mpls echo request (TTL 2) look like? >> If A is adding the DDMT in its echo Request then should it contain >> both the links received BC and BE? >> If so, then how does C or E verify which link is upstream? >> The draft mentions in some place that the interface address can be >> multicast address. But with this way we will be skipping >> the interface validation altogether. >> I am considering the fact that we are not adding the Responder >> Indentifier TLV. >> >> >> 4.4 Do we need B to send back more information such as the egress to which >> the downstream link is being added. >> Also do we need B to differentiate between a ECMP path with the path >> to multiple egress? >> May be adding a egress address in DDMT will solve these? Or is it that >> it is taken care in some other ways. >> >> NB> I don't think any of this is needed. >> >> Thanks >> Nitin >> > > --001636c5bd79922c21047d0afcbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I think i got the part of the answer for question 2, i was assuming th= e echo reply too contains DDMT with 224.0.0.2, i think the reply should con= tain the
appropriate values.
So i got further questions, how do the ingress form topology if DDMT i= s not added in the echo request (Is this a valid case?)
How do we support this for the unnumbered interface case (Where the ec= ho reply actually contains the 224.0.0.2) ?
=A0
Best Regds
Ashwin


=A0
On Wed, Jan 13, 2010 at 5:56 PM, Ashwin C. Prabh= u <prabhu.a= shwin@gmail.com> wrote:
Hello Nitin,
=A0
Thanks a lot for the reply.

I still have some more clarifications;
=A0
1. In the case of tracing node by node using the node address responde= r id TLV, only way to map C to node B would be to take the help of the IGP.=
=A0=A0=A0=A0I am assuming that the node C's address is going to be= a loopback address.
=A0=A0 Do we need to consider the case of a lsp spanning accross the A= utonomous System? Does the p2mp lsp span across different AS? Or can we hav= e
=A0=A0 lsp stitching for the p2mp lsp? If we already support any of th= ese at present or in future then we may not be able to map node C to its up= stream node
=A0=A0 B.
=A0
2. I still didn't get how the tree is formed for tracing parallely= ,
=A0=A0=A0 Extending the above topology adding a node G and H in the pr= evious topology.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A ------------ B --------------C ------= ----- G -------------- D
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \----------------E ---------- H ---= ----------- F
=A0
=A0=A0 Now considering that there is no DDMT in label request message = or DDMT with unnumbered type (interface address is multicast address)
=A0=A0 With TTL 1=A0 Node B replies back
=A0=A0 Wih TTL 2 Node C and E replies back,
=A0=A0 With TTL 3 Node G and H replies back
=A0=A0 With TTL 4 Node D and F replies with return code.
=A0
=A0 So say at instance with TTL 3 replies received, the tree could be= =A0 A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or= A --- B ----E--- H
=A0 The sender address of G or H doesn't indicate who is upstream?=
=A0 I think i am missing something here.
=A0
=A0By attaching something similar to "Node address responder id T= LV" to each instance of DDMT in the echo Request message can we not do= the interface validation even in the case of parallel trace? Basically ins= tead of sending multiple messages for each node i am sugesting to club thos= e messages and the corresponding node will pick only required information.<= /div>
=A0
Best Regds,
Ashwin
=A0
=A0
=A0=A0

On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur = <nitinb@juniper.net> wrote:
Hi Ashwin,

=A0See respons= es to some of your questions below...


On 1/12/10 1:24 AM, "Ashwin C. Prabhu" <prabhu.ashwin@gmail.c= om> wrote:
4.
=A0 =A0Say =A0 A is ingress and D and F are 2 eg= resses of the p2mp lsp.

=A0 =A0 =A0 =A0 =A0 =A0A ------------ B --------------C --------- D
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\---------------= -E ---------- F

When A sends a echo request with TTL 1, B replies ba= ck with 2 instances of DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to egress.

NB> =A0 =A0 =A0 you can trace each sub-tree at a time using the "= ;Node Address P2MP Responder Identifier Sub-TLV"
=A0 =A0and increas= ing ttl. So for TTL=3D2, A will send 2 messages: 1 with DDMT for C and one = for DDMT for E.
=A0 =A0This approach is similar to how you do tracert for LDP ECMP (wherein= we use different dest-ip).

If you want to trace paths in parallel..= ..there is a way ...at expense of reduced functionality....
=A0 =A0 =A0 = =A0 Each pkt that ingress A sends, it's DDMT always sets =A0the Address= Type to either IPv4 Unnumbered or IPv6 Unnumbered.
=A0 =A0 =A0 =A0 =A0For IPv4, it MUST set the Downstream IP Address to 224.0= .0.2. As per RFC 4379

=A0 =A0 =A0 =A0 =A0"If an LSR receives an= Echo Request packet with the all-routers
=A0 =A0 =A0 =A0 =A0 multicast = address, then this indicates that it MUST bypass both
=A0 =A0 =A0 =A0 =A0 =A0interface and label stack validation, but return Dow= nstream
=A0 =A0 =A0 =A0 =A0 Mapping TLVs using the information provided.= "

=A0 =A0 =A0 =A0 =A0 For TTL=3D1, B will respond with 2 DDMT T= LV (one for C and one for E). A can now
create a tree containing A, B, C, E. Now on TTL=3D2, A will get a response = from C and E. Based on IP addr of
=A0responding node, A will know if it&= #39;s C or E and can graft the information regarding D or F into the tree.<= br>

=A04.1 How does A distinguish whether the BC and BE are ECMP paths= or path for 2 different egresses?

NB> Ingress "does n= ot care". A is building a topology during the trace and it will realiz= e which nodes are
egresses when the topology build-up completes. Note that for P2MP RSVP-TE, = there is no concept of ECMP. For
=A0mLDP, there is ECMP...but =A0"A= " can do post-tree-computation analysis to determine ECMP paths.

=A04.2 How does node A, corelate the links BC and BE to egress D o= r F? (Basically how does the topology formed at ingress)
=A0 =A0 =A0 In = the above topology, B is transit for both C & E, where as C is part of = only D and E is part of only F.

NB> See above.

=A04.3 How should the node A's next mpls echo request (TTL 2) = look like?
=A0 =A0 =A0If A is adding the DDMT in its echo Request then s= hould it contain both the links received BC and BE?
=A0 =A0 =A0If so, th= en how does C or E verify which link is upstream?
=A0 =A0 The draft mentions in some place that the interface address can be = multicast address. But with this way we will be skipping
=A0 =A0 =A0the = interface validation altogether.
=A0 =A0 I am considering the fact that = we are not adding the Responder Indentifier TLV.


4.4 Do we need B to send back more information such as the egress t= o which the downstream link is being added.
=A0 =A0 =A0Also do we need B= to differentiate between a ECMP path with the path to multiple egress?
= =A0 =A0 May be adding a egress address in DDMT will solve these? Or is it t= hat it is taken care in some other ways.

NB> I don't think any of this is needed.

Thanks
= Nitin

=

--001636c5bd79922c21047d0afcbd-- From ostokes@extremenetworks.com Wed Jan 13 06:21:02 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5113A69F4 for ; Wed, 13 Jan 2010 06:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 DrVTBCNaWHLW for ; Wed, 13 Jan 2010 06:21:01 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id 6BD6C28C139 for ; Wed, 13 Jan 2010 06:20:59 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 13 Jan 2010 06:20:56 -0800 From: Olen Stokes To: "'David Smith (djsmith)'" , "mpls@ietf.org" Date: Wed, 13 Jan 2010 06:20:56 -0800 Thread-Topic: [mpls] Question on draft-ietf-mpls-ip-options-03.txt Thread-Index: AcqQsgdbt2csiL26Sge4p0h7m3vhjADPbqqwABfgBhA= Message-ID: <6738A78F51650A4FAEDCF6844B26C2144431549D35@USEXCHANGE.corp.extremenetworks.com> References: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Question on draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 14:21:02 -0000 David, thanks for the reply. Your response matches my initial feelings and= is consistent with the actions that will be required for other IP options = packets. My concern was over the part of the quoted description where it says "and, = thereby, target specific LSRs with any of the DoS attacks outlined above." = A method where the packet is sent to each node in the list via LSPs still = allows the possibility of DoS attacks on those nodes. I just wanted to mak= e sure that there was not a requirement to reduce this exposure by using a = LSP to send the packet directly to the ultimate destination. =20 Cheers, Olen -----Original Message----- From: David Smith (djsmith) [mailto:djsmith@cisco.com]=20 Sent: Tuesday, January 12, 2010 9:14 PM To: Olen Stokes; mpls@ietf.org Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt >What is the intended action to be taken in cases where source routing is permitted? =20 If the next address in the source route (which replaces the address in the destination address) belongs to a prefix-based FEC, the LSR/SSR packet should be MPLS encapsulated with the associated MPLS label. Conversely, if the next address in the source route does not belong to a prefix-based FEC, the LSR/SSR packet should be IP source routed. =20 These behaviors are consistent with the ingress LER requirements described in Section 4 of the draft.=20 =20 Regards, =20 /dave=20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Olen Stokes Sent: Friday, January 08, 2010 5:29 PM To: 'mpls@ietf.org' Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt The following specific type of IP option-based security attack is cited in Section 5.1 of the draft: =20 Crafted IP strict and loose source route option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at a ingress LER may allow an attacker to specify explicit IP forwarding path(s) across an MPLS network and, thereby, target specific LSRs with any of the DoS attacks outlined above. This assumes, of course, that the MPLS network is enabled to process IP strict and loose source route options. =20 What is the intended action to be taken in cases where source routing is permitted? =20 Cheers, Olen =20 =20 From djsmith@cisco.com Wed Jan 13 08:15:52 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6EF3A67D4 for ; Wed, 13 Jan 2010 08:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yCzNyUo0kB-U for ; Wed, 13 Jan 2010 08:15:50 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8D76B3A67D6 for ; Wed, 13 Jan 2010 08:15:47 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMqATUtAZnwN/2dsb2JhbADCbJR3hDAE X-IronPort-AV: E=Sophos;i="4.49,268,1262563200"; d="scan'208";a="79874102" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2010 16:15:44 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0DGFe3g003981; Wed, 13 Jan 2010 16:15:44 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:15:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 10:15:39 -0600 Message-ID: In-Reply-To: <6738A78F51650A4FAEDCF6844B26C2144431549D35@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question on draft-ietf-mpls-ip-options-03.txt Thread-Index: AcqQsgdbt2csiL26Sge4p0h7m3vhjADPbqqwABfgBhAABX7/IA== References: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> <6738A78F51650A4FAEDCF6844B26C2144431549D35@USEXCHANGE.corp.extremenetworks.com> From: "David Smith (djsmith)" To: "Olen Stokes" , X-OriginalArrivalTime: 13 Jan 2010 16:15:40.0760 (UTC) FILETIME=[A6661580:01CA946B] Subject: Re: [mpls] Question on draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:15:52 -0000 Hi Olen, >I just wanted to make sure that there was not a requirement to reduce this exposure by using a LSP to send the packet directly to the ultimate destination. =20 Correct, no such requirement. If source routing is required on LERs, mitigating the risk of LSR/SSR packets against downstream LSRs requires (i) conformance to this draft to enforce MPLS encapsulation at ingress LERs for destination addresses associated with a prefix-based FEC and (ii) core hiding (for example, by disabling IP->MPLS TTL propagation at ingress LERs) so that external sources cannot learn (eg, via traceroute) and target the IP addresses of downstream LSRs within LSR/SSR packets. (ii) core hiding (at least for option packets) is also dependent upon (i). Regards, /dave -----Original Message----- From: Olen Stokes [mailto:ostokes@extremenetworks.com]=20 Sent: Wednesday, January 13, 2010 9:21 AM To: David Smith (djsmith); mpls@ietf.org Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt David, thanks for the reply. Your response matches my initial feelings and is consistent with the actions that will be required for other IP options packets. My concern was over the part of the quoted description where it says "and, thereby, target specific LSRs with any of the DoS attacks outlined above." A method where the packet is sent to each node in the list via LSPs still allows the possibility of DoS attacks on those nodes. I just wanted to make sure that there was not a requirement to reduce this exposure by using a LSP to send the packet directly to the ultimate destination. =20 Cheers, Olen -----Original Message----- From: David Smith (djsmith) [mailto:djsmith@cisco.com] Sent: Tuesday, January 12, 2010 9:14 PM To: Olen Stokes; mpls@ietf.org Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt >What is the intended action to be taken in cases where source routing is permitted? =20 If the next address in the source route (which replaces the address in the destination address) belongs to a prefix-based FEC, the LSR/SSR packet should be MPLS encapsulated with the associated MPLS label. Conversely, if the next address in the source route does not belong to a prefix-based FEC, the LSR/SSR packet should be IP source routed. =20 These behaviors are consistent with the ingress LER requirements described in Section 4 of the draft.=20 =20 Regards, =20 /dave=20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Olen Stokes Sent: Friday, January 08, 2010 5:29 PM To: 'mpls@ietf.org' Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt The following specific type of IP option-based security attack is cited in Section 5.1 of the draft: =20 Crafted IP strict and loose source route option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at a ingress LER may allow an attacker to specify explicit IP forwarding path(s) across an MPLS network and, thereby, target specific LSRs with any of the DoS attacks outlined above. This assumes, of course, that the MPLS network is enabled to process IP strict and loose source route options. =20 What is the intended action to be taken in cases where source routing is permitted? =20 Cheers, Olen =20 =20 From loa@pi.nu Wed Jan 13 09:01:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F8D3A67E2; Wed, 13 Jan 2010 09:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 30JHTxFmRKMT; Wed, 13 Jan 2010 09:01:13 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 0C8503A677D; Wed, 13 Jan 2010 09:01:12 -0800 (PST) Received: from [192.36.158.110] (wdhcp-158-110.verkstad.net [192.36.158.110]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0D08DD403E; Wed, 13 Jan 2010 18:01:07 +0100 (CET) Message-ID: <4B4DFC51.8050301@pi.nu> Date: Wed, 13 Jan 2010 18:01:05 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:01:14 -0000 All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- From nurit.sprecher@nsn.com Wed Jan 13 09:06:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2782B3A680B; Wed, 13 Jan 2010 09:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 z7bvDEmzn3ZV; Wed, 13 Jan 2010 09:06:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DDA9D3A67EE; Wed, 13 Jan 2010 09:06:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0DH6V0e019326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2010 18:06:31 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0DH6VEp027256; Wed, 13 Jan 2010 18:06:31 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 18:06:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 18:03:13 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.net> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgT/CqHWXbshQuCgRQHJYMzFdAAACAGg References: <4B4DFC51.8050301@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , , , X-OriginalArrivalTime: 13 Jan 2010 17:06:31.0051 (UTC) FILETIME=[C0838DB0:01CA9472] Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:06:37 -0000 Yes/Support. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, January 13, 2010 7:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From annamaria.fulignoli@ericsson.com Wed Jan 13 09:16:42 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1843A69A3; Wed, 13 Jan 2010 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 yOuDVClNhJIj; Wed, 13 Jan 2010 09:16:41 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 94BEF3A67CC; Wed, 13 Jan 2010 09:16:40 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-0d-4b4dfff4283f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F9.53.04178.4FFFD4B4; Wed, 13 Jan 2010 18:16:36 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 18:16:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 18:16:35 +0100 Message-ID: <93DFCD4B101EB440B5B72997456C5F9404C4AE14@esealmw118.eemea.ericsson.se> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgV9NOe7mrLYRCa1NLGN+7sF9wAAgUUg References: <4B4DFC51.8050301@pi.nu> From: "Annamaria Fulignoli" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 13 Jan 2010 17:16:36.0241 (UTC) FILETIME=[293C3810:01CA9474] X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:16:42 -0000 Yes/support BR Annamaria -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Loa Andersson Sent: mercoled=EC 13 gennaio 2010 18.01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating = "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing = list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the = linear-protection document prior to the ring-protection document, since = we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From jordan.britnell@bell.ca Wed Jan 13 09:18:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326023A687F; Wed, 13 Jan 2010 09:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ITKlHYkX0zZ3; Wed, 13 Jan 2010 09:18:54 -0800 (PST) Received: from mail134.messagelabs.com (mail134.messagelabs.com [85.158.137.35]) by core3.amsl.com (Postfix) with ESMTP id 8AAD33A67E9; Wed, 13 Jan 2010 09:18:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jordan.britnell@bell.ca X-Msg-Ref: server-13.tower-134.messagelabs.com!1263403118!57917574!15 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.47.0.177] Received: (qmail 11315 invoked from network); 13 Jan 2010 17:18:47 -0000 Received: from dm1c8e.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-13.tower-134.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jan 2010 17:18:47 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.1.358.0; Wed, 13 Jan 2010 12:18:46 -0500 Received: from MBX01.bell.corp.bce.ca ([142.182.199.57]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Wed, 13 Jan 2010 12:18:39 -0500 From: To: , , , , , Date: Wed, 13 Jan 2010 12:18:37 -0500 Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgT/CqHWXbshQuCgRQHJYMzFdAAACAGgAACSWrA= Message-ID: References: <4B4DFC51.8050301@pi.nu> <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:18:55 -0000 Support.=20 ________________________________________ Jordan Britnell IP Technology Research BCE/Bell Canada (416) 215-3729 jordan.britnell@bell.ca -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: January 13, 2010 12:03 PM To: ext Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe= 3@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linea= r-protection an mpls wg document Yes/Support. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, January 13, 2010 7:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ssaxena@cisco.com Wed Jan 13 09:36:39 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7611D3A6855 for ; Wed, 13 Jan 2010 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Ix46TXmKfGiZ for ; Wed, 13 Jan 2010 09:36:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E311E3A682B for ; Wed, 13 Jan 2010 09:36:37 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAOGSTUutJV2a/2dsb2JhbACCFcBLlHiCOYF3BA X-IronPort-AV: E=Sophos;i="4.49,269,1262563200"; d="scan'208,217";a="466221947" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2010 17:36:35 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0DHaYb2002388; Wed, 13 Jan 2010 17:36:34 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 11:36:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9476.F365BCBB" Date: Wed, 13 Jan 2010 11:36:32 -0600 Message-ID: In-Reply-To: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaUpxPPIfHTPwS1SeaqRWJwxNggBAkgQg References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Ashwin C. Prabhu" , X-OriginalArrivalTime: 13 Jan 2010 17:36:34.0848 (UTC) FILETIME=[F3A92200:01CA9476] Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:36:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9476.F365BCBB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashwin, =20 I could not get to this yesterday. My answers are inline. =20 =20 1. In the page 8 it is mentioned that "The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That=20 is, the information is used by the ingress to check that the data plane forwarding, matches what is signaled by the control plane" =20 The ingress referes to what? The ingress lsr or the ingress interface of the transit lsr? Its not very clear from the above statement. I think it should be ingress interface? =20 [Shaleen Saxena (ssaxena): ] This section comes from the version 0 of the draft. The original intent was to verify forwarding from one hop to next. I think paragraphs needs to be updated as follows: =20 In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress router to build topology or=20 downstream routers to do extra verification. =20 Please note that the motivation section gives a high level overview of the design goals and not the actual implementation. =20 =20 2. Section 3.5 page 15 of the draft sates "Downstream Detailed Mapping TLV is described in [DDMT]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes" ... "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in [RFC4379] is being deprecated" " Therefore for P2MP, a node MUST support Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and SHOULD NOT be included in an Echo Request message" =20 Does this mean that the p2mp ingress node can still receive Downstream Mapping TLV? If so should the ingress process it? Or is it that the responding node MUST reply back with DDMT? =20 [Shaleen Saxena (ssaxena): ] In general, if a node receives DSMAP TLV, it should not respond with DDMAP. That is, in general, a node must respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV to be returned. Similarly DDMAP in echo request will cause DDMAP to be returned.=20 =20 However, for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence DDMAP SHOULD be used for traceroute. If an ingress node still sends DSMAP then the responding node can ignore it. The responding node should not convert a DSMAP into DDMAP. =20 =20 =20 3. Section 7.2 New TLV's refers to Section 3.2.4 which doesn't exist. =20 [Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and similarly 3.2.5 should change to 3.3. =20 =20 4. =20 Say A is ingress and D and F are 2 egresses of the p2mp lsp. =20 A ------------ B --------------C --------- D=20 \----------------E ---------- F =20 When A sends a echo request with TTL 1, B replies back with 2 instances of DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. =20 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for 2 different egresses? =20 [Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP TLV imply two separate outgoing paths. =20 =20 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F. [Shaleen Saxena (ssaxena): ] Node A will have to build the topology step by step. For each TTL, node A will figure out the routers at that level. By continuing the process, node A will have the complete topology. =20 =20 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain both the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be multicast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indentifier TLV.=20 [Shaleen Saxena (ssaxena): ] If there is no Responder Identifier TLV, then interface validation will have to be skipped. For the reasons you mention, it is not possible for node A to combine all the incoming DDMAP into one single outgoing DDMAP. Hence, if no Responder Identifier TLV, is present, then node A will have to use the wildcard DDMAP always. =20 If Egress Address Responder Identifier TLV is being used for traceroute, then it is possible to reuse the incoming DDMAP. =20 =20 =20 4.4 Do we need B to send back more information such as the egress to which the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path to multiple egress?=20 May be adding a egress address in DDMT will solve these? Or is it that it is taken care in some other ways. =20 [Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware of the downstream addresses. However for mLDP Tree, a midpoint node will not know the egress address. So it is not always feasible to send egress information. Even in P2MP RSVP TE tree, the scaling must be considered. Each outgoing interface can have hundreds of egress nodes. This is especially true for nodes near the head. So creating an OAM packet with this much information and parsing it will create large processing power for both the responding and initiating nodes. =20 Also, there is no ECMP in P2MP trees.=20 =20 Thanks, Shaleen ------_=_NextPart_001_01CA9476.F365BCBB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashwin,

 

I could not get to this yesterday. My answers are = inline.

 

 

1. In the page 8 it is mentioned = that

   "The transit LSR also = returns information on an echo response that helps verify the control plane = against the data plane.  That

   is, the information is used by = the ingress to check that the data plane forwarding, matches what is signaled by the control plane"

 

  The ingress referes to what? The ingress lsr = or the ingress interface of the transit lsr? Its not very clear from the above statement.

   I think it should be ingress = interface?

 

[Shaleen Saxena (ssaxena): ] This section comes from the = version 0 of the draft. The original intent was to verify forwarding from one = hop to next. I think paragraphs needs to be updated as = follows:

 

  In "traceroute" mode (fault isolation), the echo request is sent = to

  the = control plane at each transit LSR, and the control plane = checks

  that it = is indeed a transit LSR for this P2MP MPLS LSP.  The = transit

    LSR returns information about the = outgoing paths. This

    information can be used by ingress = router to build topology or

    downstream routers to do extra = verification.

 

Please note that the motivation section gives a high = level overview of the design goals and not the actual = implementation.

 

 

2. Section 3.5 page 15 of the draft = sates

   "Downstream Detailed Mapping = TLV is described in [DDMT].  A transit,
  branch or bud node can use the Downstream = Detailed Mapping TLV to
  return multiple Return Codes" ...

  "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
  [RFC4379] is being deprecated"

"  Therefore for P2MP, a node MUST = support Downstream Detailed Mapping
  TLV.  The Downstream Mapping TLV [RFC4379] is not = appropriate for P2MP
  traceroute functionality and SHOULD NOT be included in an Echo = Request
  message"

  

  Does this mean that the p2mp ingress = node can still receive Downstream Mapping TLV? If so should the ingress process = it?

  Or is it that the responding node MUST reply = back with DDMT?

 

[Shaleen Saxena (ssaxena): ] In general, if a node = receives DSMAP TLV, it should not respond with DDMAP. That is, in general, a node = must respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV = to be returned. Similarly DDMAP in echo request will cause DDMAP to be = returned.

 

However, for P2MP MPLS OAM, DDMAP is a better choice than = DSMAP; hence DDMAP SHOULD be used for traceroute. If an ingress node still = sends DSMAP then the responding node can ignore it. The responding node should not = convert a DSMAP into DDMAP.

 

 

 

3.  Section 7.2 New TLV's refers to Section = 3.2.4 which doesn't exist.

 

[Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to = just 3.2 and similarly 3.2.5 should change to = 3.3.

 

 

4.  

    Say   A is ingress and = D and F are 2 egresses of the p2mp lsp.

 

         &= nbsp;  A ------------ B --------------C --------- D 

         &= nbsp;           &n= bsp;        \----------------E ---------- F

 

When A sends a echo request with TTL 1, B replies = back with 2 instances of DDMT depicitng interface BC and BE.

Now at node A we know that there are 2 outgoing = links to egress.

 

 4.1 How does A distinguish whether the BC and = BE are ECMP paths or path for 2 different egresses?

 

[Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP = LSPs. So two DDMAP TLV imply two separate outgoing = paths.

 

 

 4.2 How does node A, corelate the links BC = and BE to egress D or F? (Basically how does the topology formed at = ingress)

       In the above = topology, B is transit for both C & E, where as C is part of only D and E is = part of only F.

[Shaleen Saxena (ssaxena): ] Node A will have to build = the topology step by step. For each TTL, node A will figure out the routers = at that level. By continuing the process, node A will have the complete = topology.

 

 

 4.3 How should the node A's next mpls echo = request (TTL 2) look like?

      If A is adding the = DDMT in its echo Request then should it contain both the links received BC and = BE?

      If so, then how does = C or E verify which link is upstream?

     The draft mentions in some = place that the interface address can be multicast address. But with this way = we will be skipping

      the interface = validation altogether.

     I am considering the fact = that we are not adding the Responder Indentifier TLV.

[Shaleen Saxena (ssaxena): ] If there is no Responder = Identifier TLV, then interface validation will have to be skipped. For the reasons = you mention, it is not possible for node A to combine all the incoming DDMAP = into one single outgoing DDMAP. Hence, if no Responder Identifier TLV, is = present, then node A will have to use the wildcard DDMAP = always.

 

If Egress Address Responder Identifier TLV  is being = used for traceroute, then it is possible to reuse the incoming = DDMAP.

 

 

    

4.4 Do we need B to send back more information such = as the egress to which the downstream link is being added.

      Also do we need B to differentiate between a ECMP path with the path to multiple egress? =

     May be adding a egress = address in DDMT will solve these? Or is it that it is taken care in some other = ways.

 

[Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a = node may be aware of the downstream addresses. However for mLDP Tree, a midpoint = node will not know the egress address. So it is not always feasible to send egress information. Even in P2MP RSVP TE tree, the scaling must be considered. = Each outgoing interface can have hundreds of egress nodes. This is especially = true for nodes near the head. So creating an OAM packet with this much = information and parsing it  will create large processing power for both the = responding and initiating nodes.

 

Also, there is no ECMP in P2MP trees. =

 

Thanks,

Shaleen

------_=_NextPart_001_01CA9476.F365BCBB-- From ssaxena@cisco.com Wed Jan 13 09:42:39 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E5F3A69F5 for ; Wed, 13 Jan 2010 09:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UsZZBK7yiNo7 for ; Wed, 13 Jan 2010 09:42:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BA1EB3A69F6 for ; Wed, 13 Jan 2010 09:42:38 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC+VTUutJV2a/2dsb2JhbADCTZR5gjmBdwQ X-IronPort-AV: E=Sophos;i="4.49,269,1262563200"; d="scan'208";a="466224456" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2010 17:42:36 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0DHgZW4003666; Wed, 13 Jan 2010 17:42:35 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 11:42:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 11:42:34 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaTbjNK+n3QOITF+rJr1V/bbIxgATflLmAC/y6vA= References: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Nitin Bahadur" , "Ashwin C. Prabhu" , X-OriginalArrivalTime: 13 Jan 2010 17:42:35.0797 (UTC) FILETIME=[CACD9450:01CA9477] Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:42:39 -0000 Hi Nitin,=20 Thanks for your response. One correction: Node Address Responder Identifier is intended for ping and Egress Address Responder Identifier TLV is intended for traceroute. If Node Address Responder Identifier is used for tracing, then the head-end needs to have an a priori knowledge of the topology.=20 Regards, Shaleen > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nitin Bahadur > Sent: Tuesday, January 12, 2010 1:44 PM > To: Ashwin C. Prabhu; mpls@ietf.org > Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt >=20 > Hi Ashwin, >=20 > See responses to some of your questions below... >=20 >=20 > On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: > 4. > Say A is ingress and D and F are 2 egresses of the p2mp lsp. >=20 > A ------------ B --------------C --------- D > \----------------E ---------- F >=20 > When A sends a echo request with TTL 1, B replies back with 2 instances > of DDMT depicitng interface BC and BE. > Now at node A we know that there are 2 outgoing links to egress. >=20 > NB> you can trace each sub-tree at a time using the "Node Address > P2MP Responder Identifier Sub-TLV" > and increasing ttl. So for TTL=3D2, A will send 2 messages: 1 with > DDMT for C and one for DDMT for E. > This approach is similar to how you do tracert for LDP ECMP > (wherein we use different dest-ip). >=20 > If you want to trace paths in parallel....there is a way ...at expense > of reduced functionality.... > Each pkt that ingress A sends, it's DDMT always sets the > Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. > For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. > As per RFC 4379 >=20 > "If an LSR receives an Echo Request packet with the all- > routers > multicast address, then this indicates that it MUST bypass > both > interface and label stack validation, but return Downstream > Mapping TLVs using the information provided." >=20 > For TTL=3D1, B will respond with 2 DDMT TLV (one for C and one > for E). A can now > create a tree containing A, B, C, E. Now on TTL=3D2, A will get a > response from C and E. Based on IP addr of > responding node, A will know if it's C or E and can graft the > information regarding D or F into the tree. >=20 > 4.1 How does A distinguish whether the BC and BE are ECMP paths or > path for 2 different egresses? >=20 > NB> Ingress "does not care". A is building a topology during the trace > and it will realize which nodes are > egresses when the topology build-up completes. Note that for P2MP RSVP- > TE, there is no concept of ECMP. For > mLDP, there is ECMP...but "A" can do post-tree-computation analysis > to determine ECMP paths. >=20 > 4.2 How does node A, corelate the links BC and BE to egress D or F? > (Basically how does the topology formed at ingress) > In the above topology, B is transit for both C & E, where as C > is part of only D and E is part of only F. >=20 > NB> See above. >=20 > 4.3 How should the node A's next mpls echo request (TTL 2) look like? > If A is adding the DDMT in its echo Request then should it > contain both the links received BC and BE? > If so, then how does C or E verify which link is upstream? > The draft mentions in some place that the interface address can be > multicast address. But with this way we will be skipping > the interface validation altogether. > I am considering the fact that we are not adding the Responder > Indentifier TLV. >=20 >=20 > 4.4 Do we need B to send back more information such as the egress to > which the downstream link is being added. > Also do we need B to differentiate between a ECMP path with the > path to multiple egress? > May be adding a egress address in DDMT will solve these? Or is it > that it is taken care in some other ways. >=20 > NB> I don't think any of this is needed. >=20 > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nnassit@gmail.com Wed Jan 13 11:00:32 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E395628C0CF for ; Wed, 13 Jan 2010 11:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SjJAHZJmJE9X for ; Wed, 13 Jan 2010 11:00:31 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id B8FF13A69FB for ; Wed, 13 Jan 2010 11:00:30 -0800 (PST) Received: by ewy1 with SMTP id 1so53895ewy.28 for ; Wed, 13 Jan 2010 11:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=CQso6aArrmXssQ/i3nF01A6aHlSNkGtDz0OXDBz8dQw=; b=gtjaS6yXc/U2++YzD9wVu9xOCskB7ji+rNQLfzB9E6B1xDC7n+rt5QnvKnXq5hYStv AT+mhy28pfUsFNjb8KdBWU2kPQ2Y3D03sk5T5k+E/ItSv/bgXubceAeSaKCAXRh7fYWU Kc/CiueR0ptw8e3VuOUIzPfieedLoQaTQaNAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RRI9dlEpxwbhnh0RcDa7XFaeFwwT48Xk9MFDyYJt61N/8X2RSgEkuVdoHN45v+E0g4 K4Sl2DtsomoOk0EiY9TqnjdpE9BY8EB7igzxv4Nt/E53YIx4qrow9VQGwjIUvj+HJhIE YRLbnhavBF+/vl+p4KJOV29ps+se/HaV20cb0= MIME-Version: 1.0 Received: by 10.213.100.195 with SMTP id z3mr7012570ebn.21.1263409222740; Wed, 13 Jan 2010 11:00:22 -0800 (PST) In-Reply-To: References: <6738A78F51650A4FAEDCF6844B26C21443410E1943@USEXCHANGE.corp.extremenetworks.com> <6738A78F51650A4FAEDCF6844B26C2144431549D35@USEXCHANGE.corp.extremenetworks.com> Date: Wed, 13 Jan 2010 19:00:22 +0000 Message-ID: <95fffc9d1001131100k26be34ffo59ccefb2d8567bdd@mail.gmail.com> From: Najat Nassit To: "David Smith (djsmith)" , mpls@ietf.org Content-Type: multipart/alternative; boundary=001636c5b65aed6db3047d10615a Subject: Re: [mpls] Question on draft-ietf-mpls-ip-options-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:00:33 -0000 --001636c5b65aed6db3047d10615a Content-Type: text/plain; charset=ISO-8859-1 hello every one, i would like ta know if you can help me to find a state of the art about the mpls vpn (specialy security). najat. 2010/1/13 David Smith (djsmith) > > Hi Olen, > > >I just wanted to make sure that there was not a requirement to reduce > this exposure by using a LSP to send the packet directly to the ultimate > destination. > > Correct, no such requirement. If source routing is required on LERs, > mitigating the risk of LSR/SSR packets against downstream LSRs requires > (i) conformance to this draft to enforce MPLS encapsulation at ingress > LERs for destination addresses associated with a prefix-based FEC and > (ii) core hiding (for example, by disabling IP->MPLS TTL propagation at > ingress LERs) so that external sources cannot learn (eg, via traceroute) > and target the IP addresses of downstream LSRs within LSR/SSR packets. > (ii) core hiding (at least for option packets) is also dependent upon > (i). > > Regards, > > /dave > > > -----Original Message----- > From: Olen Stokes [mailto:ostokes@extremenetworks.com] > Sent: Wednesday, January 13, 2010 9:21 AM > To: David Smith (djsmith); mpls@ietf.org > Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt > > David, thanks for the reply. Your response matches my initial feelings > and is consistent with the actions that will be required for other IP > options packets. > > My concern was over the part of the quoted description where it says > "and, thereby, target specific LSRs with any of the DoS attacks outlined > above." A method where the packet is sent to each node in the list via > LSPs still allows the possibility of DoS attacks on those nodes. I just > wanted to make sure that there was not a requirement to reduce this > exposure by using a LSP to send the packet directly to the ultimate > destination. > > Cheers, > Olen > > > -----Original Message----- > From: David Smith (djsmith) [mailto:djsmith@cisco.com] > Sent: Tuesday, January 12, 2010 9:14 PM > To: Olen Stokes; mpls@ietf.org > Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt > > > >What is the intended action to be taken in cases where source routing > is permitted? > > If the next address in the source route (which replaces the address in > the destination address) belongs to a prefix-based FEC, the LSR/SSR > packet should be MPLS encapsulated with the associated MPLS label. > Conversely, if the next address in the source route does not belong to a > prefix-based FEC, the LSR/SSR packet should be IP source routed. > > These behaviors are consistent with the ingress LER requirements > described in Section 4 of the draft. > > Regards, > > /dave > > ________________________________ > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Olen Stokes > Sent: Friday, January 08, 2010 5:29 PM > To: 'mpls@ietf.org' > Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt > > > The following specific type of IP option-based security attack is cited > in Section 5.1 of the draft: > > Crafted IP strict and loose source route option packets that > belong to a prefix-based FEC yet bypass MPLS encapsulation at a > ingress LER may allow an attacker to specify explicit IP > forwarding path(s) across an MPLS network and, thereby, target > specific LSRs with any of the DoS attacks outlined above. This > assumes, of course, that the MPLS network is enabled to process > IP strict and loose source route options. > > What is the intended action to be taken in cases where source routing is > permitted? > > Cheers, > Olen > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001636c5b65aed6db3047d10615a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hello every one,

i would like ta know if you can he= lp me to find a state of the art about the mpls vpn (specialy security).
najat.

2010/1/13 David Smith (djsmit= h) <djsmith@cisco= .com>

Hi Olen,

>I just wanted to make sure that there was not a requirement to reduce this exposure by using a LSP to send the packet directly to the ultimate destination.

Correct, no such requirement. If source routing is required on LERs,<= br> mitigating the risk of LSR/SSR packets against downstream LSRs requires
(i) conformance to this draft to enforce MPLS encapsulation at ingress
LERs for destination addresses associated with a prefix-based FEC and
(ii) core hiding (for example, by disabling IP->MPLS TTL propagation at<= br> ingress LERs) so that external sources cannot learn (eg, via traceroute) and target the IP addresses of downstream LSRs within LSR/SSR packets.
(ii) core hiding (at least for option packets) is also dependent upon
(i).

Regards,

/dave


-----Original Message-----
From: Olen Stokes [mailto:os= tokes@extremenetworks.com]
Sent: Wednesday, January 13, 2010 9:21 AM
To: David Smith (djsmith); mpls@ietf.org
Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt

David, thanks for the reply. =A0Your response matches my initial feelings and is consistent with the actions that will be required for other IP
options packets.

My concern was over the part of the quoted description where it says
"and, thereby, target specific LSRs with any of the DoS attacks outlin= ed
above." =A0A method where the packet is sent to each node in the list = via
LSPs still allows the possibility of DoS attacks on those nodes. =A0I just<= br> wanted to make sure that there was not a requirement to reduce this
exposure by using a LSP to send the packet directly to the ultimate
destination.

Cheers,
Olen


-----Original Message-----
From: David Smith (djsmith) [mailto:
dj= smith@cisco.com]
Sent: Tuesday, January 12, 2010 9:14 PM
To: Olen Stokes; mpls@ietf.org
Subject: RE: [mpls] Question on draft-ietf-mpls-ip-options-03.txt


>What is the intended action to be taken in cases where source routing is permitted?

If the next address in the source route (which replaces the address in
the destination address) belongs to a prefix-based FEC, the LSR/SSR
packet should be MPLS encapsulated with the associated MPLS label.
Conversely, if the next address in the source route does not belong to a prefix-based FEC, the LSR/SSR packet should be IP source routed.

These behaviors are consistent with the ingress LER requirements
described in Section 4 of the draft.

Regards,

/dave

________________________________

From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of
Olen Stokes
Sent: Friday, January 08, 2010 5:29 PM
To: 'mpls@ietf.org'
Subject: [mpls] Question on draft-ietf-mpls-ip-options-03.txt


The following specific type of IP option-based security attack is cited
in Section 5.1 of the draft:

=A0 =A0 =A0 Crafted IP strict and loose source route option packets that =A0 =A0 =A0 belong to a prefix-based FEC yet bypass MPLS encapsulation at = a
=A0 =A0 =A0 ingress LER may allow an attacker to specify explicit IP
=A0 =A0 =A0 forwarding path(s) across an MPLS network and, thereby, target=
=A0 =A0 =A0 specific LSRs with any of the DoS attacks outlined above. =A0T= his
=A0 =A0 =A0 assumes, of course, that the MPLS network is enabled to proces= s
=A0 =A0 =A0 IP strict and loose source route options.

What is the intended action to be taken in cases where source routing is permitted?

Cheers,
Olen


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001636c5b65aed6db3047d10615a-- From nitinb@juniper.net Wed Jan 13 11:02:17 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D22228C13D for ; Wed, 13 Jan 2010 11:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ORs-0shF4TkW for ; Wed, 13 Jan 2010 11:02:16 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 0B63F28C106 for ; Wed, 13 Jan 2010 11:02:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS04YpNsz7wuXQbBvBSZnzeAohPubptjp@postini.com; Wed, 13 Jan 2010 11:02:13 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 13 Jan 2010 10:59:38 -0800 From: Nitin Bahadur To: "Shaleen Saxena (ssaxena)" , "Ashwin C. Prabhu" , "mpls@ietf.org" Date: Wed, 13 Jan 2010 10:59:07 -0800 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaTbjNK+n3QOITF+rJr1V/bbIxgATflLmAC/y6vAAAt/j0A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:02:17 -0000 I don't see why Node Responder cannot be used to do traceroute. The draft d= oes not prohibit it. A - B - C - D | +----E ---F At ttl=3D1, B will respond with a DDMAPs of C and E Now A can set the node responder TLV to address of C and send a pkt with TT= L=3D2. At this point E should drop the packet and only C should process the packet= . Is my understanding incorrect? Thanks NItin On 1/13/10 9:42 AM, "Shaleen Saxena (ssaxena)" wrote: Hi Nitin, Thanks for your response. One correction: Node Address Responder Identifier is intended for ping and Egress Address Responder Identifier TLV is intended for traceroute. If Node Address Responder Identifier is used for tracing, then the head-end needs to have an a priori knowledge of the topology. Regards, Shaleen > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nitin Bahadur > Sent: Tuesday, January 12, 2010 1:44 PM > To: Ashwin C. Prabhu; mpls@ietf.org > Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt > > Hi Ashwin, > > See responses to some of your questions below... > > > On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: > 4. > Say A is ingress and D and F are 2 egresses of the p2mp lsp. > > A ------------ B --------------C --------- D > \----------------E ---------- F > > When A sends a echo request with TTL 1, B replies back with 2 instances > of DDMT depicitng interface BC and BE. > Now at node A we know that there are 2 outgoing links to egress. > > NB> you can trace each sub-tree at a time using the "Node Address > P2MP Responder Identifier Sub-TLV" > and increasing ttl. So for TTL=3D2, A will send 2 messages: 1 with > DDMT for C and one for DDMT for E. > This approach is similar to how you do tracert for LDP ECMP > (wherein we use different dest-ip). > > If you want to trace paths in parallel....there is a way ...at expense > of reduced functionality.... > Each pkt that ingress A sends, it's DDMT always sets the > Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. > For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. > As per RFC 4379 > > "If an LSR receives an Echo Request packet with the all- > routers > multicast address, then this indicates that it MUST bypass > both > interface and label stack validation, but return Downstream > Mapping TLVs using the information provided." > > For TTL=3D1, B will respond with 2 DDMT TLV (one for C and one > for E). A can now > create a tree containing A, B, C, E. Now on TTL=3D2, A will get a > response from C and E. Based on IP addr of > responding node, A will know if it's C or E and can graft the > information regarding D or F into the tree. > > 4.1 How does A distinguish whether the BC and BE are ECMP paths or > path for 2 different egresses? > > NB> Ingress "does not care". A is building a topology during the trace > and it will realize which nodes are > egresses when the topology build-up completes. Note that for P2MP RSVP- > TE, there is no concept of ECMP. For > mLDP, there is ECMP...but "A" can do post-tree-computation analysis > to determine ECMP paths. > > 4.2 How does node A, corelate the links BC and BE to egress D or F? > (Basically how does the topology formed at ingress) > In the above topology, B is transit for both C & E, where as C > is part of only D and E is part of only F. > > NB> See above. > > 4.3 How should the node A's next mpls echo request (TTL 2) look like? > If A is adding the DDMT in its echo Request then should it > contain both the links received BC and BE? > If so, then how does C or E verify which link is upstream? > The draft mentions in some place that the interface address can be > multicast address. But with this way we will be skipping > the interface validation altogether. > I am considering the fact that we are not adding the Responder > Indentifier TLV. > > > 4.4 Do we need B to send back more information such as the egress to > which the downstream link is being added. > Also do we need B to differentiate between a ECMP path with the > path to multiple egress? > May be adding a egress address in DDMT will solve these? Or is it > that it is taken care in some other ways. > > NB> I don't think any of this is needed. > > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From ssaxena@cisco.com Wed Jan 13 11:34:10 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9423A67F4 for ; Wed, 13 Jan 2010 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6T-GmPUrxXGI for ; Wed, 13 Jan 2010 11:34:01 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 29EA628C0E9 for ; Wed, 13 Jan 2010 11:34:01 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAHuvTUurRN+J/2dsb2JhbACCFcBAlHiCOYF3BA X-IronPort-AV: E=Sophos;i="4.49,270,1262563200"; d="scan'208,217";a="132759181" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2010 19:33:58 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0DJXp9D013243; Wed, 13 Jan 2010 19:33:58 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 13:33:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9487.59258618" Date: Wed, 13 Jan 2010 13:33:55 -0600 Message-ID: In-Reply-To: <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqUS7hYhZ7Hgq3XRUu1zQTuKGLOrgALB3Ow References: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Ashwin C. Prabhu" , "Nitin Bahadur" X-OriginalArrivalTime: 13 Jan 2010 19:33:57.0944 (UTC) FILETIME=[59AC4B80:01CA9487] Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:34:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9487.59258618 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 1. In the case of tracing node by node using the node address responder id TLV, only way to map C to node B would be to take the help of the IGP. [Shaleen Saxena (ssaxena): ] That is why Egress Address Responder Identifier TLV is the intended way for tracing. =20 I am assuming that the node C's address is going to be a loopback address.=20 Do we need to consider the case of a lsp spanning accross the Autonomous System? Does the p2mp lsp span across different AS? Or can we have=20 lsp stitching for the p2mp lsp? If we already support any of these at present or in future then we may not be able to map node C to its upstream node=20 B.=20 =20 =20 [Shaleen Saxena (ssaxena): ] I don't think we will have stitching in P2MP LSPs. =20 =20 2. I still didn't get how the tree is formed for tracing parallely,=20 =20 [Shaleen Saxena (ssaxena): ] Creating a tree topology using traceroute is going to be hard. Correlating responses from one TTL to next is not easy. We can use the Downstream IP/Interface Address fields in DDMAP and match it to source IP of the next response. However this may not work under multiple circumstances.=20 =20 One scenario is when the router id is put in Downstream IP/Interface Address fields and the next hop responds with interface address. Then matching will not be possible. (A possible solution would be to have the responding node return the Router ID in some new TLV.)=20 =20 Another scenario is if a router does not respond or does not give DDMAP back. Then the topology will have holes in it and creating an overall tree would not be possible. =20 =20 Regards, Shaleen =20 =20 Extending the above topology adding a node G and H in the previous topology. =20 A ------------ B --------------C ----------- G -------------- D \----------------E ---------- H -------------- F =20 Now considering that there is no DDMT in label request message or DDMT with unnumbered type (interface address is multicast address) With TTL 1 Node B replies back=20 Wih TTL 2 Node C and E replies back, With TTL 3 Node G and H replies back=20 With TTL 4 Node D and F replies with return code. =20 So say at instance with TTL 3 replies received, the tree could be A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B ----E--- H The sender address of G or H doesn't indicate who is upstream? I think i am missing something here. =20 By attaching something similar to "Node address responder id TLV" to each instance of DDMT in the echo Request message can we not do the interface validation even in the case of parallel trace? Basically instead of sending multiple messages for each node i am sugesting to club those messages and the corresponding node will pick only required information. =20 Best Regds, Ashwin =20 =20 =20 On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur wrote: Hi Ashwin, See responses to some of your questions below... On 1/12/10 1:24 AM, "Ashwin C. Prabhu" wrote: 4. Say A is ingress and D and F are 2 egresses of the p2mp lsp. A ------------ B --------------C --------- D \----------------E ---------- F When A sends a echo request with TTL 1, B replies back with 2 instances of DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. NB> you can trace each sub-tree at a time using the "Node Address P2MP Responder Identifier Sub-TLV" and increasing ttl. So for TTL=3D2, A will send 2 messages: 1 with = DDMT for C and one for DDMT for E. This approach is similar to how you do tracert for LDP ECMP (wherein we use different dest-ip). If you want to trace paths in parallel....there is a way ...at expense of reduced functionality.... Each pkt that ingress A sends, it's DDMT always sets the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. As per RFC 4379 "If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided." For TTL=3D1, B will respond with 2 DDMT TLV (one for C and one for E). A can now create a tree containing A, B, C, E. Now on TTL=3D2, A will get a = response from C and E. Based on IP addr of responding node, A will know if it's C or E and can graft the information regarding D or F into the tree. 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for 2 different egresses? NB> Ingress "does not care". A is building a topology during the trace and it will realize which nodes are egresses when the topology build-up completes. Note that for P2MP RSVP-TE, there is no concept of ECMP. For mLDP, there is ECMP...but "A" can do post-tree-computation analysis to determine ECMP paths. 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F. NB> See above. 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain both the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be multicast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indentifier TLV. 4.4 Do we need B to send back more information such as the egress to which the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path to multiple egress? May be adding a egress address in DDMT will solve these? Or is it that it is taken care in some other ways. NB> I don't think any of this is needed. Thanks Nitin =20 ------_=_NextPart_001_01CA9487.59258618 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

1. In the case of tracing node by node using the = node address responder id TLV, only way to map C to node B would be to take = the help of the IGP.

[Shaleen Saxena (ssaxena): ] That is why Egress Address = Responder Identifier TLV is the intended way for = tracing.

 

    I am assuming that the node = C's address is going to be a loopback address.

   Do we need to consider the case of a = lsp spanning accross the Autonomous System? Does the p2mp lsp span across = different AS? Or can we have

   lsp stitching for the p2mp lsp? If we = already support any of these at present or in future then we may not be able to = map node C to its upstream node

   B. =

 

 

[Shaleen Saxena (ssaxena): ] I don’t think we will = have stitching in P2MP LSPs.

 

 

2. I still didn't get how the tree is formed for = tracing parallely,

 

[Shaleen Saxena (ssaxena): ] Creating a tree topology = using traceroute is going to be hard. Correlating responses from one TTL to = next is not easy. We can use the Downstream IP/Interface Address fields in DDMAP = and match it to source IP of the next response. However this may not work = under multiple circumstances.

 

One scenario is when the router id is put in Downstream IP/Interface Address fields and the next hop responds with interface = address. Then matching will not be possible. (A possible solution would be to = have the responding node return the Router ID in some new TLV.) =

 

Another scenario is if a router does not respond or does = not give DDMAP back. Then the topology will have holes in it and creating an overall tree would not be possible.

 

 

Regards,

Shaleen

 

 

    Extending the above topology = adding a node G and H in the previous topology.

 

         &= nbsp; A ------------ B --------------C ----------- G -------------- D
            &= nbsp;           &n= bsp;    \----------------E ---------- H -------------- F

 

   Now considering that there is no DDMT = in label request message or DDMT with unnumbered type (interface address is = multicast address)

   With TTL 1  Node B replies back =

   Wih TTL 2 Node C and E replies = back,

   With TTL 3 Node G and H replies back =

   With TTL 4 Node D and F replies with = return code.

 

  So say at instance with TTL 3 replies = received, the tree could be  A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B ----E--- H

  The sender address of G or H doesn't = indicate who is upstream?

  I think i am missing something = here.

 

 By attaching something similar to "Node = address responder id TLV" to each instance of DDMT in the echo Request = message can we not do the interface validation even in the case of parallel trace? Basically instead of sending multiple messages for each node i am = sugesting to club those messages and the corresponding node will pick only required information.

 

Best Regds,

Ashwin

 

 

   =

On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur = <nitinb@juniper.net> = wrote:

Hi Ashwin,

 See responses to some of your questions below...



On 1/12/10 1:24 AM, "Ashwin C. Prabhu" <prabhu.ashwin@gmail.com> = wrote:
4.
   Say   A is ingress and D and F are 2 egresses of the = p2mp lsp.

           A ------------ B = --------------C --------- D
                    =          \----------------E ---------- F

When A sends a echo request with TTL 1, B replies back with 2 instances = of DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to = egress.

NB>       you can trace each = sub-tree at a time using the "Node Address P2MP Responder Identifier = Sub-TLV"
   and increasing ttl. So for TTL=3D2, A will send 2 messages: = 1 with DDMT for C and one for DDMT for E.
   This approach is similar to how you do tracert for LDP ECMP (wherein we use different dest-ip).

If you want to trace paths in parallel....there is a way ...at expense = of reduced functionality....
        Each pkt that ingress A sends, it's DDMT = always sets  the Address Type to either IPv4 Unnumbered or IPv6 = Unnumbered.
         For IPv4, it MUST set the Downstream = IP Address to 224.0.0.2. As per RFC 4379

         "If an LSR receives an Echo = Request packet with the all-routers
          multicast address, then this = indicates that it MUST bypass both
           interface and label stack = validation, but return Downstream
          Mapping TLVs using the information = provided."

          For TTL=3D1, B will respond with 2 = DDMT TLV (one for C and one for E). A can now
create a tree containing A, B, C, E. Now on TTL=3D2, A will get a = response from C and E. Based on IP addr of
 responding node, A will know if it's C or E and can graft the = information regarding D or F into the tree.


 4.1 How does A distinguish whether the BC and BE are ECMP paths or = path for 2 different egresses?

NB> Ingress "does not care". A is = building a topology during the trace and it will realize which nodes are
egresses when the topology build-up completes. Note that for P2MP = RSVP-TE, there is no concept of ECMP. For
 mLDP, there is ECMP...but  "A" can do post-tree-computation analysis to determine ECMP paths.


 4.2 How does node A, corelate the links BC and BE to egress D or = F? (Basically how does the topology formed at ingress)
      In the above topology, B is transit for both C = & E, where as C is part of only D and E is part of only F.

NB> See above.


 4.3 How should the node A's next mpls echo request (TTL 2) look = like?
     If A is adding the DDMT in its echo Request then = should it contain both the links received BC and BE?
     If so, then how does C or E verify which link is = upstream?
    The draft mentions in some place that the interface = address can be multicast address. But with this way we will be skipping
     the interface validation altogether.
    I am considering the fact that we are not adding the = Responder Indentifier TLV.


4.4 Do we need B to send back more information such as the egress to = which the downstream link is being added.
     Also do we need B to differentiate between a ECMP = path with the path to multiple egress?
    May be adding a egress address in DDMT will solve these? = Or is it that it is taken care in some other ways.

NB> I don't think any of this is needed.

Thanks
Nitin

 

------_=_NextPart_001_01CA9487.59258618-- From ssaxena@cisco.com Wed Jan 13 11:50:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CA63A6861 for ; Wed, 13 Jan 2010 11:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RRp5Axqqyeae for ; Wed, 13 Jan 2010 11:50:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1F6FC3A67E7 for ; Wed, 13 Jan 2010 11:50:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPKyTUurRN+J/2dsb2JhbADCPpR5gjmBdwQ X-IronPort-AV: E=Sophos;i="4.49,270,1262563200"; d="scan'208";a="132767536" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2010 19:50:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0DJoXiS027041; Wed, 13 Jan 2010 19:50:33 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 13:50:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 13:50:31 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaTbjNK+n3QOITF+rJr1V/bbIxgATflLmAC/y6vAAAt/j0AABOrUQ References: From: "Shaleen Saxena (ssaxena)" To: "Nitin Bahadur" , "Ashwin C. Prabhu" , X-OriginalArrivalTime: 13 Jan 2010 19:50:33.0464 (UTC) FILETIME=[AB0C9780:01CA9489] Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:50:37 -0000 Hi: Your understanding is correct. I have purposely kept the draft open on which TLV to use for ping or trace. Section 4.1.1: These sub-TLVs limit the responses either to the specified router only or to any router on the path to the specified router. The former capability is generally useful for ping mode, while the latter is more suited to traceroute mode. An initiating router may indicate that it wishes all egresses to respond to an echo request by omitting the P2MP Responder Identifier TLV. So this paragraph does not limit one or other use. The way you are recommending is certainly possible and allowed.=20 However the way I see is that a user would try to trace to some particular egress. Now if Node Address sub-TLV is used then the initiating node needs to know a priori on how to get there. So in your example: A - B - C - D | +----E ---F If a user is trying to trace to F only, then initiating routers should know (either via user config or from RSVP) that E is the next-hop node to F. Also if a mid-point node misbehaves (i.e. does not respond at all or does not return a DDMAP), then you may not have the required information for the next echo request. Thanks, Shaleen > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Wednesday, January 13, 2010 1:59 PM > To: Shaleen Saxena (ssaxena); Ashwin C. Prabhu; mpls@ietf.org > Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt >=20 >=20 > I don't see why Node Responder cannot be used to do traceroute. The > draft does not prohibit it. >=20 > A - B - C - D > | > +----E ---F >=20 > At ttl=3D1, B will respond with a DDMAPs of C and E > Now A can set the node responder TLV to address of C and send a pkt > with TTL=3D2. > At this point E should drop the packet and only C should process the > packet. >=20 > Is my understanding incorrect? >=20 > Thanks > NItin >=20 > On 1/13/10 9:42 AM, "Shaleen Saxena (ssaxena)" > wrote: >=20 > Hi Nitin, >=20 > Thanks for your response. One correction: Node Address Responder > Identifier is intended for ping and Egress Address Responder Identifier > TLV is intended for traceroute. >=20 > If Node Address Responder Identifier is used for tracing, then the > head-end needs to have an a priori knowledge of the topology. >=20 > Regards, > Shaleen >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Nitin Bahadur > > Sent: Tuesday, January 12, 2010 1:44 PM > > To: Ashwin C. Prabhu; mpls@ietf.org > > Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt > > > > Hi Ashwin, > > > > See responses to some of your questions below... > > > > > > On 1/12/10 1:24 AM, "Ashwin C. Prabhu" > wrote: > > 4. > > Say A is ingress and D and F are 2 egresses of the p2mp lsp. > > > > A ------------ B --------------C --------- D > > \----------------E ---------- F > > > > When A sends a echo request with TTL 1, B replies back with 2 > instances > > of DDMT depicitng interface BC and BE. > > Now at node A we know that there are 2 outgoing links to egress. > > > > NB> you can trace each sub-tree at a time using the "Node > Address > > P2MP Responder Identifier Sub-TLV" > > and increasing ttl. So for TTL=3D2, A will send 2 messages: 1 = with > > DDMT for C and one for DDMT for E. > > This approach is similar to how you do tracert for LDP ECMP > > (wherein we use different dest-ip). > > > > If you want to trace paths in parallel....there is a way ...at > expense > > of reduced functionality.... > > Each pkt that ingress A sends, it's DDMT always sets the > > Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. > > For IPv4, it MUST set the Downstream IP Address to > 224.0.0.2. > > As per RFC 4379 > > > > "If an LSR receives an Echo Request packet with the all- > > routers > > multicast address, then this indicates that it MUST bypass > > both > > interface and label stack validation, but return > Downstream > > Mapping TLVs using the information provided." > > > > For TTL=3D1, B will respond with 2 DDMT TLV (one for C = and > one > > for E). A can now > > create a tree containing A, B, C, E. Now on TTL=3D2, A will get a > > response from C and E. Based on IP addr of > > responding node, A will know if it's C or E and can graft the > > information regarding D or F into the tree. > > > > 4.1 How does A distinguish whether the BC and BE are ECMP paths or > > path for 2 different egresses? > > > > NB> Ingress "does not care". A is building a topology during the > trace > > and it will realize which nodes are > > egresses when the topology build-up completes. Note that for P2MP > RSVP- > > TE, there is no concept of ECMP. For > > mLDP, there is ECMP...but "A" can do post-tree-computation > analysis > > to determine ECMP paths. > > > > 4.2 How does node A, corelate the links BC and BE to egress D or F? > > (Basically how does the topology formed at ingress) > > In the above topology, B is transit for both C & E, where as C > > is part of only D and E is part of only F. > > > > NB> See above. > > > > 4.3 How should the node A's next mpls echo request (TTL 2) look > like? > > If A is adding the DDMT in its echo Request then should it > > contain both the links received BC and BE? > > If so, then how does C or E verify which link is upstream? > > The draft mentions in some place that the interface address can > be > > multicast address. But with this way we will be skipping > > the interface validation altogether. > > I am considering the fact that we are not adding the Responder > > Indentifier TLV. > > > > > > 4.4 Do we need B to send back more information such as the egress to > > which the downstream link is being added. > > Also do we need B to differentiate between a ECMP path with the > > path to multiple egress? > > May be adding a egress address in DDMT will solve these? Or is > it > > that it is taken care in some other ways. > > > > NB> I don't think any of this is needed. > > > > Thanks > > Nitin > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Sandeep.Bishnoi@alcatel-lucent.com Wed Jan 13 11:55:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163FE3A6867 for ; Wed, 13 Jan 2010 11:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HVQMTIgBvwVP for ; Wed, 13 Jan 2010 11:55:13 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 85B903A67E7 for ; Wed, 13 Jan 2010 11:55:13 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id o0DJt9F4025854; Wed, 13 Jan 2010 13:55:09 -0600 (CST) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.pdc.alcatel-lucent.com [172.22.216.13]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id o0DJt9x5025580; Wed, 13 Jan 2010 13:55:09 -0600 (CST) Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 13:55:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA948A.4EED4467" Date: Wed, 13 Jan 2010 13:55:06 -0600 Message-ID: <4E816EC104822245BA3C86149A7158150C12B732@USDALSMBS01.ad3.ad.alcatel.com> In-Reply-To: <1064ACAB129E654386C2FDEFADC51F3A01917C7D@S4DE9JSAANL.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-bishnoi-mpls-ldp-node-group-00 Thread-Index: AcqO2i+Pjz6wzWGdQMe/jtlDaD4XOQFqpxyQ References: <1064ACAB129E654386C2FDEFADC51F3A01917C7D@S4DE9JSAANL.ost.t-com.de> From: "BISHNOI Sandeep" To: , X-OriginalArrivalTime: 13 Jan 2010 19:55:09.0001 (UTC) FILETIME=[4F483390:01CA948A] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 Subject: Re: [mpls] draft-bishnoi-mpls-ldp-node-group-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:55:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA948A.4EED4467 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rudiger, =20 Purpose of this draft is to allow creating disjoint P2MP trees and also = to restrict flow of P2P LSP to a set of preferred routes among available = ECMP routes. It uses a "constraint" method but that is only to give = preference to certain routes among ECMP. =20 - For this to work properly, the network must be provisioned = with a rich topology to support ECMP routes. - It does not create constraint based routes as it is using a = subset of routes available from "classic" routing and not creating a = superset of routes - mLDP draft has provision to select an upstream node but does = not allow any method to create disjoint P2MP trees - Method is applicable to P2P case too where the requirement is = to not use all available ECMP paths but to prefer or restrict flow to a = subset of ECMP paths. This would help in case of "out of control ECMP" = where the ECMP routes multiply with increase in links and nodes across = network. - RSVP creates a superset of routes so falls under the domain = of constraint based routing. =20 We would appreciate comments from the WG. =20 Thanks, Sandeep =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = RKunze@telekom.de Sent: Wednesday, January 06, 2010 6:12 AM To: mpls@ietf.org Subject: [mpls] draft-bishnoi-mpls-ldp-node-group-00 =20 Hi Sandeep,=20 I think the mLDP (draft-mpls-ldp-p2mp) draft from Ice and others = addresses the upstream node selection in section 2.4.1.1. Determining = one's 'upstream LSR'. I think furthermore your method goes more into the = direction of contraint-based routing. Is this right? If yes, then my = question is why not using RSVP-TE to setup a constraint based P2MP-LSP. =20 Best regards=20 R=FCdiger=20 ------_=_NextPart_001_01CA948A.4EED4467 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bishnoi-mpls-ldp-node-group-00

Hi = Rudiger,

 

Purpose of this draft is to allow = creating disjoint P2MP trees and also to restrict flow of P2P LSP to a set of = preferred routes among available ECMP routes. It uses a “constraint” = method but that is only to give preference to certain routes among = ECMP.

 

-          For this to work properly, the network must be provisioned with a rich topology = to support ECMP routes.

-          It does not create constraint based routes as it is using a subset of routes = available from “classic” routing and not creating a superset of = routes

-          mLDP draft has provision to select an upstream node but does not allow any = method to create disjoint P2MP trees

-          Method is applicable to P2P case too where the requirement is to not use all = available ECMP paths but to prefer or restrict flow to a subset of ECMP paths. = This would help in case of “out of control ECMP” where the ECMP routes = multiply with increase in links and nodes across = network.

-          RSVP creates a superset of routes so falls under the domain of constraint = based routing.

 

We would appreciate comments from = the WG.

 

Thanks,

=

Sandeep

=

 


From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of RKunze@telekom.de
Sent: Wednesday, January = 06, 2010 6:12 AM
To: mpls@ietf.org
Subject: [mpls] draft-bishnoi-mpls-ldp-node-group-00

 

Hi Sandeep,

I think the mLDP (draft-mpls-ldp-p2mp) draft from Ice and others addresses = the upstream node selection in section 2.4.1.1. Determining one's 'upstream = LSR'. I think furthermore your method goes more into the direction of = contraint-based routing. Is this right? If yes, then my question is why not using = RSVP-TE to setup a constraint based P2MP-LSP.

 

Best regards

R=FCdiger

------_=_NextPart_001_01CA948A.4EED4467-- From nitinb@juniper.net Wed Jan 13 12:16:25 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B7A3A67AE for ; Wed, 13 Jan 2010 12:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 MR7zoptdncM4 for ; Wed, 13 Jan 2010 12:16:24 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 2EBB83A683A for ; Wed, 13 Jan 2010 12:16:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS04qFIRER1AFrueXkgLheOIucWg84YYX@postini.com; Wed, 13 Jan 2010 12:16:22 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 13 Jan 2010 12:15:59 -0800 From: Nitin Bahadur To: "'Ashwin C. Prabhu'" Date: Wed, 13 Jan 2010 12:15:58 -0800 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqUS6CKkpYwTdF6RqaR1g2U2BkdMgAQBauA Message-ID: <05542EC42316164383B5180707A489EE1D0AC2F4A8@EMBX02-HQ.jnpr.net> References: <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> In-Reply-To: <3c33c551001130426m51121622x7dd0254d1bb714ef@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1D0AC2F4A8EMBX02HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:16:25 -0000 --_000_05542EC42316164383B5180707A489EE1D0AC2F4A8EMBX02HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ashwin, 1. In the case of tracing node by node using the node address responder id= TLV, only way to map C to node B would be to take the help of the IGP. I am assuming that the node C's address is going to be a loopback addre= ss. NB> Cannot guarantee....implementation specific. Do we need to consider the case of a lsp spanning accross the Autonomous= System? NB> No. Inter-as lsp-ping draft has expired. Does the p2mp lsp span across different AS? Or can we have lsp stitching for the p2mp lsp? If we already support any o= f these at present or in future then we may not be able to map node C to it= s upstream node B. NB> You can always *have* lsp-stitching for p2mp lsp via some configuration= ...not sure how you would do it with signaling. 2. I still didn't get how the tree is formed for tracing parallely, Extending the above topology adding a node G and H in the previous topo= logy. A ------------ B --------------C ----------- G -------------- D \----------------E ---------- H --------------= F Now considering that there is no DDMT in label request message NB> Traceroute will not work if there is no DDMT in label request msg. Trac= eroute requires DDMT msg in echo request. or DDMT with unnumbered type (interface address is multicast address) NB> Traceroute with unnumbered interface is tricky.... With TTL 1 Node B replies back Wih TTL 2 Node C and E replies back, With TTL 3 Node G and H replies back With TTL 4 Node D and F replies with return code. So say at instance with TTL 3 replies received, the tree could be A ----= B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B -= ---E--- H The sender address of G or H doesn't indicate who is upstream? I think i am missing something here. NB> Yes...you are missing the fact that DDMT is required for tracert. B wou= ld need to send the DDMTs for C & E. Only then can A co-relate the responses from C & E. By attaching something similar to "Node address responder id TLV" to each = instance of DDMT in the echo Request message can we not do the interface va= lidation even in the case of parallel trace? Basically instead of sending m= ultiple messages for each node i am sugesting to club those messages and th= e corresponding node will pick only required information. NB> The draft does not support that. Echo request can contain only 1 DDMT (= as of today). Also, adding multiple DDMTs is not scalalbe. It will make the packet much bigger and increase the= processing load on the transits, esp if the packet contains a large number of DDMTs. Nitin --_000_05542EC42316164383B5180707A489EE1D0AC2F4A8EMBX02HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ashwin, 
 
 1. In the case of tracin= g node=20 by node using the node address responder id TLV, only way to map C to node = B=20 would be to take the help of the IGP.
    I am assuming that the node C's address is g= oing=20 to be a loopback address.  
 
NB> Cannot guarantee....implementation=20 specific.
 
   Do we need to consider the case of a lsp spanning accro= ss=20 the Autonomous System?  
 
NB> No. Inter-as lsp-ping draft has expired.
 
 Does the p2mp lsp span= across=20 different AS?  
 Or can we have ls= p=20 stitching for the p2mp lsp? If we already support any of these at present= or=20 in future then we may not be able to map node C to its upstream node
   B.
 
NB> You can always *have* lsp-stitching for p2mp lsp via some= =20 configuration...not sure how you would
do=20 it with signaling.
 
2. I still didn't get how the tree is formed for tracing parallely,= =20
    Extending the above topology adding a node G and = H in=20 the previous topology.
 
           A=20 ------------ B --------------C ----------- G --------------=20 D
           &n= bsp;            = ;    =20 \----------------E ---------- H -------------- F
 
   Now considering that there is no DDMT in label request= =20 message 
 
NB> Traceroute will not work if there is no DDMT in label req= uest=20 msg. Traceroute requires DDMT msg in
echo=20 request.
 
  or DDMT with unnumber= ed type=20 (interface address is multicast address)=  
 
NB> Traceroute with unnumbered interface is tricky....
 
   With TTL 1  Node B replies back
   Wih TTL 2 Node C and E replies back,
   With TTL 3 Node G and H replies back
   With TTL 4 Node D and F replies with return code.
 
  So say at instance with TTL 3 replies received, the tree coul= d=20 be  A ---- B ----- C --- G or A----- B ------C --- H or A----B---E -= -- G=20 or A --- B ----E--- H
  The sender address of G or H doesn't indicate who is=20 upstream?
  I think i am missing something here.
 
NB> Yes...you are missing the fact that DDMT is required for= =20 tracert. B would need to send the DDMTs for C & E.
Only=20 then can A co-relate the responses from C & E.
 
 By attaching something similar to "Node address responder id T= LV"=20 to each instance of DDMT in the echo Request message can we not do the=20 interface validation even in the case of parallel trace? Basically instea= d of=20 sending multiple messages for each node i am sugesting to club those mess= ages=20 and the corresponding node will pick only required information. 
 
NB> The draft does not support that. Echo request can co= ntain=20 only 1 DDMT (as of today). Also, adding multiple
DDMTs is not scalalbe. It will make the packet much bigger and i= ncrease=20 the processing load on the transits, esp
if=20 the packet contains a large number of DDMTs.
 
Nitin
--_000_05542EC42316164383B5180707A489EE1D0AC2F4A8EMBX02HQjnprn_-- From diego.caviglia@ericsson.com Wed Jan 13 23:53:29 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D43A6948; Wed, 13 Jan 2010 23:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Ze-WO9dq1hSE; Wed, 13 Jan 2010 23:53:28 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 63D423A6942; Wed, 13 Jan 2010 23:53:27 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-61-4b4ecd71e5fb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CE.CE.04178.17DCE4B4; Thu, 14 Jan 2010 08:53:21 +0100 (CET) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 08:52:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jan 2010 08:52:11 +0100 Message-ID: In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgUBglFKQurGTViBMde2E6EnFAAfHB6g References: <4B4DFC51.8050301@pi.nu> From: "Diego Caviglia" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 14 Jan 2010 07:52:33.0225 (UTC) FILETIME=[87A38B90:01CA94EE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 07:53:29 -0000 Yes support Ciao D line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Loa Andersson Sent: mercoled=EC 13 gennaio 2010 18.01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From eric.gray@ericsson.com Thu Jan 14 06:42:37 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27F23A67DB; Thu, 14 Jan 2010 06:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pQx6yOA23CcO; Thu, 14 Jan 2010 06:42:37 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0D54B3A67D9; Thu, 14 Jan 2010 06:42:36 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0EEgmr2007381; Thu, 14 Jan 2010 08:42:49 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 14 Jan 2010 09:42:32 -0500 From: Eric Gray To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Thu, 14 Jan 2010 09:42:31 -0500 Thread-Topic: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUchvOyu3COQvzSu2oIn5kgTUmpwAtaJVQ Message-ID: References: <4B4DFC51.8050301@pi.nu> In-Reply-To: <4B4DFC51.8050301@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 14:42:38 -0000 Yes.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, January 13, 2010 12:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection a= n mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nnassit@gmail.com Thu Jan 14 07:29:02 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF093A681B for ; Thu, 14 Jan 2010 07:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 L6WM8NTgv-mw for ; Thu, 14 Jan 2010 07:29:02 -0800 (PST) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id BC3613A67D1 for ; Thu, 14 Jan 2010 07:28:56 -0800 (PST) Received: by ewy1 with SMTP id 1so11702ewy.28 for ; Thu, 14 Jan 2010 07:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=z3WkQJr2+lmr8SpSLmYA+VgV8ptqsR/zPjavfXvlZbM=; b=GbLW2mFIrlX4hQB0Fa+o8KuFEOeq38pVhEhmhiBGt7fIeDL2AeID5qVUPBRFeF5M6g PvyfWfft0FN3vSaz3OzuYbk8wLDQvIG4FCK1KCV2v7MIaOM/s0iQ+krAVmWz7LdMtOxj 3y2bSuFDFb+2ulfaz3yI9J4XRSkk9pZeNPxjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GJ1aLyG8gXfEwIUkwtgEm80GsPsIX9p/cHuskeTnaT01XB/CiGyVBNFcHHyQjH2Gk8 MasA/jX8Tvx37xQyYv8/U5S91p3syNUJVe7sHBwC+oRyZI+9Pgc9qsflPwd+WETNfxJW 5Kgi59Qr04q6Wr8xyCsZpUItmnYeyER/X/W8M= MIME-Version: 1.0 Received: by 10.213.96.221 with SMTP id i29mr962496ebn.33.1263482923770; Thu, 14 Jan 2010 07:28:43 -0800 (PST) Date: Thu, 14 Jan 2010 15:28:43 +0000 Message-ID: <95fffc9d1001140728rd0cccdbte2f0c313a7cc3aa3@mail.gmail.com> From: Najat Nassit To: mpls@ietf.org Content-Type: multipart/alternative; boundary=001636c5a7c7d9e449047d218a84 Subject: [mpls] searching thesis on the MPLS VPN X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:29:03 -0000 --001636c5a7c7d9e449047d218a84 Content-Type: text/plain; charset=ISO-8859-1 please can you help me? in french if possible please. best regards --001636c5a7c7d9e449047d218a84 Content-Type: text/html; charset=ISO-8859-1
please can you help me? in french if possible please.

best regards
--001636c5a7c7d9e449047d218a84-- From eric.gray@ericsson.com Thu Jan 14 08:35:40 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326593A6910 for ; Thu, 14 Jan 2010 08:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 kyd6+slwNWNy for ; Thu, 14 Jan 2010 08:35:38 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 461543A6819 for ; Thu, 14 Jan 2010 08:35:38 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o0EGZX3g011996; Thu, 14 Jan 2010 10:35:48 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 14 Jan 2010 11:35:24 -0500 From: Eric Gray To: "Shaleen Saxena (ssaxena)" Date: Thu, 14 Jan 2010 11:35:23 -0500 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaUpxPPIfHTPwS1SeaqRWJwxNggBAkgQgADKPw3A= Message-ID: References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C0AC8FAB6849AB4FADACCC70A949E2F104337CF2E6EUSAACMS0701e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:35:40 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F104337CF2E6EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shaleen, Please see in-line below... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= leen Saxena (ssaxena) Sent: Wednesday, January 13, 2010 12:37 PM To: Ashwin C. Prabhu; mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Hi Ashwin, I could not get to this yesterday. My answers are inline. 1. In the page 8 it is mentioned that "The transit LSR also returns information on an echo response that helps= verify the control plane against the data plane. That is, the information is used by the ingress to check that the data plane = forwarding, matches what is signaled by the control plane" The ingress referes to what? The ingress lsr or the ingress interface of = the transit lsr? Its not very clear from the above statement. I think it should be ingress interface? [Shaleen Saxena (ssaxena): ] This section comes from the version 0 of the d= raft. The original intent was to verify forwarding from one hop to next. I = think paragraphs needs to be updated as follows: In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress router to build topology or downstream routers to do extra verification. Please note that the motivation section gives a high level overview of the = design goals and not the actual implementation. Since this is an LSP Ping technique, the ingress in question MUST be an LSR= , not a router. 2. Section 3.5 page 15 of the draft sates "Downstream Detailed Mapping TLV is described in [DDMT]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes" ... "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in [RFC4379] is being deprecated" " Therefore for P2MP, a node MUST support Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and SHOULD NOT be included in an Echo Request message" Does this mean that the p2mp ingress node can still receive Downstream Ma= pping TLV? If so should the ingress process it? Or is it that the responding node MUST reply back with DDMT? [Shaleen Saxena (ssaxena): ] In general, if a node receives DSMAP TLV, it s= hould not respond with DDMAP. That is, in general, a node must respond with= the same TLV. So DSMAP in echo request will cause DSMAP TLV to be returned= . Similarly DDMAP in echo request will cause DDMAP to be returned. However, for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence DDMA= P SHOULD be used for traceroute. If an ingress node still sends DSMAP then = the responding node can ignore it. The responding node should not convert a= DSMAP into DDMAP. Then the wording needs to reflect this. Currently, the choice of SHOULD i= n this case leaves the implementer the choice - irrespective of whether the implementation rec= eives a DSMAP or a DDMAP echo request - of always returning a DSMAP echo response (if the= re is a good reason to do so - where a good reason needs to be explained, or it defaults= to "I felt like doing it that way"). The wording needs to make what you say above explicit by - = for example - saying that a DDMAP TLV MUST be sent in response to a DDMAP TLV in an echo request= . 3. Section 7.2 New TLV's refers to Section 3.2.4 which doesn't exist. [Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and simil= arly 3.2.5 should change to 3.3. It would also help if the name of the TLV were consistent in usage. 4. Say A is ingress and D and F are 2 egresses of the p2mp lsp. A ------------ B --------------C --------- D \----------------E ---------- F When A sends a echo request with TTL 1, B replies back with 2 instances of = DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. 4.1 How does A distinguish whether the BC and BE are ECMP paths or path fo= r 2 different egresses? [Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP TL= V imply two separate outgoing paths. 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basic= ally how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is pa= rt of only D and E is part of only F. [Shaleen Saxena (ssaxena): ] Node A will have to build the topology step by= step. For each TTL, node A will figure out the routers at that level. By c= ontinuing the process, node A will have the complete topology. 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain bo= th the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be mul= ticast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indenti= fier TLV. [Shaleen Saxena (ssaxena): ] If there is no Responder Identifier TLV, then = interface validation will have to be skipped. For the reasons you mention, = it is not possible for node A to combine all the incoming DDMAP into one si= ngle outgoing DDMAP. Hence, if no Responder Identifier TLV, is present, the= n node A will have to use the wildcard DDMAP always. If Egress Address Responder Identifier TLV is being used for traceroute, t= hen it is possible to reuse the incoming DDMAP. 4.4 Do we need B to send back more information such as the egress to which = the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path = to multiple egress? May be adding a egress address in DDMT will solve these? Or is it that= it is taken care in some other ways. [Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware of = the downstream addresses. However for mLDP Tree, a midpoint node will not k= now the egress address. So it is not always feasible to send egress informa= tion. Even in P2MP RSVP TE tree, the scaling must be considered. Each outgo= ing interface can have hundreds of egress nodes. This is especially true fo= r nodes near the head. So creating an OAM packet with this much information= and parsing it will create large processing power for both the responding= and initiating nodes. Also, there is no ECMP in P2MP trees. Thanks, Shaleen --_000_C0AC8FAB6849AB4FADACCC70A949E2F104337CF2E6EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Shaleen,
 
  &n= bsp; Please see in-line=20 below...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Shaleen Saxena=20 (ssaxena)
Sent: Wednesday, January 13, 2010 12:37 PM
To:=20 Ashwin C. Prabhu; mpls@ietf.org
Subject: Re: [mpls] I-D=20 Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hi=20 Ashwin,

 

I=20 could not get to this yesterday. My answers are inline.

 

 

1. In the page 8 it is mentioned that

   "The transit LSR also returns inform= ation=20 on an echo response that helps verify the control plane against the data=20 plane.  That

   is, the information is used by the=20 ingress to check that the data plane forwarding, matches w= hat=20 is signaled by the control plane"

 

  The ingress referes to what? The ingress lsr or= the=20 ingress interface of the transit lsr? Its not very clear from the above=20 statement.

   I think it should be ingress=20 interface?

 

[Shaleen=20 Saxena (ssaxena): ] This section comes from the version 0 of the draft. The= =20 original intent was to verify forwarding from one hop to next. I think=20 paragraphs needs to be updated as follows:

 

 =20 In "traceroute" mode (fault isolation), the echo request is sent=20 to

 =20 the control plane at each transit LSR, and the control plane=20 checks

 =20 that it is indeed a transit LSR for this P2MP MPLS LSP.  The=20 transit

  =20  LSR returns information about the outgoing paths.=20 This

  =20  information can be used by ingress router to build topology or=20

   =20 downstream routers to do extra verification.

 

Please=20 note that the motivation section gives a high level overview of the design = goals=20 and not the actual implementation. 

 

Since this is = an LSP=20 Ping technique, the ingress in question MUST be an LSR, not a=20 router. 

 

 

2. Section 3.5 page 15 of the draft=20 sates

   "Downstream Detailed Mapping TLV is= =20 described in [DDMT].  A transit,
  branch or bud node = can=20 use the Downstream Detailed Mapping TLV to
  return multip= le=20 Return Codes" ...

  "As per Section 4.3 of [DDMT], the Downstr= eam=20 Mapping TLV as described in
  [RFC4379] is being=20 deprecated"

"  Therefore for P2MP, a node MUST support Downst= ream=20 Detailed Mapping
  TLV.  The Downstream Mapping TLV [RFC4379] = is=20 not appropriate for P2MP
  traceroute functionality and SHOULD NOT = be=20 included in an Echo Request
  message"

  

  Does this mean that the p2mp ingress node = can=20 still receive Downstream Mapping TLV? If so should the ingress process=20 it?

  Or is it that the responding node MUST reply ba= ck with=20 DDMT?

 

[Shaleen=20 Saxena (ssaxena): ] In general, if a node receives DSMAP TLV, it should not= =20 respond with DDMAP. That is, in general, a node must respond with the same = TLV.=20 So DSMAP in echo request will cause DSMAP TLV to be returned. Similarly DDM= AP in=20 echo request will cause DDMAP to be returned.

 

However,=20 for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence DDMAP SHOULD = be=20 used for traceroute. If an ingress node still sends DSMAP then the respondi= ng=20 node can ignore it. The responding node should not convert a DSMAP into=20 DDMAP.

 

 Then= the wording=20 needs to reflect this.  Currently, the choice of SHOULD in this case l= eaves=20
the implementer the choice - irrespective of whether the implementation= =20 receives a DSMAP

or a= DDMAP echo=20 request - of always returning a DSMAP echo response (if there is a=20 good

reas= on to do so -=20 where a good reason needs to be explained, or it defaults to "I felt like=20 doing

it t= hat=20 way").  The wording need= s to make=20 what you say above explicit by - for example -=20 saying

that= a DDMAP TLV=20 MUST be sent in response to a DDMAP TLV in an=20 echo request.

 

3.  Section 7.2 New TLV's refers to Section 3.2.4= which=20 doesn't exist.

 

[Shaleen=20 Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and similarly 3.2.= 5=20 should change to 3.3. 

 

It would also= =20 help if the name of the TLV were consistent in=20 usage. 

 

4.  

    Say   A is ingress and D = and F=20 are 2 egresses of the p2mp lsp.

 

         &nb= sp; =20 A ------------ B --------------C --------- D 

         &nb= sp;            =        =20 \----------------E ---------- F

 

When A sends a echo request with TTL 1, B replies back= with 2=20 instances of DDMT depicitng interface BC and BE.

Now at node A we know that there are 2 outgoing links = to=20 egress.

 

 4.1 How does A distinguish whether the BC and BE= are=20 ECMP paths or path for 2 different egresses?

 

[Shaleen=20 Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP TLV imply t= wo=20 separate outgoing paths.

 

 

 4.2 How does node A, corelate the links BC and B= E to=20 egress D or F? (Basically how does the topology formed at=20 ingress)

       In the above topo= logy, B=20 is transit for both C & E, where as C is part of only D and E is part o= f=20 only F.

[Shaleen=20 Saxena (ssaxena): ] Node A will have to build the topology step by step. Fo= r=20 each TTL, node A will figure out the routers at that level. By continuing t= he=20 process, node A will have the complete topology.<= /P>

 

 

 4.3 How should the node A's next mpls echo reque= st (TTL=20 2) look like?

      If A is adding the DDMT= in its=20 echo Request then should it contain both the links received BC and=20 BE?

      If so, then how does C = or E=20 verify which link is upstream?

     The draft mentions in some pl= ace=20 that the interface address can be multicast address. But with this way we w= ill=20 be skipping

      the interface validatio= n=20 altogether.

     I am considering the fact tha= t we=20 are not adding the Responder Indentifier TLV.

[Shaleen=20 Saxena (ssaxena): ] If there is no Responder Identifier TLV, then interface= =20 validation will have to be skipped. For the reasons you mention, it is not= =20 possible for node A to combine all the incoming DDMAP into one single outgo= ing=20 DDMAP. Hence, if no Responder Identifier TLV, is present, then node A will = have=20 to use the wildcard DDMAP always.

 

If=20 Egress Address Responder Identifier TLV  is being used for traceroute,= then=20 it is possible to reuse the incoming DDMAP.

 

 

    

4.4 Do we need B to send back more information such as= the=20 egress to which the downstream link is being added.

      Also do we need B to=20 differentiate between a ECMP path with the path to multiple egress?=20

     May be adding a egress addres= s in=20 DDMT will solve these? Or is it that it is taken care in some other=20 ways.

 

[Shaleen=20 Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware of the downs= tream=20 addresses. However for mLDP Tree, a midpoint node will not know the egress= =20 address. So it is not always feasible to send egress information. Even in P= 2MP=20 RSVP TE tree, the scaling must be considered. Each outgoing interface can h= ave=20 hundreds of egress nodes. This is especially true for nodes near the head. = So=20 creating an OAM packet with this much information and parsing it  will= =20 create large processing power for both the responding and initiating=20 nodes.

 

Also,=20 there is no ECMP in P2MP trees.

 

Thanks,

Shaleen

--_000_C0AC8FAB6849AB4FADACCC70A949E2F104337CF2E6EUSAACMS0701e_-- From bao.yuanlin@zte.com.cn Thu Jan 14 16:47:22 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B423A6A0C; Thu, 14 Jan 2010 16:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 suGSl6UoMF43; Thu, 14 Jan 2010 16:47:21 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C18C73A6878; Thu, 14 Jan 2010 16:47:11 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111644429685300; Fri, 15 Jan 2010 08:13:30 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.4803937422; Fri, 15 Jan 2010 08:47:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o0F0l1a1018238; Fri, 15 Jan 2010 08:47:01 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: <4B4DFC51.8050301@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Fri, 15 Jan 2010 08:48:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-15 08:47:00, Serialize complete at 2010-01-15 08:47:00 Content-Type: multipart/alternative; boundary="=_alternative 00044C4B482576AC_=" X-MAIL: mse1.zte.com.cn o0F0l1a1018238 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, ccamp-bounces@ietf.org, mpls-tp@ietf.org Subject: [mpls] =?gb2312?b?tPC4tDogW0NDQU1QXSBwb2xsIG9uIG1ha2luZyBkcmFm?= =?gb2312?b?dC13ZWluZ2FydGVuLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24gYW4gbXBs?= =?gb2312?b?cyB3ZyBkb2N1bWVudA==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:47:22 -0000 This is a multipart message in MIME format. --=_alternative 00044C4B482576AC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzIHN1cHBvcnQNCg0KDQoNCg0KWXVhbmxpbiBCYW8NClpURSBDb3Jwb3JhdGlvbg0KDQoNCg0K DQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGll dGYub3JnDQoyMDEwLTAxLTE0IDAxOjAxDQoNCsrVvP7Iyw0KbXBscy10cEBpZXRmLm9yZywgbXBs c0BpZXRmLm9yZywgY2NhbXBAaWV0Zi5vcmcsIHB3ZTNAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0K W0NDQU1QXSBwb2xsIG9uIG1ha2luZyBkcmFmdC13ZWluZ2FydGVuLW1wbHMtdHAtbGluZWFyLXBy b3RlY3Rpb24gYW4gbXBscyANCndnIGRvY3VtZW50DQoNCg0KDQoNCg0KDQpBbGwsDQoNCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZw0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC13ZWluZ2FydGVuLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tMDUN Cg0KYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpTZW5kIGEgbWFpbCB0byB0aGUg bXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsDQppbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIg b3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4NCg0KQ29tbWVudHMgb24gdGhlIGNvbnRlbnQgb2YgdGhl IGRyYWZ0IHNob3VsZCBiZSBzZW50IHRvIHRoZSBzYW1lDQptYWlsaW5nIGxpc3Qgd2l0aCBhIGRp ZmZlcmVudCBzdWJqZWN0IGxpbmUuDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgaXMgYSBjb25zY2lv dXMgZGVjaXNpb24gYnkgdGhlIHdnIGNoYWlyIHRvIHBvbGwNCnRoZSBsaW5lYXItcHJvdGVjdGlv biBkb2N1bWVudCBwcmlvciB0byB0aGUgcmluZy1wcm90ZWN0aW9uDQpkb2N1bWVudCwgc2luY2Ug d2Ugd2FudCB0byBtYWtlIHJvb20gZm9yIHNlcGFyYXRlZCBkaXNjdXNzaW9ucyBvbg0KdGhlIHR3 byBkb2N1bWVudHMuDQoNClRoZSBwb2xsIGVuZHMgRnJpZGF5IGp1YW51YXJ5IDI5LCAyMDEwLg0K DQovTG9hDQotLSANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQo= --=_alternative 00044C4B482576AC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcyBzdXBwb3J0PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5ZdWFubGluIEJhbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ WlRFIENvcnBvcmF0aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+TG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAt MDEtMTQgMDE6MDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+bXBscy10cEBpZXRmLm9yZywgbXBsc0BpZXRmLm9yZywgY2NhbXBAaWV0Zi5v cmcsDQpwd2UzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5bQ0NBTVBdIHBvbGwgb24gbWFraW5nIGRyYWZ0LXdlaW5nYXJ0 ZW4tbXBscy10cC1saW5lYXItcHJvdGVjdGlvbg0KYW4gbXBscyB3ZyBkb2N1bWVudDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QWxsLDxi cj4NCjxicj4NCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZzxicj4N Cjxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10 cC1saW5lYXItcHJvdGVjdGlvbi0wNTxicj4NCjxicj4NCmFuIE1QTFMgd29ya2luZyBncm91cCBk b2N1bWVudC48YnI+DQo8YnI+DQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBt YWlsaW5nIGxpc3QsPGJyPg0KaW5kaWNhdGluZyAmcXVvdDt5ZXMvc3VwcG9ydCZxdW90OyBvciAm cXVvdDtuby9kbyBub3Qgc3VwcG9ydCZxdW90Oy48YnI+DQo8YnI+DQpDb21tZW50cyBvbiB0aGUg Y29udGVudCBvZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWU8YnI+DQptYWls aW5nIGxpc3Qgd2l0aCBhIGRpZmZlcmVudCBzdWJqZWN0IGxpbmUuPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBpcyBhIGNvbnNjaW91cyBkZWNpc2lvbiBieSB0aGUgd2cgY2hhaXIgdG8g cG9sbDxicj4NCnRoZSBsaW5lYXItcHJvdGVjdGlvbiBkb2N1bWVudCBwcmlvciB0byB0aGUgcmlu Zy1wcm90ZWN0aW9uPGJyPg0KZG9jdW1lbnQsIHNpbmNlIHdlIHdhbnQgdG8gbWFrZSByb29tIGZv ciBzZXBhcmF0ZWQgZGlzY3Vzc2lvbnMgb248YnI+DQp0aGUgdHdvIGRvY3VtZW50cy48YnI+DQo8 YnI+DQpUaGUgcG9sbCBlbmRzIEZyaWRheSBqdWFudWFyeSAyOSwgMjAxMC48YnI+DQo8YnI+DQov TG9hPGJyPg0KLS0gPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00044C4B482576AC_=-- From RKunze@telekom.de Fri Jan 15 01:24:41 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09F43A6959 for ; Fri, 15 Jan 2010 01:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rt7nlXu4RKKa for ; Fri, 15 Jan 2010 01:24:41 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 769133A693A for ; Fri, 15 Jan 2010 01:24:39 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 15 Jan 2010 10:24:21 +0100 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 10:24:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA95C4.82B94021" Date: Fri, 15 Jan 2010 10:24:15 +0100 Message-ID: <1064ACAB129E654386C2FDEFADC51F3A019BE1BC@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <4E816EC104822245BA3C86149A7158150C12B732@USDALSMBS01.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-bishnoi-mpls-ldp-node-group-00 Thread-Index: AcqO2i+Pjz6wzWGdQMe/jtlDaD4XOQFqpxyQAEwhQoA= References: <1064ACAB129E654386C2FDEFADC51F3A01917C7D@S4DE9JSAANL.ost.t-com.de> <4E816EC104822245BA3C86149A7158150C12B732@USDALSMBS01.ad3.ad.alcatel.com> From: To: X-OriginalArrivalTime: 15 Jan 2010 09:24:20.0615 (UTC) FILETIME=[84B65170:01CA95C4] Subject: Re: [mpls] draft-bishnoi-mpls-ldp-node-group-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 09:24:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA95C4.82B94021 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sandeep, =20 i completely understand your intention and i suppose we have the same = situation in our network, where we use ECMP paths and have the need to = use a preferred path for a special kind of traffic. On the other side i have little concerns regarding the = "constraint-extensions" of LDP. IETF decided to use RSVP-TE instead of = LDP (CR-LDP) for constraint-based routing. Anyway, this approach could = be useful for us in a special case. I suggest to have a short discussion = on the next IETF. =20 Best regards =20 R=FCdiger =20 ------_=_NextPart_001_01CA95C4.82B94021 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bishnoi-mpls-ldp-node-group-00
Hi Sandeep,
 
i completely understand your = intention and=20 i suppose we have the same situation in our network, where we use = ECMP=20 paths and have the need to use a preferred path for = a=20 special kind of traffic.
On the other side i have little concerns = regarding the=20 "constraint-extensions" of LDP. IETF decided to use RSVP-TE instead of = LDP=20 (CR-LDP) for constraint-based routing. Anyway, this approach could = be=20 useful for us in a special case. I suggest to = have a short=20 discussion on the next IETF.
 
Best regards
 
R=FCdiger
 

------_=_NextPart_001_01CA95C4.82B94021-- From prabhu.ashwin@gmail.com Fri Jan 15 03:06:49 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA333A6883 for ; Fri, 15 Jan 2010 03:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 nufcc16cKF1d for ; Fri, 15 Jan 2010 03:06:48 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 501583A6774 for ; Fri, 15 Jan 2010 03:06:48 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 5so145129qwd.31 for ; Fri, 15 Jan 2010 03:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lUDZD16xd4Y168ktMyJPB5I6mIz2EPJEWhBKcif4kOk=; b=wvpTulnA1pmFidAOXfHr35MST66syUcEfkJyOD1ZtHo1VRQc+7mo/3Df2CTPqieSbL xsMKq8zbr8P0KPqydtLC35zaJO/i0sF+i/gX85Jft7UlmLcaO3orTzkO9wI9z5cjQx9r 2Fksf5vHzFzraSQvJMCp2LUQLThKow93Dyb3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bWf4sHtfvP8ST38AAowQbdBa7eJxS062/LL4qqe1UTPzmTtEkfroiwcz+VNjdr4RSU f7opYltU7p2kHmOg6f0Xs+1eEQNim5Wd2pXrRfxDYutoMUfJRMZsKDzJCRU7x5B1MfVN OCLT+X9GA/faMHqe8XimdAux44F3wIMya+Pd0= MIME-Version: 1.0 Received: by 10.220.126.155 with SMTP id c27mr1861269vcs.94.1263553602029; Fri, 15 Jan 2010 03:06:42 -0800 (PST) In-Reply-To: References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> Date: Fri, 15 Jan 2010 16:36:41 +0530 Message-ID: <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> From: "Ashwin C. Prabhu" To: Eric Gray Content-Type: multipart/alternative; boundary=0016369209b29a8a69047d31ff4b Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 11:06:49 -0000 --0016369209b29a8a69047d31ff4b Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks to Nitin, Shaleen and Eric for the replies and helping with my queries. I understand that the number of nodes could be very large and clubbing multiple DDMT instances in to single reply might increase the message size. Tracing node at a time may be time consuming, atlest in the error cases. I think the draft should have provision of clubbing multiple DDMT instances and it is left to implementor as how they make use of this and solve the problem of large messages. This will be atleast useful in tracing the tree where the tree has bigger depth rather than the breadth. If the mLDP doesn't know the egress at the transit then can we add the incoming_interface address so that the ingress knows where to link it to? Instead of depending on co relating the routerID and the interface address. Thanks Ashwin --0016369209b29a8a69047d31ff4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
Thanks to Nitin, Shaleen and Eric for the replies and helping with my = queries.
=A0
I understand that the number of nodes could be very large and clubbing= multiple DDMT instances in to single reply might increase the message size= .
Tracing node at a time may be time consuming, atlest in the error case= s.
I think the draft should have provision of clubbing multiple DDMT inst= ances and it is left to implementor as how they make use of this and solve = the
problem of large messages. This will be atleast useful in tracing the = tree where the tree has bigger depth rather than the breadth.
=A0
If the mLDP doesn't know the egress at the transit then can we add= the incoming_interface address so that the ingress knows where to link it = to? Instead of depending on co relating the routerID and the interface addr= ess.
=A0
=A0
Thanks
Ashwin
=A0
--0016369209b29a8a69047d31ff4b-- From wangdongflower@163.com Fri Jan 15 06:46:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A2228C0E2 for ; Fri, 15 Jan 2010 06:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.056 X-Spam-Level: ** X-Spam-Status: No, score=2.056 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_40=-0.185, HTML_MESSAGE=0.001, RELAY_IS_220=2.118] 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 TshbGWggczE5 for ; Fri, 15 Jan 2010 06:46:22 -0800 (PST) Received: from m13-155.163.com (m13-155.163.com [220.181.13.155]) by core3.amsl.com (Postfix) with ESMTP id A54CB3A68A3 for ; Fri, 15 Jan 2010 06:46:21 -0800 (PST) Received: from wangdongflower ( [222.197.180.236] ) by ajax-webmail-wmsvr155 (Coremail) ; Fri, 15 Jan 2010 22:46:14 +0800 (CST) Date: Fri, 15 Jan 2010 22:46:14 +0800 (CST) From: wangdongflower To: mpls@ietf.org Message-ID: <564235395.355301263566774252.JavaMail.coremail@app155.163.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_92583_1061317511.1263566774252" X-Originating-IP: [222.197.180.236] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 100106(9642.2839.2837) Copyright (c) 2002-2010 www.mailtech.cn 163com X-CM-CTRLDATA: wxoBo2Zvb3Rlcl9odG09MTA4NDo0NA== X-CM-TRANSID: m8GowKCb9gC3f1BLAAAAAA--.916W X-CM-SenderInfo: pzdqwvhrqjwzhrzh2qqrwthudrp/1tbiMBpZFUiNXW3xlAAAs2 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Mailman-Approved-At: Fri, 15 Jan 2010 08:59:29 -0800 Cc: =?gbk?B?xe3UxrflwM/Kpg==?= Subject: [mpls] I-D ACTION:draft-wang-mpls-rsvp-te-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:46:23 -0000 ------=_Part_92583_1061317511.1263566774252 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit Hi All, I have post a new I-D for the mpls working group, Title : Extension to RSVP-TE for signaling control of dynamic Hose-based VPN Filename : draft-wang-mpls-rsvp-te-00.txt This document describes the extension to resource reservation protocol-traffic engineering for signaling control of dynamic Hose- based VPN. The signaling procedure is used to achieve dynamic revision of hose interface. This document proposes a new Hose-Notify message and a series of signaling procedure for extension of RSVP-TE to achieve this function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-mpls-rsvp-te-00.txt Thank you for your attention! Sincerely, Dong Wang ------=_Part_92583_1061317511.1263566774252 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: 7bit
Hi All,
    I have post a new I-D for the mpls working group,
   Title : Extension to RSVP-TE for signaling control of dynamic Hose-based VPN
    Filename : draft-wang-mpls-rsvp-te-00.txt
 
   This document describes the extension to resource reservation
   protocol-traffic engineering for signaling control of dynamic Hose-
   based VPN.  The signaling procedure is used to achieve dynamic
   revision of hose interface.  This document proposes a new Hose-Notify
   message and a series of signaling procedure for extension of RSVP-TE
   to achieve this function.
    A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wang-mpls-rsvp-te-00.txt
 Thank you for your attention!
  Sincerely,
  Dong Wang


------=_Part_92583_1061317511.1263566774252-- From ssaxena@cisco.com Fri Jan 15 10:38:32 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D481D3A67B2 for ; Fri, 15 Jan 2010 10:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 SSG6hjNlg11a for ; Fri, 15 Jan 2010 10:38:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A9A883A67EE for ; Fri, 15 Jan 2010 10:38:26 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FANdEUEtAZnwN/2dsb2JhbACCFcMYlROEMQQ X-IronPort-AV: E=Sophos;i="4.49,283,1262563200"; d="scan'208,217";a="80459884" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2010 18:38:23 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.175]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0FIcAlh001295; Fri, 15 Jan 2010 18:38:23 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 12:38:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9611.E99F142A" Date: Fri, 15 Jan 2010 12:38:17 -0600 Message-ID: In-Reply-To: <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqV0tMPpRi5OU1RR8iKXa1eEwSnqwAK4K+w References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Ashwin C. Prabhu" , "Eric Gray" X-OriginalArrivalTime: 15 Jan 2010 18:38:21.0592 (UTC) FILETIME=[E9E0E180:01CA9611] Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 18:38:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9611.E99F142A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashwin: =20 Your first point: Can you explain your clubbing multiple DDMT instances idea a bit more, with some example topology? =20 Your second point: If I understand correctly, you are trying to build the topology by matching the DDMAP information with the next hop information, correct? So a DDMAP has the "Downstream IP Address" and "Downstream Interface Address". Their values are defined in RFC4379: =20 If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address. =20 If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface. =20 =20 So depending on the interface being numbered or unnumbered, you may or may not have the downstream interface address. In that case only the router-id can be matched. So to do an effective match, you need both interface address and router-id. And this is covered by the "Interface and Label Stack TLV" of RFC 4379, section 3.6. You can set the I bit in DS Flag to get this information. =20 Now this will work as long as every LSR in the network can return these values. If a LSR does not return a response or does not return the DDMAP or the downstream one does not return the ILS TLV, then matching won't work. Also I wonder how TE FRR would figure in this picture. If a link is protected via FRR, then will you be able to do correct matching? =20 Regards, Shaleen =20 =20 From: Ashwin C. Prabhu [mailto:prabhu.ashwin@gmail.com]=20 Sent: Friday, January 15, 2010 6:07 AM To: Eric Gray Cc: Shaleen Saxena (ssaxena); mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt =20 Hi,=20 =20 Thanks to Nitin, Shaleen and Eric for the replies and helping with my queries.=20 =20 I understand that the number of nodes could be very large and clubbing multiple DDMT instances in to single reply might increase the message size.=20 Tracing node at a time may be time consuming, atlest in the error cases. I think the draft should have provision of clubbing multiple DDMT instances and it is left to implementor as how they make use of this and solve the=20 problem of large messages. This will be atleast useful in tracing the tree where the tree has bigger depth rather than the breadth.=20 =20 If the mLDP doesn't know the egress at the transit then can we add the incoming_interface address so that the ingress knows where to link it to? Instead of depending on co relating the routerID and the interface address. =20 =20 Thanks Ashwin =20 ------_=_NextPart_001_01CA9611.E99F142A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashwin:

 

Your first point: Can you explain your clubbing multiple = DDMT instances idea a bit more, with some example = topology?

 

Your second point: If I understand correctly, you are = trying to build the topology by matching the DDMAP information with the next hop information, correct? So a DDMAP has the “Downstream IP = Address”  and “Downstream Interface Address”. Their values are defined in = RFC4379:

 

      If the interface to the downstream LSR is numbered, then = the

      Address Type MUST be set to IPv4 or IPv6, the Downstream = IP

      Address MUST be set to either the downstream LSR's Router ID = or

      the interface address of the downstream LSR, and the = Downstream

      Interface Address MUST be set to the downstream LSR's = interface

      address.

 

      If the interface to the downstream LSR is unnumbered, the = Address

      Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream = IP

      Address MUST be the downstream LSR's Router ID, and the = Downstream

      Interface Address MUST be set to the index assigned by = the

      upstream LSR to the interface.

 

 

So depending on the interface being numbered or = unnumbered, you may or may not have the downstream interface address. In that case only = the router-id can be matched. So to do an effective match, you need both = interface address and router-id. And this is covered by the “Interface and = Label Stack TLV” of RFC 4379, section 3.6. You can set the I bit in DS Flag to = get this information.

 

Now this will work as long as every LSR in the network = can return these values. If a LSR does not return a response or does not return the = DDMAP or the downstream one does not return the ILS TLV, then matching = won’t work.  Also I wonder how TE FRR would figure in this picture. If a = link is protected via FRR, then will you be able to do correct = matching?

 

Regards,

Shaleen

 

 

From:= Ashwin C. = Prabhu [mailto:prabhu.ashwin@gmail.com]
Sent: Friday, January 15, 2010 6:07 AM
To: Eric Gray
Cc: Shaleen Saxena (ssaxena); mpls@ietf.org
Subject: Re: [mpls] I-D = Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

 

Hi,

 

Thanks to Nitin, Shaleen and Eric for the replies = and helping with my queries.

 

I understand that the number of nodes could be very = large and clubbing multiple DDMT instances in to single reply might increase = the message size.

Tracing node at a time may be time consuming, = atlest in the error cases.

I think the draft should have provision of clubbing = multiple DDMT instances and it is left to implementor as how they make use of = this and solve the

problem of large messages. This will be atleast = useful in tracing the tree where the tree has bigger depth rather than the = breadth.

 

If the mLDP doesn't know the egress at the transit = then can we add the incoming_interface address so that the ingress knows where to = link it to? Instead of depending on co relating the routerID and the = interface address.

 

 

Thanks

Ashwin

 

------_=_NextPart_001_01CA9611.E99F142A-- From ssaxena@cisco.com Fri Jan 15 10:56:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070573A693F for ; Fri, 15 Jan 2010 10:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Ok3CbAu54U-Z for ; Fri, 15 Jan 2010 10:56:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 54EE03A693B for ; Fri, 15 Jan 2010 10:56:06 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAA9JUEurRN+K/2dsb2JhbACCFcMllRuCOoF3BA X-IronPort-AV: E=Sophos;i="4.49,283,1262563200"; d="scan'208,217";a="133834746" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2010 18:56:03 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0FIu3PM011429; Fri, 15 Jan 2010 18:56:03 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 12:56:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9614.62031934" Date: Fri, 15 Jan 2010 12:56:00 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqTaUpxPPIfHTPwS1SeaqRWJwxNggBAkgQgADKPw3AANwxBEA== References: <20091214221501.72E203A6826@core3.amsl.com><3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Eric Gray" X-OriginalArrivalTime: 15 Jan 2010 18:56:03.0067 (UTC) FILETIME=[62911CB0:01CA9614] Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 18:56:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9614.62031934 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric: =20 1. I will change the paragraph to use LSR. BTW, I researched Ashwin's original comment on the motivation for 'traceroute mode'. That paragraph has survived intact from the version 00 of the draft and seems to be derived from the RFC4379 motivation. To quote RFC4379: =20 In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path =20 =20 The original paragraph in http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-00:=20 =20 In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS TE LSP. The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That is, the information is used by the ingress to check that the data plane forwarding matches what is signaled by the control plane. =20 =20 I can see how the paragraph was derived from RFC4379. I will change it following: =20 In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress LSR to build topology or=20 downstream LSRs to do extra label verification. =20 =20 2. DSMAP versus DDMAP: We have had a lot of discussion on how deprecation of DSMAP should be handled. Initially (version 08) it was set to DDMAP MUST be used, but after feedback from other vendors, authors and the WG chairs, it was decided to use SHOULD. =20 =20 3. Inconsistent naming in 7.2. It was an oversight, I will fix the names. =20 =20 Thanks for the comments. Shaleen =20 =20 =20 From: Eric Gray [mailto:eric.gray@ericsson.com]=20 Sent: Thursday, January 14, 2010 11:35 AM To: Shaleen Saxena (ssaxena) Cc: Ashwin C. Prabhu; mpls@ietf.org Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt =20 Shaleen, =20 Please see in-line below... =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shaleen Saxena (ssaxena) Sent: Wednesday, January 13, 2010 12:37 PM To: Ashwin C. Prabhu; mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Hi Ashwin, =20 I could not get to this yesterday. My answers are inline. =20 =20 1. In the page 8 it is mentioned that "The transit LSR also returns information on an echo response that helps verify the control plane against the data plane. That=20 is, the information is used by the ingress to check that the data plane forwarding, matches what is signaled by the control plane" =20 The ingress referes to what? The ingress lsr or the ingress interface of the transit lsr? Its not very clear from the above statement. I think it should be ingress interface? =20 [Shaleen Saxena (ssaxena): ] This section comes from the version 0 of the draft. The original intent was to verify forwarding from one hop to next. I think paragraphs needs to be updated as follows: =20 In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress router to build topology or=20 downstream routers to do extra verification. =20 Please note that the motivation section gives a high level overview of the design goals and not the actual implementation.=20 =20 Since this is an LSP Ping technique, the ingress in question MUST be an LSR, not a router.=20 =20 =20 2. Section 3.5 page 15 of the draft sates "Downstream Detailed Mapping TLV is described in [DDMT]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes" ... "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in [RFC4379] is being deprecated" " Therefore for P2MP, a node MUST support Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and SHOULD NOT be included in an Echo Request message" =20 Does this mean that the p2mp ingress node can still receive Downstream Mapping TLV? If so should the ingress process it? Or is it that the responding node MUST reply back with DDMT? =20 [Shaleen Saxena (ssaxena): ] In general, if a node receives DSMAP TLV, it should not respond with DDMAP. That is, in general, a node must respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV to be returned. Similarly DDMAP in echo request will cause DDMAP to be returned.=20 =20 However, for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence DDMAP SHOULD be used for traceroute. If an ingress node still sends DSMAP then the responding node can ignore it. The responding node should not convert a DSMAP into DDMAP. =20 Then the wording needs to reflect this. Currently, the choice of SHOULD in this case leaves=20 the implementer the choice - irrespective of whether the implementation receives a DSMAP=20 or a DDMAP echo request - of always returning a DSMAP echo response (if there is a good reason to do so - where a good reason needs to be explained, or it defaults to "I felt like doing it that way"). The wording needs to make what you say above explicit by - for example - saying that a DDMAP TLV MUST be sent in response to a DDMAP TLV in an echorequest. =20 3. Section 7.2 New TLV's refers to Section 3.2.4 which doesn't exist. =20 [Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and similarly 3.2.5 should change to 3.3.=20 =20 It would also help if the name of the TLV were consistent in usage.=20 =20 =20 4. =20 Say A is ingress and D and F are 2 egresses of the p2mp lsp. =20 A ------------ B --------------C --------- D=20 \----------------E ---------- F =20 When A sends a echo request with TTL 1, B replies back with 2 instances of DDMT depicitng interface BC and BE. Now at node A we know that there are 2 outgoing links to egress. =20 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for 2 different egresses? =20 [Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP TLV imply two separate outgoing paths. =20 =20 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress) In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F. [Shaleen Saxena (ssaxena): ] Node A will have to build the topology step by step. For each TTL, node A will figure out the routers at that level. By continuing the process, node A will have the complete topology. =20 =20 4.3 How should the node A's next mpls echo request (TTL 2) look like? If A is adding the DDMT in its echo Request then should it contain both the links received BC and BE? If so, then how does C or E verify which link is upstream? The draft mentions in some place that the interface address can be multicast address. But with this way we will be skipping the interface validation altogether. I am considering the fact that we are not adding the Responder Indentifier TLV.=20 [Shaleen Saxena (ssaxena): ] If there is no Responder Identifier TLV, then interface validation will have to be skipped. For the reasons you mention, it is not possible for node A to combine all the incoming DDMAP into one single outgoing DDMAP. Hence, if no Responder Identifier TLV, is present, then node A will have to use the wildcard DDMAP always. =20 If Egress Address Responder Identifier TLV is being used for traceroute, then it is possible to reuse the incoming DDMAP. =20 =20 =20 4.4 Do we need B to send back more information such as the egress to which the downstream link is being added. Also do we need B to differentiate between a ECMP path with the path to multiple egress?=20 May be adding a egress address in DDMT will solve these? Or is it that it is taken care in some other ways. =20 [Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware of the downstream addresses. However for mLDP Tree, a midpoint node will not know the egress address. So it is not always feasible to send egress information. Even in P2MP RSVP TE tree, the scaling must be considered. Each outgoing interface can have hundreds of egress nodes. This is especially true for nodes near the head. So creating an OAM packet with this much information and parsing it will create large processing power for both the responding and initiating nodes. =20 Also, there is no ECMP in P2MP trees.=20 =20 Thanks, Shaleen ------_=_NextPart_001_01CA9614.62031934 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric:

 

1.       I will change the paragraph to use LSR. BTW, I researched = Ashwin’s original comment on the motivation for ‘traceroute mode’. = That paragraph has survived intact from the version 00 of the draft and seems = to be derived from the RFC4379 motivation. To quote = RFC4379:

 

   In "traceroute" mode (fault

   isolation), the packet is sent to the control plane of each = transit

   LSR, which performs various checks that it is indeed a transit = LSR

   for this path; this LSR also returns further information that = helps

   check the control plane against the data plane, i.e., that = forwarding

   matches what the routing protocols determined as the = path

 

 

       The original = paragraph in http= ://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-00:

 

   In "traceroute" mode (fault isolation), the =
echo request is sent to
   the control =
plane at each transit LSR, and the control plane =
checks
   that it is indeed a transit LSR =
for this P2MP MPLS TE LSP. The
   transit =
LSR also returns information on an echo response that =
helps
   verify the control plane against =
the data plane. That is, the
   =
information is used by the ingress to check that the data =
plane
   forwarding matches what is =
signaled by the control plane.

 

 

I can see how the paragraph was derived from RFC4379. I = will change it following:

 

   In "traceroute" mode (fault isolation), the =
echo request is sent to
   the control =
plane at each transit LSR, and the control plane =
checks
   that it is indeed a transit LSR =
for this P2MP MPLS LSP.  The =
transit
   LSR returns information about =
the outgoing paths. This
   information =
can be used by ingress LSR to build topology or =
   downstream LSRs to do extra =
label verification.

 

 

2.       DSMAP versus DDMAP: We have had a lot of discussion on = how deprecation of DSMAP should be handled. Initially (version 08) it was = set to DDMAP MUST be used, but after feedback from other vendors, authors and = the WG chairs, it was decided to use SHOULD.

 

 

3.       Inconsistent naming in 7.2. It was an oversight, I will = fix the names.

 

 

Thanks for the comments.

Shaleen

 

 

 

From:= Eric Gray [mailto:eric.gray@ericsson.com]
Sent: Thursday, January 14, 2010 11:35 AM
To: Shaleen Saxena (ssaxena)
Cc: Ashwin C. Prabhu; mpls@ietf.org
Subject: RE: [mpls] I-D = Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

 

Shaleen,

 

    Please see in-= line = below...

 


From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shaleen Saxena = (ssaxena)
Sent: Wednesday, January 13, 2010 12:37 PM
To: Ashwin C. Prabhu; mpls@ietf.org
Subject: Re: [mpls] I-D = Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hi Ashwin,

 

I could not get to this yesterday. My answers are = inline.

 

 

1. In the page 8 it is mentioned = that

   "The transit LSR also = returns information on an echo response that helps verify the control plane = against the data plane.  That

   is, the information is used by = the ingress to check that the data plane forwarding, matches what is signaled by the control plane"

 

  The ingress referes to what? The ingress lsr = or the ingress interface of the transit lsr? Its not very clear from the above statement.

   I think it should be ingress = interface?

 

[Shaleen Saxena (ssaxena): ] This section comes from the = version 0 of the draft. The original intent was to verify forwarding from one = hop to next. I think paragraphs needs to be updated as = follows:

 

  In "traceroute" mode (fault isolation), the echo request is sent = to

  the = control plane at each transit LSR, and the control plane = checks

  that it = is indeed a transit LSR for this P2MP MPLS LSP.  The = transit

    LSR returns information about the = outgoing paths. This

    information can be used by ingress = router to build topology or

    downstream routers to do extra = verification.

 

Please note that the motivation section gives a high = level overview of the design goals and not the actual = implementation.&n= bsp;

 

Since this is an LSP Ping technique, the ingress in question = MUST be an LSR, not a router. 

 

 

2. Section 3.5 page 15 of the draft = sates

   "Downstream Detailed Mapping = TLV is described in [DDMT].  A transit,
  branch or bud node can use the Downstream = Detailed Mapping TLV to
  return multiple Return Codes" ...

  "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
  [RFC4379] is being deprecated"

"  Therefore for P2MP, a node MUST = support Downstream Detailed Mapping
  TLV.  The Downstream Mapping TLV [RFC4379] is not = appropriate for P2MP
  traceroute functionality and SHOULD NOT be included in an Echo = Request
  message"

  

  Does this mean that the p2mp ingress = node can still receive Downstream Mapping TLV? If so should the ingress process = it?

  Or is it that the responding node MUST reply = back with DDMT?

 

[Shaleen Saxena (ssaxena): ] In general, if a node = receives DSMAP TLV, it should not respond with DDMAP. That is, in general, a node = must respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV to be returned. Similarly DDMAP in echo request will cause DDMAP to be = returned.

 

However, for P2MP MPLS OAM, DDMAP is a better choice than = DSMAP; hence DDMAP SHOULD be used for traceroute. If an ingress node still = sends DSMAP then the responding node can ignore it. The responding node should not = convert a DSMAP into DDMAP.

 

Then the wording needs to reflect this.  Currently, the = choice of SHOULD in this case leaves
the implementer = the choice - irrespective of whether the implementation receives a DSMAP =

or a DDMAP echo request - of always returning a DSMAP echo = response (if there is a good

reason to do so - where a good reason needs to be explained, = or it defaults to "I felt like doing

it that way"). The wording needs to make what you say = above explicit by - for example - saying

that a DDMAP TLV MUST be sent in response to a DDMAP TLV in = an echorequest.

 

3.  Section 7.2 New TLV's refers to Section = 3.2.4 which doesn't exist.

 

[Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to = just 3.2 and similarly 3.2.5 should change to 3.3.&n= bsp;

 

It would also help if the name of the TLV were = consistent in usage. 

 

 

4.  

    Say   A is ingress and = D and F are 2 egresses of the p2mp lsp.

 

         &= nbsp;  A ------------ B --------------C --------- D 

         &= nbsp;           &n= bsp;        \----------------E ---------- F

 

When A sends a echo request with TTL 1, B replies = back with 2 instances of DDMT depicitng interface BC and BE.

Now at node A we know that there are 2 outgoing = links to egress.

 

 4.1 How does A distinguish whether the BC and = BE are ECMP paths or path for 2 different egresses?

 

[Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP = LSPs. So two DDMAP TLV imply two separate outgoing = paths.

 

 

 4.2 How does node A, corelate the links BC = and BE to egress D or F? (Basically how does the topology formed at = ingress)

       In the above = topology, B is transit for both C & E, where as C is part of only D and E is = part of only F.

[Shaleen Saxena (ssaxena): ] Node A will have to build = the topology step by step. For each TTL, node A will figure out the routers = at that level. By continuing the process, node A will have the complete = topology.

 

 

 4.3 How should the node A's next mpls echo = request (TTL 2) look like?

      If A is adding the = DDMT in its echo Request then should it contain both the links received BC and = BE?

      If so, then how does = C or E verify which link is upstream?

     The draft mentions in some = place that the interface address can be multicast address. But with this way we = will be skipping

      the interface = validation altogether.

     I am considering the fact = that we are not adding the Responder Indentifier TLV.

[Shaleen Saxena (ssaxena): ] If there is no Responder = Identifier TLV, then interface validation will have to be skipped. For the reasons = you mention, it is not possible for node A to combine all the incoming DDMAP = into one single outgoing DDMAP. Hence, if no Responder Identifier TLV, is = present, then node A will have to use the wildcard DDMAP = always.

 

If Egress Address Responder Identifier TLV  is being = used for traceroute, then it is possible to reuse the incoming = DDMAP.

 

 

    

4.4 Do we need B to send back more information such = as the egress to which the downstream link is being added.

      Also do we need B to differentiate between a ECMP path with the path to multiple egress? =

     May be adding a egress = address in DDMT will solve these? Or is it that it is taken care in some other = ways.

 

[Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a = node may be aware of the downstream addresses. However for mLDP Tree, a midpoint = node will not know the egress address. So it is not always feasible to send = egress information. Even in P2MP RSVP TE tree, the scaling must be considered. = Each outgoing interface can have hundreds of egress nodes. This is especially = true for nodes near the head. So creating an OAM packet with this much = information and parsing it  will create large processing power for both the = responding and initiating nodes.

 

Also, there is no ECMP in P2MP trees. =

 

Thanks,

Shaleen

------_=_NextPart_001_01CA9614.62031934-- From gregimirsky@gmail.com Fri Jan 15 14:47:36 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA643A6840 for ; Fri, 15 Jan 2010 14:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PlcpJUzOi6HM for ; Fri, 15 Jan 2010 14:47:35 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id D07663A6809 for ; Fri, 15 Jan 2010 14:47:34 -0800 (PST) Received: by bwz23 with SMTP id 23so699505bwz.29 for ; Fri, 15 Jan 2010 14:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=/fG3Qs12z3aJNAr8W5p5aSrZgdjVc+RycX5MWuefeOU=; b=l+QUskhlNo9+r0R4/58lXJfsFKCbPMqP5ehO+PJIZXkXFFNaTgwBQma+MR3n1wZmBx 95BtFuIueuc8qlCgOaFqu9+Lscxoh69gvusb70xFSNX3UaphcBblZDhxpsPJRekR0kK5 4iSl4M+g5zl3qjHO2KsByOXfm2eTOO5VvnRqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vT46lTQMRPi7bhcdwF2im1+WUSctMxTeab8N4DD4p0JDVzP7C7diVxE69lqwI2tJgs +R+9/v9+r/3QQhx6cFdarGNhr9iLgYFdN9QH51Yk39jj+/Vl200Jo1AwQpsXXwJvcxRb Fc4Hzh1daidzXIaiAT5eMyNDCdrAkQi/4Y01I= MIME-Version: 1.0 Received: by 10.204.32.209 with SMTP id e17mr1676616bkd.84.1263595648380; Fri, 15 Jan 2010 14:47:28 -0800 (PST) Date: Fri, 15 Jan 2010 14:47:28 -0800 Message-ID: <787be2781001151447y5b2e2821vb9a01153230ba9bf@mail.gmail.com> From: Greg Mirsky To: Mach Chen , mpls@ietf.org Content-Type: multipart/alternative; boundary=00032555419ac2f09b047d3bc9e7 Subject: [mpls] Comments to Return Path Specified LSP Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:47:36 -0000 --00032555419ac2f09b047d3bc9e7 Content-Type: text/plain; charset=ISO-8859-1 Dear Mach, please find my comments to draft draft-chen-mpls-return-path-specified-lsp-ping-01.txtbelow: - Section 3.2, p.5 When defining the Length field could mention that "the Length field MUST NOT be zero". - In the last paragraph on p.5 stress that RP TLV can have one or more nested sub-TLVs. "It MUST have one or more nested sub-TLVs that describe the specified paths the echo reply message is required to follow." - Section 3.3.1, p.7 would propose to rename "MUST be zero" in the Flag field into "Reserved" with addition of following wording: "where Reserved MUST be set to 0 on Send and ignored on Receive". - Section 3.3.2, p.8 Use of IPv4 in the first sentence ("The IPv4 RSVP Tunnel sub-TLV ...") in the context of this section looks as typo. - Section 3.3.4 describes Any Candidate sub-TLV as indication of exclusion from consideration by egress LSR of all LSPs. But option 5 in Section 3.3 implies that the Any Candidate sub-TLV can be used in conjunction with sub-TLVs defined in RFC4379 or newly defined, excluding itself of course, to provide explicit list of LSPs to be excluded by the egress LSP from consideration as the return path for LSP Ping. This use scenario can be mentioned in the Section to clarify: "If there is only an Any Candidate sub-TLV included in the echo request (i.e., no other sub-TLVs are present in the RP TLV) ..." description. (This use case is mentioned in Section 4.2 p.11 though). Kind regards, Greg --00032555419ac2f09b047d3bc9e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mach,
please find my comments to draft draft-chen= -mpls-return-path-specified-lsp-ping-01.txt below:
  • Section 3= .2, p.5 When defining the Length field could mention that "the Length = field MUST NOT be zero".
  • In the last paragraph on p.5 stress that RP TLV can have one or more ne= sted sub-TLVs. "It MUST have one or more nested sub-TLVs that describe= the specified paths the echo reply message is required to follow."
  • Section 3.3.1, p.7=A0 would propose to rename "MUST be ze= ro" in the Flag field into "Reserved" with addition of follo= wing wording:
"where Reserv= ed MUST be set to 0 on Send and ignored on Receive".
  • Section 3.3.2, p.8 Use of IPv4 in the first sentence ("T= he IPv4 RSVP Tunnel sub-TLV ...") in the context of this section looks= as typo.
  • Section 3.3.4 describes Any Candidate sub-TLV as indicati= on of exclusion from consideration by egress LSR of all LSPs. But option 5 = in Section 3.3 implies that the Any Candidate sub-TLV can be used in conjun= ction with sub-TLVs defined in RFC4379 or newly defined, excluding itself o= f course, to provide explicit list of LSPs to be excluded by the egress LSP= from consideration as the return path for LSP Ping. This use scenario can = be mentioned in the Section to clarify: "If there is only an Any Candi= date sub-TLV included in the echo request (i.e., no other sub-TLVs are pr= esent in the RP TLV) ..." description. (This use case is mentioned in = Section 4.2 p.11 though).
Kind regards,
Greg


--00032555419ac2f09b047d3bc9e7-- From nnassit@gmail.com Sun Jan 17 07:47:06 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0963A68D4 for ; Sun, 17 Jan 2010 07:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zP1pI4lQmQHF for ; Sun, 17 Jan 2010 07:47:05 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 85C453A6895 for ; Sun, 17 Jan 2010 07:47:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so301911eye.51 for ; Sun, 17 Jan 2010 07:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KC43jIq/c4kRrZfda4kHWnLE9kCuCgR4YfTYYfSbdv0=; b=GKyb6srrPLsIiWj0wSaxGNEnCFKuAuiCpI9DXvQujh3p2wjjOJGH1lim+S71vHB+ju Pveg/djhtZJSUejdrVeQ0NGqMNP7g6/A2F/GHlhSt7WuFGGKuCOAi8fk+71uQRTGF29i lY+cWLevOnQ/WLLJAjKJ5VmZY/1smk7nlDDM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QYsXQqSaT16l6y42cMoPKTR/TtToB+YWBLKNS6bU+t/VffkSwLm8d6nKwVZyntFX+D 8qA9LF1gIH00tjVuJ2Y9xEI7NBjzaroFJ42iW+Sqp3uJ1DRMJMaqTh3xTLAnLpVFxOle WuCV0qlnbZJZjw8ale4Ckcayez54OvRxFeoy8= MIME-Version: 1.0 Received: by 10.213.100.4 with SMTP id w4mr1843391ebn.53.1263743218981; Sun, 17 Jan 2010 07:46:58 -0800 (PST) Date: Sun, 17 Jan 2010 15:46:58 +0000 Message-ID: <95fffc9d1001170746h46d38f68q9f6ccdf2fa9102b0@mail.gmail.com> From: Najat Nassit To: mpls@ietf.org Content-Type: multipart/alternative; boundary=00504502cfa8a79d0d047d5e2503 Subject: [mpls] draft-ietf-l3vpn-2547bis-mcast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 15:47:06 -0000 --00504502cfa8a79d0d047d5e2503 Content-Type: text/plain; charset=ISO-8859-1 hello, there is an implementation for every procedure/protocol specified in this draft???? can you let me know where to find this information? or let me know where i can find the implementations for these protocols and procedures. *i'm searching just a help, not a somebody's work. * thanks. --00504502cfa8a79d0d047d5e2503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hello,

there is an implementation for every procedu= re/protocol specified in this draft???? can you let me know where to find t= his information? or let me know where i can find the implementations for th= ese protocols and procedures.

i'm searching just a help, not a somebody's= work.

thanks.
--00504502cfa8a79d0d047d5e2503-- From mach@huawei.com Sun Jan 17 18:01:48 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A95B3A682A for ; Sun, 17 Jan 2010 18:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 kU+AP6jqe1qR for ; Sun, 17 Jan 2010 18:01:47 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5F7293A67FA for ; Sun, 17 Jan 2010 18:01:47 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWF005NU6YL3I@szxga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jan 2010 10:01:33 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWF00GUJ6YL3Y@szxga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jan 2010 10:01:33 +0800 (CST) Date: Mon, 18 Jan 2010 10:01:31 +0800 From: Mach Chen In-reply-to: <787be2781001151447y5b2e2821vb9a01153230ba9bf@mail.gmail.com> To: Greg Mirsky Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <787be2781001151447y5b2e2821vb9a01153230ba9bf@mail.gmail.com> Cc: mpls@ietf.org Subject: Re: [mpls] Comments to Return Path Specified LSP Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 02:01:48 -0000 Dear Greg, Thanks for your comments! Please see inline... -------------------------------------------------- From: "Greg Mirsky" Sent: Saturday, January 16, 2010 6:47 AM To: "Mach Chen" ; Subject: Comments to Return Path Specified LSP Ping > Dear Mach, > please find my comments to draft > draft-chen-mpls-return-path-specified-lsp-ping-01.txtbelow: > > - Section 3.2, p.5 When defining the Length field could mention that > "the > Length field MUST NOT be zero". > - In the last paragraph on p.5 stress that RP TLV can have one or more > nested sub-TLVs. "It MUST have one or more nested sub-TLVs that describe > the > specified paths the echo reply message is required to follow." Yes, it MUST NOT be zero, will add text for clarification in the next revision. > > > - Section 3.3.1, p.7 would propose to rename "MUST be zero" in the Flag > field into "Reserved" with addition of following wording: > > "where Reserved MUST be set to 0 on Send and ignored on Receive". OK, it's better to change to "Reserved" for new extension, will do that. > > - Section 3.3.2, p.8 Use of IPv4 in the first sentence ("The IPv4 RSVP > Tunnel sub-TLV ...") in the context of this section looks as typo. Yes, it should be IPv6, good catch! > - Section 3.3.4 describes Any Candidate sub-TLV as indication of > exclusion from consideration by egress LSR of all LSPs. But option 5 in > Section 3.3 implies that the Any Candidate sub-TLV can be used in > conjunction with sub-TLVs defined in RFC4379 or newly defined, excluding > itself of course, to provide explicit list of LSPs to be excluded by the > egress LSP from consideration as the return path for LSP Ping. This use > scenario can be mentioned in the Section to clarify: "If there is only > an > Any Candidate sub-TLV included in the echo request (i.e., no other > sub-TLVs > are present in the RP TLV) ..." description. (This use case is mentioned > in > Section 4.2 p.11 though). OK, will clarify this in the next revision. Best regards, Mach From prabhu.ashwin@gmail.com Mon Jan 18 03:02:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEB83A689C for ; Mon, 18 Jan 2010 03:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Xz7U6dF-qf53 for ; Mon, 18 Jan 2010 03:02:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 48AEF3A6836 for ; Mon, 18 Jan 2010 03:02:22 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 5so159768qwd.31 for ; Mon, 18 Jan 2010 03:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l9t3+MEJw7zjFGuHiZzinQAdaAwAWiUQwcTpiAPP/GI=; b=s1W5by0u/CquYG4JQHMnM3BUJr2fZi2gS0H2Q92MvwXDqsmKPumLNta/BULlOwI56L yMBD9IdPwERuSIHPJQRKlaWPrcBJKnrd1Za1V8iYSgyYIg4qsm1ctl1l0MCpYJTONDpF z7k273GO6thU9576bUXPt1TSAw4DzyFV7X2I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rvcmm9FFJ5WAhCa2PSJsq7j8FZnyKR49soWqpv6S/aaWDc6YGSvbPqclxX7wtnS2nQ GbqAGLhEzlMMT8qYeHHoVP9Py4QdkEXrUkigwoE6lVXtKQie1D0MVrIGOMlhGNPVCKpe gWEcq1RxRswqfSvEN9BJcketydpzjOG22HzWk= MIME-Version: 1.0 Received: by 10.220.127.95 with SMTP id f31mr2212111vcs.61.1263812535266; Mon, 18 Jan 2010 03:02:15 -0800 (PST) In-Reply-To: References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> Date: Mon, 18 Jan 2010 16:32:15 +0530 Message-ID: <3c33c551001180302r339d96ddpe65e02d5a551d1@mail.gmail.com> From: "Ashwin C. Prabhu" To: "Shaleen Saxena (ssaxena)" Content-Type: multipart/alternative; boundary=0016369fa1b53a2c93047d6e49f8 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 11:02:23 -0000 --0016369fa1b53a2c93047d6e49f8 Content-Type: text/plain; charset=ISO-8859-1 Hello Shaleen, What i was thinking was, Say if i have following topology and i want to initiate a trace from the ingress node A. A --------------- B --------------C --------- D \----------------E -------------- F--------- G 1. If all the connections are fine then trace might reutrn the o/p fast enough. 2. If Say link BC & CD is down then A will wait for the timeout and tracing AEFG might take long time in node by node tracing. 3. The present parallel tracing skips the interface validation all together. 4. Instead if A can send multiple instance of DDMT then we can as well do the validation of the interface. Say A sends MPLS echo Request with TTL 1. B & E replies back with DDMT In the next iteration A can send MPLS echo Request with TTL 2 with DDMT (From B) with Egress Address TLV D + DDMT (From E) with Egress Address TLV G packed in the single message. Then node C which is in the path to Egress TLV D can validate the BC interface, similary F. As already told by you this might work only for RSVP-TE case? With this approach we can trace the nodes parallely with lesser number of OAM packets alogn with interface validation check. Coming back to the problem of large message size, the configuration/implementation can limit the number of parallel paths it wanted to club it to. Say if we have 10 egresses then we might want to trace 5 paths first and then next 5 paths, by clubbig them together. Let me know if you see any short comings of doing this way. Thanks for answering the other question in my previous mail. Thanks Ashwin --0016369fa1b53a2c93047d6e49f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Shaleen,
=A0
=A0What i was thinking was, Say if i have following topology and i wan= t to initiate a trace from the ingress node A.
=A0=A0=A0=A0=A0=A0=A0 A --------------- B --------------C --------- D<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\----------------E -------------- F-------= -- G
=A0
1. If all the connections are fine then trace might reutrn the o/p fas= t enough.
2. If Say link BC & CD is down then A will wait for the timeout an= d tracing AEFG might take long time in node by node tracing.
3. The present parallel tracing skips the interface validation all tog= ether.
4.
Instead if A can send multiple instance of DDMT then we can as well do= the validation of the interface.
Say
A sends MPLS echo Request with TTL 1.
B & E replies back with DDMT
In the next iteration A can send MPLS echo Request with TTL 2 with
DDMT (From B) with Egress Address TLV=A0D =A0+ DDMT (From E) with Egre= ss Address TLV=A0G packed in the single message.
Then node C which is in the path to Egress TLV D can validate the BC i= nterface, similary F.
As already told by you this might work only for RSVP-TE case?
With this approach=A0we can trace the nodes parallely with lesser numb= er of OAM packets alogn with interface validation check.
Coming back to the problem of large message size, the configuration/im= plementation can limit the number of parallel paths it wanted to club it to= . Say if we have 10 egresses then=A0we might want to trace 5 paths first an= d then next 5 paths, by clubbig them together.=A0
=A0
Let me know if you see any short comings of doing this way.
=A0
Thanks for=A0answering the=A0other question in my previous mail.
=A0
=A0
Thanks
Ashwin
--0016369fa1b53a2c93047d6e49f8-- From wwwrun@core3.amsl.com Mon Jan 18 09:35:13 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AA5533A6908; Mon, 18 Jan 2010 09:35:13 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100118173513.AA5533A6908@core3.amsl.com> Date: Mon, 18 Jan 2010 09:35:13 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS122 - MPLS-TP OAM Framework draft reviewed (ref # 014.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 17:35:13 -0000 Title: LS122 - MPLS-TP OAM Framework draft reviewed (ref # 014.02) Submission Date: 2010-01-18 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=632 Please reply by 2010-04-11 From: Greg Jones(ITU-T SG 15) To: IETF WG MPLS(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: hhelvoort@huawei.com Purpose: For action Body: Attachment(s): LS122 - MPLS-TP OAM Framework draft reviewed (ref # 014.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file749.pdf) From gregimirsky@gmail.com Mon Jan 18 11:44:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7316D3A6817 for ; Mon, 18 Jan 2010 11:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 EhpBQX6hJZDA for ; Mon, 18 Jan 2010 11:44:02 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 68C303A677D for ; Mon, 18 Jan 2010 11:44:02 -0800 (PST) Received: by bwz19 with SMTP id 19so2060059bwz.28 for ; Mon, 18 Jan 2010 11:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=LvxSupm08cddCCiZjtLKTn61Zmy6HwuZKSWvxveXuF0=; b=h+iGeegSTBDoI1r1AIK+zix+E8O6rDBcLYhYQQrtn/Dk+HjcJ8rdDz360w8JwSLKqG drilp+emaFm2/c0Qpj5Y7rdGvp6UnBKUNfTFLn/MJx11lc6VShd+uIpzm3C/jF/bP0UX VbIpi+yacHFvEMnMpiGqnlw/YgyaoILq2EsA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xKVfuk8xJLliVo2zOk3H4xykUNnjUc13f/0nNP0SXDwvJaGXCWqsicXR10nqO128+g eCsEvngICXmTMzWSm6a3OsKIjkKvNMLl740006dA8jHfLpLk2rl1miooZAUOYH44L1Mv F8EXJ/wNwpXsiu8OsUu4BGvU0OrmkxsrHR190= MIME-Version: 1.0 Received: by 10.204.11.11 with SMTP id r11mr1052782bkr.12.1263843834586; Mon, 18 Jan 2010 11:43:54 -0800 (PST) Date: Mon, 18 Jan 2010 11:43:54 -0800 Message-ID: <787be2781001181143o791e9debtf2bbbd0dfc38b6a3@mail.gmail.com> From: Greg Mirsky To: kireeti@juniper.net, swallow@cisco.com Content-Type: multipart/alternative; boundary=00032555fd56cfe6e4047d759267 Cc: mpls@ietf.org Subject: [mpls] RFC 4379: Calculating Length of a TLV in presence of sub-TLV's X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 19:44:03 -0000 --00032555fd56cfe6e4047d759267 Content-Type: text/plain; charset=ISO-8859-1 Dear Kireeti and George, I've got a question on proper calculation of a Length value for a TLV that consists of more than one sub-TLV. On p.9 on RFC 4379 second drawing depicts format of a Target Stack FEC TLV with two sub-TLVs. The length in TLV displayed as 12 and I believe this is not correct. As the Legth must reflect length of the Value field of a TLV (all encompassed sub-TLVs), in this case it is equal to 29 (3 bytes of padding appended). My apologies if this was answered before (couldn't find reference in the archive). Regards, Greg --00032555fd56cfe6e4047d759267 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Kireeti and George,
I've got a question on proper calculation o= f a Length value for a TLV that consists of more than one sub-TLV.
On p= .9 on RFC 4379 second drawing depicts format of a Target Stack FEC TLV with= two sub-TLVs. The length in TLV displayed as 12 and I believe this is not = correct. As the Legth must reflect length of the Value field of a TLV (all = encompassed sub-TLVs), in this case it is equal to 29 (3 bytes of padding a= ppended).
My apologies if this was answered before (couldn't find reference in th= e archive).

Regards,
Greg
--00032555fd56cfe6e4047d759267-- From david.charlap@ericsson.com Mon Jan 18 12:45:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088293A687A for ; Mon, 18 Jan 2010 12:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 qcyiFbTVWzAU for ; Mon, 18 Jan 2010 12:45:14 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B6E393A68FB for ; Mon, 18 Jan 2010 12:45:13 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o0IKjatb027129 for ; Mon, 18 Jan 2010 14:45:36 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 18 Jan 2010 15:45:09 -0500 From: David Charlap To: IETF MPLS List Date: Mon, 18 Jan 2010 15:45:08 -0500 Thread-Topic: Questrion Re: MPLS originating forwarding behavior Thread-Index: AcqYfx77xNRFGFJJQhOXP7IhyK/T5w== Message-ID: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8E@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8EEUSAACMS0701e_" MIME-Version: 1.0 Subject: [mpls] Questrion Re: MPLS originating forwarding behavior X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:45:16 -0000 --_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8EEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the correct behavior for an MPLS forwarder under this situation: - An unlabeled packet arrives on interface X - The packet matches a FEC that has an associated originating LSP - The egress interface for the LSP (its outsegment) is interface X Is this a case of a forwarding loop, where the packet should be dropped? I= n a non-MPLS situation where the route table's next-hop is the same interfa= ce the packet arrived on, it would clearly be considered a loop and the pac= ket would be dropped, but I'm not so certain about this behavior in the MPL= S world. I'm thinking that in the MPLS case (labeled packet leaves on the same inter= face the unlabeled packet arrived on), it's not really a loop, because the = next-hop node isn't necessarily going to forward the packet back, the way i= t would in a classical IP-forwarding scenario. In the case of an LDP netwo= rk, it would be the case, because labels there follow the route table, but = in the case of RSVP-TE or provisioned LSPs, that labeled packet may not nec= essarily be in a loop, therefore the forwarder should forward the packet ac= cording to the NHLFE, without regard to the interface it arrived on. Does this sound right? -- David --_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8EEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What is t= he correct=20 behavior for an MPLS forwarder under this situation:
 
- An unla= beled=20 packet arrives on interface X
- The pac= ket matches=20 a FEC that has an associated originating LSP
- The egr= ess=20 interface for the LSP (its outsegment) is interface X
 
Is this a= case of a=20 forwarding loop, where the packet should be dropped?  In a non-MPLS=20 situation where the route table's next-hop is the same interface the packet= =20 arrived on, it would clearly be considered a loop and the packet would be=20 dropped, but I'm not so certain about this behavior in the MPLS=20 world.
 
I'm think= ing that in=20 the MPLS case (labeled packet leaves on the same interface the unlabeled pa= cket=20 arrived on), it's not really a loop, because the next-hop node isn't necess= arily=20 going to forward the packet back, the way it would in a classical IP-forwar= ding=20 scenario.  In the case of an LDP network, it would be the case, becaus= e=20 labels there follow the route table, but in the case of RSVP-TE or provisio= ned=20 LSPs, that labeled packet may not necessarily be in a loop, therefore the=20 forwarder should forward the packet according to the NHLFE, without regard = to=20 the interface it arrived on.
 
Does this= sound=20 right?
 
--=20 David
 
--_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8EEUSAACMS0701e_-- From rbonica@juniper.net Mon Jan 18 13:13:23 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99733A67F2 for ; Mon, 18 Jan 2010 13:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OtCKv3nGGPx5 for ; Mon, 18 Jan 2010 13:13:18 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 4CB633A67BD for ; Mon, 18 Jan 2010 13:13:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS1TO4EACcvvF42rtMu2Dykmy07HL1l4J@postini.com; Mon, 18 Jan 2010 13:13:13 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 18 Jan 2010 13:11:51 -0800 Received: from [172.28.134.25] (172.28.134.25) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 18 Jan 2010 16:11:50 -0500 Message-ID: <4B54CE96.4080002@juniper.net> Date: Mon, 18 Jan 2010 16:11:50 -0500 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Charlap References: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8E@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0246013C8E@EUSAACMS0701.eamcs.ericsson.se> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: IETF MPLS List Subject: Re: [mpls] Questrion Re: MPLS originating forwarding behavior X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:13:23 -0000 David, It is not a loop. In fact, there are many good reasons to do what you describe. The following is an example: A---B---C---D <--LSP-- Nodes A, B, C, and D are connected in series, as depicted above. An MPLS LSP connects Node D to Node B. Node D tells Node C about its route to Node A through the LSP. However, Node B does not tell Node C about its direct route to Node A. So, Node C's only route to Node A is through Node D and the LSP. When Node C receives the MPLS encapsulated packet from Node D, it forwards it to NODE B (based on the MPLS label) not Node D (based on the IP header). So, there is no loop. Ron David Charlap wrote: > What is the correct behavior for an MPLS forwarder under this situation: > > - An unlabeled packet arrives on interface X > - The packet matches a FEC that has an associated originating LSP > - The egress interface for the LSP (its outsegment) is interface X > > Is this a case of a forwarding loop, where the packet should be dropped? In a non-MPLS situation where the route table's next-hop is the same interface the packet arrived on, it would clearly be considered a loop and the packet would be dropped, but I'm not so certain about this behavior in the MPLS world. > > I'm thinking that in the MPLS case (labeled packet leaves on the same interface the unlabeled packet arrived on), it's not really a loop, because the next-hop node isn't necessarily going to forward the packet back, the way it would in a classical IP-forwarding scenario. In the case of an LDP network, it would be the case, because labels there follow the route table, but in the case of RSVP-TE or provisioned LSPs, that labeled packet may not necessarily be in a loop, therefore the forwarder should forward the packet according to the NHLFE, without regard to the interface it arrived on. > > Does this sound right? > > -- David > > From root@core3.amsl.com Mon Jan 18 15:45:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5F63C3A68E8; Mon, 18 Jan 2010 15:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100118234501.5F63C3A68E8@core3.amsl.com> Date: Mon, 18 Jan 2010 15:45:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mldp-in-band-signaling-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 23:45:01 -0000 --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 : mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths Author(s) : I. Wijnands, et al. Filename : draft-ietf-mpls-mldp-in-band-signaling-00.txt Pages : 13 Date : 2010-01-18 When an IP multicast tree needs to pass through an MPLS domain, it is advantageous to map the tree to a Point-to-Multipoint or Multipoint- to-Multipoint Label Switched Path. This document specifies a way to provide a one-one mapping between IP multicast trees and Label Switched Paths using mLDP signaling. The IP multicast control messages are translated into MPLS control messages when they enter the MPLS domain, and are translated back into IP multicast control messages at the far end of the MPLS domain. The IP multicast control information is coded into the MPLS control information in such a way as to ensure that a single Multipoint Label Switched Path gets set up for each IP multicast tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-in-band-signaling-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-mldp-in-band-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-18153849.I-D@ietf.org> --NextPart-- From Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Mon Jan 18 19:16:31 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260783A6A31 for ; Mon, 18 Jan 2010 19:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.71 X-Spam-Level: *** X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, 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 JARndYmVEo88 for ; Mon, 18 Jan 2010 19:16:31 -0800 (PST) Received: from mx04.melco.co.jp (mx04.melco.co.jp [192.218.140.144]) by core3.amsl.com (Postfix) with ESMTP id D25A83A6A1D for ; Mon, 18 Jan 2010 19:16:30 -0800 (PST) Received: from mr04.melco.co.jp (mr04 [133.141.98.166]) by mx04.melco.co.jp (Postfix) with ESMTP id 4525D5D043 for ; Tue, 19 Jan 2010 12:16:27 +0900 (JST) Received: from mr04.melco.co.jp (localhost [127.0.0.1]) by mr04.imss (Postfix) with ESMTP id 0C3D612F6D for ; Tue, 19 Jan 2010 12:16:27 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr04.melco.co.jp (Postfix) with ESMTP id C32E112F55 for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (iswall2a.isl.melco.co.jp [10.74.245.24]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 9490131F3DD for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 3331D22CBCD for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from LeakStopper186 (stopper.isl.melco.co.jp [10.74.245.35]) by iswall2a.isl.melco.co.jp (Postfix) with SMTP id 1CA7F22CB29 for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: (qmail 12113 invoked by uid 507); 19 Jan 2010 12:16:25 +0900 Received: from unknown (HELO ELSTEFANY) (10.74.8.38) by 0 with SMTP; 19 Jan 2010 12:15:52 +0900 From: "Shoichiro Seno" To: , Date: Tue, 19 Jan 2010 12:15:52 +0900 Message-ID: <9DF91B3ECD8E4551B29D2966672C4C61@ad.melco.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AcqYtTHqIuCpJnDtRyCuJ37u9PFqhwAAE5Qw Subject: [mpls] iPOP 2010 Call for Presentation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 03:16:31 -0000 Dear CAMP, PCE, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people.) ----------------------------------------------------------------------- Call for Presentation 6th International Conference on IP + Optical Network (iPOP 2010) June 10-11, 2010 NTT Musashino R&D Center, Tokyo, Japan http://www.pilab.jp/ipop2010/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 19, 2010 Notification of acceptance: April 2, 2010 Submission deadline of final presentation slides: April 23, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2010-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2010/ for more details. General Chairs: Tomonori Aoyama, Keio University, Japan Bijan Jabbari, ISOCORE, USA Hisashi Koumura, NTT, Japan Organization Committee Co-Chairs: Naoaki Yamanaka, Keio University, Japan Atsushi Hiramatsu, NTT, Japan Soichiro Araki, NEC, Japan Exhibition Committee Co-Chairs: Kohei Shiomoto, NTT, Japan Munefumi Tsurusawa, KDDI R&D, Japan Technical Program Committee Co-Chairs: Eiji Oki, University of Electro-Communications, Japan Monique Morrow, Cisco Systems, USA -------------------------------------------------------------------------------- - Kind regards, Sho Seno Publication Chair, iPOP 2010 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation From lufang@cisco.com Mon Jan 18 21:13:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87BA3A6905; Mon, 18 Jan 2010 21:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Sl4UrnAVLEJY; Mon, 18 Jan 2010 21:13:05 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 91DB03A6861; Mon, 18 Jan 2010 21:13:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvOVEtAZnwM/2dsb2JhbADAJ5UChDME X-IronPort-AV: E=Sophos;i="4.49,301,1262563200"; d="scan'208";a="80771531" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2010 05:13:00 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0J5D05u010654; Tue, 19 Jan 2010 05:13:00 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 23:13:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jan 2010 23:12:58 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25511A96@XMB-RCD-201.cisco.com> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document thread-index: AcqUcgRvkHymg0r/THuxP9uDW+uErwEU6vsA References: <4B4DFC51.8050301@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 19 Jan 2010 05:13:00.0222 (UTC) FILETIME=[11BFF5E0:01CA98C6] Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 05:13:06 -0000 yes/support. Luyuan -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 13 January 2010 12:01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From liu.guoman@zte.com.cn Mon Jan 18 23:50:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400E23A68B7; Mon, 18 Jan 2010 23:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 VwxEncud18on; Mon, 18 Jan 2010 23:50:54 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E5A393A6941; Mon, 18 Jan 2010 23:50:51 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101911657480; Tue, 19 Jan 2010 15:25:04 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 78921.1911657480; Tue, 19 Jan 2010 15:50:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o0J7obnF056688; Tue, 19 Jan 2010 15:50:37 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003DD655B@S4DE9JSAANI.ost.t-com.de> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 19 Jan 2010 15:50:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-19 15:50:28, Serialize complete at 2010-01-19 15:50:28 Content-Type: multipart/alternative; boundary="=_alternative 002B1174482576B0_=" X-MAIL: mse2.zte.com.cn o0J7obnF056688 Cc: mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 07:50:55 -0000 This is a multipart message in MIME format. --=_alternative 002B1174482576B0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksIGFsbA0KYWJvdXQgdGhlIGRyYWZ0LCBJIGhhdmUgc29tZSBhIGZldyBxdWVzdGlvbnMgdG8g YXNrIHRoZSBhdXRob3JzIG9mIHRoZSANCmRyYWZ0LiB0aGUgcXVlc3Rpb25zIGlzIHRoZSBmb2xs b3dpbmc6DQogICAxIGluIHRoZSBzZWN0aW9uIDQuMy41LiAgT3BlcmF0b3IgQ29udHJvbGxlZCBT d2l0Y2hpbmcsIHRoZXJlIGlzIHRoZSANCmZvbGxvd2luZyBkZXNjcmlibGVzOg0KICAgICAgIiBU cmFuc21pdCBhIFBDUyBjb250cm9sIHBhY2tldCwgdXNpbmcgR0FDSCwgd2l0aCB0aGUgYXBwcm9w cmlhdGUNCiAgICAgIFJlcXVlc3QgY29kZSAoZWl0aGVyIE1hbnVhbCBzd2l0Y2ggb3IgRm9yY2Vk IHN3aXRjaCksIHRoZSBGcGF0aA0KICAgICAgc2V0IHRvIDAsIHRvIGluZGljYXRlIHRoYXQgdGhl IGZhdWx0L2RlZ3JhZGUgd2FzIGRldGVjdGVkIG9uIHRoZQ0KICAgICAgd29ya2luZyBwYXRoLCBh bmQgdGhlIFBhdGggc2V0IHRvIDEsIGluZGljYXRpbmcgdGhhdCB0cmFmZmljIGlzDQogICAgICBu b3cgYmVpbmcgZm9yd2FyZGVkIG9uIHRoZSByZWNvdmVyeSBwYXRoLiINCiAgdGhlIHNlbnRlbmNl IHRoYXQgdGhlIEZwYXRoIHNldCB0byAwIGlzIHdyb25nLiBJTU8sIGl0IGlzIHNldCB0byAxPw0K DQogIDIgZm9yIHRoZSByZWNvdmVyeSBwYXRoLCBob3cgdG8gZGV0ZWN0IG9yIGp1ZGdlIHdoZXRo ZXIgU0QgRmFpbHVyZSANCmhhcHBlbmVkIG9uIHRoZSByZWNvdmVyeSBwYXRoLiBiZWNhdXNlIHRo ZXJlIGlzIG5vIHNlcnZpY2UgcGFja2V0cw0KICAgIG9uIHRoZSByZWNvdmVyeSBwYXRoIHVuZGVy IGlkbGUgc3RhdGUuIGlmIHdlIG9ubHkgZGV0ZWN0IG9yIGp1ZGdlIA0Kd2hldGhlciB0byBoYXBw ZW4gU0QgRmFpbHVyZSBieSBPQU0gb3IgdGVzdCBwYWNrZXRzLiBjYW4gaXQgYmUgdHJ1ZSBmb3Ig DQogICAgdGhlIGNvbmRpdGlvbiB0aGF0IHRoZXJlIGlzIHNlcnZpY2UgcGFja2V0cyBvbiB0aGUg cmVjb3ZlcnkgcGF0aD8NCg0KIA0KICAgYmVzdCByZWdhcmRzDQogICBsaXUgDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCjxNYW51ZWwuUGF1bEB0ZWxla29tLmRlPiANCreivP7IyzogIG1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wMS0xOCAwNDozOA0KDQrK1bz+yMsNCjxtcGxzLXRw QGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW21wbHMtdHBdIHBvbGwgb24gbWFraW5nICAg IGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10cC1saW5lYXItcHJvdGVjdGlvbiANCmFuIG1wbHMgd2cg ZG9jdW1lbnQNCg0KDQoNCg0KDQoNCiANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGll dGYub3JnXSBPbg0KQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NClNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAxMywgMjAxMCA2OjAxIFBNDQpUbzogbXBscy10cEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9y ZzsgY2NhbXBAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzLXRwXSBwb2xs IG9uIG1ha2luZw0KZHJhZnQtd2VpbmdhcnRlbi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uIGFu IG1wbHMgd2cgZG9jdW1lbnQNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsg cG9sbCBvbiBtYWtpbmcNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2Vpbmdh cnRlbi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLTA1DQoNCmFuIE1QTFMgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCg0KU2VuZCBhIG1haWwgdG8gdGhlIG1wbHMtdHBAaWV0Zi5vcmcgbWFpbGlu ZyBsaXN0LA0KaW5kaWNhdGluZyAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3Qgc3VwcG9ydCIu DQoNCkNvbW1lbnRzIG9uIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCBzaG91bGQgYmUgc2VudCB0 byB0aGUgc2FtZQ0KbWFpbGluZyBsaXN0IHdpdGggYSBkaWZmZXJlbnQgc3ViamVjdCBsaW5lLg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IGlzIGEgY29uc2Npb3VzIGRlY2lzaW9uIGJ5IHRoZSB3ZyBj aGFpciB0byBwb2xsDQp0aGUgbGluZWFyLXByb3RlY3Rpb24gZG9jdW1lbnQgcHJpb3IgdG8gdGhl IHJpbmctcHJvdGVjdGlvbg0KZG9jdW1lbnQsIHNpbmNlIHdlIHdhbnQgdG8gbWFrZSByb29tIGZv ciBzZXBhcmF0ZWQgZGlzY3Vzc2lvbnMgb24NCnRoZSB0d28gZG9jdW1lbnRzLg0KDQpUaGUgcG9s bCBlbmRzIEZyaWRheSBqdWFudWFyeSAyOSwgMjAxMC4NCg0KL0xvYQ0KLS0gDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxp c3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscy10cA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz Lg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 002B1174482576B0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLCBhbGw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFib3V0IHRoZSBkcmFmdCwgSSBoYXZlIHNv bWUgYSBmZXcgcXVlc3Rpb25zDQp0byBhc2sgdGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0LiB0aGUg cXVlc3Rpb25zIGlzIHRoZSBmb2xsb3dpbmc6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7MSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD5pbg0K dGhlIHNlY3Rpb24gNC4zLjUuICZuYnNwO09wZXJhdG9yIENvbnRyb2xsZWQgU3dpdGNoaW5nLCB0 aGVyZSBpcyB0aGUgZm9sbG93aW5nDQpkZXNjcmlibGVzOjwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7IDwvdHQ+PC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1yZWQ+PHR0PlRyYW5zbWl0DQphIFBDUyBjb250cm9sIHBhY2tldCwgdXNp bmcgR0FDSCwgd2l0aCB0aGUgYXBwcm9wcmlhdGU8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtS ZXF1ZXN0IGNvZGUgKGVpdGhlciBNYW51YWwgc3dpdGNoIG9yIEZvcmNlZCBzd2l0Y2gpLA0KdGhl IEZwYXRoPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7c2V0IHRvIDAsIHRvIGluZGljYXRlIHRo YXQgdGhlIGZhdWx0L2RlZ3JhZGUgd2FzIGRldGVjdGVkDQpvbiB0aGU8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDt3b3JraW5nIHBhdGgsIGFuZCB0aGUgUGF0aCBzZXQgdG8gMSwgaW5kaWNhdGlu ZyB0aGF0DQp0cmFmZmljIGlzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7bm93IGJlaW5nIGZv cndhcmRlZCBvbiB0aGUgcmVjb3ZlcnkgcGF0aDwvdHQ+PC9mb250Pjxmb250IHNpemU9Mz48dHQ+ LiZxdW90Ozxicj4NCiAmbmJzcDt0aGUgc2VudGVuY2UgdGhhdCB0aGUgRnBhdGggc2V0IHRvIDAg aXMgd3JvbmcuIElNTywgaXQgaXMgc2V0IHRvDQoxPzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mz48dHQ+Jm5ic3A7IDIgZm9yIHRoZSByZWNvdmVyeSBwYXRoLCBob3cgdG8gZGV0 ZWN0IG9yIGp1ZGdlDQp3aGV0aGVyIFNEIEZhaWx1cmUgaGFwcGVuZWQgb24gdGhlIHJlY292ZXJ5 IHBhdGguIGJlY2F1c2UgdGhlcmUgaXMgbm8gc2VydmljZQ0KcGFja2V0czwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz48dHQ+Jm5ic3A7ICZuYnNwOyBvbiB0aGUgcmVjb3ZlcnkgcGF0aCB1 bmRlciBpZGxlIHN0YXRlLg0KaWYgd2Ugb25seSBkZXRlY3Qgb3IganVkZ2Ugd2hldGhlciB0byBo YXBwZW4gU0QgRmFpbHVyZSBieSBPQU0gb3IgdGVzdA0KcGFja2V0cy4gY2FuIGl0IGJlIHRydWUg Zm9yIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+Jm5ic3A7ICZuYnNwOyB0aGUg Y29uZGl0aW9uIHRoYXQgdGhlcmUgaXMgc2VydmljZQ0KcGFja2V0cyBvbiB0aGUgcmVjb3Zlcnkg cGF0aD88L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOyAmbmJz cDsgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mbmJzcDsgJm5ic3A7YmVzdCBy ZWdhcmRzPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mbmJzcDsgJm5ic3A7bGl1 IDwvdHQ+PC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9k aXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249 Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249Y2Vu dGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTIyJT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmx0O01hbnVlbC5QYXVsQHRlbGVrb20uZGUmZ3Q7PC9iPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNw O21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDEwLTAxLTE4IDA0OjM4PC9mb250Pg0KPHRkIHdpZHRoPTc3JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDttcGxzLXRwQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFttcGxzLXRwXSBwb2xsIG9uIG1ha2luZyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJh ZnQtd2VpbmdhcnRlbi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uDQphbiBtcGxzIHdnIGRvY3Vt ZW50PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNl c0BpZXRmLm9yZ10gT248YnI+DQpCZWhhbGYgT2YgTG9hIEFuZGVyc3Nvbjxicj4NClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAxMywgMjAxMCA2OjAxIFBNPGJyPg0KVG86IG1wbHMtdHBAaWV0Zi5v cmc7IG1wbHNAaWV0Zi5vcmc7IGNjYW1wQGlldGYub3JnOyBwd2UzQGlldGYub3JnPGJyPg0KU3Vi amVjdDogW21wbHMtdHBdIHBvbGwgb24gbWFraW5nPGJyPg0KZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXRwLWxpbmVhci1wcm90ZWN0aW9uIGFuIG1wbHMgd2cgZG9jdW1lbnQ8YnI+DQo8YnI+DQpBbGws PGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nPGJy Pg0KPGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2VpbmdhcnRlbi1tcGxz LXRwLWxpbmVhci1wcm90ZWN0aW9uLTA1PGJyPg0KPGJyPg0KYW4gTVBMUyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50Ljxicj4NCjxicj4NClNlbmQgYSBtYWlsIHRvIHRoZSBtcGxzLXRwQGlldGYub3Jn IG1haWxpbmcgbGlzdCw8YnI+DQppbmRpY2F0aW5nICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7IG9y ICZxdW90O25vL2RvIG5vdCBzdXBwb3J0JnF1b3Q7Ljxicj4NCjxicj4NCkNvbW1lbnRzIG9uIHRo ZSBjb250ZW50IG9mIHRoZSBkcmFmdCBzaG91bGQgYmUgc2VudCB0byB0aGUgc2FtZTxicj4NCm1h aWxpbmcgbGlzdCB3aXRoIGEgZGlmZmVyZW50IHN1YmplY3QgbGluZS48YnI+DQo8YnI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IGlzIGEgY29uc2Npb3VzIGRlY2lzaW9uIGJ5IHRoZSB3ZyBjaGFpciB0 byBwb2xsPGJyPg0KdGhlIGxpbmVhci1wcm90ZWN0aW9uIGRvY3VtZW50IHByaW9yIHRvIHRoZSBy aW5nLXByb3RlY3Rpb248YnI+DQpkb2N1bWVudCwgc2luY2Ugd2Ugd2FudCB0byBtYWtlIHJvb20g Zm9yIHNlcGFyYXRlZCBkaXNjdXNzaW9ucyBvbjxicj4NCnRoZSB0d28gZG9jdW1lbnRzLjxicj4N Cjxicj4NClRoZSBwb2xsIGVuZHMgRnJpZGF5IGp1YW51YXJ5IDI5LCAyMDEwLjxicj4NCjxicj4N Ci9Mb2E8YnI+DQotLSA8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10cEBpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBs cy10cCBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002B1174482576B0_=-- From yaacov.weingarten@nsn.com Mon Jan 18 23:56:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5443A6892; Mon, 18 Jan 2010 23:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 HCDHYVMGI2cP; Mon, 18 Jan 2010 23:56:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 3C3623A68D1; Mon, 18 Jan 2010 23:56:10 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0J7u4oS002435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jan 2010 08:56:04 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0J7u0kv014274; Tue, 19 Jan 2010 08:56:04 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 08:56:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA98DC.D9365E78" Date: Tue, 19 Jan 2010 08:56:01 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D01EC92F5@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqY3CJ1WBry5ouuQRmc5ivIM/8mdwAADaow References: <40FB0FFB97588246A1BEFB05759DC8A003DD655B@S4DE9JSAANI.ost.t-com.de> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 19 Jan 2010 07:56:04.0520 (UTC) FILETIME=[D9A55A80:01CA98DC] Cc: mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 07:56:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA98DC.D9365E78 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Liu, hi =20 Thank you for your comments =A8C 1. Yes, you are correct and this will be corrected in the next revision = of the draft. 2. The Linear Protection is triggered by (amongst other things) the OAM = and the decision to report a SF/SD is within the scope of the OAM tools = (or the CP tools) and out-of-scope of this draft. =20 Hope this helps, Best Regards, yaacov =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext liu.guoman@zte.com.cn Sent: Tuesday, January 19, 2010 09:50 To: mpls@ietf.org Cc: mpls-tp-bounces@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document =20 hi, all=20 about the draft, I have some a few questions to ask the authors of the = draft. the questions is the following:=20 1 in the section 4.3.5. Operator Controlled Switching, there is the = following describles:=20 " Transmit a PCS control packet, using GACH, with the appropriate Request code (either Manual switch or Forced switch), the Fpath set to 0, to indicate that the fault/degrade was detected on the working path, and the Path set to 1, indicating that traffic is now being forwarded on the recovery path." the sentence that the Fpath set to 0 is wrong. IMO, it is set to 1?=20 2 for the recovery path, how to detect or judge whether SD Failure = happened on the recovery path. because there is no service packets=20 on the recovery path under idle state. if we only detect or judge = whether to happen SD Failure by OAM or test packets. can it be true for=20 the condition that there is service packets on the recovery path?=20 =20 best regards=20 liu=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org=20 2010-01-18 04:38=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 Re: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document =20 =20 =20 =20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, January 13, 2010 6:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. 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. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01CA98DC.D9365E78 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Liu, = hi

 =

Thank you for = your comments =A8C

  1. Yes, you are correct and this will be corrected in the next revision of the draft.
  2. The Linear Protection is triggered by (amongst other things) = the OAM and the decision to report a SF/SD is within the scope of the = OAM tools (or the CP tools) and out-of-scope of this = draft.

 =

Hope this = helps,

Best = Regards,

yaacov=

 =


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext = liu.guoman@zte.com.cn
Sent: Tuesday, January = 19, 2010 09:50
To: mpls@ietf.org
Cc: = mpls-tp-bounces@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] = poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg = document

 


hi, all
about the draft, I have some a few questions to ask the authors of the draft. = the questions is the following:
   1 in the section 4.3.5. =  Operator Controlled Switching, there is the following describles:
      " Transmit a PCS = control packet, using GACH, with the appropriate
     Request code (either Manual switch = or Forced switch), the Fpath
     set to 0, to indicate that the = fault/degrade was detected on the
     working path, and the Path set to = 1, indicating that traffic is
     now being forwarded on the = recovery path."
 the sentence that the Fpath set to 0 is wrong. IMO, it is set to 1? =

  2 for the recovery path, how to detect or judge whether SD Failure = happened on the recovery path. because there is no service packets
    on the recovery path under idle state. if we only detect or judge = whether to happen SD Failure by OAM or test packets. can it be true for
    the condition that there is service packets on the recovery path? =

   
   best regards
   liu

 

 

 

 

 

 

 

 




<Man= uel.Paul@telekom.de>
=B7=A2=BC=FE=C8=CB:  mpls-tp-bounces@ietf.org

2010-01-18 04:38

=CA=D5=BC=FE=C8=CB

=

<mpls-tp@ietf.org>=

=B3=AD=CB=CD

 

=D6=F7=CC=E2

Re: [mpls-tp] poll = on making       =  draft-weingarten-mpls-tp-linear-protection an mpls wg document

 

 

 




 


-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf Of Loa Andersson
Sent: Wednesday, January 13, 2010 6:01 = PM
To: mpls-tp@ietf.org; mpls@ietf.org; = ccamp@ietf.org; pwe3@ietf.org
Subject: [mpls-tp] poll on = making
draft-weingarten-mpls-tp-linear-protection an = mpls wg document

All,

this is to start a two week poll on = making

http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-= protection-05

an MPLS working group document.

Send a mail to the mpls-tp@ietf.org mailing = list,
indicating "yes/support" or = "no/do not support".

Comments on the content of the draft should be = sent to the same
mailing list with a different subject = line.

Please note that it is a conscious decision by = the wg chair to poll
the linear-protection document prior to the ring-protection
document, since we want to make room for = separated discussions on
the two documents.

The poll ends Friday juanuary 29, = 2010.

/Loa
--
_______________________________________________=
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________=
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

 
----------------------------------------------=
----------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. 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.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CA98DC.D9365E78-- From michelg@upperside.fr Tue Jan 19 02:18:54 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972393A6A17 for ; Tue, 19 Jan 2010 02:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 flcTNEZluA7K for ; Tue, 19 Jan 2010 02:18:53 -0800 (PST) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by core3.amsl.com (Postfix) with ESMTP id 201943A680D for ; Tue, 19 Jan 2010 02:18:52 -0800 (PST) Received: from nbMichelvst (AAubervilliers-752-1-16-37.w90-35.abo.wanadoo.fr [90.35.223.37]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id o0JAIkCn031712 for ; Tue, 19 Jan 2010 11:18:46 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 19 Jan 2010 11:17:10 +0100 Message-ID: <8A16C0E4BA464BDDB5F471BF353689E6@UPPERSIDECONFERENCES.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01CA98F8.F182E840" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Thread-Index: AcqY8I90MKTqbhT/SeuabPaaY261RQ== X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.1.19.100323 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Congress 2010 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 10:18:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01CA98F8.F182E840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The MPLS World Congress and the Ethernet Wholesale conferences start in three weeks in Paris. Main issues to be addressed by key players in this area: MPLS-TP & OAM Access and Aggregation Cloud computing MPLS in the RAN More info.: http://www.upperside.fr/ ------=_NextPart_000_0003_01CA98F8.F182E840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MPLS World Congress and the Ethernet = Wholesale conferences start in three weeks in Paris.

 

Main issues to be addressed by key players in = this area:

 

MPLS-TP & OAM

Access and Aggregation

Cloud computing

MPLS in the RAN

 

More info.:

http://www.upperside.fr/<= /span>

 

 

 

------=_NextPart_000_0003_01CA98F8.F182E840-- From eosborne@cisco.com Tue Jan 19 05:05:02 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE663A67EF for ; Tue, 19 Jan 2010 05:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XA5mXnJoADqd for ; Tue, 19 Jan 2010 05:05:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EE6363A6949 for ; Tue, 19 Jan 2010 05:05:00 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ48VUtAZnwN/2dsb2JhbACkepxzlQ+EMwQ X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="80957789" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2010 13:04:54 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.188]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0JD4sEj029015; Tue, 19 Jan 2010 13:04:54 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 07:04:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 07:05:08 -0600 Message-ID: In-Reply-To: <787be2781001181143o791e9debtf2bbbd0dfc38b6a3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RFC 4379: Calculating Length of a TLV in presence ofsub-TLV's Thread-Index: AcqYdpgAPG5XBRhgSKCY8MCZOtyTmQAkSUsQ References: <787be2781001181143o791e9debtf2bbbd0dfc38b6a3@mail.gmail.com> From: "Eric Osborne (eosborne)" To: "Greg Mirsky" , , "George Swallow (swallow)" X-OriginalArrivalTime: 19 Jan 2010 13:04:54.0237 (UTC) FILETIME=[FE37C8D0:01CA9907] Cc: mpls@ietf.org Subject: Re: [mpls] RFC 4379: Calculating Length of a TLV in presence ofsub-TLV's X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 13:05:02 -0000 http://www.rfc-editor.org/errata_search.php?rfc=3D4379 eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Monday, January 18, 2010 2:44 PM > To: kireeti@juniper.net; George Swallow (swallow) > Cc: mpls@ietf.org > Subject: [mpls] RFC 4379: Calculating Length of a TLV in presence > ofsub-TLV's >=20 > Dear Kireeti and George, > I've got a question on proper calculation of a Length value for a TLV > that consists of more than one sub-TLV. > On p.9 on RFC 4379 second drawing depicts format of a Target Stack FEC > TLV with two sub-TLVs. The length in TLV displayed as 12 and I believe > this is not correct. As the Legth must reflect length of the Value > field of a TLV (all encompassed sub-TLVs), in this case it is equal to > 29 (3 bytes of padding appended). > My apologies if this was answered before (couldn't find reference in > the archive). >=20 > Regards, > Greg From ssaxena@cisco.com Tue Jan 19 14:56:20 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8984F3A683D for ; Tue, 19 Jan 2010 14:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 nkuiCa4bL6fs for ; Tue, 19 Jan 2010 14:56:13 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 707003A680B for ; Tue, 19 Jan 2010 14:56:11 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABLHVUurR7Ht/2dsb2JhbACCF8E2lTqCXQGBVQQ X-IronPort-AV: E=Sophos;i="4.49,307,1262563200"; d="scan'208,217";a="469517295" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2010 22:55:06 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0JMt5px014998; Tue, 19 Jan 2010 22:55:05 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 16:55:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA995A.703152DE" Date: Tue, 19 Jan 2010 16:55:00 -0600 Message-ID: In-Reply-To: <3c33c551001180302r339d96ddpe65e02d5a551d1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqYLbMkqey/SUZ3SZGCNZzjsK7z9gBIHYrA References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> <3c33c551001180302r339d96ddpe65e02d5a551d1@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Ashwin C. Prabhu" X-OriginalArrivalTime: 19 Jan 2010 22:55:05.0030 (UTC) FILETIME=[70B1FE60:01CA995A] Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:56:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA995A.703152DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashwin: =20 1. If BC link is down and B is aware of it, then B should be able to respond to the trace quickly. If B is not aware that C is down and still forwards to C then you will have to wait for timeout. Won't you have to wait for the timeout in your proposal? Will you send the next echo request as soon as any echo response is received? =20 2. The limitation that there is only one DDMAP in the Echo Request comes from draft-ietf-mpls-lsp-ping-enhanced-dsmap and it mirrors RFC4379 having a similar requirement for DSMAP. =20 3. You are proposing the ability to send multiple Responder Identifier TLV and DDMAP in an Echo Request message. Also you would need some method to match the DDMAP to its corresponding Egress Address; otherwise you will not be able to do the correct interface validation check. The ability to have multiple Responder Identifier TLV (or Egress Address sub-TLV) in one message was debated extensively and rejected. If multiple of these are allowed, then there are different scenarios where the required behavior is ambiguous. Hence having only one Responder Identifier TLV with only one sub-TLV makes the behavior clearly defined. =20 4. The advantage of your proposal is that it will reduce the number of Echo Requests sent. However it will not reduce the number of Echo Responses being sent/received. Moreover it will increase the amount of processing at the mid or tail LSRs. =20 5. You can achieve the desired interface validation by two different methods: =20 Method 1: Start parallel echo requests at LSR A. So if there are 10 different destinations, then you can send 10 different echo requests simultaneously. Your basic packet will be same and you need to just change egress address TLV and DDMAP before each send. The cost of sending these 10 echo requests is only incrementally higher than clubbing multiple Egress Address sub-TLV and DDMAP into one.=20 =20 Method 2: Ask each router for the ILS TLV and match the previously received DDMAPs. This is an extension of my solution in the previous email. You need to match the interface address to build the tree, and you might as well do label validation. =20 Both solutions will not involve any changes to the draft and hence no changes to behavior of the responding routers. Also all extra processing burden will be at the head-end LSR and not on the mid or tail LSR. Therefore it will be easier to have vendor interoperability with these two methods =20 Thanks, Shaleen =20 From: Ashwin C. Prabhu [mailto:prabhu.ashwin@gmail.com]=20 Sent: Monday, January 18, 2010 6:02 AM To: Shaleen Saxena (ssaxena) Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt =20 Hello Shaleen, =20 What i was thinking was, Say if i have following topology and i want to initiate a trace from the ingress node A. A --------------- B --------------C --------- D \----------------E -------------- F--------- G =20 1. If all the connections are fine then trace might reutrn the o/p fast enough.=20 2. If Say link BC & CD is down then A will wait for the timeout and tracing AEFG might take long time in node by node tracing. 3. The present parallel tracing skips the interface validation all together.=20 4. Instead if A can send multiple instance of DDMT then we can as well do the validation of the interface. Say A sends MPLS echo Request with TTL 1. B & E replies back with DDMT=20 In the next iteration A can send MPLS echo Request with TTL 2 with=20 DDMT (From B) with Egress Address TLV D + DDMT (From E) with Egress Address TLV G packed in the single message. Then node C which is in the path to Egress TLV D can validate the BC interface, similary F. As already told by you this might work only for RSVP-TE case? With this approach we can trace the nodes parallely with lesser number of OAM packets alogn with interface validation check. Coming back to the problem of large message size, the configuration/implementation can limit the number of parallel paths it wanted to club it to. Say if we have 10 egresses then we might want to trace 5 paths first and then next 5 paths, by clubbig them together.=20 =20 Let me know if you see any short comings of doing this way. =20 Thanks for answering the other question in my previous mail. =20 =20 Thanks Ashwin ------_=_NextPart_001_01CA995A.703152DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashwin:

 

1.       If BC link is down and B is aware  of it, then B = should be able to respond to the trace quickly. If B is not aware that C is down = and still forwards to C then you will have to wait for timeout. Won’t  = you have to wait for the timeout in your proposal? Will you send the next = echo request as soon as any echo response is received?

 

2.       The limitation that there is only one DDMAP in the Echo = Request comes from draft-ietf-mpls-lsp-ping-enhanced-dsmap and it mirrors RFC4379 having a similar requirement for = DSMAP.

 

3.       You are proposing the ability to send multiple Responder Identifier TLV and DDMAP in an Echo Request message. Also you would need = some method to match the DDMAP to its corresponding Egress Address; otherwise = you will not be able to do the correct interface validation check. The ability to = have multiple Responder Identifier TLV (or Egress Address sub-TLV) in one = message was debated extensively and rejected. If multiple of these are allowed, = then there are different scenarios where the required behavior is ambiguous. Hence = having only one Responder Identifier TLV with only one sub-TLV makes the = behavior clearly defined.

 

4.       The advantage of your proposal is that it will reduce the = number of Echo Requests sent. However it will not reduce the number of Echo = Responses being sent/received. Moreover it will increase the amount of processing = at the mid or tail LSRs.

 

5.       You can achieve the desired interface validation by two different methods:

 

Method 1: Start parallel echo requests at LSR A. So if = there are 10 different destinations, then you can send 10 different echo requests = simultaneously. Your basic packet will be same and you need to just change egress = address TLV and DDMAP before each send. The cost of sending these 10 echo requests = is only incrementally higher than clubbing multiple Egress Address sub-TLV and = DDMAP into one.

 

Method 2: Ask each router for the ILS TLV and match the = previously received  DDMAPs. This is an extension of my solution in the = previous email. You need to match the interface address to build the tree, and = you might as well do label validation.

 

Both solutions  will not involve any changes to the = draft and hence no changes to behavior of the responding routers. Also all = extra processing burden will be at the head-end LSR and not on the mid or tail = LSR. Therefore it will be easier to have vendor interoperability with these = two methods

 

Thanks,

Shaleen

 

From:= Ashwin C. = Prabhu [mailto:prabhu.ashwin@gmail.com]
Sent: Monday, January 18, 2010 6:02 AM
To: Shaleen Saxena (ssaxena)
Cc: mpls@ietf.org
Subject: Re: [mpls] I-D = Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

 

Hello Shaleen,

 

 What i was thinking was, Say if i have = following topology and i want to initiate a trace from the ingress node = A.

        A = --------------- B --------------C --------- D
          \------------= ----E -------------- F--------- G

 

1. If all the connections are fine then trace might = reutrn the o/p fast enough.

2. If Say link BC & CD is down then A will wait = for the timeout and tracing AEFG might take long time in node by node = tracing.

3. The present parallel tracing skips the interface validation all together.

4.

Instead if A can send multiple instance of DDMT = then we can as well do the validation of the interface.

Say

A sends MPLS echo Request with TTL = 1.

B & E replies back with DDMT

In the next iteration A can send MPLS echo Request = with TTL 2 with

DDMT (From B) with Egress Address TLV D =  + DDMT (From E) with Egress Address TLV G packed in the single = message.

Then node C which is in the path to Egress TLV D = can validate the BC interface, similary F.

As already told by you this might work only for = RSVP-TE case?

With this approach we can trace the nodes = parallely with lesser number of OAM packets alogn with interface validation = check.

Coming back to the problem of large message size, = the configuration/implementation can limit the number of parallel paths it = wanted to club it to. Say if we have 10 egresses then we might want to = trace 5 paths first and then next 5 paths, by clubbig them = together. 

 

Let me know if you see any short comings of doing = this way.

 

Thanks for answering the other question = in my previous mail.

 

 

Thanks

Ashwin

------_=_NextPart_001_01CA995A.703152DE-- From gregimirsky@gmail.com Tue Jan 19 15:40:44 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544523A62C1; Tue, 19 Jan 2010 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Bb-56Dsc9iku; Tue, 19 Jan 2010 15:40:43 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id D2E843A67BD; Tue, 19 Jan 2010 15:40:42 -0800 (PST) Received: by bwz19 with SMTP id 19so3375022bwz.28 for ; Tue, 19 Jan 2010 15:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=XwyRADDa0hfJoH7N5uKhlliCRVX4QgVvS4ZU8chsn/g=; b=kw5vJx8dT7vca7qNVV9huDxnnzyFGcfus+6XeBoCrmhg80JbYOJSdQWgTuWSfG6woD 1f2UwR+SXiOXRH+Ydz80Tpt8wshvamgatOEIsVEr548/bJrQogJXRwVdigWTGbfyjaN0 O9SnyFs0krIFuj1La7He42I/uSL4OxaF68chw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=WBeWT288JrXsosYPL0y8SME5PRl/ipRzOBXDeGFi30B83slp1C3zs/1+dp7VzG52g9 CNBZfh14kmf8RCeegnPAcsrgKFYBf/7RX7qhxzN4XwiP1DiaQYaWL9B5CzrfdNpCc4DZ n1i25dOycllJiAN0OcFZaVFxPlQHjOAXKzUA0= MIME-Version: 1.0 Received: by 10.204.11.15 with SMTP id r15mr4789492bkr.40.1263944435834; Tue, 19 Jan 2010 15:40:35 -0800 (PST) Date: Tue, 19 Jan 2010 15:40:35 -0800 Message-ID: <787be2781001191540g151a5842i2c3f32851f0ddd8c@mail.gmail.com> From: Greg Mirsky To: annamaria.fulignoli@ericsson.com, sboutros@cisco.com, martin.vigoureux@alcatel-lucent.com Content-Type: multipart/alternative; boundary=00032555b4261d1f84047d8cff9b Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [mpls] Comments on Procative CV, CC and RDI for MPLS-TP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 23:40:44 -0000 --00032555b4261d1f84047d8cff9b Content-Type: text/plain; charset=ISO-8859-1 Dear Editors and Authors, please find my comments and questions to the draft below. Several formatting issues: - Page header of the draft-asm-mpls-tp-bfd-cc-cv-01still refers to 00 version (draft-asm-mpls-tp-bfd-cc-cv-00) - Enumeration of figures in the text needs to be reviewed: - format of CC Message on p.5 is not enumerated though the very next one (CV/CC Message) is - figure enumeration restarts from #1 on p.7 Comments and questions: - What is the scope of uniqueness of Source MEP-ID? If MEP-ID is unique within Maintenance Entity (e.g. TP LSP), then why Sender's My Discriminator can not be used to control misconnectivity? - Section 3.4.1 Timer negotiation and other places refer to BFD's dynamic timer negotiation process. Why would not to require that the timer negotiation process MUST be disabled and timer values and Detect Multiplier either statically provisioned or signaled outside of BFD (e.g. within GMPLS OAM signalling)? Regards, Greg --00032555b4261d1f84047d8cff9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Editors and Authors,
please find my comments and questions to the d= raft below.
Several formatting issues:
  • Page header of the d= raft-asm-mpls-tp-bfd-cc-cv-01 still refers to 00 version (draft-= asm-mpls-tp-bfd-cc-cv-00)
  • Enumeration of figures in the text needs to be reviewed:
    • fo= rmat of CC Message on p.5 is not enumerated though the very next one (CV/CC= Message) is
    • figure enumeration restarts from #1 on p.7
Comments and questions:
  • What is the scope of uniqueness of = Source MEP-ID? If MEP-ID is unique within Maintenance Entity (e.g. TP LSP),= then why Sender's My Discriminator can not be used to control misconne= ctivity?
  • Section 3.4.1 Timer negotiation and other places refer to BFD's dyn= amic timer negotiation process. Why would not to require that the timer neg= otiation process MUST be disabled and timer values and Detect Multiplier ei= ther statically provisioned or signaled outside of BFD (e.g. within GMPLS O= AM signalling)?
Regards,
Greg
--00032555b4261d1f84047d8cff9b-- From root@core3.amsl.com Tue Jan 19 18:15:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 30D333A68D7; Tue, 19 Jan 2010 18:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100120021502.30D333A68D7@core3.amsl.com> Date: Tue, 19 Jan 2010 18:15:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-framework-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 02:15:02 -0000 --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 : MPLS-TP Network Management Framework Author(s) : S. Mansfield, et al. Filename : draft-ietf-mpls-tp-nm-framework-04.txt Pages : 19 Date : 2010-01-19 This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-nm-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19180806.I-D@ietf.org> --NextPart-- From prabhu.ashwin@gmail.com Thu Jan 21 05:10:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068883A69EF for ; Thu, 21 Jan 2010 05:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 r7y7dGMHNA1E for ; Thu, 21 Jan 2010 05:09:59 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 77B1A3A6989 for ; Thu, 21 Jan 2010 05:09:59 -0800 (PST) Received: by qyk13 with SMTP id 13so4017893qyk.31 for ; Thu, 21 Jan 2010 05:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5FoOJZC18az0LYocW39JSOal+xR3DFNuqSJ8oY8zo3k=; b=hwGk/5QFDzmJD7Dstj5GGSmgXCpTv9xEnR/bDpN2GIryCF/bBPX7Ke6X/Re0fhotC4 afQUmnQRWGLl3PkC38KZ2bOzTaDRH8iBvo8Et+Cq/U+9PMOXFcup+MhDslcmrGnB928C nD16l7qdqxYVIfFDQ5clMWf8XefCf59shTnEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Qp+eAr4q36cDvDXgLS/4Wi2lLqudpzmfKZl2YliORl6rGHz2DRP6Mf2qUWY+1kdOOC eZtMjm0R0rZM9Otya9+8lHNluFMeXFqy4hq8Q3Wp4E0J4joO8B++gB/X+qRed05XxsHj jdvhC9vEy0LDE+eUFPLl/CaiVBiNhydXbYRAQ= MIME-Version: 1.0 Received: by 10.220.125.104 with SMTP id x40mr84127vcr.33.1264079391613; Thu, 21 Jan 2010 05:09:51 -0800 (PST) In-Reply-To: References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> <3c33c551001180302r339d96ddpe65e02d5a551d1@mail.gmail.com> Date: Thu, 21 Jan 2010 18:39:51 +0530 Message-ID: <3c33c551001210509h506a863dwaf49de70169cbf41@mail.gmail.com> From: "Ashwin C. Prabhu" To: "Shaleen Saxena (ssaxena)" Content-Type: multipart/alternative; boundary=001636c933e91ae2a5047dac6b11 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:10:03 -0000 --001636c933e91ae2a5047dac6b11 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Shaleen, Thanks for clarifying the doubts. I was not aware that the multiple responder id TLV was previously discussed. forgive my ignorance, i should have searched the archives. Other replies se= e inline with tag [Ashwin] One more question. Say i have a dataplane error(bug) where it is able to forward only a single copy and not multiple copies to its multiple nexthops then tracing node-by-node may not detect these errors? So shouldn't the trace follow the way the actual data flows in the p2mp cas= e instead of node by node? What is the gurantee that the packet from ingress reaches multiple destination. I understand we have a provision for this but i was just thinking of the short comings of the node-by-node trace. Thanks Ashwin On Wed, Jan 20, 2010 at 4:25 AM, Shaleen Saxena (ssaxena) wrote: > Hi Ashwin: > > > > 1. If BC link is down and B is aware of it, then B should be able > to respond to the trace quickly. If B is not aware that C is down and sti= ll > forwards to C then you will have to wait for timeout. Won=92t you have t= o > wait for the timeout in your proposal? Will you send the next echo reques= t > as soon as any echo response is received? > [Ashwin] Yes it will wait for the timeout and hence i was thinking node by node trace may not be good option and thought we can have some improovement= s by sugeesting above. > > > 2. The limitation that there is only one DDMAP in the Echo Request > comes from draft-ietf-mpls-lsp-ping-enhanced-dsmapand it mirrors RFC4379 havi= ng a similar requirement for DSMAP. > [Ashwin] At the time of writing RFC 4379 may be the p2mp was not forseen or considered. If it is beneficial then changing this might be a option. > > > 3. You are proposing the ability to send multiple Responder > Identifier TLV and DDMAP in an Echo Request message. Also you would need > some method to match the DDMAP to its corresponding Egress Address; > otherwise you will not be able to do the correct interface validation che= ck. > The ability to have multiple Responder Identifier TLV (or Egress Address > sub-TLV) in one message was debated extensively and rejected. If multiple= of > these are allowed, then there are different scenarios where the required > behavior is ambiguous. Hence having only one Responder Identifier TLV wit= h > only one sub-TLV makes the behavior clearly defined. > [Ashwin] Ok i didn't knew that it is previously disussed, i didn't get whic= h scenarios the behavior is ambguous, i will search the archives for the discussion thread. Thanks for pointing me this. > > > 4. The advantage of your proposal is that it will reduce the number > of Echo Requests sent. However it will not reduce the number of Echo > Responses being sent/received. Moreover it will increase the amount of > processing at the mid or tail LSRs. > [Ashwin] Yes that's right, > > > 5. You can achieve the desired interface validation by two differen= t > methods: > > > > Method 1: Start parallel echo requests at LSR A. So if there are 10 > different destinations, then you can send 10 different echo requests > simultaneously. Your basic packet will be same and you need to just chang= e > egress address TLV and DDMAP before each send. The cost of sending these = 10 > echo requests is only incrementally higher than clubbing multiple Egress > Address sub-TLV and DDMAP into one. > > [Ashwin] Yes, i was consdering this as option. > > Method 2: Ask each router for the ILS TLV and match the previously > received DDMAPs. This is an extension of my solution in the previous ema= il. > You need to match the interface address to build the tree, and you might = as > well do label validation. > [Ashwin] Thanks for letting me know about the ILS TLV i never thought about this. > > > Both solutions will not involve any changes to the draft and hence no > changes to behavior of the responding routers. Also all extra processing > burden will be at the head-end LSR and not on the mid or tail LSR. Theref= ore > it will be easier to have vendor interoperability with these two methods > > > > Thanks, > > Shaleen > > > > *From:* Ashwin C. Prabhu [mailto:prabhu.ashwin@gmail.com] > *Sent:* Monday, January 18, 2010 6:02 AM > *To:* Shaleen Saxena (ssaxena) > *Cc:* mpls@ietf.org > > *Subject:* Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt > > > > Hello Shaleen, > > > > What i was thinking was, Say if i have following topology and i want to > initiate a trace from the ingress node A. > > A --------------- B --------------C --------- D > \----------------E -------------- F--------- G > > > > 1. If all the connections are fine then trace might reutrn the o/p fast > enough. > > 2. If Say link BC & CD is down then A will wait for the timeout and traci= ng > AEFG might take long time in node by node tracing. > > 3. The present parallel tracing skips the interface validation all > together. > > 4. > > Instead if A can send multiple instance of DDMT then we can as well do th= e > validation of the interface. > > Say > > A sends MPLS echo Request with TTL 1. > > B & E replies back with DDMT > > In the next iteration A can send MPLS echo Request with TTL 2 with > > DDMT (From B) with Egress Address TLV D + DDMT (From E) with Egress > Address TLV G packed in the single message. > > Then node C which is in the path to Egress TLV D can validate the BC > interface, similary F. > > As already told by you this might work only for RSVP-TE case? > > With this approach we can trace the nodes parallely with lesser number of > OAM packets alogn with interface validation check. > > Coming back to the problem of large message size, the > configuration/implementation can limit the number of parallel paths it > wanted to club it to. Say if we have 10 egresses then we might want to tr= ace > 5 paths first and then next 5 paths, by clubbig them together. > > > > Let me know if you see any short comings of doing this way. > > > > Thanks for answering the other question in my previous mail. > > > > > > Thanks > > Ashwin > --001636c933e91ae2a5047dac6b11 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello Shaleen,
=A0
Thanks for clarifying the doubts. I was not aware that the multiple re= sponder id TLV was previously discussed.
forgive my ignorance, i should have searched the archives. Other repli= es see inline with tag [Ashwin]
=A0
One more question.
Say i have a dataplane error(bug) where it is able to forward only a s= ingle copy and not multiple copies to its multiple=A0nexthops then tracing = node-by-node may not detect these errors?
=A0
So shouldn't the trace follow the way the actual data flows in the= p2mp case instead of node by node?
What is the gurantee that the packet from ingress reaches multiple des= tination.
=A0
=A0
I understand we have a provision for this but=A0i was just thinking of= the short comings of the node-by-node trace.
=A0
=A0
=A0
Thanks
Ashwin
=A0

=A0
On Wed, Jan 20, 2010 at 4:25 AM, Shaleen Saxena = (ssaxena) <ssaxen= a@cisco.com> wrote:

Hi A= shwin:

=A0<= /span>

1.=A0=A0=A0=A0=A0=A0 If BC link is down and B i= s aware=A0 of it, then B should be able to respond to the trace quickly. If= B is not aware that C is down and still forwards to C then you will have t= o wait for timeout. Won=92t=A0 you have to wait for the timeout in your pro= posal? Will you send the next echo request as soon as any echo response is = received?

[Ashwin] Yes it will wait for the timeout and hence i was thinking nod= e by node trace may not be good option and thought we can have some improov= ements by sugeesting above.
=A0

=A0<= /span>

2.=A0=A0=A0=A0=A0=A0 The limitation that there = is only one DDMAP in the Echo Request comes from d= raft-ietf-mpls-lsp-ping-enhanced-dsmap and it mirrors RFC4379 having a = similar requirement for DSMAP.

[Ashwin] At the time of writing RFC 4379 may be the p2mp was not forse= en or considered. If it is beneficial then changing this might be a option.=

=A0<= /span>

3.=A0=A0=A0=A0=A0=A0 You are proposing the abil= ity to send multiple Responder Identifier TLV and DDMAP in an Echo Request = message. Also you would need some method to match the DDMAP to its correspo= nding Egress Address; otherwise you will not be able to do the correct inte= rface validation check. The ability to have multiple Responder Identifier T= LV (or Egress Address sub-TLV) in one message was debated extensively and r= ejected. If multiple of these are allowed, then there are different scenari= os where the required behavior is ambiguous. Hence having only one Responde= r Identifier TLV with only one sub-TLV makes the behavior clearly defined.<= /span>

[Ashwin] Ok i didn't knew that it is previously disussed, i didn&#= 39;t get which scenarios the behavior is ambguous, i will search the archiv= es for the discussion thread. Thanks for pointing me this.

=A0<= /span>

4.=A0=A0=A0=A0=A0=A0 The advantage of your prop= osal is that it will reduce the number of Echo Requests sent. However it wi= ll not reduce the number of Echo Responses being sent/received. Moreover it= will increase the amount of processing at the mid or tail LSRs.

[Ashwin] Yes that's right,

=A0<= /span>

5.=A0=A0=A0=A0=A0=A0 You can achieve the desire= d interface validation by two different methods:

=A0<= /span>

Method 1: Start parallel= echo requests at LSR A. So if there are 10 different destinations, then yo= u can send 10 different echo requests simultaneously. Your basic packet wil= l be same and you need to just change egress address TLV and DDMAP before e= ach send. The cost of sending these 10 echo requests is only incrementally = higher than clubbing multiple Egress Address sub-TLV and DDMAP into one.

=A0[= Ashwin] Yes, i was consdering this as option.

=A0

Method 2: Ask each route= r for the ILS TLV and match the previously received =A0DDMAPs. This is an e= xtension of my solution in the previous email. You need to match the interf= ace address to build the tree, and you might as well do label validation.

[Ashwin] Thanks for letting me know about the ILS TLV i never thought = about this.

=A0<= /span>

Both= solutions =A0will not involve any changes to the draft and hence no change= s to behavior of the responding routers. Also all extra processing burden w= ill be at the head-end LSR and not on the mid or tail LSR. Therefore it wil= l be easier to have vendor interoperability with these two methods

=A0

=A0<= /span>

Than= ks,

Shal= een

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Ashwin C. Prabhu [mailto:prabhu.ashwin@gmail.com] Sent: Monday, January 18, 2010 6:02 AM
To: Shaleen Saxena (ssaxena)
Cc: mpls@ietf.org=20


Subject: Re: [mpls] I-D Action:draft-ietf-mpls= -p2mp-lsp-ping-09.txt

=A0

Hello Shaleen,

=A0

=A0What i was thinking was, Say if i have following = topology and i want to initiate a trace from the ingress node A.

=A0=A0=A0=A0=A0=A0=A0 A --------------- B ----------= ----C --------- D
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\----------------E -----= --------- F--------- G

=A0

1. If all the connections are fine then trace might = reutrn the o/p fast enough.

2. If Say link BC & CD is down then A will wait = for the timeout and tracing AEFG might take long time in node by node traci= ng.

3. The present parallel tracing skips the interface = validation all together.

4.

Instead if A can send multiple instance of DDMT then= we can as well do the validation of the interface.

Say

A sends MPLS echo Request with TTL 1.

B & E replies back with DDMT

In the next iteration A can send MPLS echo Request w= ith TTL 2 with

DDMT (From B) with Egress Address TLV=A0D =A0+ DDMT = (From E) with Egress Address TLV=A0G packed in the single message.

Then node C which is in the path to Egress TLV D can= validate the BC interface, similary F.

As already told by you this might work only for RSVP= -TE case?

With this approach=A0we can trace the nodes parallel= y with lesser number of OAM packets alogn with interface validation check.<= /p>

Coming back to the problem of large message size, th= e configuration/implementation can limit the number of parallel paths it wa= nted to club it to. Say if we have 10 egresses then=A0we might want to trac= e 5 paths first and then next 5 paths, by clubbig them together.=A0

=A0

Let me know if you see any short comings of doing th= is way.

=A0

Thanks for=A0answering the=A0other question in my pr= evious mail.

=A0

=A0

Thanks

Ashwin


--001636c933e91ae2a5047dac6b11-- From gregimirsky@gmail.com Thu Jan 21 13:21:05 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C082B3A6947; Thu, 21 Jan 2010 13:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vuvmrNcsRHsE; Thu, 21 Jan 2010 13:21:04 -0800 (PST) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 0AA553A68DE; Thu, 21 Jan 2010 13:21:03 -0800 (PST) Received: by bwz22 with SMTP id 22so594416bwz.5 for ; Thu, 21 Jan 2010 13:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=cmStys0hLPRMLaFLdt8TKicVJ/tW3Mt4x20GkGhgWOs=; b=k9oh5tN1hNZ054HG8W7uzOo32nxSZaPYuXAWyIzJdc5dj1SMFZne9eBzTXirScoLvc i1sd914XxvOXNcq0gFK81kgQ323eypt1oykBVCrvoPO3gmrMsId0DYkciHM9eiFo6uzm xuIDOqhpL4L1xasnMKv6m8rH3BTfdFHdDa0pM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=UTk5QLq5BGx1EAH+u469euq3TNLPOE/0VcePY3C/w0rWBG+2TtCXDq7yM/Kqv01p7h gmIAOprCtS3QKzUullNgKvET7usYJEV8FtRvuUDXTMdFEWXAxzeS7WgfjvaBogMT0J0f 6JZbfUmBmMHoToNCuwYpVmr+USdHBbyh7Ecww= MIME-Version: 1.0 Received: by 10.204.15.17 with SMTP id i17mr1060045bka.173.1264108855699; Thu, 21 Jan 2010 13:20:55 -0800 (PST) Date: Thu, 21 Jan 2010 13:20:55 -0800 Message-ID: <787be2781001211320q782f4e27hf6a04de031cfefb4@mail.gmail.com> From: Greg Mirsky To: BOCCI Matthew , martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com Content-Type: multipart/alternative; boundary=00032555a7ee4d28f7047db34772 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [mpls] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:21:05 -0000 --00032555a7ee4d28f7047db34772 Content-Type: text/plain; charset=ISO-8859-1 Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between *adjacent nodes* (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --00032555a7ee4d28f7047db34772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Editors and All,
I'm puzzled by what looks to me as contradicti= on between quoted in the RFC 5586 definition of the Section Layer Network a= nd the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (= section 1.3 p.4) refers to section as server layer that provides service be= tween adjacent nodes (my underlining). At the same time, the last pa= ragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on = an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS= Section is between adjacent nodes, then, as I understand the definition, t= here can not be intermediate nodes on the section (on the segment, but not = on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg
--00032555a7ee4d28f7047db34772-- From ssaxena@cisco.com Thu Jan 21 13:37:31 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723DE3A67A7 for ; Thu, 21 Jan 2010 13:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9DQAIhLqU+H3 for ; Thu, 21 Jan 2010 13:37:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 76A883A67AF for ; Thu, 21 Jan 2010 13:37:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoEAMtXWEurRN+K/2dsb2JhbACCF8IdlimEPAQ X-IronPort-AV: E=Sophos;i="4.49,320,1262563200"; d="scan'208,217";a="77627362" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Jan 2010 21:37:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0LLbMbK028687; Thu, 21 Jan 2010 21:37:22 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 15:37:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9AE1.E9E1D4C7" Date: Thu, 21 Jan 2010 15:37:19 -0600 Message-ID: In-Reply-To: <3c33c551001210509h506a863dwaf49de70169cbf41@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt Thread-Index: AcqamwXd6fDo5EujQ6O0ccTd03ynNgARYR1g References: <20091214221501.72E203A6826@core3.amsl.com> <3c33c551001120124k74ad5845s696952865a192fdc@mail.gmail.com> <3c33c551001150306y248be77cuecbdc3daa4b474de@mail.gmail.com> <3c33c551001180302r339d96ddpe65e02d5a551d1@mail.gmail.com> <3c33c551001210509h506a863dwaf49de70169cbf41@mail.gmail.com> From: "Shaleen Saxena (ssaxena)" To: "Ashwin C. Prabhu" X-OriginalArrivalTime: 21 Jan 2010 21:37:22.0509 (UTC) FILETIME=[EA713FD0:01CA9AE1] Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:37:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9AE1.E9E1D4C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashwin: =20 The OAM packet ought to follow the data plane traffic. That is the basic premise of RFC4379. Why won't it follow in this case? =20 If forwarding is broken at some branch, then you will not get responses from downstream LSRs. As for detecting these errors, your ping needs to be aware of what destinations are present. This is generally available in P2MP TE but might have to be manually provided in mLDP. =20 Thanks, Shaleen =20 =20 =20 From: Ashwin C. Prabhu [mailto:prabhu.ashwin@gmail.com]=20 Sent: Thursday, January 21, 2010 8:10 AM To: Shaleen Saxena (ssaxena) Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt =20 Hello Shaleen,=20 =20 Thanks for clarifying the doubts. I was not aware that the multiple responder id TLV was previously discussed.=20 forgive my ignorance, i should have searched the archives. Other replies see inline with tag [Ashwin] =20 One more question.=20 Say i have a dataplane error(bug) where it is able to forward only a single copy and not multiple copies to its multiple nexthops then tracing node-by-node may not detect these errors? =20 So shouldn't the trace follow the way the actual data flows in the p2mp case instead of node by node?=20 What is the gurantee that the packet from ingress reaches multiple destination. =20 =20 I understand we have a provision for this but i was just thinking of the short comings of the node-by-node trace. =20 =20 =20 Thanks Ashwin =20 ------_=_NextPart_001_01CA9AE1.E9E1D4C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashwin:

 

The OAM packet ought to follow the data plane traffic. = That is the basic premise of RFC4379. Why won’t it follow in this = case?

 

If forwarding is broken at some branch, then you will not = get responses from downstream LSRs. As for detecting these errors, your ping = needs to be aware of what destinations are present. This is generally = available in P2MP TE but might have to be manually provided in = mLDP.

 

Thanks,

Shaleen

 

 

 

From:= Ashwin C. = Prabhu [mailto:prabhu.ashwin@gmail.com]
Sent: Thursday, January 21, 2010 8:10 AM
To: Shaleen Saxena (ssaxena)
Cc: mpls@ietf.org
Subject: Re: [mpls] I-D = Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

 


Hello Shaleen,

 

Thanks for clarifying the doubts. I was not aware = that the multiple responder id TLV was previously discussed.

forgive my ignorance, i should have searched the = archives. Other replies see inline with tag [Ashwin]

 

One more question.

Say i have a dataplane error(bug) where it is able = to forward only a single copy and not multiple copies to its multiple nexthops then tracing node-by-node may not detect these = errors?

 

So shouldn't the trace follow the way the actual = data flows in the p2mp case instead of node by node?

What is the gurantee that the packet from ingress = reaches multiple destination.

 

 

I understand we have a provision for this = but i was just thinking of the short comings of the node-by-node = trace.

 

 

 

Thanks

Ashwin

 

------_=_NextPart_001_01CA9AE1.E9E1D4C7-- From maarten.vissers@huawei.com Fri Jan 22 07:52:50 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB063A68F4; Fri, 22 Jan 2010 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 HPuvNjk6oBz7; Fri, 22 Jan 2010 07:52:49 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 498223A6812; Fri, 22 Jan 2010 07:52:49 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00M11O3MGO@szxga02-in.huawei.com>; Fri, 22 Jan 2010 23:52:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN0020NO3MII@szxga02-in.huawei.com>; Fri, 22 Jan 2010 23:52:34 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWN005DUO3M6K@szxml02-in.huawei.com>; Fri, 22 Jan 2010 23:52:34 +0800 (CST) Date: Fri, 22 Jan 2010 16:51:58 +0100 From: Maarten Vissers In-reply-to: <787be2781001211320q782f4e27hf6a04de031cfefb4@mail.gmail.com> To: 'Greg Mirsky' Message-id: <000001ca9b7a$e94837a0$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_WZiUZsvpmmtfhkrent2stA)" Thread-index: Acqa39StXLJTo/AnSAu3Z0X1ine+VgARPByw Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:52:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_WZiUZsvpmmtfhkrent2stA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_WZiUZsvpmmtfhkrent2stA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Greg,
 
It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg
--Boundary_(ID_WZiUZsvpmmtfhkrent2stA)-- From neil.2.harrison@bt.com Fri Jan 22 08:13:01 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E303A6812; Fri, 22 Jan 2010 08:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 PeacFfCoB1H2; Fri, 22 Jan 2010 08:12:59 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4DE073A686C; Fri, 22 Jan 2010 08:12:59 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 16:05:36 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9B7C.BB6DDB27" Date: Fri, 22 Jan 2010 16:05:33 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C058B5CCB@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <000001ca9b7a$e94837a0$e6150674@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: Acqa39StXLJTo/AnSAu3Z0X1ine+VgARPBywABWaX9A= From: To: , X-OriginalArrivalTime: 22 Jan 2010 16:05:36.0361 (UTC) FILETIME=[BBDDDD90:01CA9B7C] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:13:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9B7C.BB6DDB27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. =20 What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. =20 Perhaps there is something additional however that I am missing here? =20 regards, Neil ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Greg, =20 It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. =20 Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. =09 Regards, Greg =09 ------_=_NextPart_001_01CA9B7C.BB6DDB27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I guess this depends on one's = definition of=20 what a section layer is.  I think of a section layer as "the place = where=20 the *binary information symbol* meets the *q'ary symbol = metallic/optical/radio=20 road*"....so this is a true BOS (symbol/lexicon conversion) = function=20 in order to be able to modulate an EM wave and hence be able to send = information=20 over significant geographic distance.
 
What you describe below Maarten = reads to me=20 as a how a (client) *binary information* link connection at layer N is = supported=20 by a (server) *binary network connection* at layer N-1....so its just = how we=20 support a normal link connection when we are not at the = BOS.
 
Perhaps there is something = additional however=20 that I am missing here?
 
regards, = Neil


From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers
Sent: 22 January 2010 15:52
To: 'Greg=20 Mirsky'
Cc: mpls@ietf.org; = mpls-tp@ietf.org
Subject: Re:=20 [mpls-tp] RFC 5586: Intermediate nodes on MPLS = Section

Greg,
 
It is not uncommon to carry a section layer = signal as a=20 service through the network of another carrier. E.g. Ethernet port = based=20 services carry the Ethernet section layer signals as a service through = the=20 transport network. The compatible MPLS type of port based service = would carry=20 the MPLS section layer signal as a service through the network of = another=20 carrier. The section will now pass through intermediate=20 nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: donderdag 21 januari 2010 22:21
To: = BOCCI=20 Matthew; martin.vigoureux@alcatel-lucent.com; = stbryant@cisco.com
Cc:=20 mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: = Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as = contradiction between quoted in the RFC 5586 definition of the Section = Layer=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. = The=20 definition (section 1.3 p.4) refers to section as server layer that = provides=20 service between adjacent nodes (my underlining). At the same = time, the=20 last paragraph of subsection 4.2.1.2 stipulates behavior of = intermediate nodes=20 on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If = an MPLS=20 Section is between adjacent nodes, then, as I understand the = definition, there=20 can not be intermediate nodes on the section (on the segment, but not = on a=20 section) at this particular layer.
Your clarification is greatly=20 appreciated.

Regards,
Greg
------_=_NextPart_001_01CA9B7C.BB6DDB27-- From maarten.vissers@huawei.com Fri Jan 22 08:30:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E7A3A6A48; Fri, 22 Jan 2010 08:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Iefnqf-kHExV; Fri, 22 Jan 2010 08:30:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EAA1D3A68EE; Fri, 22 Jan 2010 08:30:04 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00L8QPTYL2@szxga03-in.huawei.com>; Sat, 23 Jan 2010 00:29:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00B3RPTYK0@szxga03-in.huawei.com>; Sat, 23 Jan 2010 00:29:58 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWN00BNXPTYV4@szxml01-in.huawei.com>; Sat, 23 Jan 2010 00:29:58 +0800 (CST) Date: Fri, 22 Jan 2010 17:29:57 +0100 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C058B5CCB@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, gregimirsky@gmail.com Message-id: <005801ca9b80$22f59740$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_tZ3LnZ9UkEBCBW8jBOZmyg)" Thread-index: Acqa39StXLJTo/AnSAu3Z0X1ine+VgARPBywABWaX9AAANZ9MA== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:30:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tZ3LnZ9UkEBCBW8jBOZmyg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Neil, It seems that you mix up the physical media and section layer networks. I.e. your "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*".... is the function of the physical media layer network. The section layer is the client of the physical media layer and the server of the path layer. According to G.805, the section layer network is concerned with all functions which provide for the transfer of infomation between locations in path layer networks. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the connection. Regards, Maarten Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network." Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of layer networks within the transmission media layer network which is likely to be independently administered by a network operator by decomposing the transmission media layer network. The connectivity of a transmission media layer network cannot be directly modified by management action. Transmission media layer networks are divided into section layer networks and physical media layer networks. Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. The section layer network may be decomposed into specific section layer networks as described in the examples in clause 6. Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. The physical media layer network may be decomposed into specific physical media layer networks to represent, for example, wave division multiplexing. Since a server layer network does not exist for the lowest layer network (e.g. the physical media layer network) the network connection is directly supported by the media and not by a trail." _____ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 22 januari 2010 17:06 To: maarten.vissers@huawei.com; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. Perhaps there is something additional however that I am missing here? regards, Neil _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_tZ3LnZ9UkEBCBW8jBOZmyg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Neil,
 
It seems that you mix up the physical media and section layer networks. I.e. your "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*".... is the function of the physical media layer network. The section layer is the client of the physical media layer and the server of the path layer.
 
According to G.805, the section layer network is concerned with all functions which provide for the transfer of infomation between locations in path layer networks. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the connection.
 
Regards,
Maarten
 
Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network."
 
Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of layer networks within the transmission media layer network which is likely to be independently administered by a network operator by decomposing the transmission media layer network. The connectivity of a transmission media layer network cannot be directly modified by management action. Transmission media layer networks are divided into section layer networks and physical media layer networks.

Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. The section layer network may be decomposed into specific section layer networks as described in the examples in clause 6.

Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. The physical media layer network may be decomposed into specific physical media layer networks to represent, for example, wave division multiplexing. Since a server layer network does not exist for the lowest layer network (e.g. the physical media layer network) the network connection is directly supported by the media and not by a trail."

 

 



From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 22 januari 2010 17:06
To: maarten.vissers@huawei.com; gregimirsky@gmail.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

I guess this depends on one's definition of what a section layer is.  I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance.
 
What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS.
 
Perhaps there is something additional however that I am missing here?
 
regards, Neil


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers
Sent: 22 January 2010 15:52
To: 'Greg Mirsky'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Greg,
 
It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg
--Boundary_(ID_tZ3LnZ9UkEBCBW8jBOZmyg)-- From gregimirsky@gmail.com Fri Jan 22 08:55:33 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249CA3A68EF; Fri, 22 Jan 2010 08:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QTtKva50Cjmd; Fri, 22 Jan 2010 08:55:32 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id 95A583A6998; Fri, 22 Jan 2010 08:55:31 -0800 (PST) Received: by bwz24 with SMTP id 24so1234109bwz.29 for ; Fri, 22 Jan 2010 08:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Qv/cWwNMeudkD4ShLzGjXXRP4mqKJI7lZU3D6GWiM/s=; b=doY8em4ldYTwBKUQG1OJbSsVnn2mmORPjoL96RPsupwOMZh87bdErwWfUwjaDtegRW /ULLZbC0nr87ff4sywbzgwh7HG34EWGANzPk6dXnK5RrvrJK1Vv+ZTP9ABuieX0jDC0h jhNznSCwhS93sD7SaYUB163NRvC5o0nZOMA6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FY1UU/jNwJLcfX8W6O13Bd7ebFnY+yyHPXuEZ2HmM6qzxD94zodNxpFUQJsWwfVL2N /rEIC0FjtvrsE4Q0U3U+rzKrSMwhlqJSjzs09lVVYw92TUpyKd+e3Dvhd0/ZigQQyVzY x8j2Z5L1bTWekPYg+Dw5v/tFZgG/VUH81/fOs= MIME-Version: 1.0 Received: by 10.204.15.138 with SMTP id k10mr1838061bka.27.1264179323361; Fri, 22 Jan 2010 08:55:23 -0800 (PST) In-Reply-To: <000001ca9b7a$e94837a0$e6150674@china.huawei.com> References: <787be2781001211320q782f4e27hf6a04de031cfefb4@mail.gmail.com> <000001ca9b7a$e94837a0$e6150674@china.huawei.com> Date: Fri, 22 Jan 2010 08:55:23 -0800 Message-ID: <787be2781001220855m51e411f4nedff27f9acc7159d@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=000325557a62805b0d047dc3afee Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:55:33 -0000 --000325557a62805b0d047dc3afee Content-Type: text/plain; charset=ISO-8859-1 Dear Maarten, so this is carrier's carrier scenario when MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP section by intermediate nodes of server MPLS-TP layer be just plain violation of server-client model? Regards, Greg On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers wrote: > Greg, > > It is not uncommon to carry a section layer signal as a service through the > network of another carrier. E.g. Ethernet port based services carry the > Ethernet section layer signals as a service through the transport network. > The compatible MPLS type of port based service would carry the MPLS section > layer signal as a service through the network of another carrier. The > section will now pass through intermediate nodes. > > Regards, > Maarten > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *Greg Mirsky > *Sent:* donderdag 21 januari 2010 22:21 > *To:* BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; > stbryant@cisco.com > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Dear Editors and All, > I'm puzzled by what looks to me as contradiction between quoted in the RFC > 5586 definition of the Section Layer Network and the last paragraph on > sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to > section as server layer that provides service between *adjacent nodes* (my > underlining). At the same time, the last paragraph of subsection 4.2.1.2 > stipulates behavior of intermediate nodes on an MPLS Section in regard to > G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent > nodes, then, as I understand the definition, there can not be intermediate > nodes on the section (on the segment, but not on a section) at this > particular layer. > Your clarification is greatly appreciated. > > Regards, > Greg > --000325557a62805b0d047dc3afee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP sec= tion is client of MPLS-TP transport? But wouldn't presumed processing o= f client MPLS-TP section by intermediate nodes of server MPLS-TP layer be j= ust plain violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010= at 7:51 AM, Maarten Vissers <maarten.vissers@huawei.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Greg,
=A0
It is not uncommon to carry a section layer signal as a=20 service through the network of another carrier. E.g. Ethernet port based=20 services carry the Ethernet section layer signals as a service through the= =20 transport network. The compatible MPLS type of port based service would car= ry=20 the MPLS section layer signal as a service through the network of another= =20 carrier. The section will now pass through intermediate=20 nodes.
=A0
Regards,
Maarten


From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-= tp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI= =20 Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc:=20 mpls@ietf.org; mpls-tp@ietf.org
Subject:
[mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as= =20 contradiction between quoted in the RFC 5586 definition of the Section Laye= r=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The=20 definition (section 1.3 p.4) refers to section as server layer that provide= s=20 service between adjacent nodes (my underlining). At the same time, t= he=20 last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate no= des=20 on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an M= PLS=20 Section is between adjacent nodes, then, as I understand the definition, th= ere=20 can not be intermediate nodes on the section (on the segment, but not on a= =20 section) at this particular layer.
Your clarification is greatly=20 appreciated.

Regards,
Greg

--000325557a62805b0d047dc3afee-- From neil.2.harrison@bt.com Fri Jan 22 08:58:40 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43AC3A6846; Fri, 22 Jan 2010 08:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] 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 iPD6AICm+8Rf; Fri, 22 Jan 2010 08:58:39 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B548F3A6807; Fri, 22 Jan 2010 08:58:38 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 16:49:36 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9B82.E0E89F99" Date: Fri, 22 Jan 2010 16:49:33 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C058B5D10@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <005801ca9b80$22f59740$e6150674@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: Acqa39StXLJTo/AnSAu3Z0X1ine+VgARPBywABWaX9AAANZ9MAAAovRQ From: To: , X-OriginalArrivalTime: 22 Jan 2010 16:49:36.0541 (UTC) FILETIME=[E1895CD0:01CA9B82] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:58:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9B82.E0E89F99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the additional information and pointers Maarten Seems to me like the major functional difference between 'section' and 'physical' is that the former operates in the binary symbol space and the other is a lexicon mapped q'ary symbol space (which is also a client/server relationship BTW). I'm not sure whether it would be fair to say any other factors (if there are any) are minor compared to this. =20 =20 regards, neil =20 ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 Sent: 22 January 2010 16:30 To: Harrison,N,Neil,DKQ7 R; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Neil, =20 It seems that you mix up the physical media and section layer networks. I.e. your "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*".... is the function of the physical media layer network. The section layer is the client of the physical media layer and the server of the path layer. =20 According to G.805, the section layer network is concerned with all functions which provide for the transfer of infomation between locations in path layer networks. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the connection. =20 Regards, Maarten =20 Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network." =20 Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of layer networks within the transmission media layer network which is likely to be independently administered by a network operator by decomposing the transmission media layer network. The connectivity of a transmission media layer network cannot be directly modified by management action. Transmission media layer networks are divided into section layer networks and physical media layer networks.=20 Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. The section layer network may be decomposed into specific section layer networks as described in the examples in clause 6. Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. The physical media layer network may be decomposed into specific physical media layer networks to represent, for example, wave division multiplexing. Since a server layer network does not exist for the lowest layer network (e.g. the physical media layer network) the network connection is directly supported by the media and not by a trail." =20 =20 ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: vrijdag 22 januari 2010 17:06 To: maarten.vissers@huawei.com; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. =20 What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. =20 Perhaps there is something additional however that I am missing here? =20 regards, Neil ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Greg, =20 It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. =20 Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. =09 Regards, Greg =09 ------_=_NextPart_001_01CA9B82.E0E89F99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the additional = information and=20 pointers Maarten  Seems to me like the major functional difference = between=20 'section' and 'physical' is that the former operates in the binary = symbol space=20 and the other is a lexicon mapped q'ary symbol space (which is also a=20 client/server relationship BTW).   I'm not sure whether it = would be=20 fair to say any other factors (if there are any) are minor compared to=20 this. 
 
regards, neil
 


From: Maarten Vissers=20 [mailto:maarten.vissers@huawei.com]
Sent: 22 January 2010=20 16:30
To: Harrison,N,Neil,DKQ7 R;=20 gregimirsky@gmail.com
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: = Intermediate nodes=20 on MPLS Section

Neil,
 
It seems that you mix up the physical media = and section=20 layer networks. I.e. your "the place where the *binary information symbol* meets the = *q'ary=20 symbol metallic/optical/radio road*".... is the function of the = physical media layer network. The section layer is the client of the = physical=20 media layer and the server of the path layer.
 
According to G.805, the section layer network = is=20 concerned with all functions which provide for the transfer of = infomation=20 between locations in path layer networks. It is this latter item that = allows=20 section layer trails to span multiple physical media layer trails, and = thus to=20 have intermediate nodes in the connection.
 
Regards,
Maarten
 
Section 1.2.2/RFC5654 describes: "Note that G.805 = [ITU.G805.2000]=20 defines the section layer as one of the two layer networks in a=20 transmission-media layer network. The other layer network is the=20 physical-media layer = network."
 
Section 5.3.3.3.3/G.805 describes: "It is possible to=20 identify a set of layer networks within the transmission media layer = network=20 which is likely to be independently administered by a network operator = by=20 decomposing the transmission media layer network. The connectivity of = a=20 transmission media layer network cannot be directly modified by = management=20 action. Transmission media layer networks are divided into section = layer=20 networks and physical media layer networks.=20

Section layer = networks are=20 concerned with all the functions which provide for the transfer of = information=20 between locations in path layer networks. The section layer network = may be=20 decomposed into specific section layer networks as described in the = examples=20 in clause 6.

Physical media layer = networks are=20 concerned with the actual fibres, metallic wires or radio frequency = channels=20 which support a section layer network. The physical media layer = network may be=20 decomposed into specific physical media layer networks to represent, = for=20 example, wave division multiplexing. Since a server layer network does = not=20 exist for the lowest layer network (e.g. the physical media layer = network) the=20 network connection is directly supported by the media and not by a=20 trail."

 

 



From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 22 januari = 2010=20 17:06
To: maarten.vissers@huawei.com;=20 gregimirsky@gmail.com
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: = Intermediate nodes=20 on MPLS Section

I guess this depends on one's = definition of=20 what a section layer is.  I think of a section layer as "the = place where=20 the *binary information symbol* meets the *q'ary symbol = metallic/optical/radio=20 road*"....so this is a true BOS (symbol/lexicon conversion) = function=20 in order to be able to modulate an EM wave and hence be able to send=20 information over significant geographic distance.
 
What you describe below Maarten = reads to me=20 as a how a (client) *binary information* link connection at layer N is = supported by a (server) *binary network connection* at layer N-1....so = its=20 just how we support a normal link connection when we are not at the=20 BOS.
 
Perhaps there is something = additional=20 however that I am missing here?
 
regards, = Neil


From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers
Sent: 22 January 2010 15:52
To: 'Greg=20 Mirsky'
Cc: mpls@ietf.org; = mpls-tp@ietf.org
Subject: Re:=20 [mpls-tp] RFC 5586: Intermediate nodes on MPLS = Section

Greg,
 
It is not uncommon to carry a section layer = signal as a=20 service through the network of another carrier. E.g. Ethernet port = based=20 services carry the Ethernet section layer signals as a service = through the=20 transport network. The compatible MPLS type of port based service = would=20 carry the MPLS section layer signal as a service through the network = of=20 another carrier. The section will now pass through intermediate=20 nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org=20 [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: donderdag 21 januari 2010 22:21
To: = BOCCI=20 Matthew; martin.vigoureux@alcatel-lucent.com;=20 stbryant@cisco.com
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate = nodes=20 on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me = as=20 contradiction between quoted in the RFC 5586 definition of the = Section Layer=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. = The=20 definition (section 1.3 p.4) refers to section as server layer that = provides=20 service between adjacent nodes (my underlining). At the same = time,=20 the last paragraph of subsection 4.2.1.2 stipulates behavior of = intermediate=20 nodes on an MPLS Section in regard to G-ACh message, the ACH and the = GAL. If=20 an MPLS Section is between adjacent nodes, then, as I understand the = definition, there can not be intermediate nodes on the section (on = the=20 segment, but not on a section) at this particular layer.
Your=20 clarification is greatly=20 appreciated.

Regards,
Greg
= ------_=_NextPart_001_01CA9B82.E0E89F99-- From gregimirsky@gmail.com Fri Jan 22 09:11:22 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7EC3A69F4; Fri, 22 Jan 2010 09:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DNwaa9eAHjSP; Fri, 22 Jan 2010 09:11:14 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id B05983A6A94; Fri, 22 Jan 2010 09:11:13 -0800 (PST) Received: by bwz24 with SMTP id 24so1251390bwz.29 for ; Fri, 22 Jan 2010 09:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ITYt6bk2Qvml1hgI2Ovd7HM2jb2yKoBhHgQCFxI/bbs=; b=E/hgwg1du6reZST0vJuubMqPmT4qFKgBolloLa4w2roK9z5Z/IG6DqvPFhtBUfTWKK 8eZh7XFK6kRi+J3NF8poS30A952AxBxcS2fBN+GWSdD3Jm08HtpzTIhAvJivlfbMdLby IjU/PSGIi1SPaamjUD9cUC7WUWq6l+35DsDQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kRpNv2dYQ+4ZuhMIhwIWq3XQvAQAxoC2j6rX2NB3TuqwhszyEzfHsomRN9yRezHmRR AeP7MklkpY/s1q3NCIsn+KX45CKUHglqzTOxyWr7DEm1bwjqkLBbwa/zWZmAtsjTvIN5 mlYnOMiXS+x21ChHpTpDNHE4HNj3G+SxKE8C0= MIME-Version: 1.0 Received: by 10.204.48.197 with SMTP id s5mr1801584bkf.88.1264180265282; Fri, 22 Jan 2010 09:11:05 -0800 (PST) In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C058B5CCB@E03MVB2-UKBR.domain1.systemhost.net> References: <000001ca9b7a$e94837a0$e6150674@china.huawei.com> <2ECAA42C79676B42AEBAC11229CA7D0C058B5CCB@E03MVB2-UKBR.domain1.systemhost.net> Date: Fri, 22 Jan 2010 09:11:05 -0800 Message-ID: <787be2781001220911r97888c6w6e1ee4d8d46a263e@mail.gmail.com> From: Greg Mirsky To: neil.2.harrison@bt.com Content-Type: multipart/alternative; boundary=00032555bc1ea4eebe047dc3e76a Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:11:22 -0000 --00032555bc1ea4eebe047dc3e76a Content-Type: text/plain; charset=ISO-8859-1 Dear Neil, the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "*A network segment between two LSRs that are immediately adjacent at the MPLS layer*". Thus, as I understand this definition, MPLS Section is not yet the layer of opaque binary symbols to be transformed into pulses and such but, on the other hand, it can not have intermediate MPLS-TP nodes either as it presents atomic element of MPLS-TP transport layer. Regards, Greg On Fri, Jan 22, 2010 at 8:05 AM, wrote: > I guess this depends on one's definition of what a section layer is. I > think of a section layer as "the place where the *binary information symbol* > meets the *q'ary symbol metallic/optical/radio road*"....so this is a true > BOS (symbol/lexicon conversion) function in order to be able to modulate an > EM wave and hence be able to send information over significant geographic > distance. > > What you describe below Maarten reads to me as a how a (client) *binary > information* link connection at layer N is supported by a (server) *binary > network connection* at layer N-1....so its just how we support a normal link > connection when we are not at the BOS. > > Perhaps there is something additional however that I am missing here? > > regards, Neil > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *Maarten Vissers > *Sent:* 22 January 2010 15:52 > *To:* 'Greg Mirsky' > > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Greg, > > It is not uncommon to carry a section layer signal as a service through the > network of another carrier. E.g. Ethernet port based services carry the > Ethernet section layer signals as a service through the transport network. > The compatible MPLS type of port based service would carry the MPLS section > layer signal as a service through the network of another carrier. The > section will now pass through intermediate nodes. > > Regards, > Maarten > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On > Behalf Of *Greg Mirsky > *Sent:* donderdag 21 januari 2010 22:21 > *To:* BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; > stbryant@cisco.com > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Dear Editors and All, > I'm puzzled by what looks to me as contradiction between quoted in the RFC > 5586 definition of the Section Layer Network and the last paragraph on > sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to > section as server layer that provides service between *adjacent nodes* (my > underlining). At the same time, the last paragraph of subsection 4.2.1.2 > stipulates behavior of intermediate nodes on an MPLS Section in regard to > G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent > nodes, then, as I understand the definition, there can not be intermediate > nodes on the section (on the segment, but not on a section) at this > particular layer. > Your clarification is greatly appreciated. > > Regards, > Greg > > --00032555bc1ea4eebe047dc3e76a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Neil,
the RFC refers to "MPLS Section" that is defined in= the MPLS-TP Rosetta Stone as "A network segment between two LSRs t= hat are immediately adjacent at the MPLS layer". Thus, as I unde= rstand this definition, MPLS Section is not yet the layer of opaque binary = symbols to be transformed into pulses and such but, on the other hand, it c= an not have intermediate MPLS-TP nodes either as it presents atomic element= of MPLS-TP transport layer.

Regards,
Greg

On Fri, Jan 22, 2010= at 8:05 AM, <neil.2.harrison@bt.com> wrote:
I guess this depends on one's definition of=20 what a section layer is.=A0 I think of a section layer as "the place w= here=20 the *binary information symbol* meets the *q'ary symbol metallic/optica= l/radio=20 road*"....so this is a=A0true BOS=A0(symbol/lexicon conversion) functi= on=20 in order to be able to modulate an EM wave and hence be able to send inform= ation=20 over significant geographic distance.
=A0
What you describe below Maarten reads to me=20 as a how a (client) *binary information* link connection at layer N is supp= orted=20 by a (server) *binary network connection* at layer N-1....so its just how w= e=20 support a normal link connection when we are not at the BOS.<= /div>
=A0
Perhaps there is something additional h= owever=20 that I am missing here?
=A0
regards, Neil


From: mpls-tp-bounces@ietf.org=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Maarten=20 Vissers
Sent: 22 January 2010 15:52
To: 'Greg=20 Mirsky'Subject: Re:=20 [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Greg,
=A0
It is not uncommon to carry a section layer signal as a=20 service through the network of another carrier. E.g. Ethernet port based= =20 services carry the Ethernet section layer signals as a service through th= e=20 transport network. The compatible MPLS type of port based service would c= arry=20 the MPLS section layer signal as a service through the network of another= =20 carrier. The section will now pass through intermediate=20 nodes.
=A0
Regards,
Maarten


From: mpls-tp-bounces@ietf.org=20 [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCC= I=20 Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc:=20 mpls@ietf.org; mpls-tp@ietf.org
= Subject: [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me a= s=20 contradiction between quoted in the RFC 5586 definition of the Section La= yer=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The= =20 definition (section 1.3 p.4) refers to section as server layer that provi= des=20 service between adjacent nodes (my underlining). At the same time,= the=20 last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate = nodes=20 on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an= MPLS=20 Section is between adjacent nodes, then, as I understand the definition, = there=20 can not be intermediate nodes on the section (on the segment, but not on = a=20 section) at this particular layer.
Your clarification is greatly=20 appreciated.

Regards,
Greg

--00032555bc1ea4eebe047dc3e76a-- From maarten.vissers@huawei.com Fri Jan 22 09:13:16 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E36B28B23E; Fri, 22 Jan 2010 09:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_81=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 OVBL2y17fMzP; Fri, 22 Jan 2010 09:13:09 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 239133A6998; Fri, 22 Jan 2010 09:13:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00C4URTRC5@szxga03-in.huawei.com>; Sat, 23 Jan 2010 01:13:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN0016ERTRLT@szxga03-in.huawei.com>; Sat, 23 Jan 2010 01:13:03 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWN00JQERTRSH@szxml02-in.huawei.com>; Sat, 23 Jan 2010 01:13:03 +0800 (CST) Date: Fri, 22 Jan 2010 18:13:02 +0100 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C058B5D10@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, gregimirsky@gmail.com Message-id: <007201ca9b86$2788cc40$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_9AG1Br0KfQrxVl6cVZsl1Q)" Thread-index: Acqa39StXLJTo/AnSAu3Z0X1ine+VgARPBywABWaX9AAANZ9MAAAovRQAAEtJ+A= Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:13:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9AG1Br0KfQrxVl6cVZsl1Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I don't consider the symbol space as a important functional difference from an management perspective. The major functional difference is the role of each layer in the network. Regards, Maarten _____ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 22 januari 2010 17:50 To: maarten.vissers@huawei.com; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thanks for the additional information and pointers Maarten Seems to me like the major functional difference between 'section' and 'physical' is that the former operates in the binary symbol space and the other is a lexicon mapped q'ary symbol space (which is also a client/server relationship BTW). I'm not sure whether it would be fair to say any other factors (if there are any) are minor compared to this. regards, neil _____ From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: 22 January 2010 16:30 To: Harrison,N,Neil,DKQ7 R; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Neil, It seems that you mix up the physical media and section layer networks. I.e. your "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*".... is the function of the physical media layer network. The section layer is the client of the physical media layer and the server of the path layer. According to G.805, the section layer network is concerned with all functions which provide for the transfer of infomation between locations in path layer networks. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the connection. Regards, Maarten Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network." Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of layer networks within the transmission media layer network which is likely to be independently administered by a network operator by decomposing the transmission media layer network. The connectivity of a transmission media layer network cannot be directly modified by management action. Transmission media layer networks are divided into section layer networks and physical media layer networks. Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. The section layer network may be decomposed into specific section layer networks as described in the examples in clause 6. Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. The physical media layer network may be decomposed into specific physical media layer networks to represent, for example, wave division multiplexing. Since a server layer network does not exist for the lowest layer network (e.g. the physical media layer network) the network connection is directly supported by the media and not by a trail." _____ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 22 januari 2010 17:06 To: maarten.vissers@huawei.com; gregimirsky@gmail.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. Perhaps there is something additional however that I am missing here? regards, Neil _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_9AG1Br0KfQrxVl6cVZsl1Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I don't consider the symbol space as a important functional difference from an management perspective. The major functional difference is the role of each layer in the network.
 
Regards,
Maarten


From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 22 januari 2010 17:50
To: maarten.vissers@huawei.com; gregimirsky@gmail.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Thanks for the additional information and pointers Maarten  Seems to me like the major functional difference between 'section' and 'physical' is that the former operates in the binary symbol space and the other is a lexicon mapped q'ary symbol space (which is also a client/server relationship BTW).   I'm not sure whether it would be fair to say any other factors (if there are any) are minor compared to this. 
 
regards, neil
 


From: Maarten Vissers [mailto:maarten.vissers@huawei.com]
Sent: 22 January 2010 16:30
To: Harrison,N,Neil,DKQ7 R; gregimirsky@gmail.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Neil,
 
It seems that you mix up the physical media and section layer networks. I.e. your "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*".... is the function of the physical media layer network. The section layer is the client of the physical media layer and the server of the path layer.
 
According to G.805, the section layer network is concerned with all functions which provide for the transfer of infomation between locations in path layer networks. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the connection.
 
Regards,
Maarten
 
Section 1.2.2/RFC5654 describes: "Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network."
 
Section 5.3.3.3.3/G.805 describes: "It is possible to identify a set of layer networks within the transmission media layer network which is likely to be independently administered by a network operator by decomposing the transmission media layer network. The connectivity of a transmission media layer network cannot be directly modified by management action. Transmission media layer networks are divided into section layer networks and physical media layer networks.

Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. The section layer network may be decomposed into specific section layer networks as described in the examples in clause 6.

Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. The physical media layer network may be decomposed into specific physical media layer networks to represent, for example, wave division multiplexing. Since a server layer network does not exist for the lowest layer network (e.g. the physical media layer network) the network connection is directly supported by the media and not by a trail."

 

 



From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 22 januari 2010 17:06
To: maarten.vissers@huawei.com; gregimirsky@gmail.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

I guess this depends on one's definition of what a section layer is.  I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance.
 
What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS.
 
Perhaps there is something additional however that I am missing here?
 
regards, Neil


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers
Sent: 22 January 2010 15:52
To: 'Greg Mirsky'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Greg,
 
It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg
--Boundary_(ID_9AG1Br0KfQrxVl6cVZsl1Q)-- From neil.2.harrison@bt.com Fri Jan 22 09:51:39 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB2D3A688F; Fri, 22 Jan 2010 09:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] 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 uVfYtFwEFjwS; Fri, 22 Jan 2010 09:51:38 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 9EFEF3A6870; Fri, 22 Jan 2010 09:51:37 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 17:51:32 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9B8B.8822BFEA" Date: Fri, 22 Jan 2010 17:51:30 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C058B5D50@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <787be2781001220911r97888c6w6e1ee4d8d46a263e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbheQ+RLKWCKnWSea6tIHeHLbQ2AAAUX6g From: To: X-OriginalArrivalTime: 22 Jan 2010 17:51:32.0633 (UTC) FILETIME=[88800090:01CA9B8B] Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:51:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9B8B.8822BFEA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Greg for bringing up a key point: =20 ""MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". .......think we need to factor-in S bit sublayering here. =20 S bit sublayering in MPLS allows one to have multiple signalling protocols (though I would hardly call LDP a signalling protocol, and I'm not sure that BGP4 dist of labels fits either) whilst attempting to preserve the notion of 'a single common routing instance', ie a single instance of routing which spans all the S bit sublayers. This model is not a very good one for a transport role (for many reasons) and yet it seems it persists in MPLS-TP....and it's also partly responsible for the error of creating a MS PW layer network *above* MPLS-TP...which as an aside observation destroys the notion of a 'common instance of routing' anyway! =20 All this is hardly good behaviour for an aspiring transport network and MPLS-TP would be far better off without the S bit sublayering (and for sure MS PWs) and thus each LSP would belong to its own layer network like all other network technologies in fact (MPLS is the odd man out here). =20 So, the point I am teasing out here is that there is a difference between: - a false client/server relationship where a 'link sublayer connection' at MPLS level N is provided by a 'LSP sublayer connection' at MPLS level N-1, and - a true client/server relationship where a 'link connection' in MPLS layer network N is provided by a 'LSP network connection' at MPLS layer network N-1. =20 Note - Please ignore actual words/vocab used here, it is the concept that I am trying to get across that is important. =20 Of course, this is all additional to the original point I raised with Maarten wrt to difference between 'section' and 'physical'...though sublayering does (unnecessarily) muddy this up as I noted above. =20 BTW Maarten there are important management functions at the physical layer due to section/physical binary<=3D>q'ary symbol mappings (which is = a client/server relationship) because there is usually significant redundancy in the server q'ary symbols (ie it has a larger lexicon than it binary client) to allow for things like spectral-shaping/zero-dc, error detection..... =20 regards, Neil ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 22 January 2010 17:11 To: Harrison,N,Neil,DKQ7 R Cc: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Dear Neil, the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". Thus, as I understand this definition, MPLS Section is not yet the layer of opaque binary symbols to be transformed into pulses and such but, on the other hand, it can not have intermediate MPLS-TP nodes either as it presents atomic element of MPLS-TP transport layer. =09 Regards, Greg =09 =09 On Fri, Jan 22, 2010 at 8:05 AM, wrote: =09 I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. =20 What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. =20 Perhaps there is something additional however that I am missing here? =20 regards, Neil ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky'=20 Cc: mpls@ietf.org; mpls-tp@ietf.org =09 Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Greg, =20 It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. =20 Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. =09 Regards, Greg =09 ------_=_NextPart_001_01CA9B8B.8822BFEA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Greg for bringing up = a key=20 point:
 
""MPLS Section" that is defined in the MPLS-TP Rosetta = Stone as=20 "A network segment between two LSRs that are immediately adjacent at = the MPLS=20 layer". .......think we need to factor-in S bit=20 sublayering here.
 
S bit sublayering in MPLS allows = one to have=20 multiple signalling protocols (though I would hardly call LDP a = signalling=20 protocol, and I'm not sure that BGP4 dist of labels fits either) whilst=20 attempting to preserve the notion of 'a single common routing instance', = ie a=20 single instance of routing which spans all the S bit sublayers.  = This model=20 is not a very good one for a transport role (for many reasons) and yet = it seems=20 it persists in MPLS-TP....and it's also partly responsible for the error = of=20 creating a MS PW layer network *above* MPLS-TP...which as an aside = observation=20 destroys the notion of a 'common instance of routing'=20 anyway!
 
All this is hardly good behaviour = for an=20 aspiring transport network and MPLS-TP would be far better off = without the S=20 bit sublayering (and for sure MS PWs) and thus each LSP would belong to = its=20 own layer network like all other network technologies in = fact=20 (MPLS is the odd man out here).
 
So, the point I am teasing out = here is that=20 there is a difference between:
-    a false=20 client/server relationship where a 'link sublayer connection' at MPLS = level N is=20 provided by a 'LSP sublayer connection' at MPLS level N-1,=20 and
-    a true = client/server=20 relationship where a 'link connection' in MPLS layer network N is = provided by a=20 'LSP network connection' at MPLS layer network N-1.
 
Note - Please ignore actual words/vocab used here, it is = the=20 concept that I am trying to get across that is = important.
 
Of=20 course, this is all additional to the original point I raised with = Maarten wrt=20 to difference between 'section' and 'physical'...though sublayering does = (unnecessarily) muddy this up as I noted above.
 
BTW=20 Maarten there are important management functions at the physical = layer due=20 to section/physical binary<=3D>q'ary symbol mappings (which = is a=20 client/server relationship) because there is usually significant = redundancy in=20 the server q'ary symbols (ie it has a larger lexicon than it binary = client) to=20 allow for things like spectral-shaping/zero-dc, error=20 detection.....
 
regards, Neil


From: Greg Mirsky=20 [mailto:gregimirsky@gmail.com]
Sent: 22 January 2010=20 17:11
To: Harrison,N,Neil,DKQ7 R
Cc:=20 maarten.vissers@huawei.com; mpls@ietf.org; = mpls-tp@ietf.org
Subject:=20 Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS=20 Section

Dear Neil,
the RFC refers to "MPLS Section" that is = defined in=20 the MPLS-TP Rosetta Stone as "A network segment between two LSRs = that are=20 immediately adjacent at the MPLS layer". Thus, as I understand = this=20 definition, MPLS Section is not yet the layer of opaque binary symbols = to be=20 transformed into pulses and such but, on the other hand, it can not = have=20 intermediate MPLS-TP nodes either as it presents atomic element of = MPLS-TP=20 transport layer.

Regards,
Greg

On Fri, Jan 22, 2010 at 8:05 AM, <neil.2.harrison@bt.com>=20 wrote:
I=20 guess this depends on one's definition of what a section layer = is.  I=20 think of a section layer as "the place where the *binary information = symbol*=20 meets the *q'ary symbol metallic/optical/radio road*"....so this is=20 a true BOS (symbol/lexicon conversion) function in order = to be=20 able to modulate an EM wave and hence be able to send information = over=20 significant geographic distance.
 
What=20 you describe below Maarten reads to me as a how a (client) *binary=20 information* link connection at layer N is supported by a (server) = *binary=20 network connection* at layer N-1....so its just how we support a = normal link=20 connection when we are not at the BOS.
 
Perhaps there is something = additional=20 however that I am missing here?
 
regards, Neil


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Maarten=20 Vissers
Sent: 22 January 2010 15:52
To: 'Greg = Mirsky' Subject: Re: = [mpls-tp]=20 RFC 5586: Intermediate nodes on MPLS Section

Greg,
 
It is=20 not uncommon to carry a section layer signal as a service through = the=20 network of another carrier. E.g. Ethernet port based services = carry the=20 Ethernet section layer signals as a service through the transport = network.=20 The compatible MPLS type of port based service would carry the = MPLS=20 section layer signal as a service through the network of another = carrier.=20 The section will now pass through intermediate = nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of = Greg=20 Mirsky
Sent: donderdag 21 januari 2010 = 22:21
To: BOCCI=20 Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; = mpls-tp@ietf.org
Subject: [mpls-tp] = RFC 5586:=20 Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to = me as=20 contradiction between quoted in the RFC 5586 definition of the = Section=20 Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS = Section.=20 The definition (section 1.3 p.4) refers to section as server layer = that=20 provides service between adjacent nodes (my underlining). = At the=20 same time, the last paragraph of subsection 4.2.1.2 stipulates = behavior of=20 intermediate nodes on an MPLS Section in regard to G-ACh message, = the ACH=20 and the GAL. If an MPLS Section is between adjacent nodes, then, = as I=20 understand the definition, there can not be intermediate nodes on = the=20 section (on the segment, but not on a section) at this particular=20 layer.
Your clarification is greatly=20 = appreciated.

Regards,
Greg

------_=_NextPart_001_01CA9B8B.8822BFEA-- From root@core3.amsl.com Fri Jan 22 10:30:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A6B2D3A6A76; Fri, 22 Jan 2010 10:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100122183002.A6B2D3A6A76@core3.amsl.com> Date: Fri, 22 Jan 2010 10:30:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:30:02 -0000 --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 in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-08.txt Pages : 49 Date : 2010-01-22 This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched equivalents of traditional circuit- switched carrier networks. It describes a common set of protocol functions - the MPLS Transport Profile (MPLS-TP) - that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bi-directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point paths. The remaining subset, applicable specifically to point-to-multipoint paths, are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-22101811.I-D@ietf.org> --NextPart-- From maarten.vissers@huawei.com Fri Jan 22 10:37:17 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5638A28C0F1; Fri, 22 Jan 2010 10:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_81=0.6, RDNS_NONE=0.1] 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 yrxjyTmbGwmg; Fri, 22 Jan 2010 10:37:15 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5A4833A6936; Fri, 22 Jan 2010 10:37:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00F22VPOLZ@szxga04-in.huawei.com>; Sat, 23 Jan 2010 02:37:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00M2EVPOUM@szxga04-in.huawei.com>; Sat, 23 Jan 2010 02:37:00 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWN005YMVPO6K@szxml02-in.huawei.com>; Sat, 23 Jan 2010 02:37:00 +0800 (CST) Date: Fri, 22 Jan 2010 19:36:59 +0100 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C058B5D50@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, gregimirsky@gmail.com Message-id: <008c01ca9b91$e201c350$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_qUMNWtLYnBeO240M6dy0Lg)" Thread-index: AcqbheQ+RLKWCKnWSea6tIHeHLbQ2AAAUX6gAAKNgoA= Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:37:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qUMNWtLYnBeO240M6dy0Lg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Neil, > BTW Maarten there are important management functions at the physical layer due to > section/physical binary<=>q'ary symbol mappings (which is a client/server relationship) > because there is usually significant redundancy in the server q'ary symbols (ie it has a > larger lexicon than it binary client) to allow for things like spectral-shaping/zero-dc, > error detection..... If I look at the management objects in the information model, then I don't find any of your "important management functions at the physical layer" being listed... i.e. those fucntions seems to be hidden from the management viewpoint... Regards, Maarten _____ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: vrijdag 22 januari 2010 18:52 To: gregimirsky@gmail.com Cc: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thanks Greg for bringing up a key point: ""MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". .......think we need to factor-in S bit sublayering here. S bit sublayering in MPLS allows one to have multiple signalling protocols (though I would hardly call LDP a signalling protocol, and I'm not sure that BGP4 dist of labels fits either) whilst attempting to preserve the notion of 'a single common routing instance', ie a single instance of routing which spans all the S bit sublayers. This model is not a very good one for a transport role (for many reasons) and yet it seems it persists in MPLS-TP....and it's also partly responsible for the error of creating a MS PW layer network *above* MPLS-TP...which as an aside observation destroys the notion of a 'common instance of routing' anyway! All this is hardly good behaviour for an aspiring transport network and MPLS-TP would be far better off without the S bit sublayering (and for sure MS PWs) and thus each LSP would belong to its own layer network like all other network technologies in fact (MPLS is the odd man out here). So, the point I am teasing out here is that there is a difference between: - a false client/server relationship where a 'link sublayer connection' at MPLS level N is provided by a 'LSP sublayer connection' at MPLS level N-1, and - a true client/server relationship where a 'link connection' in MPLS layer network N is provided by a 'LSP network connection' at MPLS layer network N-1. Note - Please ignore actual words/vocab used here, it is the concept that I am trying to get across that is important. Of course, this is all additional to the original point I raised with Maarten wrt to difference between 'section' and 'physical'...though sublayering does (unnecessarily) muddy this up as I noted above. BTW Maarten there are important management functions at the physical layer due to section/physical binary<=>q'ary symbol mappings (which is a client/server relationship) because there is usually significant redundancy in the server q'ary symbols (ie it has a larger lexicon than it binary client) to allow for things like spectral-shaping/zero-dc, error detection..... regards, Neil _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: 22 January 2010 17:11 To: Harrison,N,Neil,DKQ7 R Cc: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Neil, the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". Thus, as I understand this definition, MPLS Section is not yet the layer of opaque binary symbols to be transformed into pulses and such but, on the other hand, it can not have intermediate MPLS-TP nodes either as it presents atomic element of MPLS-TP transport layer. Regards, Greg On Fri, Jan 22, 2010 at 8:05 AM, wrote: I guess this depends on one's definition of what a section layer is. I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance. What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS. Perhaps there is something additional however that I am missing here? regards, Neil _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: 22 January 2010 15:52 To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_qUMNWtLYnBeO240M6dy0Lg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Neil,
 
> BTW Maarten there are important management functions at the physical layer due to
> section/physical binary<=>q'ary symbol mappings (which is a client/server relationship)
> because there is usually significant redundancy in the server q'ary symbols (ie it has a
> larger lexicon than it binary client) to allow for things like spectral-shaping/zero-dc,
> error detection.....
 
If I look at the management objects in the information model, then I don't find any of your "important management functions at the physical layer" being listed... i.e. those fucntions seems to be hidden from the management viewpoint...
 
Regards,
Maarten
 

From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: vrijdag 22 januari 2010 18:52
To: gregimirsky@gmail.com
Cc: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Thanks Greg for bringing up a key point:
 
""MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". .......think we need to factor-in S bit sublayering here.
 
S bit sublayering in MPLS allows one to have multiple signalling protocols (though I would hardly call LDP a signalling protocol, and I'm not sure that BGP4 dist of labels fits either) whilst attempting to preserve the notion of 'a single common routing instance', ie a single instance of routing which spans all the S bit sublayers.  This model is not a very good one for a transport role (for many reasons) and yet it seems it persists in MPLS-TP....and it's also partly responsible for the error of creating a MS PW layer network *above* MPLS-TP...which as an aside observation destroys the notion of a 'common instance of routing' anyway!
 
All this is hardly good behaviour for an aspiring transport network and MPLS-TP would be far better off without the S bit sublayering (and for sure MS PWs) and thus each LSP would belong to its own layer network like all other network technologies in fact (MPLS is the odd man out here).
 
So, the point I am teasing out here is that there is a difference between:
-    a false client/server relationship where a 'link sublayer connection' at MPLS level N is provided by a 'LSP sublayer connection' at MPLS level N-1, and
-    a true client/server relationship where a 'link connection' in MPLS layer network N is provided by a 'LSP network connection' at MPLS layer network N-1.
 
Note - Please ignore actual words/vocab used here, it is the concept that I am trying to get across that is important.
 
Of course, this is all additional to the original point I raised with Maarten wrt to difference between 'section' and 'physical'...though sublayering does (unnecessarily) muddy this up as I noted above.
 
BTW Maarten there are important management functions at the physical layer due to section/physical binary<=>q'ary symbol mappings (which is a client/server relationship) because there is usually significant redundancy in the server q'ary symbols (ie it has a larger lexicon than it binary client) to allow for things like spectral-shaping/zero-dc, error detection.....
 
regards, Neil


From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: 22 January 2010 17:11
To: Harrison,N,Neil,DKQ7 R
Cc: maarten.vissers@huawei.com; mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Neil,
the RFC refers to "MPLS Section" that is defined in the MPLS-TP Rosetta Stone as "A network segment between two LSRs that are immediately adjacent at the MPLS layer". Thus, as I understand this definition, MPLS Section is not yet the layer of opaque binary symbols to be transformed into pulses and such but, on the other hand, it can not have intermediate MPLS-TP nodes either as it presents atomic element of MPLS-TP transport layer.

Regards,
Greg

On Fri, Jan 22, 2010 at 8:05 AM, <neil.2.harrison@bt.com> wrote:
I guess this depends on one's definition of what a section layer is.  I think of a section layer as "the place where the *binary information symbol* meets the *q'ary symbol metallic/optical/radio road*"....so this is a true BOS (symbol/lexicon conversion) function in order to be able to modulate an EM wave and hence be able to send information over significant geographic distance.
 
What you describe below Maarten reads to me as a how a (client) *binary information* link connection at layer N is supported by a (server) *binary network connection* at layer N-1....so its just how we support a normal link connection when we are not at the BOS.
 
Perhaps there is something additional however that I am missing here?
 
regards, Neil


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers
Sent: 22 January 2010 15:52
To: 'Greg Mirsky' Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Greg,
 
It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg

--Boundary_(ID_qUMNWtLYnBeO240M6dy0Lg)-- From gregimirsky@gmail.com Fri Jan 22 11:29:03 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9023628C0E3; Fri, 22 Jan 2010 11:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Czz-8fD25+jF; Fri, 22 Jan 2010 11:29:01 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id 6F8D93A6A8F; Fri, 22 Jan 2010 11:29:00 -0800 (PST) Received: by bwz24 with SMTP id 24so1378591bwz.29 for ; Fri, 22 Jan 2010 11:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O+NF11krTIJDXZ81NOObZgbTWNJFgUPeZrY9lptxC0o=; b=wvwIBqvgg5pjbBoAZAYRixEPIEOoBZIG4vmGRwDbaI9Mtu5dahuJZ+3clgrLB4z1AC IKpOFQWdFvWPfN4HSmpmKN3gHXqh+8KmJ+NJ9yHv0nonVT8VZaq6kk3W/ZzePu/Yu+Er RxtrW3Gyy8taWGBvyPirSygMi6rtlJQPVNiIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r6rRGFKEDcaXwvxlfowhOIzwGSmyoSAafi/PtervBhGXsClmxym4xejdCWfM3W/NiZ OSo3M3jP8T+LFKJyvf/0SyqOsWBd7NZWF80JoXtC9Pp0githFsjJt9uInZCbLQ5IZ/k+ 0bDX4iirmvtRH/s+mYXU0PMTC050HUqL/gzdk= MIME-Version: 1.0 Received: by 10.204.153.202 with SMTP id l10mr1922909bkw.92.1264188532620; Fri, 22 Jan 2010 11:28:52 -0800 (PST) In-Reply-To: <008601ca9b91$3c7934e0$e6150674@china.huawei.com> References: <787be2781001220855m51e411f4nedff27f9acc7159d@mail.gmail.com> <008601ca9b91$3c7934e0$e6150674@china.huawei.com> Date: Fri, 22 Jan 2010 11:28:52 -0800 Message-ID: <787be2781001221128t17a02582w5b123658793f1975@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=0015175d07506a7f24047dc5d425 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:29:03 -0000 --0015175d07506a7f24047dc5d425 Content-Type: text/plain; charset=ISO-8859-1 Dear Maarten, I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section. In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A. S-PEs of Carrier B are unaware of that MPLS Section. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering. That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only. Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion. Maarten, I greatly appreciate your input and our discussion. Regards, Greg On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers < maarten.vissers@huawei.com> wrote: > Hi Greg, > > The intermediate nodes contain multiple MPLS-TP (MTP) layer network > instances, of which the top MTP layer is shared by carrier A and B. See > slide 7 in the mplstp-connection-concepts file. Note that the same applies > for the case of Ethernet (ETH) layer networks. In the > attached ethernet-connection-concepts file you find the same case > illustrated also on slide 7. > > Other slides illustrate other cases of carrier-carrier and customer-carrier > interactions. > > Note that the functional models for the MPLS-TP and Ethernet cases are the > same; I already had the Ethernet models and have converted those into > MPLS-TP equivalent models to illustrate this section layer question. The > difference between both technologies is the encoding of MEG levels; in > Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry > (LSE) header. > > Regards, > Maarten > > ------------------------------ > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* vrijdag 22 januari 2010 17:55 > *To:* Maarten Vissers > > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Dear Maarten, > so this is carrier's carrier scenario when MPLS-TP section is client of > MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP > section by intermediate nodes of server MPLS-TP layer be just plain > violation of server-client model? > > Regards, > Greg > > On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers < > maarten.vissers@huawei.com> wrote: > >> Greg, >> >> It is not uncommon to carry a section layer signal as a service through >> the network of another carrier. E.g. Ethernet port based services carry the >> Ethernet section layer signals as a service through the transport network. >> The compatible MPLS type of port based service would carry the MPLS section >> layer signal as a service through the network of another carrier. The >> section will now pass through intermediate nodes. >> >> Regards, >> Maarten >> >> ------------------------------ >> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >> Behalf Of *Greg Mirsky >> *Sent:* donderdag 21 januari 2010 22:21 >> *To:* BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; >> stbryant@cisco.com >> *Cc:* mpls@ietf.org; mpls-tp@ietf.org >> *Subject:* [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section >> >> Dear Editors and All, >> I'm puzzled by what looks to me as contradiction between quoted in the RFC >> 5586 definition of the Section Layer Network and the last paragraph on >> sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to >> section as server layer that provides service between *adjacent nodes*(my underlining). At the same time, the last paragraph of subsection 4.2.1.2 >> stipulates behavior of intermediate nodes on an MPLS Section in regard to >> G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent >> nodes, then, as I understand the definition, there can not be intermediate >> nodes on the section (on the segment, but not on a section) at this >> particular layer. >> Your clarification is greatly appreciated. >> >> Regards, >> Greg >> > > --0015175d07506a7f24047dc5d425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 an= d the following you've wrote "The intermediate nodes contain multiple MP= LS-TP (MTP) layer=20 network instances". I think that from the definition of = MPLS Section follows that there can not be an intermediate MPLS node on a g= iven MPLS Section which is aware of that Section. In your example (slide #7= ) nodes P and P' (to differentiate them from left to right) of Carrier = A are terminating points of MPLS Section of Carrier A. S-PEs of Carrier B a= re unaware of that MPLS Section. Thus, when Node P sends OAM with GAL as BO= S to monitor the P-P' Section, none of nodes of Carrier B, including S-= PEs, should bother to process the GAL. Doing otherwise will break client-se= rver layering. That is why I can not agree that an intermediate node contai= ns instances of multiple MPLS-TP networks. I think of a node as performing = its functions at certain MPLS-TP network layer only. Another question is wh= ether Carrier B sets its VC label as BOS or not, as I understand we haven&#= 39;t decided yet with number of BOS in carrier's carrier scenario. But = that, to me, is separate discussion.
Maarten, I greatly appreciate your input and our discussion.

Regards= ,
Greg

On Fri, Jan 22, 2010 at 10:32 A= M, Maarten Vissers <maarten.vissers@huawei.com> wrote:
Hi Greg,
=A0
The intermediate nodes contain multiple MPLS-TP (MTP) layer=20 network instances, of which the top MTP layer is shared by carrier A and B.= See=20 slide 7 in the mplstp-connection-concepts file. Note that the same applies = for=20 the case of Ethernet (ETH) layer networks. In the=20 attached=A0ethernet-connection-concepts file you find the same case=20 illustrated also on slide 7.
=A0
Other slides illustrate other cases of carrier-carrier and=20 customer-carrier interactions.
=A0
Note that the functional models for the MPLS-TP and=20 Ethernet cases are the same; I already had the Ethernet models and have=20 converted those into MPLS-TP equivalent models to illustrate this section l= ayer=20 question. The difference between both technologies is the encoding of MEG= =20 levels; in Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label S= tack=20 Entry (LSE) header.
=A0
Regards,
Maarten


From: Greg Mirsky= [mailto:gregimi= rsky@gmail.com]=20
Sent: vrijdag 22 januari 2010 17:55
To: Maarten= =20 VissersSubject: Re:=20 [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

=
Dear Maarten,
so this is carrier's carrier scenario when = MPLS-TP=20 section is client of MPLS-TP transport? But wouldn't presumed processin= g of=20 client MPLS-TP section by intermediate nodes of server MPLS-TP layer be jus= t=20 plain violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers= <maarten.vissers@huawei.com>=20 wrote:
Greg,
=A0
It is not=20 uncommon to carry a section layer signal as a service through the network= of=20 another carrier. E.g. Ethernet port based services carry the Ethernet sec= tion=20 layer signals as a service through the transport network. The compatible = MPLS=20 type of port based service would carry the MPLS section layer signal as a= =20 service through the network of another carrier. The section will now pass= =20 through intermediate nodes.
=A0
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@= ietf.org] On Behalf Of Greg=20 Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCC= I=20 Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me a= s=20 contradiction between quoted in the RFC 5586 definition of the Section La= yer=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The= =20 definition (section 1.3 p.4) refers to section as server layer that provi= des=20 service between adjacent nodes (my underlining). At the same time,= the=20 last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate = nodes=20 on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an= MPLS=20 Section is between adjacent nodes, then, as I understand the definition, = there=20 can not be intermediate nodes on the section (on the segment, but not on = a=20 section) at this particular layer.
Your clarification is greatly=20 appreciated.

Regards,
Greg


--0015175d07506a7f24047dc5d425-- From Alexander.Vainshtein@ecitele.com Fri Jan 22 13:00:13 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0383A68EE; Fri, 22 Jan 2010 13:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 fh7wEzrybpu3; Fri, 22 Jan 2010 13:00:12 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 566293A68EB; Fri, 22 Jan 2010 13:00:11 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-a3-4b5a10bfa6c7 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id EA.E1.03798.FB01A5B4; Fri, 22 Jan 2010 22:55:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 22 Jan 2010 23:00:05 +0200 From: Alexander Vainshtein To: Greg Mirsky , Maarten Vissers Date: Fri, 22 Jan 2010 22:56:55 +0200 Thread-Topic: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSxHT4GPnJG+RQ2CHOJqLx6NMwADEIQ7 Message-ID: References: <787be2781001220855m51e411f4nedff27f9acc7159d@mail.gmail.com> <008601ca9b91$3c7934e0$e6150674@china.huawei.com>, <787be2781001221128t17a02582w5b123658793f1975@mail.gmail.com> In-Reply-To: <787be2781001221128t17a02582w5b123658793f1975@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEAILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 21:00:13 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEAILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, Maarten and all, I concur with Greg. If section connects adjacent nodes (at a certain layer)= , physical intermediate nodes crossed by such a section in the carriers' ca= rrier scenario are fully transparent to that. My 2c, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Greg Mirsk= y [gregimirsky@gmail.com] Sent: Friday, January 22, 2010 9:28 PM To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, I'll concentrate, as you suggested, on the slide #7 and the following you'v= e wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer networ= k instances". I think that from the definition of MPLS Section follows that= there can not be an intermediate MPLS node on a given MPLS Section which i= s aware of that Section. In your example (slide #7) nodes P and P' (to diff= erentiate them from left to right) of Carrier A are terminating points of M= PLS Section of Carrier A. S-PEs of Carrier B are unaware of that MPLS Secti= on. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section= , none of nodes of Carrier B, including S-PEs, should bother to process the= GAL. Doing otherwise will break client-server layering. That is why I can = not agree that an intermediate node contains instances of multiple MPLS-TP = networks. I think of a node as performing its functions at certain MPLS-TP = network layer only. Another question is whether Carrier B sets its VC label= as BOS or not, as I understand we haven't decided yet with number of BOS i= n carrier's carrier scenario. But that, to me, is separate discussion. Maarten, I greatly appreciate your input and our discussion. Regards, Greg On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers > wrote: Hi Greg, The intermediate nodes contain multiple MPLS-TP (MTP) layer network instanc= es, of which the top MTP layer is shared by carrier A and B. See slide 7 in= the mplstp-connection-concepts file. Note that the same applies for the ca= se of Ethernet (ETH) layer networks. In the attached ethernet-connection-co= ncepts file you find the same case illustrated also on slide 7. Other slides illustrate other cases of carrier-carrier and customer-carrier= interactions. Note that the functional models for the MPLS-TP and Ethernet cases are the = same; I already had the Ethernet models and have converted those into MPLS-= TP equivalent models to illustrate this section layer question. The differe= nce between both technologies is the encoding of MEG levels; in Ethernet vi= a the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) heade= r. Regards, Maarten ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 17:55 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, so this is carrier's carrier scenario when MPLS-TP section is client of MPL= S-TP transport? But wouldn't presumed processing of client MPLS-TP section = by intermediate nodes of server MPLS-TP layer be just plain violation of se= rver-client model? Regards, Greg On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers > wrote: Greg, It is not uncommon to carry a section layer signal as a service through the= network of another carrier. E.g. Ethernet port based services carry the Et= hernet section layer signals as a service through the transport network. Th= e compatible MPLS type of port based service would carry the MPLS section l= ayer signal as a service through the network of another carrier. The sectio= n will now pass through intermediate nodes. Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Greg M= irsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC = 5586 definition of the Section Layer Network and the last paragraph on sub-= section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to se= ction as server layer that provides service between adjacent nodes (my unde= rlining). At the same time, the last paragraph of subsection 4.2.1.2 stipul= ates behavior of intermediate nodes on an MPLS Section in regard to G-ACh m= essage, the ACH and the GAL. If an MPLS Section is between adjacent nodes, = then, as I understand the definition, there can not be intermediate nodes o= n the section (on the segment, but not on a section) at this particular lay= er. Your clarification is greatly appreciated. Regards, Greg --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEAILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greg, Maarten and all,
I concur with Greg. If sect= ion connects adjacent nodes (at a certain layer), physical interm= ediate nodes crossed by such a section in the carriers' carrier scenar= io are fully transparent to that.
 
My 2c,
     Sa= sha

From: mpls-bounces@ietf.org [mpls-b= ounces@ietf.org] On Behalf Of Greg Mirsky [gregimirsky@gmail.com]
Sent: Friday, January 22, 2010 9:28 PM
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS S= ection

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you'v= e wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network = instances". I think that from the definition of MPLS Section follows that there can not be an intermediate M= PLS node on a given MPLS Section which is aware of that Section. In your ex= ample (slide #7) nodes P and P' (to differentiate them from left to right) = of Carrier A are terminating points of MPLS Section of Carrier A. S-PEs of Carrier B are unaware of that MPLS = Section. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Se= ction, none of nodes of Carrier B, including S-PEs, should bother to proces= s the GAL. Doing otherwise will break client-server layering. That is why I can not agree that an intermed= iate node contains instances of multiple MPLS-TP networks. I think of a nod= e as performing its functions at certain MPLS-TP network layer only. Anothe= r question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet wi= th number of BOS in carrier's carrier scenario. But that, to me, is separat= e discussion.
Maarten, I greatly appreciate your input and our discussion.

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten Visser= s <maarten.vissers@huawei.co= m> wrote:
Hi Greg,
 
The intermediate nodes contain multiple MPLS-TP (MTP) layer ne= twork instances, of which the top MTP layer is shared by carrier A and B. S= ee slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer netw= orks. In the attached ethernet-connection-concepts file you find the s= ame case illustrated also on slide 7.
 
Other slides illustrate other cases of carrier-carrier and cus= tomer-carrier interactions.
 
Note that the functional models for the MPLS-TP and Ethernet c= ases are the same; I already had the Ethernet models and have converted tho= se into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is t= he encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MP= LS-TP via a Label Stack Entry (LSE) header.
 
Regards,
Maarten


From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of MPL= S-TP transport? But wouldn't presumed processing of client MPLS-TP section = by intermediate nodes of server MPLS-TP layer be just plain violation of se= rver-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers= <maarten.vissers@huawei.co= m> wrote:
Greg,
 
It is not uncommon to carry a section layer signal as a servic= e through the network of another carrier. E.g. Ethernet port based services= carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of po= rt based service would carry the MPLS section layer signal as a service thr= ough the network of another carrier. The section will now pass through inte= rmediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC = 5586 definition of the Section Layer Network and the last paragraph on sub-= section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to se= ction as server layer that provides service between adjacent nodes (my underlining). At the same time, = the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediat= e nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL.= If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate= nodes on the section (on the segment, but not on a section) at this partic= ular layer.
Your clarification is greatly appreciated.

Regards,
Greg


--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEAILPTMAIL02eci_-- From loa@pi.nu Fri Jan 22 18:22:38 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09513A69AD; Fri, 22 Jan 2010 18:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 dqh6GiiEwirv; Fri, 22 Jan 2010 18:22:36 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 408773A6811; Fri, 22 Jan 2010 18:22:36 -0800 (PST) Received: from [172.17.165.88] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 37AC5D404F; Sat, 23 Jan 2010 03:22:28 +0100 (CET) Message-ID: <4B5A5D62.5030908@pi.nu> Date: Sat, 23 Jan 2010 03:22:26 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org References: <4B29B534.8040906@pi.nu> In-Reply-To: <4B29B534.8040906@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 02:22:39 -0000 All, this poll has ended. We have a new mpls working group document! Could the authors please republish it as draft-ietf-mpls-tp-fault-00.txt. /Loa On 2009-12-17 05:36, Loa Andersson wrote: > All, > > this is to start a two week poll on making > > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, > indicating "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Friday 15 Jan, 2010. > > /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Alexander.Vainshtein@ecitele.com Fri Jan 22 23:56:52 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D333A67D4; Fri, 22 Jan 2010 23:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ECg3HsWM-Rpq; Fri, 22 Jan 2010 23:56:50 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 1A2613A67B3; Fri, 22 Jan 2010 23:56:48 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-70-4b5aaaa29a64 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id C1.A4.03798.2AAAA5B4; Sat, 23 Jan 2010 09:52:03 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 23 Jan 2010 09:56:42 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Sat, 23 Jan 2010 09:56:43 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJo= Message-ID: References: <787be2781001221128t17a02582w5b123658793f1975@mail.gmail.com>, <003f01ca9bee$15be8690$e6150674@china.huawei.com> In-Reply-To: <003f01ca9bee$15be8690$e6150674@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEBILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 07:56:52 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEBILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten, I may be missing something important, but how iy seems that you ignore the = fundamental differences between Ethernet and MPLS data planes in your analy= sis. Ethernet data plane inherently recognizes "well-know multicast MAC destinat= ion addresses". If a switch wants so, it can catch all the frames with such= a DA and decide how it treats them "out-of-band". All Ethernet protocols o= perate in this way, 802.1ag is not an exception. And this is exactly what a= llows separation between addressing and MEP/MIP levels in 802.1ag. The dis= advantage of this approach is that Ethernet OAM frames are not necessarily = fate-sharing with the data traffic. The MPLS data plane is defined in RFC 3031, 30302 and (for upstream-allocat= ed labels) in RFC 5331, 5332. Its analog of Ethernet well-know multicast MA= C destination addresses is the reserved Router Alert Label. But its usage = has been rejected for usage in MPLS-TP OAM exactly because fate-sharing of = data and OAM packets could be broken. Instead, MPLS-TP uses two different m= echanisms: 1. GAL. This mechanism can only be used to address MEPs, because the LER proce= ssing a packet with the GAL at some level in the label stack is not allowed= to look at it unless it terminates all the labels above it are terminated = (i.e., its ILM entries for these labels must be "pop and forward to the loo= pback interface"). 2. TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. = And, of course, TTL expiration must occur in the first label stack entry fo= llowing all the labels terminated by the supporting node. In short, LERs do not look at the next label if they do not terminate the p= revious one. Hence I think that some of the MEPs you've defined are non-addressable (and= hence unusable) in MPLS-TP which shares the MPLS data plane. My 2c, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com] Sent: Saturday, January 23, 2010 7:37 AM To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Hi Greg, See inline.. ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 20:29 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, I'll concentrate, as you suggested, on the slide #7 and the following you'v= e wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer networ= k instances". I think that from the definition of MPLS Section follows that= there can not be an intermediate MPLS node on a given MPLS Section which i= s aware of that Section. In your example (slide #7) nodes P and P' (to differentiate them from left = to right) of Carrier A are terminating points of MPLS Section of Carrier A. [maarten] Correct. S-PEs of Carrier B are unaware of that MPLS Section. [maarten] not correct. The figure shows two MPLS-TP Section layer MEG level= s; the top level MEG has its endpoints (blue MEP functions) in the carrier = A P and P' nodes, the bottom level MEG has its end points in the interface = ports of P and left S-PE and in right S-PE and P' nodes. [maarten] The most left and right S-PEs of carrier B terminate the physical= media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment= OAM in the blue colored MEP function. On top of this MEP function there is= a (blue) MPLS-TP Section layer MIP function, which will process the MPLS-T= P Section layer OAM from the top MEG level. [maarten] I have attached a slightly modified version of the slide 7. The m= odification is the replacement of the 802.3 interface between carrier A's P= node and the left S-PE node of carrier B by an SDH STM-N interface. Such S= DH interface has excellent section monitoring capabilities and it is now no= t necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level = between these P and left S-PE nodes. This is reflected by the absence of th= e lower blue Section MEP functions. [maarten] On the side of the adaptation functions between MPLS-TP Section = layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated= "P-LSE" to represent that it may be necessary to insert a kind of "priorit= y label stack entry header" (in analogy to the priority vlan tag in etherne= t). The use of such "P-LSE" header on the MPLS-TP over SDH interface would = be required when carrier A wants to have explicit control over the priority= and drop eligibility of each of the MPLS-TP packets passed through the car= rier B network; i.e. including the MPLS-TP Section OAM packets. If all Sect= ion OAM packets have the same priority/drop eligibility, then insertion of = such P-LSE header is not necessary as carrier B's S-PE node can assign the = right priority/drop eligible level to the the unlabelled (section OAM) pack= ets. [maarten] For the latter case, the MPLS-TP Section layer signal will have i= ts section OAM equipped with GAL as BOS. For the former case, the MPLS-TP S= ection layer signal will have its section OAM equipped with 'P-LSP' label = as BOS and GAL as second label. [maarten] Assume the latter case, then the blue MIP function in the left S-= PE node will process the GAL as BOS. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, no= ne of nodes of Carrier B, including S-PEs, should bother to process the GAL= . Doing otherwise will break client-server layering. [maarten] I understand why we were coming to different conclusions. I hope = I have clarified my view with the SDH physical media layer example. [maarten] You may now also understand why the definition of Section layer i= n G.805 defines that the section layer network is concerned with all functi= ons which"**provide for the transfer of infomation between locations in pat= h layer networks**. It is this latter item that allows section layer trails to span multiple ph= ysical media layer trails, and thus to have intermediate nodes in the secti= on layer connection. [maarten] But in all honesty, most of the Section layer connections are ter= minating at the same ports as their underlying physical media layer connect= ions. Someone who looks only at the appearances of section layers inside on= e network will conclude that section layer connections terminate at adjacen= t nodes. Someone who looks beyond its own network will conclude that sectio= n layer connections terminate in nodes that provide access to path layer si= gnals. That is why I can not agree that an intermediate node contains instances of= multiple MPLS-TP networks. I think of a node as performing its functions a= t certain MPLS-TP network layer only. [maarten] It is my understanding that we are missing a description which ex= plicitly describes the mapping of labels onto layers. One MPLS-TP layer net= work will in my understanding contain one or more labels. As the ppt file w= ith my investigation results is too large to attach, I will email you a cop= y privately. I have attached a summary of the results up to this point in t= ime. Another question is whether Carrier B sets its VC label as BOS or not, as I= understand we haven't decided yet with number of BOS in carrier's carrier = scenario. But that, to me, is separate discussion. [maarten] I have understood that that decision has been made. Refer to the = SB10 comment "Yes. S=3D1 does not indicate the boundary between the client = and server. It indicates the boundary between the label stack and the label= stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU-= T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-= framework-08, see section 3.4.1. Maarten, I greatly appreciate your input and our discussion. [maarten] I appreciate your questions and discussion. Regards, Maarten Regards, Greg On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers > wrote: Hi Greg, The intermediate nodes contain multiple MPLS-TP (MTP) layer network instanc= es, of which the top MTP layer is shared by carrier A and B. See slide 7 in= the mplstp-connection-concepts file. Note that the same applies for the ca= se of Ethernet (ETH) layer networks. In the attached ethernet-connection-co= ncepts file you find the same case illustrated also on slide 7. Other slides illustrate other cases of carrier-carrier and customer-carrier= interactions. Note that the functional models for the MPLS-TP and Ethernet cases are the = same; I already had the Ethernet models and have converted those into MPLS-= TP equivalent models to illustrate this section layer question. The differe= nce between both technologies is the encoding of MEG levels; in Ethernet vi= a the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) heade= r. Regards, Maarten ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 17:55 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, so this is carrier's carrier scenario when MPLS-TP section is client of MPL= S-TP transport? But wouldn't presumed processing of client MPLS-TP section = by intermediate nodes of server MPLS-TP layer be just plain violation of se= rver-client model? Regards, Greg On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers > wrote: Greg, It is not uncommon to carry a section layer signal as a service through the= network of another carrier. E.g. Ethernet port based services carry the Et= hernet section layer signals as a service through the transport network. Th= e compatible MPLS type of port based service would carry the MPLS section l= ayer signal as a service through the network of another carrier. The sectio= n will now pass through intermediate nodes. Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpl= s-tp-bounces@ietf.org] On Behalf Of Greg M= irsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC = 5586 definition of the Section Layer Network and the last paragraph on sub-= section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to se= ction as server layer that provides service between adjacent nodes (my unde= rlining). At the same time, the last paragraph of subsection 4.2.1.2 stipul= ates behavior of intermediate nodes on an MPLS Section in regard to G-ACh m= essage, the ACH and the GAL. If an MPLS Section is between adjacent nodes, = then, as I understand the definition, there can not be intermediate nodes o= n the section (on the segment, but not on a section) at this particular lay= er. Your clarification is greatly appreciated. Regards, Greg --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEBILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten,
I may be missing somet= hing important, but how iy seems that you ignore the fundamental diffe= rences between Ethernet and MPLS data planes in your analysis.<= /div>
 
Ethernet data plane&nb= sp;inherently recognizes "well-know multicast MAC destination addresse= s". If a switch wants so, it can catch all the frames with such a DA a= nd decide how it treats them "out-of-band". All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is&nb= sp;exactly what allows separation between addressing and MEP/MIP = levels in 802.1ag.  The disadvantage of this approach is that Ethernet= OAM frames are not necessarily fate-sharing with the data traffic.
 
The MPLS data plane is defi= ned in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331= , 5332. Its analog of Ethernet well-know multicast MAC destination add= resses is the reserved Router Alert Label. But its usage  has been rejected for usage in MPLS-TP OAM exactly be= cause fate-sharing of data and OAM packets could be broken. Instead, MPLS-T= P uses two different mechanisms:
  1. GAL. This mechanism can only be used to= address MEPs, because the LER processing a packet with the GAL at some lev= el in the label stack is not allowed to look at it unless it terminates all= the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to t= he loopback interface").
  2. TTL expiration. This is the only mechan= ism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occ= ur in the first label stack entry following all the labels terminated by th= e supporting node.

In short, LERs do not look at the next la= bel if they do not terminate the previous one.

Hence I think that some of the MEPs you'v= e defined are non-addressable (and hence unusable) in MPLS-TP which shares = the MPLS data plane.

 

My 2c,

     Sasha


From:=  mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com]
Sent: Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Hi Greg,
 
See inline..
From: Greg Mirsky [mailto:greg= imirsky@gmail.com]
Sent: vrijdag 22 januari 2010 20:29
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you'v= e wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network = instances". I think that from the definition of MPLS Section follows that there can not be an intermediate M= PLS node on a given MPLS Section which is aware of that Section.  
 
In your example (slide #7) nodes P and P' (to differentiate them from = left to right) of Carrier A are terminating points of MPLS Section of Carri= er A.  
 
[maarten] Correct.
 
S-PEs of Carrier B are unaware of that MPLS Section. &= nbsp;
 
[maarten] not correct. The figure shows two MPLS-TP Section = layer MEG levels; the top level MEG has its endpoints (blue MEP functions)&= nbsp;in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and= in right S-PE and P' nodes.
 
[maarten] The most left and right S-PEs of carrier B te= rminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP= Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Sectio= n layer MIP function, which will process the MPLS-TP Section layer OAM from= the top MEG level.
 
[maarten] I have attached a slightly modified version of the= slide 7. The modification is the replacement of the 802.3 interface betwee= n carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent s= ection monitoring capabilities and it is now not necessary to instantiate t= he MPLS-TP Section layer TCM/Segment MEG level between these P and left S-P= E nodes. This is reflected by the absence of the lower blue Section MEP functions.
 
[maarten] On the side of the adaptation functions&= nbsp; between MPLS-TP Section layer and SDH layers (blue/grey colored = trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry h= eader" (in analogy to the priority vlan tag in ethernet). The use= of such "P-LSE" header on the MPLS-TP over SDH interface would b= e required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets pass= ed through the carrier B network; i.e. including the MPLS-TP Section OAM pa= ckets. If all Section OAM packets have the same priority/drop eligibility, = then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/dr= op eligible level to the the unlabelled (section OAM) packets.<= /span>
 
[maarten] For the latter case, the MPLS-= TP Section layer signal will have its section OAM equipped with GAL as BOS.= For the former case, the MPLS-TP Section layer signal will have its sectio= n OAM equipped with 'P-LSP'  label as BOS and GAL as second label.
 
[maarten] Assume the latter case, then the blue MIP function= in the left S-PE node will process the GAL as BOS.
 
Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Sectio= n, none of nodes of Carrier B, including S-PEs, should bother to process th= e GAL. Doing otherwise will break client-server layering. &= nbsp;
 
[maarten] I understand why we were coming to different concl= usions. I hope I have clarified my view with the SDH physical media layer e= xample.
 
[maarten] You may now also understand why the definition of = Section layer in G.805 defines that the section layer network is concerned = with all functions which"**provide for the transfer of infomation between locations in path layer networks**.
It is this latter item that allows section layer trails to s= pan multiple physical media layer trails, and thus to have intermediate nod= es in the section layer connection.
 
[maarten] But in all honesty, most of the Section layer conn= ections are terminating at the same ports as their underlying physical medi= a layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that= section layer connections terminate at adjacent nodes. Someone who looks b= eyond its own network will conclude that section layer connections terminat= e in nodes that provide access to path layer signals.
 
That is why I can not agree that an intermediate node contains instanc= es of multiple MPLS-TP networks. I think of a node as performing its functi= ons at certain MPLS-TP network layer only.  
 
[maarten] It is my understanding that we are missing a descr= iption which explicitly describes the mapping of labels onto layers. One MP= LS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation res= ults is too large to attach, I will email you a copy privately. I have atta= ched a summary of the results up to this point in time.
 
Another question is whether Carrier B sets its VC label as BOS or not,= as I understand we haven't decided yet with number of BOS in carrier's car= rier scenario. But that, to me, is separate discussion. 
 
[maarten] I have understood that that decision has been made= . Refer to the SB10 comment "Yes. S=3D1 does not indicate the boundary between the client and server. It ind= icates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU= -T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1.

Maarten, I greatly appreciate your input and our discussion. = ;
 
[maarten] I appreciate your questions and discussion.=
 
Regards,
Maarten 

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten V= issers <maarten.vissers@huawei.co= m> wrote:
Hi Greg,
 
The intermediate nodes contain multiple MPLS-TP (MTP) layer ne= twork instances, of which the top MTP layer is shared by carrier A and B. S= ee slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer netw= orks. In the attached ethernet-connection-concepts file you find the s= ame case illustrated also on slide 7.
 
Other slides illustrate other cases of carrier-carrier and cus= tomer-carrier interactions.
 
Note that the functional models for the MPLS-TP and Ethernet c= ases are the same; I already had the Ethernet models and have converted tho= se into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is t= he encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MP= LS-TP via a Label Stack Entry (LSE) header.
 
Regards,
Maarten


From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of MPL= S-TP transport? But wouldn't presumed processing of client MPLS-TP section = by intermediate nodes of server MPLS-TP layer be just plain violation of se= rver-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vi= ssers <maarten.vissers@huawei.co= m> wrote:
Greg,
 
It is not uncommon to carry a section layer signal as a servic= e through the network of another carrier. E.g. Ethernet port based services= carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of po= rt based service would carry the MPLS section layer signal as a service thr= ough the network of another carrier. The section will now pass through inte= rmediate nodes.
 
Regards,
Maarten


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC = 5586 definition of the Section Layer Network and the last paragraph on sub-= section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to se= ction as server layer that provides service between adjacent nodes (my underlining). At the same time, = the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediat= e nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL.= If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate= nodes on the section (on the segment, but not on a section) at this partic= ular layer.
Your clarification is greatly appreciated.

Regards,
Greg


--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEBILPTMAIL02eci_-- From jdrake@juniper.net Sat Jan 23 09:50:55 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3573A6992; Sat, 23 Jan 2010 09:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599] 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 TvnhK5jMZIYL; Sat, 23 Jan 2010 09:50:54 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0B31C3A6985; Sat, 23 Jan 2010 09:50:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS1s282UtTTRx/3+Z5qf30Rgbf+yfOqMt@postini.com; Sat, 23 Jan 2010 09:50:50 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sat, 23 Jan 2010 09:47:25 -0800 From: John E Drake To: Alexander Vainshtein , Greg Mirsky , Maarten Vissers Date: Sat, 23 Jan 2010 09:47:23 -0800 Thread-Topic: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSxHT4GPnJG+RQ2CHOJqLx6NMwADEIQ7ACuaxSA= Message-ID: <5E893DB832F57341992548CDBB3331639804E4EB3E@EMBX01-HQ.jnpr.net> References: <787be2781001220855m51e411f4nedff27f9acc7159d@mail.gmail.com> <008601ca9b91$3c7934e0$e6150674@china.huawei.com>, <787be2781001221128t17a02582w5b123658793f1975@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 17:50:55 -0000 That sounds right. A 'section' is what would normally be called a 'link', = but for some reason that term wasn't considered sufficient. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Friday, January 22, 2010 12:57 PM > To: Greg Mirsky; Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Sectio= n >=20 > Greg, Maarten and all, > I concur with Greg. If section connects adjacent nodes (at a certain > layer), physical intermediate nodes crossed by such a section in the > carriers' carrier scenario are fully transparent to that. >=20 > My 2c, > Sasha > ________________________________ >=20 > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Greg > Mirsky [gregimirsky@gmail.com] > Sent: Friday, January 22, 2010 9:28 PM > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Sectio= n >=20 >=20 > Dear Maarten, > I'll concentrate, as you suggested, on the slide #7 and the following > you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer > network instances". I think that from the definition of MPLS Section > follows that there can not be an intermediate MPLS node on a given MPLS > Section which is aware of that Section. In your example (slide #7) nodes = P > and P' (to differentiate them from left to right) of Carrier A are > terminating points of MPLS Section of Carrier A. S-PEs of Carrier B are > unaware of that MPLS Section. Thus, when Node P sends OAM with GAL as BOS > to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, > should bother to process the GAL. Doing otherwise will break client-serve= r > layering. That is why I can not agree that an intermediate node contains > instances of multiple MPLS-TP networks. I think of a node as performing > its functions at certain MPLS-TP network layer only. Another question is > whether Carrier B sets its VC label as BOS or not, as I understand we > haven't decided yet with number of BOS in carrier's carrier scenario. But > that, to me, is separate discussion. > Maarten, I greatly appreciate your input and our discussion. >=20 > Regards, > Greg >=20 >=20 > On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers > wrote: >=20 >=20 > Hi Greg, >=20 > The intermediate nodes contain multiple MPLS-TP (MTP) layer network > instances, of which the top MTP layer is shared by carrier A and B. See > slide 7 in the mplstp-connection-concepts file. Note that the same applie= s > for the case of Ethernet (ETH) layer networks. In the attached ethernet- > connection-concepts file you find the same case illustrated also on slide > 7. >=20 > Other slides illustrate other cases of carrier-carrier and customer- > carrier interactions. >=20 > Note that the functional models for the MPLS-TP and Ethernet cases > are the same; I already had the Ethernet models and have converted those > into MPLS-TP equivalent models to illustrate this section layer question. > The difference between both technologies is the encoding of MEG levels; i= n > Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entr= y > (LSE) header. >=20 > Regards, > Maarten >=20 > ________________________________ >=20 >=20 > From: Greg Mirsky [mailto:gregimirsky@gmail.com] >=20 > Sent: vrijdag 22 januari 2010 17:55 > To: Maarten Vissers >=20 > Cc: mpls@ietf.org; mpls-tp@ietf.org >=20 > Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section >=20 >=20 > Dear Maarten, > so this is carrier's carrier scenario when MPLS-TP section is client > of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP > section by intermediate nodes of server MPLS-TP layer be just plain > violation of server-client model? >=20 > Regards, > Greg >=20 >=20 > On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers > wrote: >=20 >=20 > Greg, >=20 > It is not uncommon to carry a section layer signal as a > service through the network of another carrier. E.g. Ethernet port based > services carry the Ethernet section layer signals as a service through th= e > transport network. The compatible MPLS type of port based service would > carry the MPLS section layer signal as a service through the network of > another carrier. The section will now pass through intermediate nodes. >=20 > Regards, > Maarten >=20 > ________________________________ >=20 > From: mpls-tp-bounces@ietf.org bounces@ietf.org> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg > Mirsky > Sent: donderdag 21 januari 2010 22:21 > To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; > stbryant@cisco.com > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS > Section >=20 >=20 > Dear Editors and All, > I'm puzzled by what looks to me as contradiction between > quoted in the RFC 5586 definition of the Section Layer Network and the > last paragraph on sub-section 4.2.1.2 MPLS Section. The definition > (section 1.3 p.4) refers to section as server layer that provides service > between adjacent nodes (my underlining). At the same time, the last > paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes > on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an > MPLS Section is between adjacent nodes, then, as I understand the > definition, there can not be intermediate nodes on the section (on the > segment, but not on a section) at this particular layer. > Your clarification is greatly appreciated. >=20 > Regards, > Greg >=20 >=20 >=20 From root@core3.amsl.com Sun Jan 24 08:15:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F1D423A6912; Sun, 24 Jan 2010 08:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100124161501.F1D423A6912@core3.amsl.com> Date: Sun, 24 Jan 2010 08:15:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:15:02 -0000 --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 : IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-05.txt Pages : 23 Date : 2010-01-24 The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) in cooperation between the IETF and the ITU-T is document in RFC 5317 as the decision of the Joint Working Team on MPLS-TP. This document provides additional detail of the processes for the development of IETF RFCs on MPLS-TP. It provides an adaptation of the IETF working group process; identifies the expected participation in the process by the ITU-T; and clarifies the rules and conventions regarding MPLS-TP documents. This document does not specify any ITU-T process; ITU-T activities will be done according to ITU-T process/rules. This document does not specify or modify the normal IETF working group process. It is limited to the specific adaptations of that process to facilitate the cooperation agreement between the IETF and the ITU-T on MPLS-TP, and to ensure a good and consistent document review across the two organizations. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-process-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-process-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-24080050.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Jan 24 21:45:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 42F8A3A6836; Sun, 24 Jan 2010 21:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100125054502.42F8A3A6836@core3.amsl.com> Date: Sun, 24 Jan 2010 21:45:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 05:45:02 -0000 --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 : LDP Typed Wildcard FEC Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-typed-wildcard-05.txt Pages : 11 Date : 2010-01-24 The Label Distribution Protocol (LDP) specification for the Wildcard FEC element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-ldp-typed-wildcard-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-24213929.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Jan 25 06:22:56 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8EB9C3A689C; Mon, 25 Jan 2010 06:22:56 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100125142256.8EB9C3A689C@core3.amsl.com> Date: Mon, 25 Jan 2010 06:22:56 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-framework (MPLS-TP Network Management Framework) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:22:56 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Network Management Framework ' as an Informational RFC 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@ietf.org mailing lists by 2010-02-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18654&rfc_flag=0 From wwwrun@core3.amsl.com Mon Jan 25 06:23:33 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CFD0B3A6868; Mon, 25 Jan 2010 06:23:33 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100125142333.CFD0B3A6868@core3.amsl.com> Date: Mon, 25 Jan 2010 06:23:33 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-ldp-typed-wildcard (LDP Typed Wildcard FEC) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:23:33 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Typed Wildcard FEC ' 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@ietf.org mailing lists by 2010-02-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15621&rfc_flag=0 From Alexander.Vainshtein@ecitele.com Tue Jan 26 11:35:41 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181793A6956; Tue, 26 Jan 2010 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CIcort+f7Mbi; Tue, 26 Jan 2010 11:35:40 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 3BC113A67FC; Tue, 26 Jan 2010 11:35:39 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-8b-4b5f42ec5f0e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id D3.96.03798.CE24F5B4; Tue, 26 Jan 2010 21:30:52 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 26 Jan 2010 21:35:48 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Tue, 26 Jan 2010 21:34:16 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAABfimOI= Message-ID: References: <000001ca9c45$7c86dc90$e6150674@china.huawei.com>, <02D7222D58419F409B1BE84E6095C260AA5E902792@ILPTMAIL02.ecitele.com> In-Reply-To: <02D7222D58419F409B1BE84E6095C260AA5E902792@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEFILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:35:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEFILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten and all, I resend this message since the original one exceeded the moderators' limit= (40K). I've snipped the tail of the message thread. Regards, Sasha ________________________________ From: Alexander Vainshtein Sent: Tuesday, January 26, 2010 10:37 AM To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I apologize for a delayed response. I think that the example you've given actually confirms my point of view: y= our model does not work with the regular MPLS data plane. Here is my analysis of your logic, based on the assumption that all LSPs ar= e P2P and downstream label allocation is used. The conclusions would not ch= ange if 1. The MPLS-TP LSP OAM inserted by the lower blue MEP in node P= -left has as top and bottom of stack the GAL [[Sasha]] OK. This implies tha= t S-PE-left looks on the labeled packets it receives from P-Left, otherwise= it would simply ignore GAL 2. The MPLS-TP LSP OAM inserted by the higher blue MEP in node = P-left has as top of stack the label inserted by the lower blue MEP (identi= fied as LSE) and as bottom of stack the GAL... The interface port in the S-= PE-left port will swap the top of stack label of non-OAM and TTL not-expire= d packets [[Sasha]] This implies that the top label in this stack has been = allocated by S-PE-Left, bound by it to a certain FEC, and this binding "dis= tributed" (no matter by which means) to P-Left. Were it not so, the label p= laced by the higher blue MEP on top of the label stack in a labeled packet = P-left sends to S-PE-left would be treated by the latter as invalid, and th= e packet would be discarded - see RFC 3031, Section 3.18. And this, in its = turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds t= o FECs labels that P-left puts on top of the stack in labeled packets that = from its point of view, belong to these FECs. In your example the FEC in qu= estion is formed by the packets that should go to PE-right, and the conclus= ion is that PE-right is NOT adjacent to PE-Left. The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane (and,= by implication, in the MPLS-TP one) is directly related to the label alloc= ation and label-to-FEC binding. If we can agree on that, this should be exp= licitly mentioned in the MPLS-TP Framework document to prevent misunderstan= ding. Regards, Sasha --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEFILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten and all,
I resend this message since the original one exceeded the moderators' lim= it (40K).
 
I've snipped the tail of th= e message thread.
 
Regards,
     Sa= sha

From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 10:37 AM
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Maarten,
I apologize for a delayed response.
I think that the example you've given actually confirms my p= oint of view: your model does not work with the regular MPLS data plane.=
Here is my analysis of your logic, based on the assumption t= hat all LSPs are P2P and downstream label allocation is used. The conclusio= ns would not change if
  1. <Maarten> The MPLS-TP LSP OAM inserted by the lower blue MEP in = node P-left has as top and bottom of stack the GAL [[Sasha]] OK. This implies that S-PE-left looks on = the labeled packets it receives from P-Left, otherwise it would simply= ignore GAL
  2. <Maarten> The MPLS-TP LSP OAM inserted by the higher = blue MEP in node P-left has as top of stack the label inserted by the lower= blue MEP (identified as LSE) and as bottom of stack the GAL... The interface port in the S-PE-left port will swap the top= of stack label of non-OAM and TTL not-expired packets [[Sasha]] This implies that the top label in this stack has been a= llocated by S-PE-Left, bound by it to a certain FEC, and this binding "distributed" (no matter by which means) t= o P-Left. Were it not so, the label placed by the higher blue MEP on t= op of the label stack in a labeled packet P-left sends to S-PE-left wo= uld be treated by the latter as invalid, and the packet would be discarded - see RFC 3031= , Section 3.18. And this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds to FECs l= abels that P-left puts on top of the stack in labeled packets that from its= point of view, belong to these FECs. In your example the FEC in question i= s formed by the packets that should go to PE-right, and the conclusion is that PE-right is NOT adjacent to= PE-Left.
The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane= (and, by implication, in the MPLS-TP one) is directly related to the label= allocation and label-to-FEC binding. If we can agree on that, this should be explicitly mentioned in the MPLS-T= P Framework document to prevent misunderstanding.
 
Regards,
     Sasha
 
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEFILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Tue Jan 26 11:39:56 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609AC28C0E0; Tue, 26 Jan 2010 11:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 z3a5QNUzyNMS; Tue, 26 Jan 2010 11:39:55 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id CCFC43A67FC; Tue, 26 Jan 2010 11:39:53 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-47-4b5f43eb0c4a Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id F0.A6.03798.BE34F5B4; Tue, 26 Jan 2010 21:35:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 26 Jan 2010 21:40:03 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Tue, 26 Jan 2010 21:36:00 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAAAxEoZAAAY80UAAKHjJC Message-ID: References: <005601ca9e96$0efc4fe0$e6150674@china.huawei.com>, <02D7222D58419F409B1BE84E6095C260AA5E90279A@ILPTMAIL02.ecitele.com> In-Reply-To: <02D7222D58419F409B1BE84E6095C260AA5E90279A@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF0ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:39:56 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF0ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten and all, I resend this message since the original one has exceeded the moderators' l= imit (40K). I've snipped the tail of the thread. Regards, Sasha ________________________________ From: Alexander Vainshtein Sent: Tuesday, January 26, 2010 4:48 PM To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, IMHO and FWIW, OAM must follow what the data plane (which, in the case of M= PLS is label-based) does. If MEG levels (and adjacencies) are not bound to data plane adjacencies, wh= at are these MEGs about? Regards, Sasha ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: Tuesday, January 26, 2010 4:44 PM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, See inline.. ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: dinsdag 26 januari 2010 9:38 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I apologize for a delayed response. I think that the example you've given actually confirms my point of view: y= our model does not work with the regular MPLS data plane. Here is my analysis of your logic, based on the assumption that all LSPs ar= e P2P and downstream label allocation is used. The conclusions would not ch= ange if 1. The MPLS-TP LSP OAM inserted by the lower blue MEP in node P= -left has as top and bottom of stack the GAL [[Sasha]] OK. This implies tha= t S-PE-left looks on the labeled packets it receives from P-Left, otherwise= it would simply ignore GAL [maarten2] The S-PE-left has a MPLS-TP blue MEP function at its input and t= his blue MEP function will look for packets with as top label the GAL. 1. The MPLS-TP LSP OAM inserted by the higher blue MEP in node = P-left has as top of stack the label inserted by the lower blue MEP (identi= fied as LSE) and as bottom of stack the GAL... The interface port in the S-= PE-left port will swap the top of stack label of non-OAM and TTL not-expire= d packets [[Sasha]] This implies that the top label in this stack has been = allocated by S-PE-Left, bound by it to a certain FEC, and this binding "dis= tributed" (no matter by which means) to P-Left. Were it not so, the label p= laced by the higher blue MEP on top of the label stack in a labeled packet = P-left sends to S-PE-left would be treated by the latter as invalid, and th= e packet would be discarded - see RFC 3031, Section 3.18. And this, in its = turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds t= o FECs labels that P-left puts on top of the stack in labeled packets that = from its point of view, belong to these FECs. In your example the FEC in qu= estion is formed by the packets that should go to PE-right, and the conclus= ion is that PE-right is NOT adjacent to PE-Left. [maarten2] There are two MEG levels (bindings) in the Section layer: A. P-left to S-PE-left B. P-left to P-right. For the A. binding P-left and S-PE-left are adjacent. They share one Mainte= nance Entity Group (MEG) level and monitor this Section MEG by means of two= Section MEP functions. For the B. binding P-left and P-right are adjacent. They share one Mainten= ance Entity Group (MEG) level and monitor this Section Segment MEG by means= of two Section Segment MEP functions. The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane (and,= by implication, in the MPLS-TP one) is directly related to the label alloc= ation and label-to-FEC binding. If we can agree on that, this should be exp= licitly mentioned in the MPLS-TP Framework document to prevent misunderstan= ding. [maarten2] There are multiple adjacencies in the MPLS and MPLS-TP (and any= other) data plane. Those adjacencies are Maintenance Entity Groups and are represented by thei= r MEG levels. For OAM the MEG type of adjacencies are relevant, not the label type adjace= ncies. A server layer or server sublayer MEG type adjacency has a 1-to-1 relations= hip with a label type adjacency. A label identifies one 'link connection' within a 'network connection', in = the blue Section layer, the label used on the link between P-left and S-PE-= left identifies one of the three link connections that establish the Sectio= n layer network connection, which latter is monitored by the Section MEG. [maarten2] I understand that there are two types of adjacencies to recogniz= e and specify in MPLS-TP. I suggest that we specify both explicitly and tha= t we describe the relationship between these two adjacencies. This will pre= vent further misunderstandings. Regards, Maarten Regards, Sasha --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF0ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten and all,
I resend this message since= the original one has exceeded the moderators' limit (40K).
I've snipped the tail of th= e thread.
 
Regards,
     Sa= sha

From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 4:48 PM
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Maarten,
IMHO and FWIW, OAM must follow what the data plane (which, i= n the case of MPLS is label-based) does.
If MEG levels (and adjacencies) are not bound to data plane = adjacencies, what are these MEGs about?
 
Regards,
     Sasha


From: Maarten Vissers [mailto:maart= en.vissers@huawei.com]
Sent: Tuesday, January 26, 2010 4:44 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Sasha,
 
See inline..


From: Alexander Vainshtein [mailto:= Alexander.Vainshtein@ecitele.com]
Sent: dinsdag 26 januari 2010 9:38
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Maarten,
I apologize for a delayed response.
I think that the example you've given actually confirms my p= oint of view: your model does not work with the regular MPLS data plane.=
Here is my analysis of your logic, based on the assumption t= hat all LSPs are P2P and downstream label allocation is used. The conclusio= ns would not change if
  1. <Maarten> The MPLS-TP LSP OAM inserted by the lower blue MEP in = node P-left has as top and bottom of stack the GAL [[Sasha]] OK. This implies that S-PE-left looks on = the labeled packets it receives from P-Left, otherwise it would simply= ignore GAL  
  2. [maarten2] The S-PE-left has a MPLS-TP blue MEP functio= n at its input and this blue MEP function will look for packets with a= s top label the GAL.
    1. <Maarten> The MPLS-TP LSP OAM inserted by the higher blu= e MEP in node P-left has as top of stack the label inserted by the lower bl= ue MEP (identified as LSE) and as bottom of stack the GAL... The interface port in the S-PE-left port will swap the top= of stack label of non-OAM and TTL not-expired packets [[Sasha]] This implies that the top label in this stack has been a= llocated by S-PE-Left, bound by it to a certain FEC, and this binding "distributed" (no matter by which means) t= o P-Left. Were it not so, the label placed by the higher blue MEP on t= op of the label stack in a labeled packet P-left sends to S-PE-left wo= uld be treated by the latter as invalid, and the packet would be discarded - see RFC 3031= , Section 3.18. And this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds to FECs l= abels that P-left puts on top of the stack in labeled packets that from its= point of view, belong to these FECs. In your example the FEC in question i= s formed by the packets that should go to PE-right, and the conclusion is that PE-right is NOT adjacent to= PE-Left. 
    [maarten2] There are two MEG levels (bindings) in t= he Section layer:
    A. P-left to S-PE-left<= /span>
    B. P-left to P-right.
    For the A. binding P-left and S-PE-left are adjacen= t. They share one Maintenance Entity Group (MEG) level and monitor this Section MEG by means of two Section MEP functions.<= /font>
    For the B. binding P-left and P-right are  adjacent. Th= ey share one Maintenance Entity Group (MEG) level and monitor this Section = Segment MEG by means of two Section Segment MEP functions.
     
    The bottom line, IMHO and FWIW, that adjacency in the MPLS dat= a plane (and, by implication, in the MPLS-TP one) is directly related to th= e label allocation and label-to-FEC binding. If we can agree on that, this should be explicitly mentioned in the MPLS-T= P Framework document to prevent misunderstanding. =
     
    [maarten2]  There are multiple adjacencies= in the MPLS and MPLS-TP (and any other) data plane.
    Those adjacencies are Maintenance Entity Groups= and are represented by their MEG levels.
    For= OAM the MEG type of adjacencies are relevant, not the label type adjacenci= es.
    A s= erver layer or server sublayer MEG type adjacency has a 1-to-1 relationship= with a label type adjacency.
    A l= abel identifies one 'link connection' within a 'network connection', in the= blue Section layer, the label used on the link between P-left and S-PE-left identifies one of the three link connections = that establish the Section layer network connection, which latter is monito= red by the Section MEG.
     
    [ma= arten2] I understand that there are two types of adjacencies to recognize a= nd specify in MPLS-TP. I suggest that we specify both explicitly and that we describe the relationship between these two ad= jacencies. This will prevent further misunderstandings.
     
    Reg= ards,
    Maa= rten
     
    Regards,
         Sasha
     
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF0ILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Tue Jan 26 11:42:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02013A69A0; Tue, 26 Jan 2010 11:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1bgnH4hFuuRn; Tue, 26 Jan 2010 11:42:17 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id CF1FC28C0F1; Tue, 26 Jan 2010 11:42:16 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-b6-4b5f447ae41c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 3A.A6.03798.A744F5B4; Tue, 26 Jan 2010 21:37:30 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 26 Jan 2010 21:42:26 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Tue, 26 Jan 2010 21:41:30 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAAAxEoZAAAY80UAAAh+AwAADnMHAACOBM4g== Message-ID: References: <006e01ca9e9b$649f2030$e6150674@china.huawei.com>, <02D7222D58419F409B1BE84E6095C260AA5E90279E@ILPTMAIL02.ecitele.com> In-Reply-To: <02D7222D58419F409B1BE84E6095C260AA5E90279E@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF1ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:42:19 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF1ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten and all, I resend this message since the original one has exceeded the moderator's l= imit. I've snipped the tail of the email thread. Regards, Sasha ________________________________ From: Alexander Vainshtein Sent: Tuesday, January 26, 2010 5:31 PM To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, You are saying (not for the first time) that the same OAM model equally app= lies to all data planes. I think that this is fundamentally incorrect: one = size does not fit all. Y.1731 inherited its definitions of MEGs and such with IEEE 802.1ag which d= ealt exclusively with the networks build by 802.1-compliant switches (a.k.a= . "learning bridges") with their specific data plane. The data plane of MPLS (and MPLS-TP) is very much different. Regards, Sasha ________________________________ From: Maarten Vissers [mailto:maarten.vissers@huawei.com] Sent: Tuesday, January 26, 2010 5:23 PM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, Below the definitions of a MEG and ME from Y.1731. It are the basic archite= cture components for OAM. OAM frames exist within one MEG, and determine the status/performance of th= e MEG. An MEG exists within the bounds of a transport entity. In MPLS-TP a MEG is bound to a MS-PW and to a LSP. In the example, the "Section layer transport path" is provided by an LSP, w= hich is monitored by the top blue MEG. The "Section layer transport path segment" between P-left and S-PE-left is = provided by either an unlabeled or priority labelled LSP, which is monitore= d by the bottom blue MEG. This "Section layer transport path segment" may be unmonitored (as illustra= ted in mplstp-connection-concepts-06w.pdf), and in this case there is no ME= G and there is no LSP. Regards, Maarten --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF1ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten and all,
I resend this message since= the original one has exceeded the moderator's limit.
I've snipped the tail of th= e email thread.
Regards,
     Sa= sha

From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 5:31 PM
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Maarten,
You are saying (not for the first time) that the same OAM mo= del equally applies to all data planes. I think that this is fundamentally incorrect: one s= ize does not fit all.
 
Y.1731 inherited its definitions of MEGs and such with = IEEE 802.1ag which dealt exclusively with the networks build by 802.1-compl= iant switches (a.k.a. "learning bridges") with their specific data plane.
 
The data plane of MPLS (and MPLS-TP) is very much different.
 
Regards,
     Sasha
 
 


From: Maarten Vissers [mailto:maart= en.vissers@huawei.com]
Sent: Tuesday, January 26, 2010 5:23 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Sasha,
 
Below the definitions of a MEG an= d ME from Y.1731. It are the basic architecture components for OAM.
OAM frames exist within one MEG, = and determine the status/performance of the MEG.
An MEG exists within the bounds o= f a transport entity.
 
In MPLS-TP a MEG is bound to a MS= -PW and to a LSP.
In the example, the "Se= ction layer transport path" is provided by an LSP, which is monitored = by the top blue MEG.
The "Section layer transport= path segment" between P-left and S-PE-left is provided by either an u= nlabeled or priority labelled LSP, which is monitored by the bottom blue MEG.
This "Section layer transpor= t path segment" may be unmonitored (as illustrated in mplstp-connectio= n-concepts-06w.pdf), and in this case there is no MEG and there is no LSP.
 
Regards,
Maarten
 
 
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF1ILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Tue Jan 26 11:49:28 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84D828C100; Tue, 26 Jan 2010 11:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 xEuP7jW55iyQ; Tue, 26 Jan 2010 11:49:27 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id D8B3928C0FF; Tue, 26 Jan 2010 11:49:26 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-19-4b5f46285ea9 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B1.C6.03798.8264F5B4; Tue, 26 Jan 2010 21:44:40 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 26 Jan 2010 21:49:36 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Tue, 26 Jan 2010 21:49:36 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAAAxEoZAAAY80UAAAh+AwAADnMHAAAodX0AAGZm+y Message-ID: References: , <008a01ca9eab$147e53e0$e6150674@china.huawei.com> In-Reply-To: <008a01ca9eab$147e53e0$e6150674@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF2ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:49:29 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF2ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten, I has believed - and still believe - that Ethernet data plane has been defi= ned (and continues to be defined via multiple updates) by the IEEE 802.1 te= ams, since 802.1 is the "design authority " for the Ethernet technology - j= ust as IETF is a design authority for MPLS technology and its derivatives. As for differences between Ethernet and MPLS actual data planes - I think t= hose are well known, no need to repeat myself. I firmly believe that attempts to disregard actual data plane differences f= or the sake of imposing a unified OAM model will eventually fail. Regards, Sasha ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Tuesday, January 26, 2010 7:14 PM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, You have an incorrect understanding of the background of Y.1731. Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in = 2002 and was initiated by the deployment of Ethernet in transport networks = where it replaced SDH equipment. The performance of those initial deploymen= ts were extremely poor due to lack of OAM and protection. Set up of VLANs w= as done by NMS. In the same year work on Ethernet over Transport architectu= re was initiated in SG15 (by me :-) ), quickly expanding in the development= of a series of recommendations specifying the Ethernet as a transport tech= nology. 802.1ag was started later, and implements only a subset of the Y.1731 tools= et; i.e. the subset which spanning tree protocol/vlan registration protocol= controlled ethernet switches specified in 802.1 would need and can use. Bu= t ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking possibl= e between networks using Y.1731 and networks using 802.1ag. Ethernet switches compliant with ITU-T's Ethernet recommendations are trans= port network grade switches (with VLAN ID translation capabilities (e.g. VI= D translation, PW label swapping) in every node), which are managed by NMS = and optionally the GMPLS control plane. The Ethernet data plane specified in the ITU-T Recommendations supports all= MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet = VC connections. Some operators have recognized this and have build their pa= cket transport network with a UNI-to-UNI Ethernet VC layer as their transpo= rt service layer; transport path layer technologies used are Ethernet VP an= d MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are= used for broadband backhaul in such networks, p2p Ethernet VC connections = are used to support any type of Line service and mp2mp Ethernet VC connecti= ons are used to support E-LAN services. With the growing bandwidth demand O= TN ODUs will be added in the near future as transport path layer technology= to carry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet= data planes in such networks are managed in the same way. Ethernet Transpo= rt Networks (ETN) exist for many years already and are proven technology. It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T = Ethernet recommendations based) Ethernet VLAN data plane functionalities ar= e the same and that we can and should use the very similar OAM, protection = switching and the same management principles. T-MPLS was fully based on thi= s understanding and approach, and was designed to seamlessly operate in a h= ybrid T-MPLS/Ethernet packet transport network. My hope is that seamless in= teroperability will also be possible in the emerging hybrid MPLS-TP/Etherne= t packet transport networks. Regards, Maarten --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF2ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten,
I has believed - and s= till believe - that Ethernet data plane has been defined (and continue= s to be defined via multiple updates) by the IEEE 802.1 team= s, since 802.1 is the "design authority " for the Ethernet techno= logy - just as IETF is a design authority for MPLS technology and its derivativ= es.
 
As for differences between = Ethernet and MPLS actual data planes - I think those are well known, no nee= d to repeat myself.
 
I firmly believe that = attempts to disregard actual data plane differences for the sake of imposin= g a unified OAM model will eventually fail.
 
Regards,
     Sa= sha
 

From: Maarten Vissers [maarten.viss= ers@huawei.com]
Sent: Tuesday, January 26, 2010 7:14 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Sasha,
 
You have an incorrect understandi= ng of the background of Y.1731.
Y.1731 is created by ITU-T SG13 w= ith the help of SG15. The work started in 2002 and was initiated by the dep= loyment of Ethernet in transport networks where it replaced SDH equipment. The performance of those initial deployments we= re extremely poor due to lack of OAM and protection. Set up of VLANs was do= ne by NMS. In the same year work on Ethernet over Transport architecture wa= s initiated in SG15 (by me :-) ), quickly expanding in the development of a series of recommendations specif= ying the Ethernet as a transport technology.
 
802.1ag was started later, and im= plements only a subset of the Y.1731 toolset; i.e. the subset which spannin= g tree protocol/vlan registration protocol controlled ethernet switches specified in 802.1 would need and can use. But ITU-T SG1= 3/15 and IEEE 802.1 made sure that there is interworking possible betw= een networks using Y.1731 and networks using 802.1ag.
 
Ethernet switches compliant with = ITU-T's Ethernet recommendations are transport network grade switches (with= VLAN ID translation capabilities (e.g. VID translation, PW label swapping) in every node), which are managed by = NMS and optionally the GMPLS control plane.
 
The Ethernet data plane specified= in the ITU-T Recommendations supports all MPLS(-TP) data plane capabi= lities plus it supports rmp and mp2mp Ethernet VC connections. Some operators have recognized this and have build their pack= et transport network with a UNI-to-UNI Ethernet VC layer as their transport= service layer; transport path layer technologies used are Ethernet VP and&= nbsp;MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are used for broadband backhaul in such networks, = p2p Ethernet VC connections are used to support any type of Line service an= d mp2mp Ethernet VC connections are used to support E-LAN services. With th= e growing bandwidth demand OTN ODUs will be added in the near future as transport path layer technology to car= ry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet data p= lanes in such networks are managed in the same way. Ethernet Transport Netw= orks (ETN) exist for many years already and are proven technology.
 
<= span class=3D"031453916-26012010">It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T Ethernet recommendations based) Eth= ernet VLAN data plane functionalities are the same and that we ca= n and should use the very similar OAM, protection switching and the same ma= nagement principles. T-MPLS was fully based on this understanding and approach, and was designed to seamlessly operate= in a hybrid T-MPLS/Ethernet packet transport network. My hope is that seam= less interoperability will also be possible in the emerging hybrid MPLS-TP/= Ethernet packet transport networks.
 
Regards,
Maarten
 

 
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF2ILPTMAIL02eci_-- From gregimirsky@gmail.com Tue Jan 26 13:03:39 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA193A6954; Tue, 26 Jan 2010 13:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8gAVNPVfOuxD; Tue, 26 Jan 2010 13:03:32 -0800 (PST) Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by core3.amsl.com (Postfix) with ESMTP id 8EF3B3A68C3; Tue, 26 Jan 2010 13:03:31 -0800 (PST) Received: by fxm21 with SMTP id 21so1016037fxm.29 for ; Tue, 26 Jan 2010 13:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GesVcIp2Pulr2qr/YJ172MXY473qKYFvLcqdhaJW1y8=; b=WfLhsG8zjK84Muac97es8Tg6uw5mSUsPNt5eV5wzPSBbby2CL6YeIf8x0UIgPWXVvg 2cbZBTgjNnE35I+LmM/MNIXUPBxMjXS8x1lkje18BDtjngMJHTjc76hVmjjgrAlMxdx0 gA4peNArBSmbkRG4OL0SY5p+UPa7stot4IL+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WeK2TjC6EAB33OwDK1Ub6VmrW06sND7NW+y3T7cNP637zz3ho+7jwigLLHhk2DRiKL cgGYk4GekeLycV85xdD/lZeFZ0gcqbaL+4Z5bh1F9BfXOkxVZPnGzezbe8UXm308krvq 7DeVbayzLnOsUxoVGm36UjAMbP/Huj4hmZOIw= MIME-Version: 1.0 Received: by 10.239.185.77 with SMTP id b13mr907492hbh.158.1264539819452; Tue, 26 Jan 2010 13:03:39 -0800 (PST) In-Reply-To: <000001ca9c45$7c86dc90$e6150674@china.huawei.com> References: <000001ca9c45$7c86dc90$e6150674@china.huawei.com> Date: Tue, 26 Jan 2010 13:03:39 -0800 Message-ID: <787be2781001261303u1c4df2f4xb879c0242f9e0687@mail.gmail.com> From: Greg Mirsky To: Maarten Vissers Content-Type: multipart/alternative; boundary=001485f778a8be2c1b047e179e23 X-Mailman-Approved-At: Tue, 26 Jan 2010 14:06:49 -0800 Cc: mpls@ietf.org, Alexander Vainshtein , mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 21:03:39 -0000 --001485f778a8be2c1b047e179e23 Content-Type: text/plain; charset=ISO-8859-1 Dear Maarten, I think that your scenarios are based on the following assumption you're making "The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; *new mpls switch ports will be able to look at inner labels of all packets* (my underline); this is a similar evolution as we got in ethernet... " I don't think that is the direction where MPLS-TP should go and will go. Regards, Greg On Sat, Jan 23, 2010 at 8:02 AM, Maarten Vissers wrote: > Sasha, > > > > In short, LERs do not look at the next label if they do not terminate > the previous one. > > > Hence I think that some of the MEPs you've defined are non-addressable > (and hence unusable) in MPLS-TP which shares the MPLS data plane. > > > > If what you state is correct there is a serious problem within the existing > draft specification for MPLS-TP. These functional models describe a part > of the required functional behaviour in a (packet) transport network of any > technology. > > > > I doubt that such problem exist... so the MEPs and MIPs in my models are > all addressable (and hence usable) in MPLS-TP... > > > > Let's analyse the left inter domain interface between carrier A's P node > and B's left S-PE node as an exercise... > > 1) there is a MPLS-TP Section layer transport path (VSC) between carrier A > nodes P-left and P-right > > 2) there is a MPLS-TP Section layer transport path segment (VSC Segment) > between nodes P-left and S-PE-left > > 3) there is a MPLS-TP transport service layer transport path (VCC) between > nodes S-PE-left and S-PE-right (yellow MEPs). > > > > - The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as > top and bottom of stack the GAL. > > - The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as > top of stack the label inserted by the lower blue MEP (identified as LSE) > and as bottom of stack the GAL. > > - The lower blue MEP in node S-PE-left has to process all packets with top > of stack the GAL. > > - The blue MIP in node S-PE-left has to process all packets generated by > the higher blue MEP in node P of which the TTL expires; these packets arrive > at node S-PE-left with two labels, of which the bottom of stack label is the > GAL and the top of stack label is a regular LSP label. > > - The interface port in the S-PE-left port will swap the top of stack label > of non-OAM and TTL not-expired packets; the new label value will be the > value inserted by the left yellow MEP in the S-PE-left node (indicated by > LSE next to the yellow MEP symbol). > > - If the packet was a VSC OAM packet of which the TTL expires, the packet > will be extracted by the blue MIP within the VSC. > > - The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a > monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This > VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in > the S-PE-left node (i.e. egress MIP issue applies). > > - The VCC signal is multiplexed into an MPLS-TP transport path layer > transport path (VPC) and its packets are prepended with a new LSP label > identifying the VCC. > > - Etc. > > > > - In the reverse direction, the VPC terminates on the right NNI port of the > S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL > of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All > other VCC LSP related packets are forwarded to the egress port which is > connected to carrier A's P node. > > - The VCC LSP terminates on the egress port, and the LSP label identifying > this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can > now determine which packets carry the VCC LSP OAM by checking for the GAL as > next top label. > > - The VCC LSP label is also removed from the non-VCC LSP OAM packets and it > is possible that on one of those packets the TTL expires. Such packets are > processed by the blue MIP function above the yellow MEP function in the > S-PE-left node. > > - The outer label on packets of which the TTL has not expired will be > swapped, and LSP OAM will be added in the lower blue section layer MEP on > the S-PE-left node. This OAM will be output with GAL as top and bottom of > stack label. > > - Etc. > > > > I can't find a problem in the above required behaviour, besides the well > known egress-MIP identification problem. > > There is always an outer LSP label being terminated when a MEP function is > following and LSP OAM has to be extracted and processed. > > In some cases the LSP terminates on an ingress port (DOWN MEP), in other > cases the LSP terminates on an egress port (UP MEP). > > > > See inline for more comment... > > ------------------------------ > *From:* Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > *Sent:* zaterdag 23 januari 2010 8:57 > *To:* Maarten Vissers > *Cc:* mpls@ietf.org; mpls-tp@ietf.org; 'Greg Mirsky' > *Subject:* RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Maarten, > I may be missing something important, but how iy seems that you ignore the > fundamental differences between Ethernet and MPLS data planes in your > analysis. > > [maarten] I am absolutely not ignoring the differences between Ethernet and > MPLS data planes, as I am also not ignoring the commonalities. > > [maarten] What I mean is that it is possible to set up an e.g. 9-port > mp2mp LSP connection in the MPLS technology and order an mpls switch to read > the inner (PW) label and use the value of this inner label to forward the > packet to one of the 9 output ports of the mp2mp LSP... It should be clear > that a switch with such capability has a feature which is not described in > the MPLS RFCs; i.e. it is a proprietary extension which I am describing > below to illustrate that such extension does not interfere with the > standardized MPLS behaviour, and that it does not change that behaviour. > > ----------------- > [maarten] It is very simple to test the forwarding of packets in such mp2mp > LSP in a research lab :-)...; inner label values 1000-1999 were delivered at > output port 1, inner label values 2000-2999 were delivered at output 2, > inner label values 3000-3999 were delivered at output port 3, etc. The mpls > switch reads the outer label value to identify the LSP, then reads the inner > label value and forwards all packets with inner label value 1xxx to output > port 1, with inner label value 2xxx to output port 2, etc. > > [maarten] Another nice test application for such LSP is in a physical ring; > e.g. with 8 nodes. In this case you can identify the destination ring node > in the 3 most significant bits of the PW label and the output trib card on a > ring node by the next 7 bits and the individual PW instances by the 10 least > significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will > forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via > its east line port and packets with inner label values > 100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks > between nodes 5 and 6, then ring node 0 will change the forwarding of > packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line > port to the east line port. Node 0 is informed about the break between nodes > 6 and 7 by means of a ring-APS message including the number of the node and > the interface (east/west) detecting the fault. Ring node 0 will always > extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent > that packets get looped in the mp2mp Ring-LSP and forward packets with other > label values on the east line port to the west line port (and vice versa). > > [maarten] to support the transport of p2mp PWs through such mp2mp LSP > another set of PW label values was allocated, e.g. 10000-10999. The mpls > switch reads the outer label value to identify the LSP, then reads the inner > label value and in case of a value in the 10xxx range looks up in a table > the subset of output ports to which this packet has to be sent. > > [maarten] The same mpls switch also supports p2p LSPs and when the outer > label value is associated with such p2p LSP it will ignore the inner label > value and forward the packet to the output port. > > [maarten] The same mpls switch also supports p2mp LSPs and when the out > label value is associated with such p2mp LSP the switch will ignore the > inner label value and looks up in a table the set of output ports of this > p2mp LSP and forwards the packet to all output ports. > > [maarten] The same mpls switch also looks at the inner label on the > interface port to identify if the packet is an OAM packet and then look at > the ACH channel type to identify the type of OAM packet to see if the packet > must be processed in the interface port (and not forwarded to the switch > fabric). The existing mpls switch ports will only be able to look at inner > labels of packets of which the outer label is terminated; new mpls switch > ports will be able to look at inner labels of all packets; this is a similar > evolution as we got in ethernet... existing ethernet switches could only > look at the TYPE and DA fields to identify if an OAM frame had to be > processed (those switches could only support a subset of the Y.1731 OAM), > new ethernet switches are looking at the TYPE and MEL fields and can support > the full set of Y.1731 OAM. > > [maarten] I hope you understand now that it is possible to extend the MPLS > data plane specified in the RFCs with a 'connectionless-LSP' capability. > Such extended mpls dataplane will then contain a mix of connection > oriented-LSPs and connectionless-LSPs. The behaviour of the > connection-oriented-LSPs complies with the specifications in the RFCs. The > connectionless-LSPs are a bonus. > --------------------- > > [maarten] An ethernet switch reads the outer vlan identifier and when the > outer vlan identifier is associated with a > - p2p VLAN it will ignore the DA value and forward the frame to the output > port > - p2mp VLAN it will ignore the DA value and looks up in a table the set of > output ports of this p2mp VLAN and forwards the frame to all those output > ports > - mp2mp or rmp VLAN it will read the DA and looks up in a table the output > port or ports of this mp2mp VLAN to which this frame should be forwarded. > The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases > on the interface port to identify if the frame is an OAM frame and then look > at the MEL field and OpCode fields to identify the type of OAM frame and its > MEG level to see if the packet must be processed in the interface port (and > not forwarded to the switch fabric). > > [maarten] I don't see as such any functional difference between the mpls > and ethernet data planes; the same information elements are present in both > data planes, but with a different encoding of this information in the > frame/packet... the main difference is that standard mpls switches don't use > the inner label value to control forwarding of a packet to a subset of > output ports of an LSP, while ethernet switches typically support both the > use of the DA value to control forwarding and the don't use of the DA value > to control forwarding to a subset of VLAN output ports... but note that > there is also a set of ethernet switches that only support don't use of the > DA value to control forwarding, i.e. which support only p2p and p2mp VLANs. > > Ethernet data plane inherently recognizes "well-know multicast MAC > destination addresses". If a switch wants so, it can catch all the frames > with such a DA and decide how it treats them "out-of-band". > > [maarten] The well-known MAC multicast destination addresses listed in > Table 8-1/802.1Q are identifying management plane and control plane > protocols that are carried over the links; those frames are not belonging to > the user traffic carried in the VLANs. In MPLS-TP similar management and > control plane information is carried via the MCC and SCC packets specified > in RFC5718. > > [maarten] If you read G.8021 then you will notice that the well-know > multicast MAC destination addresses for OAM are not being recognized in the > ETH atomic functions processing Ethernet OAM. > Note that G.8021 has never used the DA field in the Ethernet OAM frame as a > means to identify OAM from non-OAM frames, as Y.1731 has from day one > specified OAM frames that carry a unicast address which do not contain these > well-known OAM multicase destination addresses. > Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the > MEL field to identify the MEG level and the OpCode field to identify the > type of OAM. > > [maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from > non-LSP OAM packets, the label stack to identify the MEG level and the ACH > channel type field to identify the type of OAM. > I.e. the same information, just a different encoding. > > All Ethernet protocols operate in this way, 802.1ag is not an exception. > And this is exactly what allows separation between addressing and > MEP/MIP levels in 802.1ag. > > [maarten] As indicated above, your understanding of Ethernet OAM protocol > processing does not align with Y.1731/G.8021 specifications. > > [maarten] The unicast LBM OAM is a special OAM frame/packet as it requires > one additional information element; i.e. a MIP identifier. This MIP > identifier must be carried in the LBM OAM frame/packet in both Ethernet and > in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in > a bidirectional p2mp LSP located at the same hop count from the MEP. Because > the bidir p2mp LSP was only recently described in this mailinglist the > implications of such LSP on the loopback OAM have not yet been investigated > and documented. > > [maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP > identifier field when the OAM frame/packet is identified as a LBM OAM. The > MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on > which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the > OAM framework. But if there is a real demand for such bidir p2mp LSP or PW, > we should include the MIP Identifier in the OAM framework document for > loopback OAM. > > The disadvantage of this approach is that Ethernet OAM frames are not > necessarily fate-sharing with the data traffic. > > [maarten] All Ethernet OAM frames fate share with the VLAN (i.e. the > Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets > will fate share with the PW and LSP (i.e. the MPLS transport entities). > > [maarten] There is one type of OAM that has to fate share with more then > the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both > the VLAN/PW/LSP and the frames/packets for which the ingress count > is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is > no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs > there is a problem to meet the second requirement. I.e. no difference as > such between Ethernet and MPLS. > > The MPLS data plane is defined in RFC 3031, 30302 and (for > upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet > well-know multicast MAC destination addresses is the reserved Router Alert > Label. But its usage has been rejected for usage in MPLS-TP OAM exactly > because fate-sharing of data and OAM packets could be broken. Instead, > MPLS-TP uses two different mechanisms: > > 1. GAL. This mechanism can only be used to address MEPs, because the > LER processing a packet with the GAL at some level in the label stack is not > allowed to look at it unless it terminates all the labels above it are > terminated (i.e., its ILM entries for these labels must be "pop and forward > to the loopback interface"). [maarten] The ethernet equivalent to the > GAL is the OAM ethertype value 89-02. > 2. TTL expiration. This is the only mechanism for addressing MIPs in > MPLS-TP. And, of course, TTL expiration must occur in the first label stack > entry following all the labels terminated by the supporting node. [maarten] > As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it > will have to include the MIP Identifier to address the MIP that has to > perform the loopback. > > [maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry > management plane frames. This is similar to the MPLS-TP MCC OAM packet > defined in RFC5718. > > > > Regards, > > Maarten > > > > In short, LERs do not look at the next label if they do not terminate the > previous one. > > Hence I think that some of the MEPs you've defined are non-addressable (and > hence unusable) in MPLS-TP which shares the MPLS data plane. > > > > My 2c, > > Sasha > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of > Maarten Vissers [maarten.vissers@huawei.com] > *Sent:* Saturday, January 23, 2010 7:37 AM > *To:* 'Greg Mirsky' > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Hi Greg, > > See inline.. > ------------------------------ > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* vrijdag 22 januari 2010 20:29 > *To:* Maarten Vissers > *Cc:* mpls@ietf.org; mpls-tp@ietf.org > *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section > > Dear Maarten, > I'll concentrate, as you suggested, on the slide #7 and the following > you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer > network instances". I think that from the definition of MPLS Section > follows that there can not be an intermediate MPLS node on a given MPLS > Section which is aware of that Section. > > In your example (slide #7) nodes P and P' (to differentiate them from left > to right) of Carrier A are terminating points of MPLS Section of Carrier A. > > > [maarten] Correct. > > S-PEs of Carrier B are unaware of that MPLS Section. > > [maarten] not correct. The figure shows two MPLS-TP Section layer MEG > levels; the top level MEG has its endpoints (blue MEP functions) in the > carrier A P and P' nodes, the bottom level MEG has its end points in the > interface ports of P and left S-PE and in right S-PE and P' nodes. > > [maarten] The most left and right S-PEs of carrier B terminate the physical > media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment > OAM in the blue colored MEP function. On top of this MEP function there is a > (blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP > Section layer OAM from the top MEG level. > > [maarten] I have attached a slightly modified version of the slide 7. The > modification is the replacement of the 802.3 interface between carrier A's P > node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH > interface has excellent section monitoring capabilities and it is now not > necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level > between these P and left S-PE nodes. This is reflected by the absence of the > lower blue Section MEP functions. > > [maarten] On the side of the adaptation functions between MPLS-TP Section > layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated > "P-LSE" to represent that it may be necessary to insert a kind of "priority > label stack entry header" (in analogy to the priority vlan tag in ethernet). > The use of such "P-LSE" header on the MPLS-TP over SDH interface would be > required when carrier A wants to have explicit control over the priority and > drop eligibility of each of the MPLS-TP packets passed through the carrier B > network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM > packets have the same priority/drop eligibility, then insertion of such > P-LSE header is not necessary as carrier B's S-PE node can assign the right > priority/drop eligible level to the the unlabelled (section OAM) packets. > > [maarten] For the latter case, the MPLS-TP Section layer signal will have > its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP > Section layer signal will have its section OAM equipped with 'P-LSP' label > as BOS and GAL as second label. > > [maarten] Assume the latter case, then the blue MIP function in the left > S-PE node will process the GAL as BOS. > > Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, > none of nodes of Carrier B, including S-PEs, should bother to process the > GAL. Doing otherwise will break client-server layering. > > [maarten] I understand why we were coming to different conclusions. I hope > I have clarified my view with the SDH physical media layer example. > > [maarten] You may now also understand why the definition of Section layer > in G.805 defines that the section layer network is concerned with all > functions which"**provide for the transfer of infomation between locations > in path layer networks**. > It is this latter item that allows section layer trails to span multiple > physical media layer trails, and thus to have intermediate nodes in the > section layer connection. > > [maarten] But in all honesty, most of the Section layer connections are > terminating at the same ports as their underlying physical media layer > connections. Someone who looks only at the appearances of section layers > inside one network will conclude that section layer connections terminate at > adjacent nodes. Someone who looks beyond its own network will conclude that > section layer connections terminate in nodes that provide access to path > layer signals. > > That is why I can not agree that an intermediate node contains instances of > multiple MPLS-TP networks. I think of a node as performing its functions at > certain MPLS-TP network layer only. > > [maarten] It is my understanding that we are missing a description which > explicitly describes the mapping of labels onto layers. One MPLS-TP layer > network will in my understanding contain one or more labels. As the ppt file > with my investigation results is too large to attach, I will email you a > copy privately. I have attached a summary of the results up to this point in > time. > > Another question is whether Carrier B sets its VC label as BOS or not, as I > understand we haven't decided yet with number of BOS in carrier's carrier > scenario. But that, to me, is separate discussion. > > [maarten] I have understood that that decision has been made. Refer to the > SB10 comment "Yes. S=1 does not indicate the boundary between the client > and server. It indicates the boundary between the label stack and the label > stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of > ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in > draft-ietf-mpls-tp-framework-08, see section 3.4.1. > > Maarten, I greatly appreciate your input and our discussion. > > [maarten] I appreciate your questions and discussion. > > Regards, > Maarten > > Regards, > Greg > > On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers < > maarten.vissers@huawei.com> wrote: > >> Hi Greg, >> >> The intermediate nodes contain multiple MPLS-TP (MTP) layer network >> instances, of which the top MTP layer is shared by carrier A and B. See >> slide 7 in the mplstp-connection-concepts file. Note that the same applies >> for the case of Ethernet (ETH) layer networks. In the >> attached ethernet-connection-concepts file you find the same case >> illustrated also on slide 7. >> >> Other slides illustrate other cases of carrier-carrier and >> customer-carrier interactions. >> >> Note that the functional models for the MPLS-TP and Ethernet cases are the >> same; I already had the Ethernet models and have converted those into >> MPLS-TP equivalent models to illustrate this section layer question. The >> difference between both technologies is the encoding of MEG levels; in >> Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry >> (LSE) header. >> >> Regards, >> Maarten >> >> ------------------------------ >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* vrijdag 22 januari 2010 17:55 >> *To:* Maarten Vissers >> >> *Cc:* mpls@ietf.org; mpls-tp@ietf.org >> *Subject:* Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section >> >> Dear Maarten, >> so this is carrier's carrier scenario when MPLS-TP section is client of >> MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP >> section by intermediate nodes of server MPLS-TP layer be just plain >> violation of server-client model? >> >> Regards, >> Greg >> >> On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers < >> maarten.vissers@huawei.com> wrote: >> >>> Greg, >>> >>> It is not uncommon to carry a section layer signal as a service through >>> the network of another carrier. E.g. Ethernet port based services carry the >>> Ethernet section layer signals as a service through the transport network. >>> The compatible MPLS type of port based service would carry the MPLS section >>> layer signal as a service through the network of another carrier. The >>> section will now pass through intermediate nodes. >>> >>> Regards, >>> Maarten >>> >>> ------------------------------ >>> *From:* mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] *On >>> Behalf Of *Greg Mirsky >>> *Sent:* donderdag 21 januari 2010 22:21 >>> *To:* BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; >>> stbryant@cisco.com >>> *Cc:* mpls@ietf.org; mpls-tp@ietf.org >>> *Subject:* [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section >>> >>> Dear Editors and All, >>> I'm puzzled by what looks to me as contradiction between quoted in the >>> RFC 5586 definition of the Section Layer Network and the last paragraph on >>> sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to >>> section as server layer that provides service between *adjacent nodes*(my underlining). At the same time, the last paragraph of subsection 4.2.1.2 >>> stipulates behavior of intermediate nodes on an MPLS Section in regard to >>> G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent >>> nodes, then, as I understand the definition, there can not be intermediate >>> nodes on the section (on the segment, but not on a section) at this >>> particular layer. >>> Your clarification is greatly appreciated. >>> >>> Regards, >>> Greg >>> >> >> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --001485f778a8be2c1b047e179e23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Maarten,
I think that your scenarios are based on the following ass= umption you're making "The exist= ing mpls=20 switch ports will only be able to look at inner labels of packets of which = the=20 outer label is terminated; new mpls switch ports will be able to look at= inner=20 labels of all packets (my underline); this is a similar evolution as we= got in ethernet... " I don't think that is the dire= ction where MPLS-TP should go and will go.

Regards,
Greg

On Sat, Jan 23, 2010 at 8:02 AM, Maarten Vis= sers <ma= arten.vissers@huawei.com> wrote:
Sasha,
=A0

>=A0 In short, LERs do not look at the=20 next label if they do not terminate the previous one.=A0

> Hence I think = that some of the MEPs you've=20 defined are non-addressable (and hence unusable) in MPLS-TP which shares th= e=20 MPLS data plane.=A0

=A0

If what you state is correct there is a serious=20 problem within the existing draft specification for MPLS-TP.=A0 These functional models describe a pa= rt of the=20 required functional behaviour in a (packet) transport network of any=20 technology.

=A0

I doubt=20 that such problem exist... so the MEPs and MIPs in my models are all addres= sable=20 (and hence usable) in MPLS-TP...

=A0

Let's=20 analyse the left=A0inter domain interface between carrier A's P node an= d B's=20 left S-PE node=A0as an exercise...

1) there=20 is a=A0MPLS-TP Section layer transport path (VSC) between carrier A nodes= =20 P-left and P-right

2) there=20 is a MPLS-TP Section layer transport path segment (VSC Segment) between nod= es=20 P-left and S-PE-left

3) there=20 is a MPLS-TP transport service layer transport path (VCC) between nodes=20 S-PE-left and S-PE-right (yellow MEPs).

=A0

- The=20 MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top an= d=20 bottom=A0of stack the GAL.

- The=20 MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top o= f=20 stack the label inserted by the lower blue MEP (identified as LSE) and as b= ottom=20 of stack the GAL.

- The=20 lower blue MEP in node S-PE-left has to process all packets with top of sta= ck=20 the GAL.

- The blue=20 MIP in node S-PE-left has to process all packets generated by the higher bl= ue=20 MEP in node P of which the TTL expires; these packets arrive at node S-PE-l= eft=20 with two labels, of which the bottom of stack label is the GAL and the top = of=20 stack label is a regular LSP label.

- The=20 interface port=A0in the S-PE-left port will swap the top of stack label of= =20 non-OAM and TTL not-expired packets; the new label value will be the value= =20 inserted by the left yellow MEP in the S-PE-left node (indicated by LSE nex= t to=20 the yellow MEP symbol).

- If the=20 packet was a VSC OAM packet of which the TTL expires, the packet will be=20 extracted by the blue MIP within the VSC.

- The=20 yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a mon= itored=20 VSC Segment, and treats this VSC Segment as one of its VCCs. This VCC relat= ed=20 LSP OAM will pass through a VCC MIP on the egress NNI port in the S-PE-left= node=20 (i.e. egress MIP issue applies).

- The VCC=20 signal is multiplexed into an MPLS-TP transport path layer transport path (= VPC)=20 and its packets are prepended with a new LSP label identifying the VCC.=20

-=20 Etc.

=A0

- In the=20 reverse direction, the VPC terminates on the right NNI port of the S-PE-lef= t=20 node, providing access the VCC LSPs carried in the VPC. If the TTL of a VCC= LSP=20 OAM expires the VCC LSP MIP function will process the OAM. All other VCC LS= P=20 related packets are forwarded to the egress port which is connected to carr= ier=20 A's P node.

- The VCC=20 LSP terminates on the egress port, and the LSP label identifying this VCC= =20 LSP=A0is terminated; the yellow VCC LSP MEP on the egress port can now=20 determine which packets carry the VCC LSP OAM by checking for the GAL as ne= xt=20 top label.

- The VCC=20 LSP label is also removed from the non-VCC LSP OAM packets and it is possib= le=20 that on one of those packets the TTL expires. Such packets are processed by= the=20 blue MIP function above the yellow MEP function in the S-PE-left=20 node.

- The=20 outer label on packets of which the TTL has not expired will be swapped, an= d LSP=20 OAM will be added in the lower blue section layer MEP on the S-PE-left node= .=20 This OAM will be output with GAL as top and bottom of stack=20 label.

-=20 Etc.

=A0

I can't=20 find a problem in the above required behaviour, besides the well known=20 egress-MIP identification problem.

There is=20 always an outer LSP label being terminated when a MEP function is following= and=20 LSP OAM has to be extracted and processed.

In some=20 cases the LSP terminates on an ingress port (DOWN MEP), in other cases the = LSP=20 terminates on an egress port (UP MEP).

=A0

=A0
See=20 inline for more comment...


From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: zaterdag 23 janua= ri=20 2010 8:57
To: Maarten Vissers
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org;= 'Greg Mirsky'
Subject: RE: [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Maarten,
I=A0may be missing somethin= g=20 important, but how=A0iy seems that you ignore the fundamental differences= =20 between=A0Ethernet and MPLS data planes in your analysis.=A0
=A0
[maarten] I am absolute= ly not=20 ignoring the differences between Ethernet and MPLS data planes, as I am als= o not=20 ignoring the commonalities.=A0
= =A0
[maarten] What I=20 mean is that it is possible to set up an e.g.=A09-port mp2mp LSP connection= =20 in the MPLS technology and order an mpls switch to read the inner (PW) labe= l and=20 use the value of this inner label to forward the packet to one of the=A09= =20 output ports of the mp2mp LSP... It should be clear that a switch with such= =20 capability has a feature which is=A0not described in the MPLS RFCs; i.e. it= =20 is a proprietary extension which I am describing below to illustrate that s= uch=20 extension does not interfere with the standardized MPLS behaviour, and that= it=20 does not change that behaviour.
=A0
-----------------
[maarten] It is=20 very simple to test the forwarding of packets in such mp2mp LSP in a resear= ch=20 lab :-)...; inner label values 1000-1999 were delivered at output port 1, i= nner=20 label values 2000-2999 were delivered at output 2, inner label values 3000-= 3999=20 were delivered at output port 3, etc. The mpls switch=A0reads the=A0outer= =20 label value to identify the LSP, then reads the inner label value and forwa= rds=20 all packets with inner label value 1xxx to output port 1, with inner label = value=20 2xxx to output port 2, etc.
=A0
[maarten]=20 Another nice test application for such LSP is in a physical ring; e.g. with= 8=20 nodes. In this case you can identify the destination ring node in the 3 mos= t=20 significant bits of the PW label and the output trib card on a ring node by= the=20 next 7 bits and the individual PW instances by the 10 least significant bit= s.=20 Number the ring nodes from=A00 to 7. Now ring node=A00 will forward the=20 packets with inner label values=A0001/010/011xxxxxxxxxxxxxxxxx via its east= =20 line port and packets with inner label values 100/101/110/111xxxxxxxxxxxxxx= xxx=20 via its west line port. If the ring breaks between nodes=A05 and 6, then ri= ng=20 node=A00 will change the forwarding of packets with inner label values=20 100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port. Nod= e 0=20 is informed about the break between nodes 6 and 7 by means of a ring-APS me= ssage=20 including the number of the node and the interface (east/west) detecting th= e=20 fault. Ring node 0 will always extract packets with inner label values=20 000xxxxxxxxxxxxxxxxxxx to prevent that packets get looped in the mp2mp Ring= -LSP=20 and forward packets with other label values on the east line port to the we= st=20 line port (and vice versa).
=A0
[maarten] to=20 support the transport of p2mp PWs through such mp2mp LSP another set of PW = label=20 values was allocated, e.g. 10000-10999. The mpls switch reads the outer lab= el=20 value to identify the LSP, then reads the inner label value and in case of = a=20 value in the 10xxx range=A0looks up in a table the subset of output ports t= o=20 which this packet has to be sent.
=A0
[maarten] The=20 same mpls switch also supports p2p LSPs and when the outer label value is= =20 associated with such p2p LSP it will ignore the inner label value and forwa= rd=20 the packet to the output port.
=A0
[maarten] The=20 same mpls switch also supports p2mp LSPs and when the out label value is=20 associated with such p2mp LSP the switch will ignore the inner label value = and=20 looks up in a table the set of output ports of this p2mp LSP and forwards t= he=20 packet to all output ports.
=A0
[maarten] The=20 same mpls switch also looks at the inner label on the interface port=A0to= =20 identify if the packet is an OAM packet and then look at the ACH channel ty= pe to=20 identify the type of OAM packet to see if the packet must be processed in t= he=20 interface port (and not forwarded to the switch fabric). The existing mpls= =20 switch ports will only be able to look at inner labels of packets of which = the=20 outer label is terminated; new mpls switch ports will be able to look at in= ner=20 labels of all packets; this is a similar evolution as we got in ethernet...= =20 existing ethernet switches could only look at the TYPE and DA fields to ide= ntify=20 if an OAM frame had to be processed (those switches could only support a su= bset=20 of the Y.1731 OAM), new ethernet switches are looking at the TYPE and MEL f= ields=20 and can support the full set of Y.1731 OAM.
=A0
[maarten] I=20 hope=A0you understand now that it is possible to extend the MPLS data plane= =20 specified in the RFCs with a 'connectionless-LSP' capability. Such = extended mpls=20 dataplane will then contain a mix of connection oriented-LSPs and=20 connectionless-LSPs. The behaviour of the connection-oriented-LSPs complies= with=20 the specifications in the RFCs. The connectionless-LSPs are a=20 bonus.
---------------------=
=A0
[maarten] An=20 ethernet switch reads the outer vlan identifier and when the outer vlan=20 identifier is associated with a
- p2p VLAN it=20 will ignore the DA value and forward the frame to the output=20 port
- p2mp VLAN it=20 will ignore the DA value and looks up in a table the set of output ports of= this=20 p2mp VLAN and forwards the frame to all those output ports
- mp2mp or=20 rmp=A0VLAN it will read the DA and looks up in a table the output port or= =20 ports of this mp2mp VLAN to which this frame should be=20 forwarded.
The ethernet=20 switch also looks at the inner TYPE (i.e. TPID) in all cases on the interfa= ce=20 port to identify if the frame is an OAM frame and then look at the MEL fiel= d and=20 OpCode fields to identify the type of OAM frame and its MEG level to see if= the=20 packet must be processed in the interface port (and not forwarded to the sw= itch=20 fabric).
=A0
[maarten] I=20 don't see as such any functional difference between the mpls and ethern= et data=20 planes; the same information elements are present in both data planes, but = with=20 a different encoding of this information in the frame/packet... the main=20 difference is that standard mpls switches don't use the inner label val= ue to=20 control forwarding of a packet to a subset of output ports of an LSP, while= =20 ethernet switches typically support both=A0the use of the DA value to contr= ol=20 forwarding and the don't use of the DA value to control forwarding to a= subset=20 of VLAN output ports... but note that there is also a set of ethernet switc= hes=20 that only support don't use of the DA value to control forwarding, i.e.= which=20 support only p2p and p2mp VLANs.
=A0
Ethernet=A0data=20 plane=A0inherently recognizes "well-know multicast MAC destination=20 addresses". If a switch wants so, it can catch all the frames with suc= h a DA and=20 decide how it treats them "out-of-band".=A0=A0
=A0
[ma= arten] The well-known MAC multicast destination=20 addresses listed in Table 8-1/802.1Q=A0are identifying management plane and= =20 control plane protocols that are carried over the links; those frames are n= ot=20 belonging to the user traffic carried in the VLANs. In MPLS-TP similar=20 management and control plane information is carried via the MCC and SCC pac= kets=20 specified in RFC5718.
=A0
[ma= arten] If you=20 read G.8021 then you will notice that the well-know multicast MAC destinati= on=20 addresses for OAM are not being recognized in the ETH atomic functions=20 processing Ethernet OAM.=A0=A0
Note that=20 G.8021 has never used the DA field in the Ethernet OAM frame as a means to= =20 identify OAM from non-OAM frames, as Y.1731 has from day one specified OAM= =20 frames that carry=A0a unicast address which do not contain these well-known= =20 OAM=A0multicase destination=20 addresses.=A0
= Y.1731/G.8021 use the TYPE= field to=20 separate OAM from non-OAM frames, the MEL field to identify the MEG level a= nd=20 the OpCode field to identify the type of OAM. <= /font>
=A0
[maarten]=20 MPLS-TP will use the LABEL field to=20 separate LSP-OAM from non-LSP OAM packets, the label stack to identify the = MEG=20 level and the ACH channel type field to identify the type of OAM.=20
I.e. the same information, just a=20 different encoding.
=A0
All Ethernet protocols operate in this way, 802.1ag is not= an=20 exception. And this is=A0exactly what allows separation between=20 addressing=A0and MEP/MIP=A0levels in 802.1ag.=A0
=A0
[ma= arten] As indicated above, your understanding of=20 Ethernet OAM protocol processing does not align with Y.1731/G.8021=20 specifications.
=A0
[ma= arten] The unicast LBM OAM is a special OAM=20 frame/packet as it requires one additional information element; i.e. a MIP= =20 identifier. This MIP identifier must be carried in the LBM OAM frame/packet= in=20 both Ethernet and in=A0bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to= =20 differentiate MIPs in a bidirectional p2mp LSP located at the same hop coun= t=20 from the MEP. Because the bidir p2mp LSP was only recently described in thi= s=20 mailinglist the implications of such LSP on the loopback OAM have not yet b= een=20 investigated and documented.
=A0
[ma= arten] Both in Ethernet and MPLS OAM the OAM process=20 must read this MIP identifier field when the OAM frame/packet is identified= as a=20 LBM OAM. The MIP identifier in Ethernet OAM is the EUI-48 of the physical= =20 subsystem on which the MIP resides, while in MPLS-TP OAM this is not yet in= =20 scope of the OAM framework. But if there is a real demand for such bidir p2= mp=20 LSP or PW, we should include the MIP Identifier in the OAM framework docume= nt=20 for loopback OAM.
=A0
The disadvantage of this approach=20 is that Ethernet OAM frames are not necessarily fate-sharing with the data= =20 traffic.=A0<= /span>
=A0
[maarten] =A0All Ethernet OAM frames=20 fate share with the VLAN (i.e. the Ethernet transport entity) in a similar= =20 manner as all MPLS-TP OAM packets will fate share with the PW and LSP (i.e.= the=20 MPLS transport entities).
=A0
[maarten] There is one type of OAM that has to fate=20 share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to= fate=20 share with both the VLAN/PW/LSP and the frames/packets=A0for which the=20 ingress count is=A0transported in this OAM frame/packet. In p2p/p2mp=20 VLANs/PWs/LSPs there is no problem to meet this requirement. In=A0rmp/mp2mp= =20 VLANs and mp2p PWs/LSPs there is a problem to meet the second requirement. = I.e.=20 no difference as such between Ethernet and MPLS.
= =A0
The MPLS data plane is defi= ned in RFC=20 3031, 30302 and (for upstream-allocated labels)=A0in RFC 5331, 5332.=A0Its= =20 analog of Ethernet well-know multicast MAC destination addresses is the res= erved=20 Router Alert Label.=A0But its=A0usage=A0 has been rejected for usage in=20 MPLS-TP OAM exactly because fate-sharing of data and OAM packets could be= =20 broken. Instead, MPLS-TP uses two different mechanisms:=A0
  1. GAL. This mechanism can only be used = to=20 address MEPs, because the LER processing a packet with the GAL at some le= vel=20 in the label stack is not allowed to look at it unless it terminates all = the=20 labels above it are terminated (i.e., its ILM entries for these labels mu= st be=20 "pop and forward to the loopback interface").=A0 <= font color=3D"#0000ff">[maarten] The ethernet equivalent to the GAL is=20 the OAM ethertype value 89-02.=A0
  2. TTL expiration. This is the only mech= anism=20 for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur= in=20 the first label stack entry following all the labels terminated by the=20 supporting node.=A0 [maarten] As desc= ribed above, as soon as MPLS-TP has to support=20 bidir p2mp LSPs/PWs it will have to include the MIP Identifier to address= the=20 MIP that has to perform the=20 loopback.
[maarten]=A0Ethernet OAM Y.1731=20 specifies an Ethernet MCC OAM frame to carry management plane frames. This = is=20 similar to the MPLS-TP MCC OAM packet defined in=20 RFC5718.

=A0

Regard= s,

Maarten=A0=A0

=A0

In short, LERs do not look at the next la= bel if=20 they do not terminate the previous one.=A0

Hence I think that some = of the MEPs=20 you've defined are non-addressable (and hence unusable) in MPLS-TP whic= h shares=20 the MPLS data plane.=A0

=A0

My 2c,

=A0=A0=A0=A0 Sasha


From:=A0mpls-tp-b= ounces@ietf.org [mpls-tp-bounces@ietf.org] On=20 Behalf Of Maarten=A0Vissers [maarten.vissers@huawei.com]
Sent:=20 Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
<= b>Cc:
=20 mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Hi Greg,
=A0
See inline..=20
From: Greg=A0Mirsky=20 [mailto:gregimir= sky@gmail.com]
Sent:=A0vrijdag 22=A0januari=20 2010 20:29
To: Maarten Vissers
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org<= br>Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes=20 on MPLS Section

Dear Maarten,
I'll concentrate, as you suggested, on the slide = #7 and=20 the following you've wrote "<= font face=3D"Arial" size=3D"2">The intermediate nodes contain multiple MPLS= -TP (MTP) layer network=20 instances".
I think that from the definition of MPLS Sec= tion=20 follows that there can not be an intermediate MPLS node on a given MPLS Sec= tion=20 which is aware of that Section.=A0=A0
= =A0
In your example (slide #7) nodes P and P' (to differentiate them f= rom left=20 to right) of Carrier A are terminating points of MPLS Section of Carrier=20 A.=A0=A0
= =A0
[maarten] Corr= ect.
=A0
S-PEs of Carrier B are unaware of that MPLS Section.=A0=A0
= =A0
[maarten] not = correct. The figure shows two MPLS-TP Section layer MEG=20 levels; the top level MEG has its endpoints (blue MEP functions)=A0in the= =20 carrier A P and P' nodes, the bottom level MEG has its end points in th= e=20 interface ports of P and left S-PE and in right S-PE and P'=20 nodes.
= =A0
[maarten] The = most left and right=A0S-PEs of carrier B terminate the=20 physical media layer (the 802.3 ETY layer) and then the MPLS-TP Section=20 TCM/Segment OAM in the blue colored MEP function. On top of this MEP functi= on=20 there is a (blue) MPLS-TP Section layer MIP function, which will process th= e=20 MPLS-TP Section layer OAM from the top MEG level.
= =A0
[maarten] I ha= ve attached a slightly modified version of the slide 7. The=20 modification is the replacement of the 802.3 interface between carrier A= 9;s P=20 node and the left S-PE node of carrier B by an SDH STM-N interface. Such SD= H=20 interface has excellent section monitoring capabilities and it is now not= =20 necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level be= tween=20 these P and left S-PE nodes. This is reflected by the absence of the lower = blue=20 Section MEP functions.
= =A0
[maarten]=A0On= the side of the=A0adaptation=20 functions=A0=A0between MPLS-TP Section layer and SDH layers (blue/grey=20 colored trapezoid symbols) I have indicated "P-LSE" to represent = that it may be=20 necessary to insert a kind of "priority label stack entry header"= (in analogy to=20 the priority=A0vlan tag in ethernet). The use of such "P-LSE" hea= der on the=20 MPLS-TP over SDH interface would be required when carrier A wants to have= =20 explicit control over the priority and drop eligibility of each of the MPLS= -TP=20 packets passed through the carrier B network; i.e. including the MPLS-TP Se= ction=20 OAM packets. If all Section OAM packets have the same priority/drop eligibi= lity,=20 then insertion of such P-LSE header is not necessary as carrier B's S-P= E node=20 can assign the right priority/drop eligible level to the=A0the unlabelled= =20 (section OAM) packets.
= =A0
[maarten]=A0Fo= r the=A0latter=A0case,=A0the MPLS-TP Section=20 layer signal will have its section OAM equipped with GAL as=20 BOS. = For the former case, the MPLS-TP Section layer signal will have its=20 section OAM equipped with 'P-LSP'=A0 label as BOS and GAL as second= =20 label.
= =A0
[maarten] Assu= me the latter case, then the blue MIP function in the left=20 S-PE node will process the GAL as BOS.
=A0
Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Se= ction,=20 none of nodes of Carrier B, including S-PEs, should bother to process the G= AL.=20 Doing otherwise will break client-server layering.=A0=A0
= =A0
[maarten] I un= derstand why we were coming to different conclusions. I=20 hope I have clarified my view with the SDH physical media layer=20 example.
= =A0
[maarten] You = may now also understand why the definition of Section layer=20 in G.805 defines that the section layer network is concerned with all funct= ions=20 which"**provide for the transfer of=A0infomation between locations in = path=20 layer networks**.
It is=20 this latter item that allows section layer trails to span multiple physical= =20 media layer trails, and thus to have intermediate nodes in the section laye= r=20 connection.
= =A0
[maarten] But = in all honesty, most of the Section layer connections are=20 terminating at the same ports as their underlying physical media layer=20 connections. Someone who looks only at the appearances of section layers in= side=20 one network will conclude that section layer connections terminate at adjac= ent=20 nodes. Someone who looks beyond its own network will conclude that section = layer=20 connections terminate in nodes that provide access to path layer=20 signals.
=A0
That is why I can not agree that an intermediate node contains instanc= es of=20 multiple MPLS-TP networks. I think of a node as performing its functions at= =20 certain MPLS-TP network layer only.=A0=A0
=A0
[maarten] It i= s my understanding that we are missing a description which=20 explicitly describes the mapping of labels onto layers. One MPLS-TP layer= =20 network will in my understanding contain one or more labels. As the=A0ppt= =20 file with my investigation results is too large to attach, I will email you= a=20 copy privately. I have attached a summary of the results up to this point i= n=20 time.
= =A0
Another question is whether Carrier B sets its VC label as BOS or not,= as I=20 understand we haven't decided yet with number of BOS in carrier's c= arrier=20 scenario. But that, to me, is separate discussion.=A0
=A0
[maarten] I ha= ve understood that that decision has been made. Refer to=20 the SB10 comment "Yes.=20 S=3D1 does not indicate the boundary between the client and server. It indi= cates=20 the boundary between the label stack and the label stack payload."=20 in the draft-ietf-mpls-tp-framework-07-post-review-of=20 ITU-T-informal-cts-19-Jan-2010.doc. This is now=A0inlcuded in=20 draft-ietf-mpls-tp-framework-08, see section 3.4.1.

Maarten, I greatly appreciate=20 your input and our discussion.=A0
=A0
[maarten] I ap= preciate your questions and discussion.
=A0
Regards,
Maarten= =A0

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten=A0Viss= ers=20 <maarten.vissers@huawei.com>=20 wrote:
Hi=20 Greg,
=A0
The=20 intermediate nodes contain multiple MPLS-TP (MTP) layer network instances= , of=20 which the top MTP layer is shared by carrier A and B. See slide 7 in the= =20 mplstp-connection-concepts file. Note that the same applies for the case = of=20 Ethernet (ETH) layer networks. In the=20 attached=A0ethernet-connection-concepts file you find the same case=20 illustrated also on slide 7.
=A0
Other=20 slides illustrate other cases of carrier-carrier and customer-carrier=20 interactions.
=A0
Note that=20 the functional models for the MPLS-TP and Ethernet cases are the same; I= =20 already had the Ethernet models and have converted those into MPLS-TP=20 equivalent models to illustrate this section layer question. The differen= ce=20 between both technologies is the encoding of MEG levels; in Ethernet via = the=20 MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE)=20 header.
=A0
Regards,
Maarten


From: Greg=A0Mirsky [mailto:gregimirsky@gmail.com]=20
Sent:=A0vrijdag 22=A0januari 2010 17:55
To:=20 Maarten=A0Vissers=20 Subject:=20 Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS=20 Section

Dear Maarten,
so this is carrier's carrier scenario whe= n MPLS-TP=20 section is client of MPLS-TP transport? But wouldn't presumed process= ing of=20 client MPLS-TP section by intermediate nodes of server MPLS-TP layer be j= ust=20 plain violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten=A0Vis= sers=20 <maarten.vissers@huawei.com>=20 wrote:
Greg,
=A0
It is=20 not uncommon to carry a section layer signal as a service through the= =20 network of another carrier. E.g. Ethernet port based services carry the= =20 Ethernet section layer signals as a service through the transport netwo= rk.=20 The compatible MPLS type of port based service would carry the MPLS sec= tion=20 layer signal as a service through the network of another carrier. The= =20 section will now pass through intermediate nodes.
=A0
Regards,
Maarten


From:=A0mpls-tp-bounces@ietf.org=20 [mailto:m= pls-tp-bounces@ietf.org] On=20 Behalf Of Greg Mirsky
Sent:=A0donderdag 21=A0januari=20 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.c= om;=20 stbryant@cisco.= com
Cc: mp= ls@ietf.org; mpls= -tp@ietf.org
Subject:=20 [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me= as=20 contradiction between quoted in the RFC 5586 definition of the Section = Layer=20 Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The= =20 definition (section 1.3 p.4) refers to section as server layer that pro= vides=20 service between adjacent nodes (my underlining). At the same tim= e,=20 the last paragraph of subsection 4.2.1.2 stipulates behavior of interme= diate=20 nodes on an MPLS Section in regard to G-ACh message, the ACH and the GA= L. If=20 an MPLS Section is between adjacent nodes, then, as I understand the=20 definition, there can not be intermediate nodes on the section (on the= =20 segment, but not on a section) at this particular layer.
Your=20 clarification is greatly=20 appreciated.

Regards,
Greg
=



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp


--001485f778a8be2c1b047e179e23-- From maarten.vissers@huawei.com Tue Jan 26 15:43:09 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5543A68D2; Tue, 26 Jan 2010 15:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 v9arVXYm7rUk; Tue, 26 Jan 2010 15:43:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 85CE03A68BE; Tue, 26 Jan 2010 15:43:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWV00GN2OK5VD@szxga03-in.huawei.com>; Wed, 27 Jan 2010 07:43:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWV00H93OK5PW@szxga03-in.huawei.com>; Wed, 27 Jan 2010 07:43:17 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWV000GSOK56O@szxml01-in.huawei.com>; Wed, 27 Jan 2010 07:43:17 +0800 (CST) Date: Wed, 27 Jan 2010 00:43:16 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' Message-id: <000601ca9ee1$54f8c460$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_gkLwltACeFQf+uECMPu6bQ)" Thread-index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAAAxEoZAAAY80UAAAh+AwAADnMHAAAodX0AAGZm+yAAhJnrA= Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 23:43:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gkLwltACeFQf+uECMPu6bQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Sasha, This is getting into a yes/no discussion at this point in time. We have a different understanding. Each of us believe what we believe, based on the work we have been doing so far. Thanks for the discussion. Regards, Maarten _____ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: dinsdag 26 januari 2010 20:50 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I has believed - and still believe - that Ethernet data plane has been defined (and continues to be defined via multiple updates) by the IEEE 802.1 teams, since 802.1 is the "design authority " for the Ethernet technology - just as IETF is a design authority for MPLS technology and its derivatives. As for differences between Ethernet and MPLS actual data planes - I think those are well known, no need to repeat myself. I firmly believe that attempts to disregard actual data plane differences for the sake of imposing a unified OAM model will eventually fail. Regards, Sasha _____ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Tuesday, January 26, 2010 7:14 PM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, You have an incorrect understanding of the background of Y.1731. Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in 2002 and was initiated by the deployment of Ethernet in transport networks where it replaced SDH equipment. The performance of those initial deployments were extremely poor due to lack of OAM and protection. Set up of VLANs was done by NMS. In the same year work on Ethernet over Transport architecture was initiated in SG15 (by me :-) ), quickly expanding in the development of a series of recommendations specifying the Ethernet as a transport technology. 802.1ag was started later, and implements only a subset of the Y.1731 toolset; i.e. the subset which spanning tree protocol/vlan registration protocol controlled ethernet switches specified in 802.1 would need and can use. But ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking possible between networks using Y.1731 and networks using 802.1ag. Ethernet switches compliant with ITU-T's Ethernet recommendations are transport network grade switches (with VLAN ID translation capabilities (e.g. VID translation, PW label swapping) in every node), which are managed by NMS and optionally the GMPLS control plane. The Ethernet data plane specified in the ITU-T Recommendations supports all MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet VC connections. Some operators have recognized this and have build their packet transport network with a UNI-to-UNI Ethernet VC layer as their transport service layer; transport path layer technologies used are Ethernet VP and MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are used for broadband backhaul in such networks, p2p Ethernet VC connections are used to support any type of Line service and mp2mp Ethernet VC connections are used to support E-LAN services. With the growing bandwidth demand OTN ODUs will be added in the near future as transport path layer technology to carry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet data planes in such networks are managed in the same way. Ethernet Transport Networks (ETN) exist for many years already and are proven technology. It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T Ethernet recommendations based) Ethernet VLAN data plane functionalities are the same and that we can and should use the very similar OAM, protection switching and the same management principles. T-MPLS was fully based on this understanding and approach, and was designed to seamlessly operate in a hybrid T-MPLS/Ethernet packet transport network. My hope is that seamless interoperability will also be possible in the emerging hybrid MPLS-TP/Ethernet packet transport networks. Regards, Maarten --Boundary_(ID_gkLwltACeFQf+uECMPu6bQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Sasha,
 
This is getting into a yes/no discussion at this point in time.
We have a different understanding.
Each of us believe what we believe, based on the work we have been doing so far.
Thanks for the discussion.
 
Regards,
Maarten


From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: dinsdag 26 januari 2010 20:50
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
I has believed - and still believe - that Ethernet data plane has been defined (and continues to be defined via multiple updates) by the IEEE 802.1 teams, since 802.1 is the "design authority " for the Ethernet technology - just as IETF is a design authority for MPLS technology and its derivatives.
 
As for differences between Ethernet and MPLS actual data planes - I think those are well known, no need to repeat myself.
 
I firmly believe that attempts to disregard actual data plane differences for the sake of imposing a unified OAM model will eventually fail.
 
Regards,
     Sasha
 

From: Maarten Vissers [maarten.vissers@huawei.com]
Sent: Tuesday, January 26, 2010 7:14 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Sasha,
 
You have an incorrect understanding of the background of Y.1731.
Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in 2002 and was initiated by the deployment of Ethernet in transport networks where it replaced SDH equipment. The performance of those initial deployments were extremely poor due to lack of OAM and protection. Set up of VLANs was done by NMS. In the same year work on Ethernet over Transport architecture was initiated in SG15 (by me :-) ), quickly expanding in the development of a series of recommendations specifying the Ethernet as a transport technology.
 
802.1ag was started later, and implements only a subset of the Y.1731 toolset; i.e. the subset which spanning tree protocol/vlan registration protocol controlled ethernet switches specified in 802.1 would need and can use. But ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking possible between networks using Y.1731 and networks using 802.1ag.
 
Ethernet switches compliant with ITU-T's Ethernet recommendations are transport network grade switches (with VLAN ID translation capabilities (e.g. VID translation, PW label swapping) in every node), which are managed by NMS and optionally the GMPLS control plane.
 
The Ethernet data plane specified in the ITU-T Recommendations supports all MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet VC connections. Some operators have recognized this and have build their packet transport network with a UNI-to-UNI Ethernet VC layer as their transport service layer; transport path layer technologies used are Ethernet VP and MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are used for broadband backhaul in such networks, p2p Ethernet VC connections are used to support any type of Line service and mp2mp Ethernet VC connections are used to support E-LAN services. With the growing bandwidth demand OTN ODUs will be added in the near future as transport path layer technology to carry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet data planes in such networks are managed in the same way. Ethernet Transport Networks (ETN) exist for many years already and are proven technology.
 
It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T Ethernet recommendations based) Ethernet VLAN data plane functionalities are the same and that we can and should use the very similar OAM, protection switching and the same management principles. T-MPLS was fully based on this understanding and approach, and was designed to seamlessly operate in a hybrid T-MPLS/Ethernet packet transport network. My hope is that seamless interoperability will also be possible in the emerging hybrid MPLS-TP/Ethernet packet transport networks.
 
Regards,
Maarten
 

 
--Boundary_(ID_gkLwltACeFQf+uECMPu6bQ)-- From ldunbar@huawei.com Tue Jan 26 16:31:12 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3093A6768; Tue, 26 Jan 2010 16:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PX4VqPrpbd4l; Tue, 26 Jan 2010 16:31:12 -0800 (PST) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id 329083A63C9; Tue, 26 Jan 2010 16:31:12 -0800 (PST) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2010012616312431467 ; Tue, 26 Jan 2010 16:31:24 -0800 Received: from L735042 ([10.0.103.99]) by s-utl01-sjpop.stsn.net; Tue, 26 Jan 2010 16:31:23 -0800 From: "Linda Dunbar" To: "'Loa Andersson'" , , , , References: <4B4DFC51.8050301@pi.nu> Date: Tue, 26 Jan 2010 18:31:15 -0600 Message-ID: <007c01ca9ee8$10817000$d867000a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqUclEF3wbLlNyvSOKn9kGSlOPK/AKdbEew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B4DFC51.8050301@pi.nu> Subject: Re: [mpls] [CCAMP] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:31:13 -0000 Support. Linda Dunbar -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, January 13, 2010 11:01 AM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [CCAMP] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Tue Jan 26 18:45:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7CA833A68A0; Tue, 26 Jan 2010 18:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100127024501.7CA833A68A0@core3.amsl.com> Date: Tue, 26 Jan 2010 18:45:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-fault-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 02:45:01 -0000 --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 : MPLS Fault Management OAM Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-tp-fault-00.txt Pages : 12 Date : 2010-01-26 This draft specifies OAM messages to indicate service disruptive conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-fault-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26184145.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Tue Jan 26 21:19:18 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F49E3A686D; Tue, 26 Jan 2010 21:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 c9d3nGXyWq42; Tue, 26 Jan 2010 21:19:11 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 1489B3A69FE; Tue, 26 Jan 2010 21:19:09 -0800 (PST) X-AuditID: 93eaf2e7-b7c38ae000000ed6-74-4b5fcbae14b6 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 71.FA.03798.EABCF5B4; Wed, 27 Jan 2010 07:14:23 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 27 Jan 2010 07:19:21 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Wed, 27 Jan 2010 07:18:45 +0200 Thread-Topic: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQACQ8oWAAAxEoZAAAY80UAAAh+AwAADnMHAAAodX0AAGZm+yAAhJnrAAC9H+Zw== Message-ID: References: , <000601ca9ee1$54f8c460$e6150674@china.huawei.com> In-Reply-To: <000601ca9ee1$54f8c460$e6150674@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF4ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 05:19:19 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF4ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maarten, Looks like one point where we come to full agreement! Thanks for an interesting discussion and best regards, Sasha ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Wednesday, January 27, 2010 1:43 AM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, This is getting into a yes/no discussion at this point in time. We have a different understanding. Each of us believe what we believe, based on the work we have been doing so= far. Thanks for the discussion. Regards, Maarten ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: dinsdag 26 januari 2010 20:50 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I has believed - and still believe - that Ethernet data plane has been defi= ned (and continues to be defined via multiple updates) by the IEEE 802.1 te= ams, since 802.1 is the "design authority " for the Ethernet technology - j= ust as IETF is a design authority for MPLS technology and its derivatives. As for differences between Ethernet and MPLS actual data planes - I think t= hose are well known, no need to repeat myself. I firmly believe that attempts to disregard actual data plane differences f= or the sake of imposing a unified OAM model will eventually fail. Regards, Sasha ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Tuesday, January 26, 2010 7:14 PM To: Alexander Vainshtein Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, You have an incorrect understanding of the background of Y.1731. Y.1731 is created by ITU-T SG13 with the help of SG15. The work started in = 2002 and was initiated by the deployment of Ethernet in transport networks = where it replaced SDH equipment. The performance of those initial deploymen= ts were extremely poor due to lack of OAM and protection. Set up of VLANs w= as done by NMS. In the same year work on Ethernet over Transport architectu= re was initiated in SG15 (by me :-) ), quickly expanding in the development= of a series of recommendations specifying the Ethernet as a transport tech= nology. 802.1ag was started later, and implements only a subset of the Y.1731 tools= et; i.e. the subset which spanning tree protocol/vlan registration protocol= controlled ethernet switches specified in 802.1 would need and can use. Bu= t ITU-T SG13/15 and IEEE 802.1 made sure that there is interworking possibl= e between networks using Y.1731 and networks using 802.1ag. Ethernet switches compliant with ITU-T's Ethernet recommendations are trans= port network grade switches (with VLAN ID translation capabilities (e.g. VI= D translation, PW label swapping) in every node), which are managed by NMS = and optionally the GMPLS control plane. The Ethernet data plane specified in the ITU-T Recommendations supports all= MPLS(-TP) data plane capabilities plus it supports rmp and mp2mp Ethernet = VC connections. Some operators have recognized this and have build their pa= cket transport network with a UNI-to-UNI Ethernet VC layer as their transpo= rt service layer; transport path layer technologies used are Ethernet VP an= d MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are= used for broadband backhaul in such networks, p2p Ethernet VC connections = are used to support any type of Line service and mp2mp Ethernet VC connecti= ons are used to support E-LAN services. With the growing bandwidth demand O= TN ODUs will be added in the near future as transport path layer technology= to carry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet= data planes in such networks are managed in the same way. Ethernet Transpo= rt Networks (ETN) exist for many years already and are proven technology. It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T = Ethernet recommendations based) Ethernet VLAN data plane functionalities ar= e the same and that we can and should use the very similar OAM, protection = switching and the same management principles. T-MPLS was fully based on thi= s understanding and approach, and was designed to seamlessly operate in a h= ybrid T-MPLS/Ethernet packet transport network. My hope is that seamless in= teroperability will also be possible in the emerging hybrid MPLS-TP/Etherne= t packet transport networks. Regards, Maarten --_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF4ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maarten,
Looks like one point where = we come to full agreement!
Thanks for an interesting d= iscussion and best regards,
     Sa= sha

From: Maarten Vissers [maarten.viss= ers@huawei.com]
Sent: Wednesday, January 27, 2010 1:43 AM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Sasha,
 
This is getting into a yes/no dis= cussion at this point in time.
We have a different understanding= .
Each of us believe what we believ= e, based on the work we have been doing so far.
Thanks for the discussion.=
 
Regards,
Maarten


From: Alexander Vainshtein [mailto:= Alexander.Vainshtein@ecitele.com]
Sent: dinsdag 26 januari 2010 20:50
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Maarten,
I has believed - and s= till believe - that Ethernet data plane has been defined (and continue= s to be defined via multiple updates) by the IEEE 802.1 team= s, since 802.1 is the "design authority " for the Ethernet techno= logy - just as IETF is a design authority for MPLS technology and its derivativ= es.
 
As for differences between = Ethernet and MPLS actual data planes - I think those are well known, no nee= d to repeat myself.
 
I firmly believe that = attempts to disregard actual data plane differences for the sake of imposin= g a unified OAM model will eventually fail.
 
Regards,
     Sa= sha
 

From: Maarten Vissers [maarten.viss= ers@huawei.com]
Sent: Tuesday, January 26, 2010 7:14 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Sasha,
 
You have an incorrect understandi= ng of the background of Y.1731.
Y.1731 is created by ITU-T SG13 w= ith the help of SG15. The work started in 2002 and was initiated by the dep= loyment of Ethernet in transport networks where it replaced SDH equipment. The performance of those initial deployments we= re extremely poor due to lack of OAM and protection. Set up of VLANs was do= ne by NMS. In the same year work on Ethernet over Transport architecture wa= s initiated in SG15 (by me :-) ), quickly expanding in the development of a series of recommendations specif= ying the Ethernet as a transport technology.
 
802.1ag was started later, and im= plements only a subset of the Y.1731 toolset; i.e. the subset which spannin= g tree protocol/vlan registration protocol controlled ethernet switches specified in 802.1 would need and can use. But ITU-T SG1= 3/15 and IEEE 802.1 made sure that there is interworking possible betw= een networks using Y.1731 and networks using 802.1ag.
 
Ethernet switches compliant with = ITU-T's Ethernet recommendations are transport network grade switches (with= VLAN ID translation capabilities (e.g. VID translation, PW label swapping) in every node), which are managed by = NMS and optionally the GMPLS control plane.
 
The Ethernet data plane specified= in the ITU-T Recommendations supports all MPLS(-TP) data plane capabi= lities plus it supports rmp and mp2mp Ethernet VC connections. Some operators have recognized this and have build their pack= et transport network with a UNI-to-UNI Ethernet VC layer as their transport= service layer; transport path layer technologies used are Ethernet VP and&= nbsp;MPLS(-TP) VP. The efficient rooted-multipoint Ethernet VC connections are used for broadband backhaul in such networks, = p2p Ethernet VC connections are used to support any type of Line service an= d mp2mp Ethernet VC connections are used to support E-LAN services. With th= e growing bandwidth demand OTN ODUs will be added in the near future as transport path layer technology to car= ry the Ethernet VC connections between S-PE nodes. MPLS and Ethernet data p= lanes in such networks are managed in the same way. Ethernet Transport Netw= orks (ETN) exist for many years already and are proven technology.
 
<= span class=3D"031453916-26012010">It is on this basis that I continue to state that the MPLS(-TP) and (ITU-T Ethernet recommendations based) Eth= ernet VLAN data plane functionalities are the same and that we ca= n and should use the very similar OAM, protection switching and the same ma= nagement principles. T-MPLS was fully based on this understanding and approach, and was designed to seamlessly operate= in a hybrid T-MPLS/Ethernet packet transport network. My hope is that seam= less interoperability will also be possible in the emerging hybrid MPLS-TP/= Ethernet packet transport networks.
 
Regards,
Maarten
 

 
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFF4ILPTMAIL02eci_-- From michelg@upperside.fr Wed Jan 27 02:32:53 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CA33A691A for ; Wed, 27 Jan 2010 02:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 HlwXz4Rm+u6C for ; Wed, 27 Jan 2010 02:32:52 -0800 (PST) Received: from smtp02.msg.oleane.net (smtp02.msg.oleane.net [62.161.4.2]) by core3.amsl.com (Postfix) with ESMTP id 1A0963A68FC for ; Wed, 27 Jan 2010 02:32:51 -0800 (PST) Received: from nbMichelvst (AAubervilliers-752-1-14-86.w90-35.abo.wanadoo.fr [90.35.221.86]) (authenticated) by smtp02.msg.oleane.net (MSA) with ESMTP id o0RAX2Af018526 for ; Wed, 27 Jan 2010 11:33:02 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 27 Jan 2010 11:31:04 +0100 Message-ID: <065D2A92E7554159B44C734610E6FB6F@UPPERSIDECONFERENCES.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CA9F44.3622C000" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Thread-index: AcqfO9QbWn+mMyvKQT+eDOZVU+vaqg== X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.1.27.101820 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Congress Paris 2010 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 10:32:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004F_01CA9F44.3622C000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The MPLS World Congress and the Ethernet Wholesale conferences start in two weeks in Paris. Main issues to be addressed by key players in this area: MPLS-TP & OAM Access and Aggregation Cloud Computing MPLS in the RAN There is still time to register. More info.: http://www.upperside.fr/ ------=_NextPart_000_004F_01CA9F44.3622C000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MPLS World Congress and the Ethernet = Wholesale conferences start in two weeks in Paris.

 

Main issues to be addressed by key players in = this area:

 

MPLS-TP & OAM

Access and = Aggregation

Cloud Computing<= /p>

MPLS in the RAN

 

There is still time to register.

 

More info.:

http://www.upperside.fr/

 

 

 

 

------=_NextPart_000_004F_01CA9F44.3622C000-- From neil.2.harrison@bt.com Wed Jan 27 03:00:58 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06103A6A39; Wed, 27 Jan 2010 03:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] 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 IZi-oPB6YTLv; Wed, 27 Jan 2010 03:00:56 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 690AB3A6925; Wed, 27 Jan 2010 03:00:56 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 11:01:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9F40.08C7CA3D" Date: Wed, 27 Jan 2010 11:01:00 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C058B685A@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Thread-Index: Acqe0/OfY447O/CKQLurAaZdPraxtAAZheIwAAF1wkA= From: To: , X-OriginalArrivalTime: 27 Jan 2010 11:01:09.0429 (UTC) FILETIME=[07FDFE50:01CA9F40] Cc: mpls@ietf.org, Alexander.Vainshtein@ecitele.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 11:00:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9F40.08C7CA3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Snipped and re-sending as I got a bounce indication due to original length ________________________________ From: Harrison,N,Neil,DKQ7 R=20 Sent: 27 January 2010 10:57 To: 'Greg Mirsky'; Maarten Vissers Cc: mpls@ietf.org; Alexander Vainshtein; mpls-tp@ietf.org Subject: RE: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Some care is going to need to be exercised here...why? Well, I was on the MPLS-TP audio-conf call yesterday that considered 2 issues (both that I have raised previously): - what does the term 'network layer' mean? - why should MS PWs exist in MPLS-TP? =20 Wrt to the latter item the technical issue here is that PWs are an artefact of the architectural conditions imposed by the LDP form of MPLS, and since LDP is not used in MPLS-TP then PWs are not technically required in MPLS-TP. Furthermore, we should not create a new (PW) co-ps mode layer network above MPLS-TP (which is what MS PWs represent) just because we can. A very closely related issue is the difference between (i) true client/server LSP layering and (ii) nested LSP sublayering that we find in MPLS today and identified from the setting of the S bit (note that the former demands different routing instances per client and server whilst the latter assumes the same instance of routing across the sublayers) =20 What became clear from the ensuing discussion is (this is only a subset of conclusions reached): - the above is technically accurate, ie if we were designing MPLS-TP without the history there would be no need to create PWs - MS PWs are optional - (and the key point wrt this thread) MPLS-TP will allow both (i) nested LSPs as we find in MPLS today (sublayering, same layer network) and (ii) true client/server LSPs (true layering, different layer networks) to exist....the choice is down to the network operator...and *maybe both these cases can appear in the same stack of nested headers* (?) =20 I am not quite sure how one can distinguish cases (i) and (ii) from just looking at DP headers, but the key point I wanted to make here is that in case (ii) there must be no snooping of the client layer network as transparency and client/server layer network functional decoupling are essential (this observation applies to all client/server cases). Note carefully that in MPLS as-is one cannot tell the implied semantic of a label just from looking at the DP header, one has to know the context of the label (ie essentially which 'signalling' protocol issued it) to know this. Note also that TCM is a form of sublayering and one can justify snooping here *iff* one is sure of the semantic of the higher level header (especially the label).=20 =20 I think there could be some quite interesting problems in a multi-party networking scenario due to this sublayering/layering flexibility. My personal view is that a transport network does not require sublayering. =20 regards, Neil ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: 26 January 2010 21:04 To: Maarten Vissers Cc: mpls@ietf.org; Alexander Vainshtein; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section =09 =09 Dear Maarten, I think that your scenarios are based on the following assumption you're making "The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; new mpls switch ports will be able to look at inner labels of all packets (my underline); this is a similar evolution as we got in ethernet... " I don't think that is the direction where MPLS-TP should go and will go. =09 Regards, Greg =09 ------_=_NextPart_001_01CA9F40.08C7CA3D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Snipped and re-sending as I got a bounce = indication due=20 to original length


From: Harrison,N,Neil,DKQ7 R =
Sent:=20 27 January 2010 10:57
To: 'Greg Mirsky'; Maarten=20 Vissers
Cc: mpls@ietf.org; Alexander Vainshtein;=20 mpls-tp@ietf.org
Subject: RE: [mpls] [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Some care is going to need to = be exercised=20 here...why?  Well, I was on the MPLS-TP audio-conf call yesterday = that=20 considered 2 issues (both that I have raised = previously):
-    what does = the term=20 'network layer' mean?
-    why should = MS PWs exist=20 in MPLS-TP?
 
Wrt to the latter item the = technical issue=20 here is that PWs are an artefact of the architectural conditions = imposed by=20 the LDP form of MPLS, and since LDP is not used in MPLS-TP then PWs = are not=20 technically required in MPLS-TP.  Furthermore, we should not = create=20 a new (PW) co-ps mode layer network above MPLS-TP (which is what MS = PWs=20 represent) just because we can.  A very closely related issue is = the=20 difference between (i) true client/server LSP layering and (ii) nested = LSP=20 sublayering that we find in MPLS today and identified from the setting = of the=20 S bit (note that the former demands different routing instances per = client and=20 server whilst the latter assumes the same instance of routing across = the=20 sublayers)
 
What became clear from the = ensuing=20 discussion is (this is only a subset of conclusions=20 reached):
-    the above = is=20 technically accurate, ie if we were designing MPLS-TP without the = history=20 there would be no need to create PWs
-    MS PWs are=20 optional
-    (and = the key point=20 wrt this thread) MPLS-TP will allow both (i) nested LSPs as we find in = MPLS=20 today (sublayering, same layer network) and (ii) true client/server = LSPs (true=20 layering, different layer networks) to exist....the choice is down to = the=20 network operator...and *maybe both these cases can appear in the same = stack of=20 nested headers* (?)
 
I am not quite sure how one can distinguish = cases (i)=20 and (ii) from just looking at DP headers, but the key point I wanted to make here is = that in=20 case (ii) there must be no snooping of the client layer network as=20 transparency and client/server layer network functional decoupling are = essential (this observation applies to all client/server cases).  = Note=20 carefully that in MPLS as-is one cannot tell the implied semantic of a = label=20 just from looking at the DP header, one has to know the context of the = label=20 (ie essentially which 'signalling' protocol issued it) to know = this. =20 Note also that TCM is a form of sublayering and one can justify = snooping here=20 *iff* one is sure of the semantic of the higher level header = (especially the=20 label). 
 
I think there could be some quite = interesting=20 problems in a multi-party networking scenario due to this = sublayering/layering=20 flexibility.  My personal view is that a transport network does = not=20 require sublayering.
 
regards, Neil

From:=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Greg=20 Mirsky
Sent: 26 January 2010 21:04
To: Maarten=20 Vissers
Cc: mpls@ietf.org; Alexander Vainshtein;=20 mpls-tp@ietf.org
Subject: Re: [mpls] [mpls-tp] RFC 5586:=20 Intermediate nodes on MPLS Section

Dear Maarten,
I think that your scenarios are based on = the=20 following assumption you're making "The existing mpls switch ports will = only be=20 able to look at inner labels of packets of which the outer label is=20 terminated; new mpls switch ports will be able to look at inner = labels of=20 all packets (my underline); this is a similar evolution as we = got in=20 ethernet... " I don't think that is the direction = where=20 MPLS-TP should go and will=20 go.

Regards,
Greg
------_=_NextPart_001_01CA9F40.08C7CA3D-- From mach@huawei.com Thu Jan 28 04:57:14 2010 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C493A6782; Thu, 28 Jan 2010 04:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 AfPoQNhuWa1B; Thu, 28 Jan 2010 04:57:13 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 97B333A672E; Thu, 28 Jan 2010 04:57:13 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWY00MATJZTEO@szxga02-in.huawei.com>; Thu, 28 Jan 2010 20:57:30 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWY00E4KJZT2C@szxga02-in.huawei.com>; Thu, 28 Jan 2010 20:57:29 +0800 (CST) Date: Thu, 28 Jan 2010 20:57:29 +0800 From: Mach Chen In-reply-to: <4B4DFC51.8050301@pi.nu> To: Loa Andersson , mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Message-id: <387E4A6CAB424C53ADDF9C59DAD04F43@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <4B4DFC51.8050301@pi.nu> Subject: Re: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 12:57:14 -0000 yes/support Mach -------------------------------------------------- From: "Loa Andersson" Sent: Thursday, January 14, 2010 1:01 AM To: ; ; ; Subject: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document > All, > > this is to start a two week poll on making > > http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, > indicating "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > Please note that it is a conscious decision by the wg chair to poll > the linear-protection document prior to the ring-protection > document, since we want to make room for separated discussions on > the two documents. > > The poll ends Friday juanuary 29, 2010. > > /Loa > -- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From root@core3.amsl.com Fri Jan 29 07:15:01 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BB0FF28B56A; Fri, 29 Jan 2010 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100129151501.BB0FF28B56A@core3.amsl.com> Date: Fri, 29 Jan 2010 07:15:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:15:01 -0000 --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 in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-09.txt Pages : 48 Date : 2010-01-29 This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions - the MPLS Transport Profile (MPLS-TP) - that supports the operational models and capabilities typical of such networks, including signalled or explicitly provisioned bi-directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point paths. The remaining subset, applicable specifically to point-to-multipoint paths, are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-tp-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-29070431.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Jan 29 15:15:02 2010 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A13C73A677C; Fri, 29 Jan 2010 15:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100129231502.A13C73A677C@core3.amsl.com> Date: Fri, 29 Jan 2010 15:15:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-upstream-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 23:15:02 -0000 --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 : MPLS Upstream Label Assignment for LDP Author(s) : R. Aggarwal, J. Le Roux Filename : draft-ietf-mpls-ldp-upstream-05.txt Pages : 11 Date : 2010-01-29 This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-upstream-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mpls-ldp-upstream-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-29151202.I-D@ietf.org> --NextPart--