From Martin.Vigoureux@alcatel-lucent.com Mon Feb 1 02:47:08 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 EF95128C120 for ; Mon, 1 Feb 2010 02:47:07 -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_FR=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 t-E767kxCoES for ; Mon, 1 Feb 2010 02:47:07 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 88E1428C0E9 for ; Mon, 1 Feb 2010 02:45:46 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o11Ak67t008312; Mon, 1 Feb 2010 11:46:07 +0100 Received: from [172.27.205.236] ([172.27.205.236]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:46:04 +0100 Message-ID: <4B66B0E8.5000604@alcatel-lucent.com> Date: Mon, 01 Feb 2010 11:46:00 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 10:46:04.0103 (UTC) FILETIME=[C070F570:01CAA32B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: Nurit Sprecher , Huub van Helvoort , Stewart Bryant Subject: [mpls] End of poll for draft-weingarten-mpls-tp-linear-protection 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, 01 Feb 2010 10:47:08 -0000 all, the poll for making draft-weingarten-mpls-tp-linear-protection-05 an MPLS WG document has ended. There was support for this. Could the Editors please republish as: draft-ietf-mpls-tp-linear-protection-00 and address as part of a later revision comments that would have been expressed during the poll period. regards, martin From Alexander.Vainshtein@ecitele.com Mon Feb 1 08:59: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 AC2E23A695A; Mon, 1 Feb 2010 08:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, 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 Hx9OqrMjIOuZ; Mon, 1 Feb 2010 08:59:26 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 032713A67B4; Mon, 1 Feb 2010 08:59:24 -0800 (PST) X-AuditID: 93eaf2e7-b7cc5ae000002e30-56-4b67074b3af1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 10.32.11824.B47076B4; Mon, 1 Feb 2010 18:54:35 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 1 Feb 2010 18:59:58 +0200 From: Alexander Vainshtein To: "stbryant@cisco.com" , 'Dan Frost' , 'BOCCI Matthew' Date: Mon, 1 Feb 2010 18:59:57 +0200 Thread-Topic: Comments on draft-fbb-mpls-tp-data-plane-00 Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5Q== Message-ID: 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_A3C5DF08D38B6049839A6F553B331C76BFDEE35F51ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-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: Mon, 01 Feb 2010 16:59:27 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDEE35F51ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 2. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 3. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 4. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 5. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_A3C5DF08D38B6049839A6F553B331C76BFDEE35F51ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Stewart, = Dan,=20 Matthew and all,
First of = all I'd=20 like to say that the need for clear-cut definition of the MPLS-TP data plan= e=20 architecture has been quite clear to me.
The draft= is clearly=20 the necessary first step in the right direction, and I thank you for produc= ing=20 it.
 
That said= , I think=20 that quite a few issues have been left undecided in this -00 version of the= =20 draft.
 
I will ma= ke a=20 (hopefully, short) list of items that IMHO require additional clarification= and,=20 eventually, codification.
 
  1. = LSP=20 Merge:
    • In MPL= S, nothing=20 prevents LSPs from merging at some point:
      • One = well-known=20 usage of LSP merge is FRR
      • PHP = can be=20 considered as a special case of LSP merge
    • One of= the often=20 repeated mantras of MPLS-TP is that its LSPs cannot be=20 merge. 
    • It is = not clear=20 (at least, to me):
      • Whet= her this=20 limitation has to be respected at the data plane level, and if yes, t= hen=20 how
      • Whet= her it=20 means that FRR cannot be used in MPLS-TP
    • Status= of this=20 topic in the -00 draft: not mentioned at all
  2. Per-Interface Label=20 Space:
    • The dr= aft states=20 that per-interface label space MAY be used in MPLS-TP
    • AFAIK,= in=20 MPLS:
      • This= referred=20 to data links (including bundles, e.g., produced by LAG). As a=20 consequence, the number of label contexts has been reasonably=20 low
      • This= has been=20 only allowed on P2P links
    • One of= the=20 problems with MPLS-TP is that in many cases it does not differenti= ate=20 between data links and lower layer LSPs (see also my notes regarding=20 Sections). As a consequence, it is not clear (to me) whether per-interf= ace=20 label space may become a label space per lower layer LSP. (To the best = of my=20 understanding this is explicitly prohibited by RFC=20 3031).
    • Status= of this=20 topic in the -00 draft: requires clarification, preferably aligned with= RFC=20 3031.
  3. Sections:
    • The dr= aft states=20 that Sections could be data links (level 0 sections) or LSPs with N lab= els=20 (level N Sections).
    • The fo= llowing=20 is not clear to me:
      • Can = LAN-like=20 data links be Sections in MPLS-TP (The Editors ask this question=20 themselves when they discuss MAC addresses)
      • Whic= h types of=20 LSPs can be Sections (e.g., can a P2P unidirectional LSP be a=20 Section? Can an associated bi-directional LSP be a section? etc.).=20
      • If a= ssociated=20 bi-directional LSPs can be Sections, can we treat the LSPs rumming ov= er=20 these Sections as co-routed bidirectional?
      • Per-= data link=20 (interface) label space is supported in MPLS. Does MPLS-Tp allow=20 per-Section label space (see above)?
    • Status= of this=20 topic in the -00 draft: requires clarification, one aspect already=20 recognized as such by the Editors. IMHO and FWIW preferred resolution w= ould=20 be to equate Sections with data links
  4. = Label=20 Allocation Schemes:
    • MPLS r= ecognizes=20 two label allocation schemes, each with its own area of=20 applicability:
      • Down= stream=20 label allocation as per RFC 3031
      • Upst= ream label=20 allocation as per RFC 5331
    • IMHO t= he label=20 allocation scheme is essentially a data plane issue:
      • Labe= l=20 allocation scheme is reflected in the Ethertype in the case of Ethern= et=20 encapsulation etc.
      • Packets with invalid labels mus= t be=20 silently discarded=20 etc.
    • It is = not clear=20 to me, which label allocation schemes can be used in= =20 MPLS-TP.
      • This= includes=20 applicability of these schemes, e.g., can we use upstream label alloc= ation=20
      • This= issue is=20 closely related to proposed usage of a well-known multicast= MAC=20 destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requi= res=20 clarification
  5. MAC addresses on Ethernet data links i= n=20 MPLS-TP:
    • The draft discusses this topic, and proposes= using=20 a well-known multicast DA in Ethernet encapsulations for for P2P=20 LSPs
    • IMHO and FWIW if LAN interfaces are all= owed in=20 MPLS-TP, usage of  well-known multicast DA is not compatible with = the=20 downstream label allocation scheme.
    • Status of this topic in the -00-draft: parti= ally=20 recognized by the Editors, there seems to be a bug in the proposed=20 solution.
Hopefully, these notes will be=20 useful.
 
Regards,
    =20 Sasha
    •  
--_000_A3C5DF08D38B6049839A6F553B331C76BFDEE35F51ILPTMAIL02eci_-- From wwwrun@core3.amsl.com Mon Feb 1 12:55:16 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 32B3E3A6874; Mon, 1 Feb 2010 12:55:16 -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: <20100201205516.32B3E3A6874@core3.amsl.com> Date: Mon, 1 Feb 2010 12:55:16 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, ghani.abbas@ericsson.com, hklam@alcatel-lucent.com, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03)" 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, 01 Feb 2010 20:55:16 -0000 Title: LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03) Submission Date: 2010-02-01 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=633 Please reply by 2010-04-09 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: ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@huawei.com hklam@alcatel-lucent.com Purpose: For action Body: Thank you for your liaison statement (ref # 010.02) providing a list of the MPLS-TP drafts that are either completed or currently in progress. Attached is a table indicating our current view of the dependency between the ITU-T MPLS-TP Recommendations and these drafts. We would appreciate an update on the status of the drafts and in particular confirmation that the drafts identified as being required for normative references for the consent of Recommendations in June 2010 will be available. Attachment: Dependency table, 31 January 2010 Attachment(s): LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file750.pdf) LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03) - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file751.pdf) From root@core3.amsl.com Tue Feb 2 07:45:45 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 24A5B28C0ED; Tue, 2 Feb 2010 07:45:39 -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: <20100202154545.24A5B28C0ED@core3.amsl.com> Date: Tue, 2 Feb 2010 07:45:39 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-ach-tlv-01.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, 02 Feb 2010 15:45:45 -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 : Definition of ACH TLV Structure Author(s) : S. Boutros, et al. Filename : draft-ietf-mpls-tp-ach-tlv-01.txt Pages : 11 Date : 2010-02-02 In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types. The following notes (up until the start of "Requirements Language" will be deleted before Working Group Last Call NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1. NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2. NOTE The intension is to keep this document as a living list of TLVs for some time. When the Working Groups consider that we have captured the majority of the TLVs we will close the document and submit for publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ach-tlv-01.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-ach-tlv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-02073653.I-D@ietf.org> --NextPart-- From lieven.levrau@alcatel-lucent.com Tue Feb 2 23:05:51 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 7FBE33A6860; Tue, 2 Feb 2010 23:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 WWG3XgpnieQ2; Tue, 2 Feb 2010 23:05:43 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3C9293A67E5; Tue, 2 Feb 2010 23:05:42 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o13765Rc005160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 08:06:17 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 3 Feb 2010 08:06:13 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: Alexander Vainshtein , "stbryant@cisco.com" , "'Dan Frost'" , "Bocci, Matthew (Matthew)" Date: Wed, 3 Feb 2010 08:06:03 +0100 Thread-Topic: Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+Pw Message-ID: References: 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_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA4FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [mpls] Label alloc. Schemes in data-plane-draft' 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, 03 Feb 2010 07:05:51 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA4FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label all= oc. Schemes in data-plane-draft' In my view - This is a control plane issue and not a data plane issue. How = the labels are assigned is outside the scope of the draft. ./ Lieven 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 1. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 1. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 1. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA4FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-= 00 -> Label alloc. Schemes in data-plane-draft’

 

In my view - This is a control plane issue and not a data pl= ane issue. How the labels are assigned is outside the scope of the draft.<= /o:p>

 

./

Lieven

  1. Label Allocation Schemes:
    • MPLS recognizes two label allocation schemes, e= ach with its own area of applicability:
      • Downstream label allocation as per RFC 3031
      • Upstream label allocation as per RFC 5331
    • IMHO the label allocation scheme is essentially= a data plane issue:
      • Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
      • Packets with invalid labels must be silently discarded etc.
    • It is not clear to me, which label allocation schemes can be used in MPLS-TP.
      • This includes applicability of these schemes, e.g., can we use upstream label allocation
      • This issue is closely related to proposed usag= e of a well-known multicast MAC destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requires clarification

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Al= exander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

 

Stewart, Dan, Matthew and all,

First of all I'd like to say that the need for clear-cut definition of the MPLS-T= P data plane architecture has been quite clear to me.

The draft is clearly the necessary first step in the right direction, and I tha= nk you for producing it.

 

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

 

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 

  1. LSP Merge:
    • In MPLS, nothing prevents LSPs from merging at = some point:
      • One well-known usage of LSP merge is FRR
      • PHP can be considered as a special case of LSP merge
    • One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. 
    • It is not clear (at least, to me):<= /o:p>
      • Whether this limitation has to be respected at= the data plane level, and if yes, then how
      • Whether it means that FRR cannot be used in MPLS-TP
    • Status of this topic in the -00 draft: not mentioned at all
  1. Per-Interface Label Space:
    • The draft states that per-interface label space= MAY be used in MPLS-TP
    • AFAIK, in MPLS:
      • This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of lab= el contexts has been reasonably low
      • This has been only allowed on P2P links
    • One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lowe= r layer LSPs (see also my notes regarding Sections). As a consequence, = it is not clear (to me) whether per-interface label space may become a l= abel space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
    • Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
  1. Sections:
    • The draft states that Sections could be data li= nks (level 0 sections) or LSPs with N labels (level N Sections).
    • The following is not clear to me:
      • Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
      • Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associ= ated bi-directional LSP be a section? etc.).
      • If associated bi-directional LSPs can be Secti= ons, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
      • Per-data link (interface) label space is suppo= rted in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
    • Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. = IMHO and FWIW preferred resolution would be to equate Sections w= ith data links
  1. Label Allocation Schemes:
    • MPLS recognizes two label allocation schemes, e= ach with its own area of applicability:
      • Downstream label allocation as per RFC 3031
      • Upstream label allocation as per RFC 5331
    • IMHO the label allocation scheme is essentially= a data plane issue:
      • Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
      • Packets with invalid labels must be silently discarded etc.
    • It is not clear to me, which label allocation schemes can be used in MPLS-TP.
      • This includes applicability of these schemes, e.g., can we use upstream label allocation
      • This issue is closely related to proposed usag= e of a well-known multicast MAC destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requires clarification
  1. MAC addresses on Ethernet data links in MPLS-TP<= /span>:
    • The draft discusses this topic, and proposes us= ing a well-known multicast DA in Ethernet encapsulations for for P2P LSPs=
    • IMHO and FWIW if LAN interfaces are allowe= d in MPLS-TP, usage of  well-known multicast DA is not compatible wit= h the downstream label allocation scheme.
    • Status of this topic in the -00-draft: partiall= y recognized by the Editors, there seems to be a bug in the proposed solution.

Hopefully, these notes will be useful.

 

Regards,

     Sasha

    •  
--_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA4FRMRSSXCHMBSC3d_-- From lieven.levrau@alcatel-lucent.com Tue Feb 2 23:05: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 55A1C28C0F0; Tue, 2 Feb 2010 23:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ryFkrZrnXAY2; Tue, 2 Feb 2010 23:05:49 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9066E3A6838; Tue, 2 Feb 2010 23:05:48 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1376NvU028363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 08:06:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 3 Feb 2010 08:06:23 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: Alexander Vainshtein , "stbryant@cisco.com" , "'Dan Frost'" , "Bocci, Matthew (Matthew)" Date: Wed, 3 Feb 2010 08:06:15 +0100 Thread-Topic: Per-interface label space in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA89nXA Message-ID: References: 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_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA5FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [mpls] Per-interface label space in data-plane-draft' 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, 03 Feb 2010 07:05:57 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA5FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Per-inter= face label space in data-plane-draft' I agree with the fact that the interface limitation is a bit flue in terms = of the client server model. So the question would be what is an "interface" - what relevance does it ha= ve for MPLS-TP when a server layer interface is bundled or is another LSP? = I appreciate the impact on the LAG hashing algorithms potentially includin= g more than just the MAC address fields. I agree with your suggestion. ./ Lieven Per-Interface Label Space: o The draft states that per-interface label space MAY be used in MPLS-TP o AFAIK, in MPLS: =A7 This referred to data links (including bundles, e.g., produced by LAG)= . As a consequence, the number of label contexts has been reasonably low =A7 This has been only allowed on P2P links o One of the problems with MPLS-TP is that in many cases it does not dif= ferentiate between data links and lower layer LSPs (see also my notes regar= ding Sections). As a consequence, it is not clear (to me) whether per-inter= face label space may become a label space per lower layer LSP. (To the best= of my understanding this is explicitly prohibited by RFC 3031). o Status of this topic in the -00 draft: requires clarification, prefera= bly aligned with RFC 3031. From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 1. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 1. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 1. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA5FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-= 00 -> Per-interface label space in data-plane-draft’

I agree with the fact that the interface limitation is a bit flue in terms of the c= lient server model.

So the question would be what is an “interface” – what relevance does it have for MPLS-TP when a server layer interface is bundled or is ano= ther LSP? =A0I appreciate the impact on the LAG hashing algorithms potentially i= ncluding more than just the MAC address fields.

I agree with your suggestion.

./

Lieven

Per-Interface L= abel Space:

o    The draft state= s that per-interface label space MAY be used in MPLS-TP

o    AFAIK, in MPLS:=

=A7  This referred to data links (including bundles, e.g., produced by LAG). As a consequ= ence, the number of label contexts has been reasonably low

=A7  This has been o= nly allowed on P2P links

o    One of the prob= lems with MPLS-TP is that in many cases it does not differentiate between d= ata links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding = this is explicitly prohibited by RFC 3031).

o    Status of this = topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.=

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Al= exander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

 

Stewart, Dan, Matthew and all,

First of all I'd like to say that the need for clear-cut definition of the MPLS-T= P data plane architecture has been quite clear to me.

The draft is clearly the necessary first step in the right direction, and I tha= nk you for producing it.

 

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

 

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 

  1. LSP Merge:
    • In MPLS, nothing prevents LSPs from merging at = some point:
      • One well-known usage of LSP merge is FRR
      • PHP can be considered as a special case of LSP merge
    • One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. 
    • It is not clear (at least, to me):<= /o:p>
      • Whether this limitation has to be respected at= the data plane level, and if yes, then how
      • Whether it means that FRR cannot be used in MPLS-TP
    • Status of this topic in the -00 draft: not mentioned at all
  1. Per-Interface Label Space:
    • The draft states that per-interface label space= MAY be used in MPLS-TP
    • AFAIK, in MPLS:
      • This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of lab= el contexts has been reasonably low
      • This has been only allowed on P2P links
    • One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lowe= r layer LSPs (see also my notes regarding Sections). As a consequence, = it is not clear (to me) whether per-interface label space may become a l= abel space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
    • Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
  1. Sections:
    • The draft states that Sections could be data li= nks (level 0 sections) or LSPs with N labels (level N Sections).
    • The following is not clear to me:
      • Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
      • Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associ= ated bi-directional LSP be a section? etc.).
      • If associated bi-directional LSPs can be Secti= ons, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
      • Per-data link (interface) label space is suppo= rted in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
    • Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. = IMHO and FWIW preferred resolution would be to equate Sections w= ith data links
  1. Label Allocation Schemes:
    • MPLS recognizes two label allocation schemes, e= ach with its own area of applicability:
      • Downstream label allocation as per RFC 3031
      • Upstream label allocation as per RFC 5331
    • IMHO the label allocation scheme is essentially= a data plane issue:
      • Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
      • Packets with invalid labels must be silently discarded etc.
    • It is not clear to me, which label allocation schemes can be used in MPLS-TP.
      • This includes applicability of these schemes, e.g., can we use upstream label allocation
      • This issue is closely related to proposed usag= e of a well-known multicast MAC destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requires clarification
  1. MAC addresses on Ethernet data links in MPLS-TP<= /span>:
    • The draft discusses this topic, and proposes us= ing a well-known multicast DA in Ethernet encapsulations for for P2P LSPs=
    • IMHO and FWIW if LAN interfaces are allowe= d in MPLS-TP, usage of  well-known multicast DA is not compatible wit= h the downstream label allocation scheme.
    • Status of this topic in the -00-draft: partiall= y recognized by the Editors, there seems to be a bug in the proposed solution.

Hopefully, these notes will be useful.

 

Regards,

     Sasha

    •  
--_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA5FRMRSSXCHMBSC3d_-- From lieven.levrau@alcatel-lucent.com Tue Feb 2 23:06: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 8620228C0F5; Tue, 2 Feb 2010 23:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 VYGyLriCYwc9; Tue, 2 Feb 2010 23:06:06 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 40F6528C111; Tue, 2 Feb 2010 23:06:05 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1376epi028462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 08:06:40 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 3 Feb 2010 08:06:40 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: Alexander Vainshtein , "stbryant@cisco.com" , "'Dan Frost'" , "Bocci, Matthew (Matthew)" Date: Wed, 3 Feb 2010 08:06:34 +0100 Thread-Topic: LSP merging in data-plane-draft Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA8voEw Message-ID: References: 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_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA6FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [mpls] LSP merging in data-plane-draft 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, 03 Feb 2010 07:06:12 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA6FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> LSP mergi= ng in data-plane-draft' On the topic of LSP merging... I think we need to define merging or elabora= te on what merging is. Afai understand the LSP are not merged continuously. But only when/if a fai= lure has occurred. So, for the concern when the FRR is operationally up and used, the other (p= rimary) LSP is down, so in that case, I'm not sure we can still call it mer= ging. PHP is by default not allowed in the MPLS-TP and I think that is clear in t= he frame work document. Suggestion - worth to mention but a non- issue. ./ Lieven 1. LSP Merge: o In MPLS, nothing prevents LSPs from merging at some point: =A7 One well-known usage of LSP merge is FRR =A7 PHP can be considered as a special case of LSP merge o One of the often repeated mantras of MPLS-TP is that its LSPs cannot b= e merge. o It is not clear (at least, to me): =A7 Whether this limitation has to be respected at the data plane level, a= nd if yes, then how =A7 Whether it means that FRR cannot be used in MPLS-TP o Status of this topic in the -00 draft: not mentioned at all From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 2. LSP Merge: o In MPLS, nothing prevents LSPs from merging at some point: =A7 One well-known usage of LSP merge is FRR =A7 PHP can be considered as a special case of LSP merge o One of the often repeated mantras of MPLS-TP is that its LSPs cannot be = merge. o It is not clear (at least, to me): =A7 Whether this limitation has to be respected at the data plane level, a= nd if yes, then how =A7 Whether it means that FRR cannot be used in MPLS-TP o Status of this topic in the -00 draft: not mentioned at all 3. Per-Interface Label Space: o The draft states that per-interface label space MAY be used in MPLS-TP o AFAIK, in MPLS: =A7 This referred to data links (including bundles, e.g., produced by LAG)= . As a consequence, the number of label contexts has been reasonably low =A7 This has been only allowed on P2P links o One of the problems with MPLS-TP is that in many cases it does not diffe= rentiate between data links and lower layer LSPs (see also my notes regardi= ng Sections). As a consequence, it is not clear (to me) whether per-interfa= ce label space may become a label space per lower layer LSP. (To the best o= f my understanding this is explicitly prohibited by RFC 3031). o Status of this topic in the -00 draft: requires clarification, preferabl= y aligned with RFC 3031. 4. Sections: o The draft states that Sections could be data links (level 0 sections) or= LSPs with N labels (level N Sections). o The following is not clear to me: =A7 Can LAN-like data links be Sections in MPLS-TP (The Editors ask this q= uestion themselves when they discuss MAC addresses) =A7 Which types of LSPs can be Sections (e.g., can a P2P unidirectional LS= P be a Section? Can an associated bi-directional LSP be a section? etc.). =A7 If associated bi-directional LSPs can be Sections, can we treat the LS= Ps rumming over these Sections as co-routed bidirectional? =A7 Per-data link (interface) label space is supported in MPLS. Does MPLS-= Tp allow per-Section label space (see above)? o Status of this topic in the -00 draft: requires clarification, one aspec= t already recognized as such by the Editors. IMHO and FWIW preferred resolu= tion would be to equate Sections with data links 5. Label Allocation Schemes: o MPLS recognizes two label allocation schemes, each with its own area of = applicability: =A7 Downstream label allocation as per RFC 3031 =A7 Upstream label allocation as per RFC 5331 o IMHO the label allocation scheme is essentially a data plane issue: =A7 Label allocation scheme is reflected in the Ethertype in the case of E= thernet encapsulation etc. =A7 Packets with invalid labels must be silently discarded etc. o It is not clear to me, which label allocation schemes can be used in MPL= S-TP. =A7 This includes applicability of these schemes, e.g., can we use upstrea= m label allocation =A7 This issue is closely related to proposed usage of a well-known multic= ast MAC destination address for P2P LSPs) o Status of this topic in the -00 draft: requires clarification 6. MAC addresses on Ethernet data links in MPLS-TP: o The draft discusses this topic, and proposes using a well-known multicas= t DA in Ethernet encapsulations for for P2P LSPs o IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-k= nown multicast DA is not compatible with the downstream label allocation sc= heme. o Status of this topic in the -00-draft: partially recognized by the Edito= rs, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA6FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-= 00 -> LSP merging in data-plane-draft’

 

On the topic of LSP merging… I think we need to define merging or elaborate on what merging is.

Afai understand the LSP are not merged continuously. But onl= y when/if a failure has occurred.

So, for the concern when the FRR is operationally up and use= d, the other (primary) LSP is down, so in that case, I’m not sure we can still call it merging.

 

PHP is by default not allowed in the MPLS-TP and I think tha= t is clear in the frame work document.

Suggestion – worth to mention but a non- issue.

 

./

Lieven

1.&n= bsp;     LSP Merge:

o    In MPLS, nothin= g prevents LSPs from merging at some point:

=A7  One well-known = usage of LSP merge is FRR

=A7  PHP can be cons= idered as a special case of LSP merge

o    One of the ofte= n repeated mantras of MPLS-TP is that its LSPs cannot be merge. <= o:p>

o    It is not clear= (at least, to me):

=A7  Whether this limitation has to be respected at the data plane level, and if yes, then ho= w

=A7  Whether it mean= s that FRR cannot be used in MPLS-TP

o    Status of this = topic in the -00 draft: not mentioned at all

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Al= exander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

 

Stewart, Dan, Matthew and all,

First of all I'd like to say that the need for clear-cut definition of the MPLS-T= P data plane architecture has been quite clear to me.

The draft is clearly the necessary first step in the right direction, and I tha= nk you for producing it.

 

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

 

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 

2.&n= bsp;  LSP Merge:

o  In MPLS, nothin= g prevents LSPs from merging at some point:

=A7  One well-known = usage of LSP merge is FRR

=A7  PHP can be cons= idered as a special case of LSP merge

o  One of the ofte= n repeated mantras of MPLS-TP is that its LSPs cannot be merge. <= o:p>

o  It is not clear= (at least, to me):

=A7  Whether this limitation has to be respected at the data plane level, and if yes, then ho= w

=A7  Whether it mean= s that FRR cannot be used in MPLS-TP

o  Status of this = topic in the -00 draft: not mentioned at all

3.&n= bsp;  Per-Interface Label Space:

o  The draft state= s that per-interface label space MAY be used in MPLS-TP

o  AFAIK, in MPLS:=

=A7  This referred to data links (including bundles, e.g., produced by LAG). As a consequ= ence, the number of label contexts has been reasonably low

=A7  This has been o= nly allowed on P2P links

o  One of the prob= lems with MPLS-TP is that in many cases it does not differentiate between d= ata links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding = this is explicitly prohibited by RFC 3031).

o  Status of this = topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.=

4.&n= bsp;  Sections:

o  The draft state= s that Sections could be data links (level 0 sections) or LSPs with N labels (leve= l N Sections).

o  The following is not clear to me:

=A7  Can LAN-like da= ta links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)

=A7  Which types of = LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can = an associated bi-directional LSP be a section? etc.).

=A7  If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over the= se Sections as co-routed bidirectional?

=A7  Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Sectio= n label space (see above)?

o  Status of this = topic in the -00 draft: requires clarification, one aspect already recognized as = such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links

5.&n= bsp;  Label Allocation Schemes:

o  MPLS recognizes= two label allocation schemes, each with its own area of applicability:

=A7  Downstream labe= l allocation as per RFC 3031

=A7  Upstream label allocation as per RFC 5331

o  IMHO the label allocation scheme is essentially a data plane issue:

=A7  Label allocatio= n scheme is reflected in the Ethertype in the case of Ethernet encapsulation = etc.

=A7  Packets with in= valid labels must be silently discarded etc.

o  It is not clear= to me, which label allocation schemes can be used in MPLS-TP.

=A7  This includes applicability of these schemes, e.g., can we use upstream label allocation =

=A7  This issue is c= losely related to proposed usage of a well-known multicast MAC destinati= on address for P2P LSPs)

o  Status of this = topic in the -00 draft: requires clarification

6.&n= bsp;  MAC addresses on Ethernet data links in MPLS-TP:

o  The draft discu= sses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs

o  IMHO and FWIW&n= bsp;if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast = DA is not compatible with the downstream label allocation scheme.<= /o:p>

o  Status of this = topic in the -00-draft: partially recognized by the Editors, there seems to be a = bug in the proposed solution.

Hopefully, these notes will be useful.

 

Regards,

     Sasha

    •  
--_000_E6E66922099CFB4391FAA7A7D3238F9F0B8C3EA6FRMRSSXCHMBSC3d_-- From root@core3.amsl.com Thu Feb 4 03: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 D516928C122; Thu, 4 Feb 2010 03: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: <20100204114501.D516928C122@core3.amsl.com> Date: Thu, 4 Feb 2010 03:45:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-linear-protection-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: Thu, 04 Feb 2010 11: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 : MPLS-TP Linear Protection Author(s) : S. Bryant, et al. Filename : draft-ietf-mpls-tp-linear-protection-00.txt Pages : 20 Date : 2010-02-04 The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF and ITU-T includes requirements documents and framework documents. The framework documents define the basic architecture that is needed in order to support various aspects of the required behavior. This document addresses the functionality described in the MPLS-TP Survivability Framework document and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that 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-linear-protection-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-linear-protection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-04033447.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Feb 4 04: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 6D1D73A6D93; Thu, 4 Feb 2010 04: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: <20100204121502.6D1D73A6D93@core3.amsl.com> Date: Thu, 4 Feb 2010 04:15:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-10.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, 04 Feb 2010 12: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 : A Framework for MPLS in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-10.txt Pages : 49 Date : 2010-02-04 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 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-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-04041501.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Thu Feb 4 05:11: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 2D44028C178; Thu, 4 Feb 2010 05:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, 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 05DpOSqtVdcK; Thu, 4 Feb 2010 05:11:24 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 4648A28C199; Thu, 4 Feb 2010 05:11:19 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-7c-4b6ac653961c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 13.28.18464.356CA6B4; Thu, 4 Feb 2010 15:06:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 4 Feb 2010 15:12:02 +0200 From: Alexander Vainshtein To: "LEVRAU, LIEVEN (LIEVEN)" Date: Thu, 4 Feb 2010 15:12:01 +0200 Thread-Topic: Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOA= Message-ID: References: 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_A3C5DF08D38B6049839A6F553B331C76BFDF65C64DILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "stbryant@cisco.com" , 'Dan Frost' , "mpls-tp@ietf.org" Subject: Re: [mpls] Label alloc. Schemes in data-plane-draft' 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, 04 Feb 2010 13:11:46 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDF65C64DILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lieven, Lots of thanks for a prompt response. IMHO and FWIW the label allocation scheme is not just a control plane issue= . Please note that, as per RFC 5332, MPLS packets with upstream-allocated lab= els use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. What is more, upstream-allocated labels must refer to a certain context by = the downstream router. And context resolution is part of the data plane as = well. Regards, Sasha ________________________________ From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] Sent: Wednesday, February 03, 2010 9:06 AM To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (= Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Label alloc. Schemes in data-plane-draft' Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label all= oc. Schemes in data-plane-draft' In my view - This is a control plane issue and not a data plane issue. How = the labels are assigned is outside the scope of the draft. ./ Lieven 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 1. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 1. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 1. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_A3C5DF08D38B6049839A6F553B331C76BFDF65C64DILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lieven,
Lots=20 of thanks for a prompt response.
 
IMHO=20 and FWIW the label allocation scheme is not just a control plane=20 issue.
Please=20 note that, as per RFC 5332, MPLS packets with upstream-allocated labels use= a=20 different code point on Ethernet links and GRE tunnels.
To me=20 this is a data plane issue.
 
What=20 is more, upstream-allocated labels must refer to a certain context by the=20 downstream router. And context resolution is part of= the data=20 plane as well.
 
Regards,
     Sasha
 
 
 
 

 
 

From: LEVRAU, LIEVEN (LIEVEN)=20 [mailto:lieven.levrau@alcatel-lucent.com]
Sent: Wednesday, Feb= ruary=20 03, 2010 9:06 AM
To: Alexander Vainshtein; stbryant@cisco.com; = 'Dan=20 Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: Label alloc. Schemes in=20 data-plane-draft'

 

 

Hello=20 Shasha

Changed=20 title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc.= =20 Schemes in data-plane-draft’

 

In=20 my view - This is a control plane issue and not a data plane issue. How t= he=20 labels are assigned is outside the scope of the draft.<= /P>

 

./

Lieven

  1. Label Allo= cation=20 Schemes:=20
    • MPLS rec= ognizes=20 two label allocation schemes, each with its own area of=20 applicability:=20
      • Downst= ream=20 label allocation as per RFC 3031=20
      • Upstre= am=20 label allocation as per RFC 5331
    • IMHO the= label=20 allocation scheme is essentially a data plane issue:=20
      • Label= =20 allocation scheme is reflected in the Ethertype in the case of Ethe= rnet=20 encapsulation etc.=20
      • Packet= s with=20 invalid labels must be silently discarded etc.=20
    • It is no= t clear=20 to me, which label allocation schemes can be used in MPLS-TP.=20
      • This i= ncludes=20 applicability of these schemes, e.g., can we use upstream label=20 allocation
      • This i= ssue is=20 closely related to proposed usage of a well-known multica= st=20 MAC destination address for P2P LSPs)
    • Status o= f this=20 topic in the -00 draft: requires clarification=20

 

 

From:=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: 01 February 2010 18:00
To:= =20 stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc:=20 mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls] Comments on=20 draft-fbb-mpls-tp-data-plane-00

 

Stewart, Dan= ,=20 Matthew and all,

First of all= I'd=20 like to say that the need for clear-cut definition of the MPLS-TP data pl= ane=20 architecture has been quite clear to me.

The draft is= =20 clearly the necessary first step in the right direction, and I thank you = for=20 producing it.

 

That said, I= think=20 that quite a few issues have been left undecided in this -00 version of t= he=20 draft.

 

I will make = a=20 (hopefully, short) list of items that IMHO require additional clarificati= on=20 and, eventually, codification.

 

  1. LSP=20 Merge:=20
    • In MPLS,= =20 nothing prevents LSPs from merging at some point:=20
      • One=20 well-known usage of LSP merge is FRR=20
      • PHP ca= n be=20 considered as a special case of LSP merge=20
    • One of t= he=20 often repeated mantras of MPLS-TP is that its LSPs cannot be=20 merge. =20
    • It is no= t clear=20 (at least, to me):
      • Whethe= r this=20 limitation has to be respected at the data plane level, and if yes,= then=20 how=20
      • Whethe= r it=20 means that FRR cannot be used in MPLS-TP=20
    • Status o= f this=20 topic in the -00 draft: not mentioned at all
      • <= /UL>
  1. Per-Interf= ace=20 Label Space:=20
    • The draf= t=20 states that per-interface label space MAY be used in=20 MPLS-TP=20
    • AFAIK, i= n=20 MPLS:
      • This r= eferred=20 to data links (including bundles, e.g., produced by LAG). As a= =20 consequence, the number of label contexts has been reasonably=20 low=20
      • This h= as been=20 only allowed on P2P links
    • One of t= he=20 problems with MPLS-TP is that in many cases it does not differen= tiate=20 between data links and lower layer LSPs (see also my notes regarding= =20 Sections). As a consequence, it is not clear (to me) whether per-inte= rface=20 label space may become a label space per lower layer LSP. (To the bes= t of=20 my understanding this is explicitly prohibited by RFC=20 3031).=20
    • Status o= f this=20 topic in the -00 draft: requires clarification, preferably aligned wi= th=20 RFC 3031.
  1. Sections:=20
    • The draf= t=20 states that Sections could be data links (level 0 sections) or LSPs w= ith N=20 labels (level N Sections).=20
    • The foll= owing=20 is not clear to me:
      • Can LA= N-like=20 data links be Sections in MPLS-TP (The Editors ask this question=20 themselves when they discuss MAC addresses)=20
      • Which = types=20 of LSPs can be Sections (e.g., can a P2P unidirectional LSP be= a=20 Section? Can an associated bi-directional LSP be a section? etc.).= =20
      • If ass= ociated=20 bi-directional LSPs can be Sections, can we treat the LSPs rumming = over=20 these Sections as co-routed bidirectional?=20
      • Per-da= ta link=20 (interface) label space is supported in MPLS. Does MPLS-Tp allow=20 per-Section label space (see above)?
    • Status o= f this=20 topic in the -00 draft: requires clarification, one aspect already=20 recognized as such by the Editors. IMHO and FWIW preferred resolution= =20 would be to equate Sections with data links=20
  1. Label Allo= cation=20 Schemes:=20
    • MPLS rec= ognizes=20 two label allocation schemes, each with its own area of=20 applicability:
      • Downst= ream=20 label allocation as per RFC 3031=20
      • Upstre= am=20 label allocation as per RFC 5331
    <= /OL>
      • IMHO the= label=20 allocation scheme is essentially a data plane issue:=20
        • Label= =20 allocation scheme is reflected in the Ethertype in the case of Ethe= rnet=20 encapsulation etc.=20
        • Packet= s with=20 invalid labels must be silently discarded etc.=20
      • It is no= t clear=20 to me, which label allocation schemes can be used in MPLS-TP.=20
        • This i= ncludes=20 applicability of these schemes, e.g., can we use upstream label=20 allocation
        • This i= ssue is=20 closely related to proposed usage of a well-known multica= st=20 MAC destination address for P2P LSPs)
        <= /UL>
      • Status o= f this=20 topic in the -00 draft: requires clarification=20
    1. MAC addres= ses on=20 Ethernet data links in MPLS-TP:=20
      • The draf= t=20 discusses this topic, and proposes using a well-known multicast DA in= =20 Ethernet encapsulations for for P2P LSPs=20
      • IMHO and= =20 FWIW if LAN interfaces are allowed in MPLS-TP, usage of =20 well-known multicast DA is not compatible with the downstream label=20 allocation scheme.=20
      • Status o= f this=20 topic in the -00-draft: partially recognized by the Editors, there se= ems=20 to be a bug in the proposed solution.

      Hopefully, t= hese=20 notes will be useful.

       

      Regards,

        =   =20 Sasha

        •  =20
--_000_A3C5DF08D38B6049839A6F553B331C76BFDF65C64DILPTMAIL02eci_-- From loa@pi.nu Thu Feb 4 07:03: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 042753A6D54; Thu, 4 Feb 2010 07:03:27 -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 o7G0B93Ol7eS; Thu, 4 Feb 2010 07:03:24 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id ABCA23A68A7; Thu, 4 Feb 2010 07:03:24 -0800 (PST) Received: from [192.36.158.44] (f-158-44.verkstad.net [192.36.158.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id E355FD4052; Thu, 4 Feb 2010 16:04:08 +0100 (CET) Message-ID: <4B6AE1E8.1080404@pi.nu> Date: Thu, 04 Feb 2010 16:04:08 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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] Working Group last call on draft-ietf-mpls-tp-framework-10 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, 04 Feb 2010 15:03:27 -0000 Working Group, this is to start a two week MPLS working group last call on draft-ietf-mpls-tp-framework-10 This working group last call ends eob January 19th. Please send comments to the mpls-tp@ietf.org mailing list. We would like request that special attention is focused on section 3.5 - 3.15 since it is our impression that these sections has been less well reviewed than the rest of the document, this is not to say that the earlier sections does not need review. Loa and George MPLS WG co-chairs -- 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 neil.2.harrison@bt.com Thu Feb 4 08:57: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 376043A6915; Thu, 4 Feb 2010 08:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, 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 tyJKWZZ81VuX; Thu, 4 Feb 2010 08:57:39 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 3C74B3A680C; Thu, 4 Feb 2010 08:57:39 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 16:58:24 +0000 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: Thu, 4 Feb 2010 16:58:21 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05951F05@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAACAIS8A== From: To: , X-OriginalArrivalTime: 04 Feb 2010 16:58:24.0589 (UTC) FILETIME=[43A5D7D0:01CAA5BB] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 04 Feb 2010 16:57:40 -0000 One remark.... =20 Sasha wrote 04 February 2010 13:12 =09 =09 Lieven, Lots of thanks for a prompt response. =20 IMHO and FWIW the label allocation scheme is not just a control plane issue. Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. =20 What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well. NH=3D> Indeed it is. I'd refer to this as the requirement for the DP traffic units to have consistent characteristic information (CI) ...which is more than the label of course, but the label is the most functionally overworked field in an MPLS traffic unit. One can at least mitigate the effects of poor DP CI design by adding a consistent OAM CV flow to every LSP. Aside=3D> In a transport network context I think the MPLS-TP label only needs to have 2 types of semantic: - forwarding semantic if value >15...swapped per hop (label-swapping is not ideal, the best forwarding labels are like the ones used in a cl-ps network like IP or Ethernet, ie network unique and not swapped per hop...this mitigates misconnectivity even without any adjunct CV OAM flow) - globally well-known functional action semantic if value 0-15...never swapped regards, Neil =20 Regards, Sasha =20 From loa@pi.nu Thu Feb 4 09:08: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 EA5863A6836; Thu, 4 Feb 2010 09:08:20 -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 aCGX+MDLXSSp; Thu, 4 Feb 2010 09:08:20 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 16E9D3A6C52; Thu, 4 Feb 2010 09:08:19 -0800 (PST) Received: from [192.36.158.44] (f-158-44.verkstad.net [192.36.158.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 08463D4052; Thu, 4 Feb 2010 18:09:04 +0100 (CET) Message-ID: <4B6AFF25.5020300@pi.nu> Date: Thu, 04 Feb 2010 18:08:53 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org References: <4B6AE1E8.1080404@pi.nu> In-Reply-To: <4B6AE1E8.1080404@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] [mpls-tp] Working Group last call on draft-ietf-mpls-tp-framework-10 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, 04 Feb 2010 17:08:21 -0000 All, as has been pointed out be several observant working group members, I meant February 19th as the day when the wg last call ends. /Loa Loa Andersson wrote: > Working Group, > > this is to start a two week MPLS working group last call on > > draft-ietf-mpls-tp-framework-10 > > This working group last call ends eob January 19th. > > Please send comments to the mpls-tp@ietf.org mailing list. > > We would like request that special attention is focused on > section 3.5 - 3.15 since it is our impression that these > sections has been less well reviewed than the rest of the > document, this is not to say that the earlier sections does > not need review. > > Loa and George > > MPLS WG co-chairs > > > -- 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 wwwrun@core3.amsl.com Thu Feb 4 09:41: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 EE1833A69F9; Thu, 4 Feb 2010 09:41:56 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100204174156.EE1833A69F9@core3.amsl.com> Date: Thu, 4 Feb 2010 09:41:56 -0800 (PST) Cc: loa.andersson@ericsson.com, MPLS WG , Greg Jones , MPLS-TP List , Stewart Bryant , Malcolm Betts , Yoichi Maeda , Dave Ward , ITU-T ad hoc team on MPLS-TP , Patrik Fältström , Adrian Farrel , Ross Callon , tsbsg15@itu.int, Huub Van Helvoort , Hing-Kam Lam , Ghani Abbas Subject: [mpls] New Liaison Statement, "Working Group Lat Call on the MPLS-TP Framework (ref #015.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 17:41:57 -0000 Title: Working Group Lat Call on the MPLS-TP Framework (ref #015.01) Submission Date: 2010-02-04 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=636 Please reply by 2010-03-05 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15(greg.jones@itu.int) Cc: Yoichi Maeda Greg Jones Ghani Abbas Huub Van Helvoort Malcolm Betts Hing-Kam Lam ITU-T ad hoc team on MPLS-TP Dave Ward Adrian Farrel Ross Callon Patrik F�ltstr�m Stewart Bryant MPLS WG MPLS-TP List Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: Working Group Last Call on the MPLS-TP Framework (ref #015.01). SG15, Q9, Q11, Q12 and Q14 We like to to inform you that we have just started a working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-10). We would like to receive comments from the ITU-T by March 5th 2010. Loa Andersson George Swallow MPLS Working Group co-chairs Attachment(s): No document has been attached From maarten.vissers@huawei.com Fri Feb 5 02:59: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 20EA93A6AAF; Fri, 5 Feb 2010 02:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[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 tlEzKf+J9Vaa; Fri, 5 Feb 2010 02:59:13 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CFB203A6B51; Fri, 5 Feb 2010 02:59:12 -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 <0KXD005ZH7VQUM@szxga02-in.huawei.com>; Fri, 05 Feb 2010 18:59:50 +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 <0KXD00D2P7VPH3@szxga02-in.huawei.com>; Fri, 05 Feb 2010 18:59:49 +0800 (CST) Received: from M00900002 ([10.202.112.149]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXD004X07VL04@szxml04-in.huawei.com>; Fri, 05 Feb 2010 18:59:49 +0800 (CST) Date: Fri, 05 Feb 2010 11:59:46 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' , "'LEVRAU, LIEVEN (LIEVEN)'" Message-id: <004b01caa652$562d2a10$9570ca0a@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_69IgPalU5XRDdr3zqVizwQ)" Thread-index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0A== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 05 Feb 2010 10:59:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_69IgPalU5XRDdr3zqVizwQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sasha, There can/will be many labels in the label stack on MPSL-TP interfaces. Is the Ethernet code point application only to the top of stack label, or to all labels in the stack? I would expect that the code point only applies to the top of stack label and not to the non-top of stack labels; is this correct? Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 4 februari 2010 14:12 To: LEVRAU, LIEVEN (LIEVEN) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' Lieven, Lots of thanks for a prompt response. IMHO and FWIW the label allocation scheme is not just a control plane issue. Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well. Regards, Sasha _____ From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] Sent: Wednesday, February 03, 2010 9:06 AM To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Label alloc. Schemes in data-plane-draft' Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft' In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft. ./ Lieven 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own area of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used in MPLS-TP. * This includes applicability of these schemes, e.g., can we use upstream label allocation * This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I thank you for producing it. That said, I think that quite a few issues have been left undecided in this -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane level, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 2. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS-TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031. 3. Sections: * The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.). * If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links 4. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own area of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used in MPLS-TP. * This includes applicability of these schemes, e.g., can we use upstream label allocation * This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 5. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-known multicast DA is not compatible with the downstream label allocation scheme. * Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --Boundary_(ID_69IgPalU5XRDdr3zqVizwQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Sasha,
 
There can/will be many labels in the label stack on MPSL-TP interfaces.
Is the Ethernet code point application only to the top of stack label, or to all labels in the stack?
 
I would expect that the code point only applies to the top of stack label and not to the non-top of stack labels; is this correct?
 
Regards,
Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: donderdag 4 februari 2010 14:12
To: LEVRAU, LIEVEN (LIEVEN)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Lieven,
Lots of thanks for a prompt response.
 
IMHO and FWIW the label allocation scheme is not just a control plane issue.
Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels.
To me this is a data plane issue.
 
What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well.
 
Regards,
     Sasha
 
 
 
 

 
 

From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com]
Sent: Wednesday, February 03, 2010 9:06 AM
To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Label alloc. Schemes in data-plane-draft'

 

 

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft’

 

In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft.

 

./

Lieven

  1. Label Allocation Schemes:
    • MPLS recognizes two label allocation schemes, each with its own area of applicability:
      • Downstream label allocation as per RFC 3031
      • Upstream label allocation as per RFC 5331
    • IMHO the label allocation scheme is essentially a data plane issue:
      • Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
      • Packets with invalid labels must be silently discarded etc.
    • It is not clear to me, which label allocation schemes can be used in MPLS-TP.
      • This includes applicability of these schemes, e.g., can we use upstream label allocation
      • This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requires clarification

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

 

Stewart, Dan, Matthew and all,

First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me.

The draft is clearly the necessary first step in the right direction, and I thank you for producing it.

 

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

 

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 

  1. LSP Merge:
    • In MPLS, nothing prevents LSPs from merging at some point:
      • One well-known usage of LSP merge is FRR
      • PHP can be considered as a special case of LSP merge
    • One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. 
    • It is not clear (at least, to me):
      • Whether this limitation has to be respected at the data plane level, and if yes, then how
      • Whether it means that FRR cannot be used in MPLS-TP
    • Status of this topic in the -00 draft: not mentioned at all
  1. Per-Interface Label Space:
    • The draft states that per-interface label space MAY be used in MPLS-TP
    • AFAIK, in MPLS:
      • This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low
      • This has been only allowed on P2P links
    • One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
    • Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
  1. Sections:
    • The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections).
    • The following is not clear to me:
      • Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
      • Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.).
      • If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
      • Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
    • Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links
  1. Label Allocation Schemes:
    • MPLS recognizes two label allocation schemes, each with its own area of applicability:
      • Downstream label allocation as per RFC 3031
      • Upstream label allocation as per RFC 5331
    • IMHO the label allocation scheme is essentially a data plane issue:
      • Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
      • Packets with invalid labels must be silently discarded etc.
    • It is not clear to me, which label allocation schemes can be used in MPLS-TP.
      • This includes applicability of these schemes, e.g., can we use upstream label allocation
      • This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requires clarification
  1. MAC addresses on Ethernet data links in MPLS-TP:
    • The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs
    • IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast DA is not compatible with the downstream label allocation scheme.
    • Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution.

Hopefully, these notes will be useful.

 

Regards,

     Sasha

    •  
--Boundary_(ID_69IgPalU5XRDdr3zqVizwQ)-- From wwwrun@core3.amsl.com Fri Feb 5 07:16: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 0DC063A6F0E; Fri, 5 Feb 2010 07:16:55 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100205151656.0DC063A6F0E@core3.amsl.com> Date: Fri, 5 Feb 2010 07:16:56 -0800 (PST) Cc: loa.andersson@ericsson.com, IETF MPLS WG , ITU-T ad hoc team on MPLS-TP , Malcolm Betts , MPLS-TP mailing list , Adrian Farrel , Ross Callon , tsbsg15@itu.int, Huub Van Helvoort , Hing-Kam Lam , Ghani Abbas Subject: [mpls] New Liaison Statement, "Response to early comments on draft-ietf-mpls-tp-framework (ref #009.04)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 15:16:56 -0000 Title: Response to early comments on draft-ietf-mpls-tp-framework (ref #009.04) Submission Date: 2010-02-05 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=637 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q11, Q12 and Q14(greg.jones@itu.int) Cc: Ghani Abbas Huub Van Helvoort Malcolm Betts Hing-Kam Lam ITU-T ad hoc team on MPLS-TP Adrian Farrel Ross Callon IETF MPLS WG MPLS-TP mailing list Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: Thanks for your liaison "LS111 - Comments on draft-ietf-mpls-tp-framework-06 (ref # 009.02)" from November 10th, 2009. The comments have been of great value in the work preparing version -10 of this document. We have now issued a working group last call on that version of the document. We have discussed the comments in your liaison during the weekly phone conferences and included the agreements in version -10, hence it is not our intention to respond to these comments in detail, but to do comment resolution on the comments received during the working group last call. Loa Andersson George Swallow MPLS Working Group Co-Chairs Attachment(s): No document has been attached From Alexander.Vainshtein@ecitele.com Fri Feb 5 10:27: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 BEACF3A6C8A; Fri, 5 Feb 2010 10:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, 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 kJgPqJYI+EpF; Fri, 5 Feb 2010 10:27:37 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 5BE8C3A6C14; Fri, 5 Feb 2010 10:27:35 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-ad-4b6c61f46b3d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 9C.BC.18464.4F16C6B4; Fri, 5 Feb 2010 20:22:44 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 5 Feb 2010 20:28:26 +0200 From: Alexander Vainshtein To: Maarten Vissers , "'LEVRAU, LIEVEN (LIEVEN)'" Date: Fri, 5 Feb 2010 20:28:25 +0200 Thread-Topic: [mpls-tp] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeN Message-ID: References: , <004b01caa652$562d2a10$9570ca0a@china.huawei.com> In-Reply-To: <004b01caa652$562d2a10$9570ca0a@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_A3C5DF08D38B6049839A6F553B331C76BFDF75E7BCILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 05 Feb 2010 18:27:39 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76BFDF75E7BCILPTMAIL02eci_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Maarten, Lots of thanks for an EXCELLENT question. I do not think I can answer it in full, but the following considerations ma= y be useful. 1. Downstream label allocation scheme is explicitly defined as the defaul= t in RFC 5331 and 5332. Hence, IMHO, if the code point of the data link de= fines the top label as downstream-assigned, the router terminating this lab= el will treat the next one(s) as downstream-assigned - unless it has been e= xplicitly aware that they are upstream-assigned. In other words, the LSR te= rminating the top label must explicitly bind it to a context space for upst= ream-allocated ones. 2. The primary usage of upstream-allocated labels in MPLS (but not necess= ary in MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in= conjunction with multicast datalink addresses (or their analogs as in the = case of MPLS-in-GRE). This means that, generally speaking, more than one ro= uter can terminate the top upstream-allocated label and look at the next on= e. And this is only compatible with the upstream allocation scheme for the = next label. Does this help? Did I miss something important? Regards, Sasha ________________________________ From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Friday, February 05, 2010 12:59 PM To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Sasha, There can/will be many labels in the label stack on MPSL-TP interfaces. Is the Ethernet code point application only to the top of stack label, or t= o all labels in the stack? I would expect that the code point only applies to the top of stack label a= nd not to the non-top of stack labels; is this correct? Regards, Maarten ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: donderdag 4 februari 2010 14:12 To: LEVRAU, LIEVEN (LIEVEN) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' Lieven, Lots of thanks for a prompt response. IMHO and FWIW the label allocation scheme is not just a control plane issue= . Please note that, as per RFC 5332, MPLS packets with upstream-allocated lab= els use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. What is more, upstream-allocated labels must refer to a certain context by = the downstream router. And context resolution is part of the data plane as = well. Regards, Sasha ________________________________ From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] Sent: Wednesday, February 03, 2010 9:06 AM To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (= Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Label alloc. Schemes in data-plane-draft' Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label all= oc. Schemes in data-plane-draft=92 In my view - This is a control plane issue and not a data plane issue. How = the labels are assigned is outside the scope of the draft. ./ Lieven 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 1. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 1. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 1. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 1. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_A3C5DF08D38B6049839A6F553B331C76BFDF75E7BCILPTMAIL02eci_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Maarten,
Lots of thanks for an EXCEL= LENT question.
 
I do not think I can a= nswer it in full, but the following considerations may be useful.
 
  1. Downstream label allocation scheme is ex= plicitly defined as the default  in RFC 5331 and 5332. Hence, IMHO, if the code point= of the data link defines the top label as downstream-assigned, the router = terminating this label will treat the next one(s) as downstream-assigned - = unless it has been explicitly aware that they are upstream-assigned. In other words, the LSR terminating the t= op label must explicitly bind it to a context space for upstream-allocated = ones.
  2. The primary usage of upstream-alloc= ated labels in MPLS (but not necessary in MPLS-TP) is MPLS multicast, and t= he dedicated codepoints are used in conjunction with multicast da= talink addresses (or their analogs as in the case of MPLS-in-GRE). This means that, generally speaking, more than one r= outer can terminate the top upstream-allocated label and look at the next o= ne. And this is only compatible with the upstream allocation scheme for the= next label.

 

Does this help? Did I miss something impo= rtant?

 

Regards,

     Sasha

From:= Maarten Vissers [maarten.vissers@huawei.com]
Sent: Friday, February 05, 2010 12:59 PM
To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Sasha,
 
There can/will be many labels in = the label stack on MPSL-TP interfaces.
Is the Ethernet code point applic= ation only to the top of stack label, or to all labels in the stack?
&= nbsp;
I would expect that the code poin= t only applies to the top of stack label and not to the non-top of stack la= bels; is this correct?
 
Regards,
Maarten

From: mpls-tp-bounces@ietf.org= [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: donderdag 4 februari 2010 14:12
To: LEVRAU, LIEVEN (LIEVEN)
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft'

= Lieven,
Lots of thanks for a prompt response.
 
IMHO and FWIW the label allocation scheme is not just a cont= rol plane issue.
Please note that, as per RFC 5332, MPLS packets with upstrea= m-allocated labels use a different code point on Ethernet links and GRE tun= nels.
To me this is a data plane issue.
 
What is more, upstream-allocated labels must refer to a cert= ain context by the downstream router. And context&n= bsp;resolution is part of the data plane as well.
 
Regards,
     Sasha
 
&n=
bsp;
&n=
bsp;
 <=
/pre>

 







 

 









From: LEVRAU, LIEVEN (LIEVEN) [mail=
to:lieven.levrau@alcatel-lucent.com]


Sent: Wednesday, February 03, 2010 9:06 AM

To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Ma=
tthew (Matthew)

Cc: mpls@ietf.org; mpls-tp@ietf.org

Subject: Label alloc. Schemes in data-plane-draft'










 


 


Hello
Shasha


Changed title from Comments on draft-fbb-m=
pls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft=92


 


In my view - This is a control plane issue=
 and not a data plane issue. How the labels are assigned is outside the sco=
pe of the draft.


 


./


Lieven


    

  1. Label Allocation Schemes:

      

    • MPLS recognizes two label allocation schemes, each with its=
 own area of applicability:

        

      • Downstream label allocation as per RFC 3031

      • Upstream label allocation as per RFC 5331

      

    • IMHO the label allocation scheme is essentially a data=
 plane issue:

        

      • Label allocation scheme is reflected in the Ethertype =
in the case of Ethernet encapsulation etc.

      • Packets with invalid labels must be silently discarded=
 etc.

      

    • It is not clear to me, which label allocation schemes =
can be used in MPLS-TP.


        

      • This includes applicability of these schemes, e.g., can we =
use upstream label allocation

      • This issue is closely related to proposed usage=
 of a well-known multicast MAC destination address for P2P LSPs)<=
/span>

      

    • Status of this topic in the -00 draft: requires clarif=
ication

    



 


 








From: mpls-bounces@ietf.org [mailto:mpls-bounce=
s@ietf.org]
On Behalf Of Alexander Vainshtein

Sent: 01 February 2010 18:00

To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)

Cc: mpls@ietf.org; mpls-tp@ietf.org

Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00





 




Stewart, Dan, Matthew and all,






First of all I'd like to say that the need for clear-cut def=
inition of the MPLS-TP data plane architecture has been quite clear to me.<=
/span>






The draft is clearly the necessary first step in the right d=
irection, and I thank you for producing it.






 






That said, I think that quite a few issues have been left un=
decided in this -00 version of the draft.






 






I will make a (hopefully, short) list of items that IMHO req=
uire additional clarification and, eventually, codification.






 




    

  1. LSP Merge:



    

      

    • In MPLS, nothing prevents LSPs from merging at some point:<=
/span>

    



    

      

        

      • One well-known usage of LSP merge is FRR

      • PHP can be considered as a special case of LSP merge

      

    



    

      

    • One of the often repeated mantras of MPLS-TP is that its LS=
Ps cannot be merge. 

    • It is not clear (at least, to me):

    



    

      

        

      • Whether this limitation has to be respected at the data pla=
ne level, and if yes, then how

      • Whether it means that FRR cannot be used in MPLS-TP

      

    



    

      

    • Status of this topic in the -00 draft: not mentioned at all=


    



    

  1. Per-Interface Label Space:



    

      

    • The draft states that per-interface label space MAY be used=
 in MPLS-TP

    • AFAIK, in MPLS:

    



    

      

        

      • This referred to data links (including bundles, e.g., =
produced by LAG). As a consequence, the number of label contexts has been r=
easonably low

      • This has been only allowed on P2P links

      

    



    

      

    • One of the problems with MPLS-TP is that in many cases=
 it does not differentiate between data links and lower layer LSPs (see als=
o my notes regarding Sections). As a consequence,
 it is not clear (to me) whether per-interface label space may become a lab=
el space per lower layer LSP. (To the best of my understanding this is expl=
icitly prohibited by RFC 3031).

    • Status of this topic in the -00 draft: requires clarif=
ication, preferably aligned with RFC 3031.

    



    

  1. Sections:



    

      

    • The draft states that Sections could be data links (level 0=
 sections) or LSPs with N labels (level N Sections).

    • The following is not clear to me:

    



    

      

        

      • Can LAN-like data links be Sections in MPLS-TP (The Editors=
 ask this question themselves when they discuss MAC addresses)

      • Which types of LSPs can be Sections (e.g., can a =
P2P unidirectional LSP be a Section? Can an associated bi-directional LSP b=
e a section? etc.).

      • If associated bi-directional LSPs can be Sectio=
ns, can we treat the LSPs rumming over these Sections as co-routed bid=
irectional?

      • Per-data link (interface) label space is supported in =
MPLS. Does MPLS-Tp allow per-Section label space (see above)?

      

    



    

      

    • Status of this topic in the -00 draft: requires clarificati=
on, one aspect already recognized as such by the Editors. IMHO and FWIW pre=
ferred resolution would be to equate Sections
 with data links 
    



    

  1. Label Allocation Schemes:



    

      

    • MPLS recognizes two label allocation schemes, each with its=
 own area of applicability:

    



    

      

        

      • Downstream label allocation as per RFC 3031

      • Upstream label allocation as per RFC 5331

      

    



    

      

    • IMHO the label allocation scheme is essentially a data plan=
e issue:

    



    

      

        

      • Label allocation scheme is reflected in the Ethertype =
in the case of Ethernet encapsulation etc.

      • Packets with invalid labels must be silently discarded=
 etc.

      

    



    

      

    • It is not clear to me, which label allocation schemes can b=
e used in MPLS-TP.

    



    

      

        

      • This includes applicability of these schemes, e.g., can we =
use upstream label allocation

      • This issue is closely related to proposed usage=
 of a well-known multicast MAC destination address for P2P LSPs)<=
/span>

      

    



    

      

    • Status of this topic in the -00 draft: requires clarificati=
on

    



    

  1. MAC addresses on Ethernet data links in MPLS-TP:



    

      

    • The draft discusses this topic, and proposes using a well-k=
nown multicast DA in Ethernet encapsulations for for P2P LSPs

    • IMHO and FWIW if LAN interfaces are allowed in MP=
LS-TP, usage of  well-known multicast DA is not compatible with the do=
wnstream label allocation scheme.

    • Status of this topic in the -00-draft: partially recog=
nized by the Editors, there seems to be a bug in the proposed solution.

    





Hopefully, these notes will be useful.






 






Regards,






     Sasha
--_000_A3C5DF08D38B6049839A6F553B331C76BFDF75E7BCILPTMAIL02eci_-- From rahul@juniper.net Fri Feb 5 15:59:45 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 08B893A6FB0; Fri, 5 Feb 2010 15:59:45 -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 xMyCBC5CNf-F; Fri, 5 Feb 2010 15:59:43 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 5D5543A6E84; Fri, 5 Feb 2010 15:59:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS2yxH2T8X8taRlGPJxQmlMvqoAcX6uKr@postini.com; Fri, 05 Feb 2010 16:00:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Fri, 5 Feb 2010 15:59:41 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:59:40 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:59:40 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:59:40 -0800 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o15Nxd973775; Fri, 5 Feb 2010 15:59:39 -0800 (PST) (envelope-from rahul@juniper.net) Date: Fri, 5 Feb 2010 15:59:39 -0800 From: Rahul Aggarwal To: Loa Andersson In-Reply-To: <4B6AE1E8.1080404@pi.nu> Message-ID: <20100205154513.X25815@sapphire.juniper.net> References: <4B6AE1E8.1080404@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginalArrivalTime: 05 Feb 2010 23:59:40.0195 (UTC) FILETIME=[477EFF30:01CAA6BF] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [mpls] LC comments on draft-ietf-mpls-tp-framework-10 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, 05 Feb 2010 23:59:45 -0000 Here are my LC comments on draft-ietf-mpls-tp-framework-10, prefixed by : 1. 1.3.4. MPLS-TP Label Switched Path An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as set out in [RFC5654]. The characteristics of an MPLS-TP LSP are primarily that it: I would suggest adding: "A MPLS-TP LSP is the lowest server layer provided by MPLS-TP. The client layers of a MPLS-TP LSP maybe IP, MPLS or PWs. The client layers of a MPLS-TP LSP are described in detail in section 3.4" This is to make the client server relationship in MPLS-TP clearer. 2. 1.3.10. Additional Definitions and Terminology Detailed definitions and additional terminology may be found in [RFC5654]. I would suggest a section on "Service Interface". This is to clarify the applicability of the use of MPLS-TP LSPs and PWs as described in section 3.4. Furhter it is needed to clarify what is the interface exposed by MPLS-TP to the client network. "Service Interface The transport service provided by MPLS-TP is said to be provided by a service interface. The following are the service interfaces supported by MPLS-TP: - The service interface may a layer 2 interface that carries only network layer clients. MPLS-TP LSPs are both necessary and sufficient to support this service interface as described in section 3.4.3 - Or the service interface may be a layer 2 interface that carries both network layer and non-network layer clients. To support this service interface, a PW is required to adapt the client traffic received over the service interface. This PW in turn is a client of the MPLS-TP server layer. This is described in section 3.4.2. - Or the service interface may be a MPLS LSP or a PW. To support this case a MPLS-TP PE participates in the service interface signaling." 3. 1.4. Applicability MPLS-TP can be used to construct packet transport networks and is therefore applicable in any packet transport network context. It is also applicable to subsets of a packet network where the transport network operational model is deemed attractive. The following are examples of MPLS-TP applicability models: 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or LSRs), acting as a server for other layer 1, layer 2 and layer 3 networks (Figure 1). 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs and PWs (i.e. both LSPs and PWs that conform to the transport profile and those that do not, exist between the PEs), acting as a server for other layer 1, layer 2 and layer 3 networks (Figure 2). 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS networks which do not use functions of the MPLS transport profile. For MPLS traffic, the MPLS-TP server layer network uses PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that terminates the MPLS-TP server layer (Figure 3). I think figure 3 and case 3 as written currently are making an assumption that a MPLS-TP PE participates in the "service interface signaling" where the service interface provided by MPLS-TP is a MPLS LSP or a PW. This is a NNI model. Perhaps we need two sub-cases of case 3. One is a UNI model where the MPLS network just sees a P2P or P2MP link, which is provided by the MPLS-TP network. In this case mechanisms of section 3.4.3 are sufficient. The second case is the one which the current text seems to imply and in that case the MPLS-TP PE would participate in the MPLS signaling. In this case the MPLS-TP PE may use LSP hierarchy or LSP stitching to support the MPLS-LSP as a service interface and may use PW stitching to support PW as a service interface. So I would propose to replace example number 3 above with: "3. MPLS-TP as a server layer for client layer traffic of IP or MPLS networks which do not use functions of the MPLS transport profile. Here are two examples of applicability models of this: a) The client IP or MPLS network is provided a layer 2 P2P or P2MP link by the MPLS-TP network. In other words the service interface is a layer 2 inteface that carries only IP or MPLS packets. To support this case the MPLS-TP server layer network uses the mechanisms of section 3.4.3 to carry IP or MPLS client l layer traffic over MPLS-TP LSPs" b) The client IP or MPLS network is provided a LSP or a PW as a service interface by the MPLS-TP network. In this case the MPLS-TP PE would participate in the client MPLS signaling. In this case the MPLS-TP PE may use LSP hierarchy or LSP stitching to support the MPLS-LSP as a service interface and may use PW stitching to support PW as a service interface (Figure 3)" 4. 3.1 Packet Transport Services One objective of MPLS-TP is to enable MPLS networks to provide packet transport services with a similar degree of predictability to that found in existing transport networks. Such packet transport services inherit a number of characteristics, defined in [RFC5654]: o In an environment where an MPLS-TP layer network is supporting a client layer network, and the MPLS-TP layer network is supported by a server layer network then operation of the MPLS-TP layer network must be possible without any dependencies on either the server or client layer network. o The service provided by the MPLS-TP network to the client is guaranteed not to fall below the agreed level regardless of other client activity. o The control and management planes of any client network layer that uses the service is isolated from the control and management planes of the MPLS-TP layer network, where the client network layer is considered to be the native service of the MPLS-TP network. o Where a client network makes use of an MPLS-TP server that provides a packet transport service, the level of co-ordination required between the client and server layer networks is minimal (preferably no co-ordination will be required). o The complete set of packets generated by a client MPLS(-TP) layer network using the packet transport service, which may contain packets that are not MPLS packets (e.g. IP or CLNS packets used by the control/management plane of the client MPLS(-TP) layer Bocci, et al. Expires August 8, 2010 [Page 12] Internet-Draft MPLS Transport Profile Framework February 2010 network), are transported by the MPLS-TP server layer network. o The packet transport service enables the MPLS-TP layer network addressing and other information (e.g. topology) to be hidden from any client layer networks using that service, and vice-versa. These characteristics imply that a packet transport service does not support a connectionless packet-switched forwarding mode. However, this does not preclude it carrying client traffic associated with a connectionless service. Such packet transport services are very similar to Layer 2 Virtual Private Networks as defined by the IETF. The last sentence should be deleted. It doesn't add value and is in potential conflict with section 3.4.3. 5. 3.3. Architecture MPLS-TP comprises the following architectural elements: o A standard MPLS data plane [RFC3031] as profiled in [I-D.fbb-mpls-tp-data-plane]. Standard MPLS data plane also includes RFC 5331 and RFC 5332. Given draft-fbb is not a WG draft, I don't think we should add a reference to it here. 6. 3.4.2. Pseudowire Adaptation The architecture for an MPLS-TP network that provides PW emulated services is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures. I think instead of "PW emulated services", the section should start with the service interface that requires PWs. Something like: "If the MPLS-TP network provides a layer 2 interface, that carries both network layer and non-network layer traffic, as a service interface then a PW is required to support the service interface. The PW is a client of the MPLS-TP LSP server layer. The architecture of a MPLS-TP network that uses such PWs is is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures." The above is to make it very clear the applicability of 3.4.2 as compared to 3.4.3. Multi-segment pseudowires may optionally be used to provide a packet transport service, and their use is consistent with Bocci, et al. Expires August 8, 2010 [Page 18] Internet-Draft MPLS Transport Profile Framework February 2010 the MPLS-TP architecture. The use of MS-PWs may be motivated by, for example, the requirements specified in [RFC5254]. If MS-PWs are used, then the MS-PW architecture [RFC5659] also applies. Figure 6 shows the architecture for an MPLS-TP network using single- segment PWs. |<--------------- Emulated Service ----------------->| | | | |<-------- Pseudowire -------->| | | | encapsulated, packet | | | | transport service | | | | | | | | |<------ LSP ------->| | | | V V V V | V AC +----+ +-----+ +----+ AC V +-----+ | | PE1|=======\ /========| PE2| | +-----+ | |----------|.......PW1.| \ / |............|----------| | | CE1 | | | | | X | | | | | CE2 | | |----------|.......PW2.| / \ |............|----------| | +-----+ ^ | | |=======/ \========| | | ^ +-----+ ^ | +----+ +-----+ +----+ | ^ | | Provider Edge 1 ^ Provider Edge 2 | | | | | | | Customer | P Router | Customer Edge 1 | | Edge 2 | | | | Native service Native service Figure 6: MPLS-TP Architecture (Single Segment PW) Figure 7 shows the architecture for an MPLS-TP network when multi- segment pseudowires are used. Note that as in the SS-PW case, P-routers may also exist. This figure needs to clarify where the MPLS-TP PEs are and where the "service PEs" are. Or whether PE1 is actually both the MPLS-TP PE and the service PE. Bocci, et al. Expires August 8, 2010 [Page 19] Internet-Draft MPLS Transport Profile Framework February 2010 |<----------- Pseudowire encapsulated ------------->| | packet transport service | | | | | | | AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC | V V V V V V | | +----+ +-----+ +----+ +----+ | +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ | |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| | |CE1| | | | | X | | | | | | |CE2| | |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| | +---+ | | |===============/ \=====| |==========| | | +---+ ^ +----+ ^ +-----+ +----+ ^ +----+ ^ | | ^ | | | TE LSP | TE LSP | | P-router | | | |<-------------------- Emulated Service ------------------->| PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while PW2-segment1 and PW2-segment2 are segments of another MS-PW Figure 7: MPLS-TP Architecture (Multi-Segment PW) The corresponding MPLS-TP protocol stacks including PWs are shown in Figure 8. In this figure the Transport Service Layer [RFC5654] is identified by the PW demultiplexer (Demux) label and the Transport Path Layer [RFC5654] is identified by the LSP Demux Label. Bocci, et al. Expires August 8, 2010 [Page 20] Internet-Draft MPLS Transport Profile Framework February 2010 +-------------------+ /===================\ /===================\ | Client Layer | H OAM PDU H H OAM PDU H /===================\ H-------------------H H-------------------H H PW Encap H H GACh H H GACh H H-------------------H H-------------------H H-------------------H H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H H-------------------H H-------------------H H-------------------H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H \===================/ \===================/ \===================/ | Server Layer | | Server Layer | | Server Layer | +-------------------+ +-------------------+ +-------------------+ User Traffic PW OAM LSP OAM Note: H(ighlighted) indicates the part of the protocol stack we are considering in this document. Figure 8: MPLS-TP Layer Network using Pseudowires PWs and their associated labels may be configured or signaled. See Section 3.11 for additional details related to configured service types. See Section 3.9 for additional details related to signaled service types. 7. 3.4.2.1. Pseudowire Based Services When providing a Virtual Private Wire Service (VPWS) , Virtual Private Local Area Network Service (VPLS), Virtual Private Multicast Service (VPMS) or Internet Protocol Local Area Network Service (IPLS), pseudowires must be used to carry the client service. VPWS, VLPS, and IPLS are described in [RFC4664]. VPMS is described in [I-D.ietf-l2vpn-vpms-frmwk-requirements]. This section should be deleted. From a MPLS-TP network view point the service interface, that requires PWs, is a point-to-point layer 2 interface that carries both network layer and non-network layer traffic. This is orthogonal to the service which is being delivered to the end user. Hence this section doesn't belong here. 8. 3.4.3. Network Layer Adaptation MPLS-TP LSPs can be used to transport network layer clients. This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. The network layer protocols supported by [RFC3031] and [RFC3032] can be transported between service interfaces. Examples are shown in Figure 5 above. Support for network layer clients follows the MPLS architecture for support of network layer protocols as specified in [RFC3031] and [RFC3032]. With network layer adaptation, the MPLS-TP domain provides either a uni-directional or bidirectional point-to-point connection between two PEs in order to deliver a packet transport service to attached customer edge (CE) nodes. For example, a CE may be an IP, MPLS or Bocci, et al. Expires August 8, 2010 [Page 21] Internet-Draft MPLS Transport Profile Framework February 2010 MPLS-TP node. As shown in Figure 9, there is an attachment circuit between the CE node on the left and its corresponding provider edge (PE) node which provides the service interface, a bidirectional LSP across the MPLS-TP network to the corresponding PE node on the right, and an attachment circuit between that PE node and the corresponding CE node for this service. The attachment circuits may be heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads arrive at the service interface encapsulated in the Layer1/Layer2 encoding defined for that access link type. It should be noted that the set of network layer protocols includes MPLS and hence MPLS encoded packets with an MPLS label stack (the client MPLS stack), may appear at the service interface. |<------------- Client Network Layer ------------->| | | | |<---- Pkt Xport Service --->| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +---+ +----+ AC V +-----+ | |PE1 | | | |PE2 | | +-----+ | | |LSP | | | | | | | | | | CE1 |----------| |========X=========| |----------| CE2 | | | ^ |IP | | ^ | | ^ | | | ^ | | +-----+ | | | | | | | | | | | | +-----+ ^ | +----+ | +---+ | +----+ | | ^ | | Provider | ^ | Provider | | | | Edge | | | Edge | | Customer | 1 | P-router | 2 | Customer Edge 1 | TE TE | Edge 2 | LSP LSP | | | Native service Native service Figure 9: MPLS-TP Architecture for Network Layer Clients PE1 and PE2 should be specifically labeled as MPLS-TP PEs. At the ingress service interface the client packets are received . The PE pushes one or more labels onto the client packets which are then label switched over the transport network. Correspondingly the egress PE pops any labels added by the MPLS-TP networks and transmits the packet for delivery to the attached CE via the egress service interface. 9. 3.6. Generic Associated Channel (G-ACh) For correct operation of the OAM it is important that the OAM packets fate-share with the data packets. In addition in MPLS-TP it is necessary to discriminate between user data payloads and other types of payload. For example, a packet may be associated with a Signaling Communication Channel (SCC), or a channel used for Automatic Protection Switching (APS) data. This is achieved by carrying such packets on a generic control channel associated to the LSP, PW or section. Suggest replacing the last sentence with: "This is achieved by either carrying such packets in an IP encapsulation that provides the necessary discrimination, or by carrying such packets on a generic control channel associated to the LSP, PW or section. Rest of this section describes the latter mechanism." Also please see related comment in section 3.7. 10. 3.7. Operations, Administration and Maintenance (OAM) MPLS-TP must be able to operate in environments where IP is not used in the forwarding plane. Therefore, the default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated Channel (Section 3.6). Forwarding based on IP addresses for user or OAM packets is not required for MPLS-TP. [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when the OAM packets are encapsulated in an IP header. These alert mechanisms are based on TTL expiration and/or use an IP destination address in the range 127/8 for IPv4 and that same range embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the OAM packets are encapsulated in an IP header, these mechanisms are the default mechanisms for MPLS networks in general for identifying MPLS OAM packets. MPLS-TP must be able to operate in an environments where IP forwarding is not supported, and thus the G-ACh/GAL is the default mechanism to demultiplex OAM packets in MPLS-TP. The last sentence is in conflict with the following from section 4.1 of RFC 5586: "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header although the mechanism defined in this document MAY also be used." Hence the last sentence of the above paragraph must be removed. rahul From Alexander.Vainshtein@ecitele.com Sat Feb 6 04:56: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 2EC213A709C; Sat, 6 Feb 2010 04:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 yxq1RRdiQMs1; Sat, 6 Feb 2010 04:55:59 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id EBEC93A6AF0; Sat, 6 Feb 2010 04:55:58 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-03-4b6d65ba7e2f Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 60.A1.18464.AB56D6B4; Sat, 6 Feb 2010 14:51:06 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 6 Feb 2010 14:56:51 +0200 From: Alexander Vainshtein To: Maarten Vissers , "'LEVRAU, LIEVEN (LIEVEN)'" Date: Sat, 6 Feb 2010 14:56:06 +0200 Thread-Topic: [mpls-tp] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6g== Message-ID: References: , <004b01caa652$562d2a10$9570ca0a@china.huawei.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 06 Feb 2010 12:56:01 -0000 Resending as plain text due to size limitations. Regards, Sasha From: Alexander Vainshtein Sent: Saturday, February 06, 2010 11:14 AM To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, Lieven and all, On the second thought, it seems that if the data link code point indicates = the downstream label allocation scheme for the top label, then the next lab= el MUST be downstream-allocated as well. This is because processing of this label, as defined in 3031, MUST NOT depe= nd on any labels that have been present above it in the label stack and ter= minated (popped) by the LSR that looks it up. The relevant text in Section 3.9 states: Although, as we shall see, MPLS supports a hierarchy, the processing of a l= abeled packet is completely independent of the level of hierarchy. The pro= cessing is always based on the top label, without regard for the possibilit= y that some number of other labels may have been "above it" in the past, = or that some number of other labels may be below it at present. In other words, downstream label allocation scheme does not support "contex= t labels" defined in 5331. They are only compatible with the upstream label= allocation scheme. The bottom line: If the data link code point indicates downstream label allocation of the to= p label, then all the labels in the stack MUST be downstream-allocated (by = the appropriate LSRs) If the data link code point indicates upstream label allocation of the top = label, then both upstream-allocated and downstream-allocated labels MAY app= ear in the stack. In certain situations such a mix can result in undesirabl= e behavior. Regards, Sasha =20 From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander = Vainshtein [Alexander.Vainshtein@ecitele.com] Sent: Friday, February 05, 2010 8:28 PM To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, Lots of thanks for an EXCELLENT question. I do not think I can answer it in full, but the following considerations ma= y be useful. Downstream label allocation scheme is explicitly defined as the default in= RFC 5331 and 5332. Hence, IMHO, if the code point of the data link defines= the top label as downstream-assigned, the router terminating this label wi= ll treat the next one(s) as downstream-assigned - unless it has been explic= itly aware that they are upstream-assigned. In other words, the LSR termina= ting the top label must explicitly bind it to a context space for upstream-= allocated ones.=20 The primary usage of upstream-allocated labels in MPLS (but not necessary i= n MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in conj= unction with multicast datalink addresses (or their analogs as in the case = of MPLS-in-GRE). This means that, generally speaking, more than one router = can terminate the top upstream-allocated label and look at the next one. An= d this is only compatible with the upstream allocation scheme for the next = label. Does this help? Did I miss something important? Regards, Sasha From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Friday, February 05, 2010 12:59 PM To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Sasha, There can/will be many labels in the label stack on MPSL-TP interfaces.=20 Is the Ethernet code point application only to the top of stack label, or t= o all labels in the stack? I would expect that the code point only applies to the top of stack label a= nd not to the non-top of stack labels; is this correct? Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: donderdag 4 februari 2010 14:12 To: LEVRAU, LIEVEN (LIEVEN) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' Lieven, Lots of thanks for a prompt response. IMHO and FWIW the label allocation scheme is not just a control plane issue= . Please note that, as per RFC 5332, MPLS packets with upstream-allocated lab= els use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. What is more, upstream-allocated labels must refer to a certain context by = the downstream router. And context resolution is part of the data plane as = well. Regards, Sasha =20 =20 =20 From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com]=20 Sent: Wednesday, February 03, 2010 9:06 AM To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (= Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Label alloc. Schemes in data-plane-draft' Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label all= oc. Schemes in data-plane-draft=92 In my view - This is a control plane issue and not a data plane issue. How = the labels are assigned is outside the scope of the draft. ./ Lieven Label Allocation Schemes:=20 MPLS recognizes two label allocation schemes, each with its own area of app= licability:=20 Downstream label allocation as per RFC 3031=20 Upstream label allocation as per RFC 5331=20 IMHO the label allocation scheme is essentially a data plane issue:=20 Label allocation scheme is reflected in the Ethertype in the case of Ethern= et encapsulation etc.=20 Packets with invalid labels must be silently discarded etc.=20 It is not clear to me, which label allocation schemes can be used in MPLS-T= P.=20 This includes applicability of these schemes, e.g., can we use upstream lab= el allocation=20 This issue is closely related to proposed usage of a well-known multicast M= AC destination address for P2P LSPs)=20 Status of this topic in the -00 draft: requires clarification=20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. LSP Merge:=20 In MPLS, nothing prevents LSPs from merging at some point:=20 One well-known usage of LSP merge is FRR=20 PHP can be considered as a special case of LSP merge=20 One of the often repeated mantras of MPLS-TP is that its LSPs cannot be mer= ge. =20 It is not clear (at least, to me):=20 Whether this limitation has to be respected at the data plane level, and if= yes, then how=20 Whether it means that FRR cannot be used in MPLS-TP=20 Status of this topic in the -00 draft: not mentioned at all=20 Per-Interface Label Space:=20 The draft states that per-interface label space MAY be used in MPLS-TP=20 AFAIK, in MPLS:=20 This referred to data links (including bundles, e.g., produced by LAG). As = a consequence, the number of label contexts has been reasonably low=20 This has been only allowed on P2P links=20 One of the problems with MPLS-TP is that in many cases it does not differen= tiate between data links and lower layer LSPs (see also my notes regarding = Sections). As a consequence, it is not clear (to me) whether per-interface = label space may become a label space per lower layer LSP. (To the best of m= y understanding this is explicitly prohibited by RFC 3031).=20 Status of this topic in the -00 draft: requires clarification, preferably a= ligned with RFC 3031.=20 Sections:=20 The draft states that Sections could be data links (level 0 sections) or LS= Ps with N labels (level N Sections).=20 The following is not clear to me:=20 Can LAN-like data links be Sections in MPLS-TP (The Editors ask this questi= on themselves when they discuss MAC addresses)=20 Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be = a Section? Can an associated bi-directional LSP be a section? etc.).=20 If associated bi-directional LSPs can be Sections, can we treat the LSPs ru= mming over these Sections as co-routed bidirectional?=20 Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp al= low per-Section label space (see above)?=20 Status of this topic in the -00 draft: requires clarification, one aspect a= lready recognized as such by the Editors. IMHO and FWIW preferred resolutio= n would be to equate Sections with data links=20 Label Allocation Schemes:=20 MPLS recognizes two label allocation schemes, each with its own area of app= licability:=20 Downstream label allocation as per RFC 3031=20 Upstream label allocation as per RFC 5331=20 IMHO the label allocation scheme is essentially a data plane issue:=20 Label allocation scheme is reflected in the Ethertype in the case of Ethern= et encapsulation etc.=20 Packets with invalid labels must be silently discarded etc.=20 It is not clear to me, which label allocation schemes can be used in MPLS-T= P.=20 This includes applicability of these schemes, e.g., can we use upstream lab= el allocation=20 This issue is closely related to proposed usage of a well-known multicast M= AC destination address for P2P LSPs)=20 Status of this topic in the -00 draft: requires clarification=20 MAC addresses on Ethernet data links in MPLS-TP:=20 The draft discusses this topic, and proposes using a well-known multicast D= A in Ethernet encapsulations for for P2P LSPs=20 IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-know= n multicast DA is not compatible with the downstream label allocation schem= e.=20 Status of this topic in the -00-draft: partially recognized by the Editors,= there seems to be a bug in the proposed solution.=20 Hopefully, these notes will be useful. Regards, Sasha= From maarten.vissers@huawei.com Sun Feb 7 23:29: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 7B2463A716D; Sun, 7 Feb 2010 23:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.085 X-Spam-Level: X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 s+Yd2GXojFfP; Sun, 7 Feb 2010 23:29:28 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B10813A6FFF; Sun, 7 Feb 2010 23:29:27 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXI00A53I6IW2@szxga01-in.huawei.com>; Mon, 08 Feb 2010 15:30:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXI00MIWI6I02@szxga01-in.huawei.com>; Mon, 08 Feb 2010 15:30:18 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXI00KNTI6DRG@szxml01-in.huawei.com>; Mon, 08 Feb 2010 15:30:18 +0800 (CST) Date: Mon, 08 Feb 2010 08:30:03 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' , "'LEVRAU, LIEVEN (LIEVEN)'" Message-id: <004901caa890$8a099040$ec7bfea9@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+Czw Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 08 Feb 2010 07:29:29 -0000 Sasha, If I am thinking of a set of p2mp PWs and/or service LSPs carried in a p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up prior to service requests, and uses downstream allocated labels, whereas the p2mp PWs/serviceLSPs must use upstream allocated labels. The intermediate p2mp LSP can use downstream allocated labels. This implies that I have the top two labels with downstream allocated and the bottom label with upstream allocated. Correct? Regards, Maarten -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: zaterdag 6 februari 2010 13:56 To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Resending as plain text due to size limitations. Regards, Sasha From: Alexander Vainshtein Sent: Saturday, February 06, 2010 11:14 AM To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, Lieven and all, On the second thought, it seems that if the data link code point indicates the downstream label allocation scheme for the top label, then the next label MUST be downstream-allocated as well. This is because processing of this label, as defined in 3031, MUST NOT depend on any labels that have been present above it in the label stack and terminated (popped) by the LSR that looks it up. The relevant text in Section 3.9 states: Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present. In other words, downstream label allocation scheme does not support "context labels" defined in 5331. They are only compatible with the upstream label allocation scheme. The bottom line: If the data link code point indicates downstream label allocation of the top label, then all the labels in the stack MUST be downstream-allocated (by the appropriate LSRs) If the data link code point indicates upstream label allocation of the top label, then both upstream-allocated and downstream-allocated labels MAY appear in the stack. In certain situations such a mix can result in undesirable behavior. Regards, Sasha From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] Sent: Friday, February 05, 2010 8:28 PM To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, Lots of thanks for an EXCELLENT question. I do not think I can answer it in full, but the following considerations may be useful. Downstream label allocation scheme is explicitly defined as the default in RFC 5331 and 5332. Hence, IMHO, if the code point of the data link defines the top label as downstream-assigned, the router terminating this label will treat the next one(s) as downstream-assigned - unless it has been explicitly aware that they are upstream-assigned. In other words, the LSR terminating the top label must explicitly bind it to a context space for upstream-allocated ones. The primary usage of upstream-allocated labels in MPLS (but not necessary in MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in conjunction with multicast datalink addresses (or their analogs as in the case of MPLS-in-GRE). This means that, generally speaking, more than one router can terminate the top upstream-allocated label and look at the next one. And this is only compatible with the upstream allocation scheme for the next label. Does this help? Did I miss something important? Regards, Sasha From: Maarten Vissers [maarten.vissers@huawei.com] Sent: Friday, February 05, 2010 12:59 PM To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' Sasha, There can/will be many labels in the label stack on MPSL-TP interfaces. Is the Ethernet code point application only to the top of stack label, or to all labels in the stack? I would expect that the code point only applies to the top of stack label and not to the non-top of stack labels; is this correct? Regards, Maarten From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 4 februari 2010 14:12 To: LEVRAU, LIEVEN (LIEVEN) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' Lieven, Lots of thanks for a prompt response. IMHO and FWIW the label allocation scheme is not just a control plane issue. Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels. To me this is a data plane issue. What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well. Regards, Sasha From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] Sent: Wednesday, February 03, 2010 9:06 AM To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Label alloc. Schemes in data-plane-draft' Hello Shasha Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft' In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft. ./ Lieven Label Allocation Schemes: MPLS recognizes two label allocation schemes, each with its own area of applicability: Downstream label allocation as per RFC 3031 Upstream label allocation as per RFC 5331 IMHO the label allocation scheme is essentially a data plane issue: Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. Packets with invalid labels must be silently discarded etc. It is not clear to me, which label allocation schemes can be used in MPLS-TP. This includes applicability of these schemes, e.g., can we use upstream label allocation This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) Status of this topic in the -00 draft: requires clarification From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: 01 February 2010 18:00 To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I thank you for producing it. That said, I think that quite a few issues have been left undecided in this -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification. LSP Merge: In MPLS, nothing prevents LSPs from merging at some point: One well-known usage of LSP merge is FRR PHP can be considered as a special case of LSP merge One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. It is not clear (at least, to me): Whether this limitation has to be respected at the data plane level, and if yes, then how Whether it means that FRR cannot be used in MPLS-TP Status of this topic in the -00 draft: not mentioned at all Per-Interface Label Space: The draft states that per-interface label space MAY be used in MPLS-TP AFAIK, in MPLS: This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low This has been only allowed on P2P links One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031). Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031. Sections: The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections). The following is not clear to me: Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses) Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.). If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional? Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)? Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links Label Allocation Schemes: MPLS recognizes two label allocation schemes, each with its own area of applicability: Downstream label allocation as per RFC 3031 Upstream label allocation as per RFC 5331 IMHO the label allocation scheme is essentially a data plane issue: Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. Packets with invalid labels must be silently discarded etc. It is not clear to me, which label allocation schemes can be used in MPLS-TP. This includes applicability of these schemes, e.g., can we use upstream label allocation This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) Status of this topic in the -00 draft: requires clarification MAC addresses on Ethernet data links in MPLS-TP: The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-known multicast DA is not compatible with the downstream label allocation scheme. Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha= From Alexander.Vainshtein@ecitele.com Mon Feb 8 00:44: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 506A83A72D9; Mon, 8 Feb 2010 00:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 zzQzMyFvFvnS; Mon, 8 Feb 2010 00:44:22 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 947923A72D8; Mon, 8 Feb 2010 00:44:21 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-95-4b6fcdbffa37 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B0.DA.18464.FBDCF6B4; Mon, 8 Feb 2010 10:39:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 8 Feb 2010 10:45:21 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Mon, 8 Feb 2010 10:45:19 +0200 Thread-Topic: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyA= Message-ID: References: <004901caa890$8a099040$ec7bfea9@china.huawei.com> In-Reply-To: <004901caa890$8a099040$ec7bfea9@china.huawei.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 08 Feb 2010 08:44:24 -0000 =20 Maarten, In short: NOT CORRECT. The construction you present violates the MPLS data plane architecture as d= efined in 3031. The LSR that terminates the outer P2P LSP cannot know that the next label i= t looks-up =20 is upstream-allocated (and hence to be looked-up in a different context):=20 - the data link does not indicate that (otherwise the top label would be up= stream-allocated) - the terminated label CANNOT be used as the context label. It must be proc= essed=20 regardless of its position in the label stack. Aside:=20 Early LSRs have used a physical loopback interface for multiple label look-= ups. I.e., when they received a labeled packet with two or more labels in the st= ack and wanted to look at the 2nd label, they physically popped the top label and forwarde= d the packet to a dedicated looped-back physical interface. The packet received from tha= t interface would have the former 2nd label as the top one, and would then process it as any = other top label. Of course, the top label and the original ingress interface would be lost i= n this operation. MPLS (and PW) architecture has been designed to allow this type of processi= ng. Modern LSRs do not usually use a physical loopback interface for multiple l= abel lookups,=20 but neither do they prevent their downstream peers from using it as long as= the downstream=20 label allocation scheme is used.=20 Hopefully this clarification will be helpful. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Maarten Vissers > Sent: Monday, February 08, 2010 9:30 AM > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > data-plane-draft' >=20 > Sasha, >=20 > If I am thinking of a set of p2mp PWs and/or service LSPs=20 > carried in a p2mp > LSP carried over a p2p LSP. The oter p2p LSP is set up prior=20 > to service > requests, and uses downstream allocated labels, whereas the p2mp > PWs/serviceLSPs must use upstream allocated labels. The=20 > intermediate p2mp > LSP can use downstream allocated labels. >=20 > This implies that I have the top two labels with downstream=20 > allocated and > the bottom label with upstream allocated. Correct? >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: zaterdag 6 februari 2010 13:56 > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' >=20 > Resending as plain text due to size limitations. >=20 > Regards, > Sasha >=20 >=20 >=20 > From: Alexander Vainshtein > Sent: Saturday, February 06, 2010 11:14 AM > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' >=20 >=20 > Maarten, Lieven and all, > On the second thought, it seems that if the data link code=20 > point indicates > the downstream label allocation scheme for the top label,=20 > then the next > label MUST be downstream-allocated as well. >=20 > This is because processing of this label, as defined in 3031, MUST NOT > depend on any labels that have been present above it in the=20 > label stack and > terminated (popped) by the LSR that looks it up. >=20 > The relevant text in Section 3.9 states: >=20 > Although, as we shall see, MPLS supports a hierarchy, the=20 > processing of a > labeled packet is completely independent of the level of=20 > hierarchy. The > processing is always based on the top label, without regard for the > possibility that some number of other labels may have been=20 > "above it" in > the past, or that some number of other labels may be below it=20 > at present. > In other words, downstream label allocation scheme does not=20 > support "context > labels" defined in 5331. They are only compatible with the=20 > upstream label > allocation scheme. > The bottom line: > If the data link code point indicates downstream label=20 > allocation of the top > label, then all the labels in the stack MUST be=20 > downstream-allocated (by the > appropriate LSRs) If the data link code point indicates upstream label > allocation of the top label, then both upstream-allocated and > downstream-allocated labels MAY appear in the stack. In=20 > certain situations > such a mix can result in undesirable behavior. > Regards, > Sasha > =20 >=20 >=20 >=20 >=20 > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf=20 > Of Alexander > Vainshtein [Alexander.Vainshtein@ecitele.com] > Sent: Friday, February 05, 2010 8:28 PM > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > data-plane-draft' >=20 >=20 > Maarten, > Lots of thanks for an EXCELLENT question. >=20 > I do not think I can answer it in full, but the following=20 > considerations may > be useful. >=20 > Downstream label allocation scheme is explicitly defined as=20 > the default in > RFC 5331 and 5332. Hence, IMHO, if the code point of the data=20 > link defines > the top label as downstream-assigned, the router terminating=20 > this label will > treat the next one(s) as downstream-assigned - unless it has=20 > been explicitly > aware that they are upstream-assigned. In other words, the=20 > LSR terminating > the top label must explicitly bind it to a context space for > upstream-allocated ones.=20 > The primary usage of upstream-allocated labels in MPLS (but=20 > not necessary in > MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in > conjunction with multicast datalink addresses (or their=20 > analogs as in the > case of MPLS-in-GRE). This means that, generally speaking,=20 > more than one > router can terminate the top upstream-allocated label and=20 > look at the next > one. And this is only compatible with the upstream allocation=20 > scheme for the > next label. >=20 > Does this help? Did I miss something important? >=20 > Regards, > Sasha >=20 >=20 >=20 > From: Maarten Vissers [maarten.vissers@huawei.com] > Sent: Friday, February 05, 2010 12:59 PM > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' >=20 >=20 > Sasha, >=20 > There can/will be many labels in the label stack on MPSL-TP=20 > interfaces.=20 > Is the Ethernet code point application only to the top of=20 > stack label, or to > all labels in the stack? >=20 > I would expect that the code point only applies to the top of=20 > stack label > and not to the non-top of stack labels; is this correct? >=20 > Regards, > Maarten >=20 >=20 >=20 >=20 > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: donderdag 4 februari 2010 14:12 > To: LEVRAU, LIEVEN (LIEVEN) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' >=20 >=20 > Lieven, > Lots of thanks for a prompt response. >=20 > IMHO and FWIW the label allocation scheme is not just a=20 > control plane issue. > Please note that, as per RFC 5332, MPLS packets with=20 > upstream-allocated > labels use a different code point on Ethernet links and GRE tunnels. > To me this is a data plane issue. >=20 > What is more, upstream-allocated labels must refer to a=20 > certain context by > the downstream router. And context resolution is part of the=20 > data plane as > well. >=20 > Regards, > Sasha >=20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: LEVRAU, LIEVEN (LIEVEN)=20 > [mailto:lieven.levrau@alcatel-lucent.com] > Sent: Wednesday, February 03, 2010 9:06 AM > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost';=20 > Bocci, Matthew > (Matthew) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Label alloc. Schemes in data-plane-draft' >=20 >=20 >=20 >=20 > Hello Shasha > Changed title from Comments on=20 > draft-fbb-mpls-tp-data-plane-00 -> Label > alloc. Schemes in data-plane-draft' >=20 > In my view - This is a control plane issue and not a data=20 > plane issue. How > the labels are assigned is outside the scope of the draft. >=20 > ./ > Lieven > Label Allocation Schemes:=20 > MPLS recognizes two label allocation schemes, each with its=20 > own area of > applicability:=20 > Downstream label allocation as per RFC 3031=20 > Upstream label allocation as per RFC 5331=20 > IMHO the label allocation scheme is essentially a data plane issue:=20 > Label allocation scheme is reflected in the Ethertype in the case of > Ethernet encapsulation etc.=20 > Packets with invalid labels must be silently discarded etc.=20 > It is not clear to me, which label allocation schemes can be used in > MPLS-TP.=20 > This includes applicability of these schemes, e.g., can we=20 > use upstream > label allocation=20 > This issue is closely related to proposed usage of a=20 > well-known multicast > MAC destination address for P2P LSPs)=20 > Status of this topic in the -00 draft: requires clarification=20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of > Alexander Vainshtein > Sent: 01 February 2010 18:00 > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 >=20 > Stewart, Dan, Matthew and all, > First of all I'd like to say that the need for clear-cut=20 > definition of the > MPLS-TP data plane architecture has been quite clear to me. > The draft is clearly the necessary first step in the right=20 > direction, and I > thank you for producing it. >=20 > That said, I think that quite a few issues have been left=20 > undecided in this > -00 version of the draft. >=20 > I will make a (hopefully, short) list of items that IMHO=20 > require additional > clarification and, eventually, codification. >=20 > LSP Merge:=20 > In MPLS, nothing prevents LSPs from merging at some point:=20 > One well-known usage of LSP merge is FRR=20 > PHP can be considered as a special case of LSP merge=20 > One of the often repeated mantras of MPLS-TP is that its LSPs=20 > cannot be > merge. =20 > It is not clear (at least, to me):=20 > Whether this limitation has to be respected at the data plane=20 > level, and if > yes, then how=20 > Whether it means that FRR cannot be used in MPLS-TP=20 > Status of this topic in the -00 draft: not mentioned at all=20 > Per-Interface Label Space:=20 > The draft states that per-interface label space MAY be used=20 > in MPLS-TP=20 > AFAIK, in MPLS:=20 > This referred to data links (including bundles, e.g.,=20 > produced by LAG). As a > consequence, the number of label contexts has been reasonably low=20 > This has been only allowed on P2P links=20 > One of the problems with MPLS-TP is that in many cases it does not > differentiate between data links and lower layer LSPs (see=20 > also my notes > regarding Sections). As a consequence, it is not clear (to me) whether > per-interface label space may become a label space per lower=20 > layer LSP. (To > the best of my understanding this is explicitly prohibited by=20 > RFC 3031).=20 > Status of this topic in the -00 draft: requires=20 > clarification, preferably > aligned with RFC 3031.=20 > Sections:=20 > The draft states that Sections could be data links (level 0=20 > sections) or > LSPs with N labels (level N Sections).=20 > The following is not clear to me:=20 > Can LAN-like data links be Sections in MPLS-TP (The Editors ask this > question themselves when they discuss MAC addresses)=20 > Which types of LSPs can be Sections (e.g., can a P2P=20 > unidirectional LSP be a > Section? Can an associated bi-directional LSP be a section? etc.).=20 > If associated bi-directional LSPs can be Sections, can we=20 > treat the LSPs > rumming over these Sections as co-routed bidirectional?=20 > Per-data link (interface) label space is supported in MPLS.=20 > Does MPLS-Tp > allow per-Section label space (see above)?=20 > Status of this topic in the -00 draft: requires=20 > clarification, one aspect > already recognized as such by the Editors. IMHO and FWIW preferred > resolution would be to equate Sections with data links=20 > Label Allocation Schemes:=20 > MPLS recognizes two label allocation schemes, each with its=20 > own area of > applicability:=20 > Downstream label allocation as per RFC 3031=20 > Upstream label allocation as per RFC 5331=20 > IMHO the label allocation scheme is essentially a data plane issue:=20 > Label allocation scheme is reflected in the Ethertype in the case of > Ethernet encapsulation etc.=20 > Packets with invalid labels must be silently discarded etc.=20 > It is not clear to me, which label allocation schemes can be used in > MPLS-TP.=20 > This includes applicability of these schemes, e.g., can we=20 > use upstream > label allocation=20 > This issue is closely related to proposed usage of a=20 > well-known multicast > MAC destination address for P2P LSPs)=20 > Status of this topic in the -00 draft: requires clarification=20 > MAC addresses on Ethernet data links in MPLS-TP:=20 > The draft discusses this topic, and proposes using a=20 > well-known multicast DA > in Ethernet encapsulations for for P2P LSPs=20 > IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage=20 > of well-known > multicast DA is not compatible with the downstream label=20 > allocation scheme.=20 > Status of this topic in the -00-draft: partially recognized=20 > by the Editors, > there seems to be a bug in the proposed solution.=20 > Hopefully, these notes will be useful. >=20 > Regards, > Sasha=3D >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From maarten.vissers@huawei.com Mon Feb 8 04:10: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 393123A71B9; Mon, 8 Feb 2010 04:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 pmCf93LChOjo; Mon, 8 Feb 2010 04:10:04 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5F4693A7038; Mon, 8 Feb 2010 04:10: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 <0KXI00F3AV67XR@szxga03-in.huawei.com>; Mon, 08 Feb 2010 20:10:56 +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 <0KXI004OGV67IJ@szxga03-in.huawei.com>; Mon, 08 Feb 2010 20:10:55 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXI00AJ3V63QP@szxml02-in.huawei.com>; Mon, 08 Feb 2010 20:10:55 +0800 (CST) Date: Mon, 08 Feb 2010 13:10:41 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' Message-id: <006d01caa8b7$bde51930$ec7bfea9@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwA== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 08 Feb 2010 12:10:06 -0000 Sasha, An interesting limitation in the MPLS data plane architecture. >From a transport network perspective one should not expect such limitation. E.g. in OTN I can set up a p2p HO ODU3 connection over which I carry a p2mp LO ODU2 connection, which carries up to 8 p2mp ODU0 signals with e.g. 1GE clients. And in an Ethernet network I can set up a p2p Ethernet VP connection over which I carry a p2mp Ethernet VC connection, which carries a number of p2mp Ethernet VLANs. The fact that both OTN and Ethernet can support the example, I am wondering if it is the MPLS data plane architecture that is not capable, or if it are the existing MPLS equipment that are not capable? Regards, Maarten -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: maandag 8 februari 2010 9:45 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, In short: NOT CORRECT. The construction you present violates the MPLS data plane architecture as defined in 3031. The LSR that terminates the outer P2P LSP cannot know that the next label it looks-up is upstream-allocated (and hence to be looked-up in a different context): - the data link does not indicate that (otherwise the top label would be upstream-allocated) - the terminated label CANNOT be used as the context label. It must be processed regardless of its position in the label stack. Aside: Early LSRs have used a physical loopback interface for multiple label look-ups. I.e., when they received a labeled packet with two or more labels in the stack and wanted to look at the 2nd label, they physically popped the top label and forwarded the packet to a dedicated looped-back physical interface. The packet received from that interface would have the former 2nd label as the top one, and would then process it as any other top label. Of course, the top label and the original ingress interface would be lost in this operation. MPLS (and PW) architecture has been designed to allow this type of processing. Modern LSRs do not usually use a physical loopback interface for multiple label lookups, but neither do they prevent their downstream peers from using it as long as the downstream label allocation scheme is used. Hopefully this clarification will be helpful. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Maarten Vissers > Sent: Monday, February 08, 2010 9:30 AM > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > Sasha, > > If I am thinking of a set of p2mp PWs and/or service LSPs carried in a > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up prior to > service requests, and uses downstream allocated labels, whereas the > p2mp PWs/serviceLSPs must use upstream allocated labels. The > intermediate p2mp LSP can use downstream allocated labels. > > This implies that I have the top two labels with downstream allocated > and the bottom label with upstream allocated. Correct? > > Regards, > Maarten > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: zaterdag 6 februari 2010 13:56 > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > Resending as plain text due to size limitations. > > Regards, > Sasha > > > > From: Alexander Vainshtein > Sent: Saturday, February 06, 2010 11:14 AM > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > Maarten, Lieven and all, > On the second thought, it seems that if the data link code point > indicates the downstream label allocation scheme for the top label, > then the next label MUST be downstream-allocated as well. > > This is because processing of this label, as defined in 3031, MUST NOT > depend on any labels that have been present above it in the label > stack and terminated (popped) by the LSR that looks it up. > > The relevant text in Section 3.9 states: > > Although, as we shall see, MPLS supports a hierarchy, the processing > of a labeled packet is completely independent of the level of > hierarchy. The processing is always based on the top label, without > regard for the > possibility that some number of other labels may have been > "above it" in > the past, or that some number of other labels may be below it at > present. > In other words, downstream label allocation scheme does not support > "context labels" defined in 5331. They are only compatible with the > upstream label allocation scheme. > The bottom line: > If the data link code point indicates downstream label allocation of > the top label, then all the labels in the stack MUST be > downstream-allocated (by the appropriate LSRs) If the data link code > point indicates upstream label allocation of the top label, then both > upstream-allocated and downstream-allocated labels MAY appear in the > stack. In certain situations such a mix can result in undesirable > behavior. > Regards, > Sasha > > > > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > Sent: Friday, February 05, 2010 8:28 PM > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > > Maarten, > Lots of thanks for an EXCELLENT question. > > I do not think I can answer it in full, but the following > considerations may be useful. > > Downstream label allocation scheme is explicitly defined as the > default in RFC 5331 and 5332. Hence, IMHO, if the code point of the > data link defines the top label as downstream-assigned, the router > terminating this label will treat the next one(s) as > downstream-assigned - unless it has been explicitly aware that they > are upstream-assigned. In other words, the LSR terminating the top > label must explicitly bind it to a context space for > upstream-allocated ones. > The primary usage of upstream-allocated labels in MPLS (but not > necessary in > MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in > conjunction with multicast datalink addresses (or their analogs as in > the case of MPLS-in-GRE). This means that, generally speaking, more > than one router can terminate the top upstream-allocated label and > look at the next one. And this is only compatible with the upstream > allocation scheme for the next label. > > Does this help? Did I miss something important? > > Regards, > Sasha > > > > From: Maarten Vissers [maarten.vissers@huawei.com] > Sent: Friday, February 05, 2010 12:59 PM > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > Sasha, > > There can/will be many labels in the label stack on MPSL-TP > interfaces. > Is the Ethernet code point application only to the top of stack label, > or to all labels in the stack? > > I would expect that the code point only applies to the top of stack > label and not to the non-top of stack labels; is this correct? > > Regards, > Maarten > > > > > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein > Sent: donderdag 4 februari 2010 14:12 > To: LEVRAU, LIEVEN (LIEVEN) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > Lieven, > Lots of thanks for a prompt response. > > IMHO and FWIW the label allocation scheme is not just a > control plane issue. > Please note that, as per RFC 5332, MPLS packets with > upstream-allocated > labels use a different code point on Ethernet links and GRE tunnels. > To me this is a data plane issue. > > What is more, upstream-allocated labels must refer to a > certain context by > the downstream router. And context resolution is part of the > data plane as > well. > > Regards, > Sasha > > > > > > > > > > > > > > From: LEVRAU, LIEVEN (LIEVEN) > [mailto:lieven.levrau@alcatel-lucent.com] > Sent: Wednesday, February 03, 2010 9:06 AM > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; > Bocci, Matthew > (Matthew) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Label alloc. Schemes in data-plane-draft' > > > > > Hello Shasha > Changed title from Comments on > draft-fbb-mpls-tp-data-plane-00 -> Label > alloc. Schemes in data-plane-draft' > > In my view - This is a control plane issue and not a data > plane issue. How > the labels are assigned is outside the scope of the draft. > > ./ > Lieven > Label Allocation Schemes: > MPLS recognizes two label allocation schemes, each with its > own area of > applicability: > Downstream label allocation as per RFC 3031 > Upstream label allocation as per RFC 5331 > IMHO the label allocation scheme is essentially a data plane issue: > Label allocation scheme is reflected in the Ethertype in the case of > Ethernet encapsulation etc. > Packets with invalid labels must be silently discarded etc. > It is not clear to me, which label allocation schemes can be used in > MPLS-TP. > This includes applicability of these schemes, e.g., can we > use upstream > label allocation > This issue is closely related to proposed usage of a > well-known multicast > MAC destination address for P2P LSPs) > Status of this topic in the -00 draft: requires clarification > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > Alexander Vainshtein > Sent: 01 February 2010 18:00 > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > > Stewart, Dan, Matthew and all, > First of all I'd like to say that the need for clear-cut > definition of the > MPLS-TP data plane architecture has been quite clear to me. > The draft is clearly the necessary first step in the right > direction, and I > thank you for producing it. > > That said, I think that quite a few issues have been left > undecided in this > -00 version of the draft. > > I will make a (hopefully, short) list of items that IMHO > require additional > clarification and, eventually, codification. > > LSP Merge: > In MPLS, nothing prevents LSPs from merging at some point: > One well-known usage of LSP merge is FRR > PHP can be considered as a special case of LSP merge > One of the often repeated mantras of MPLS-TP is that its LSPs > cannot be > merge. > It is not clear (at least, to me): > Whether this limitation has to be respected at the data plane > level, and if > yes, then how > Whether it means that FRR cannot be used in MPLS-TP > Status of this topic in the -00 draft: not mentioned at all > Per-Interface Label Space: > The draft states that per-interface label space MAY be used > in MPLS-TP > AFAIK, in MPLS: > This referred to data links (including bundles, e.g., > produced by LAG). As a > consequence, the number of label contexts has been reasonably low > This has been only allowed on P2P links > One of the problems with MPLS-TP is that in many cases it does not > differentiate between data links and lower layer LSPs (see > also my notes > regarding Sections). As a consequence, it is not clear (to me) whether > per-interface label space may become a label space per lower > layer LSP. (To > the best of my understanding this is explicitly prohibited by > RFC 3031). > Status of this topic in the -00 draft: requires > clarification, preferably > aligned with RFC 3031. > Sections: > The draft states that Sections could be data links (level 0 > sections) or > LSPs with N labels (level N Sections). > The following is not clear to me: > Can LAN-like data links be Sections in MPLS-TP (The Editors ask this > question themselves when they discuss MAC addresses) > Which types of LSPs can be Sections (e.g., can a P2P > unidirectional LSP be a > Section? Can an associated bi-directional LSP be a section? etc.). > If associated bi-directional LSPs can be Sections, can we > treat the LSPs > rumming over these Sections as co-routed bidirectional? > Per-data link (interface) label space is supported in MPLS. > Does MPLS-Tp > allow per-Section label space (see above)? > Status of this topic in the -00 draft: requires > clarification, one aspect > already recognized as such by the Editors. IMHO and FWIW preferred > resolution would be to equate Sections with data links > Label Allocation Schemes: > MPLS recognizes two label allocation schemes, each with its > own area of > applicability: > Downstream label allocation as per RFC 3031 > Upstream label allocation as per RFC 5331 > IMHO the label allocation scheme is essentially a data plane issue: > Label allocation scheme is reflected in the Ethertype in the case of > Ethernet encapsulation etc. > Packets with invalid labels must be silently discarded etc. > It is not clear to me, which label allocation schemes can be used in > MPLS-TP. > This includes applicability of these schemes, e.g., can we > use upstream > label allocation > This issue is closely related to proposed usage of a > well-known multicast > MAC destination address for P2P LSPs) > Status of this topic in the -00 draft: requires clarification > MAC addresses on Ethernet data links in MPLS-TP: > The draft discusses this topic, and proposes using a > well-known multicast DA > in Ethernet encapsulations for for P2P LSPs > IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage > of well-known > multicast DA is not compatible with the downstream label > allocation scheme. > Status of this topic in the -00-draft: partially recognized > by the Editors, > there seems to be a bug in the proposed solution. > Hopefully, these notes will be useful. > > Regards, > Sasha= > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From neil.2.harrison@bt.com Mon Feb 8 04:22: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 617CF3A6D4A; Mon, 8 Feb 2010 04:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, 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 j9uy5VsUsilL; Mon, 8 Feb 2010 04:22:02 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 07FE53A6A8A; Mon, 8 Feb 2010 04:22:01 -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); Mon, 8 Feb 2010 12:23:02 +0000 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, 8 Feb 2010 12:22:59 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05952566@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <006d01caa8b7$bde51930$ec7bfea9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwAAASiRA From: To: , X-OriginalArrivalTime: 08 Feb 2010 12:23:02.0946 (UTC) FILETIME=[75A23020:01CAA8B9] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 08 Feb 2010 12:22:04 -0000 Maarten, As I remarked in my last mail to Sasha, I am not sure MPLS-TP will be delivering a transport network solution. It *could* do this (as CCAMPs folks have proved with GMPLS) but here it is a conscious choice not to do this....and the decisions that are being taken cannot appeal to technical naivety IMO. The difficulty I can see is that MPLS-TP is trying to be seen as a transport network whilst still retaining certain behaviours from MPLS that are not behaviours of a transport network. It's a pity IMO but it is an outcome I could see happening. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 08 February 2010 12:11 > To: 'Alexander Vainshtein' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [mpls] Label alloc. Schemes in=20 > data-plane-draft' >=20 > Sasha, >=20 > An interesting limitation in the MPLS data plane architecture. > From a transport network perspective one should not expect=20 > such limitation. >=20 > E.g. in OTN I can set up a p2p HO ODU3 connection over which=20 > I carry a p2mp LO ODU2 connection, which carries up to 8 p2mp=20 > ODU0 signals with e.g. 1GE clients. >=20 > And in an Ethernet network I can set up a p2p Ethernet VP=20 > connection over which I carry a p2mp Ethernet VC connection,=20 > which carries a number of p2mp Ethernet VLANs. >=20 > The fact that both OTN and Ethernet can support the example,=20 > I am wondering if it is the MPLS data plane architecture that=20 > is not capable, or if it are the existing MPLS equipment that=20 > are not capable? >=20 > Regards, > Maarten=20 >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: maandag 8 februari 2010 9:45 > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in=20 > data-plane-draft' >=20 > =20 > Maarten, > In short: NOT CORRECT. > The construction you present violates the MPLS data plane=20 > architecture as defined in 3031. >=20 > The LSR that terminates the outer P2P LSP cannot know that=20 > the next label it looks-up is upstream-allocated (and hence=20 > to be looked-up in a different > context):=20 > - the data link does not indicate that (otherwise the top=20 > label would be > upstream-allocated) > - the terminated label CANNOT be used as the context label.=20 > It must be processed > regardless of its position in the label stack. >=20 > Aside:=20 > Early LSRs have used a physical loopback interface for=20 > multiple label look-ups. > I.e., when they received a labeled packet with two or more=20 > labels in the stack and wanted to look at the 2nd label, they=20 > physically popped the top label and forwarded the packet to a=20 > dedicated looped-back physical interface. The packet received=20 > from that interface would have the former 2nd label as the=20 > top one, and would then process it as any other top label. > Of course, the top label and the original ingress interface=20 > would be lost in this operation. > MPLS (and PW) architecture has been designed to allow this=20 > type of processing. > Modern LSRs do not usually use a physical loopback interface=20 > for multiple label lookups, but neither do they prevent their=20 > downstream peers from using it as long as the downstream=20 > label allocation scheme is used.=20 >=20 > Hopefully this clarification will be helpful. >=20 > Regards, > Sasha >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of Maarten Vissers > > Sent: Monday, February 08, 2010 9:30 AM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > data-plane-draft' > >=20 > > Sasha, > >=20 > > If I am thinking of a set of p2mp PWs and/or service LSPs=20 > carried in a=20 > > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up=20 > prior to=20 > > service requests, and uses downstream allocated labels, whereas the=20 > > p2mp PWs/serviceLSPs must use upstream allocated labels. The=20 > > intermediate p2mp LSP can use downstream allocated labels. > >=20 > > This implies that I have the top two labels with downstream=20 > allocated=20 > > and the bottom label with upstream allocated. Correct? > >=20 > > Regards, > > Maarten > >=20 > >=20 > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: zaterdag 6 februari 2010 13:56 > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > >=20 > > Resending as plain text due to size limitations. > >=20 > > Regards, > > Sasha > >=20 > >=20 > >=20 > > From: Alexander Vainshtein > > Sent: Saturday, February 06, 2010 11:14 AM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > >=20 > >=20 > > Maarten, Lieven and all, > > On the second thought, it seems that if the data link code point=20 > > indicates the downstream label allocation scheme for the top label,=20 > > then the next label MUST be downstream-allocated as well. > >=20 > > This is because processing of this label, as defined in=20 > 3031, MUST NOT=20 > > depend on any labels that have been present above it in the label=20 > > stack and terminated (popped) by the LSR that looks it up. > >=20 > > The relevant text in Section 3.9 states: > >=20 > > Although, as we shall see, MPLS supports a hierarchy, the=20 > processing=20 > > of a labeled packet is completely independent of the level of=20 > > hierarchy. The processing is always based on the top=20 > label, without=20 > > regard for the > > possibility that some number of other labels may have been=20 > > "above it" in > > the past, or that some number of other labels may be below it at=20 > > present. > > In other words, downstream label allocation scheme does not support=20 > > "context labels" defined in 5331. They are only compatible with the=20 > > upstream label allocation scheme. > > The bottom line: > > If the data link code point indicates downstream label=20 > allocation of=20 > > the top label, then all the labels in the stack MUST be=20 > > downstream-allocated (by the appropriate LSRs) If the data=20 > link code=20 > > point indicates upstream label allocation of the top label,=20 > then both=20 > > upstream-allocated and downstream-allocated labels MAY=20 > appear in the=20 > > stack. In certain situations such a mix can result in undesirable=20 > > behavior. > > Regards, > > Sasha > > =20 > >=20 > >=20 > >=20 > >=20 > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of=20 > > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > > Sent: Friday, February 05, 2010 8:28 PM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > data-plane-draft' > >=20 > >=20 > > Maarten, > > Lots of thanks for an EXCELLENT question. > >=20 > > I do not think I can answer it in full, but the following=20 > > considerations may be useful. > >=20 > > Downstream label allocation scheme is explicitly defined as the=20 > > default in RFC 5331 and 5332. Hence, IMHO, if the code=20 > point of the=20 > > data link defines the top label as downstream-assigned, the router=20 > > terminating this label will treat the next one(s) as=20 > > downstream-assigned - unless it has been explicitly aware that they=20 > > are upstream-assigned. In other words, the LSR terminating the top=20 > > label must explicitly bind it to a context space for=20 > > upstream-allocated ones. > > The primary usage of upstream-allocated labels in MPLS (but not=20 > > necessary in > > MPLS-TP) is MPLS multicast, and the dedicated codepoints=20 > are used in=20 > > conjunction with multicast datalink addresses (or their=20 > analogs as in=20 > > the case of MPLS-in-GRE). This means that, generally speaking, more=20 > > than one router can terminate the top upstream-allocated label and=20 > > look at the next one. And this is only compatible with the upstream=20 > > allocation scheme for the next label. > >=20 > > Does this help? Did I miss something important? > >=20 > > Regards, > > Sasha > >=20 > >=20 > >=20 > > From: Maarten Vissers [maarten.vissers@huawei.com] > > Sent: Friday, February 05, 2010 12:59 PM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > >=20 > >=20 > > Sasha, > >=20 > > There can/will be many labels in the label stack on MPSL-TP=20 > > interfaces. > > Is the Ethernet code point application only to the top of=20 > stack label,=20 > > or to all labels in the stack? > >=20 > > I would expect that the code point only applies to the top of stack=20 > > label and not to the non-top of stack labels; is this correct? > >=20 > > Regards, > > Maarten > >=20 > >=20 > >=20 > >=20 > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein > > Sent: donderdag 4 februari 2010 14:12 > > To: LEVRAU, LIEVEN (LIEVEN) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > >=20 > >=20 > > Lieven, > > Lots of thanks for a prompt response. > >=20 > > IMHO and FWIW the label allocation scheme is not just a=20 > control plane=20 > > issue. > > Please note that, as per RFC 5332, MPLS packets with=20 > > upstream-allocated labels use a different code point on=20 > Ethernet links=20 > > and GRE tunnels. > > To me this is a data plane issue. > >=20 > > What is more, upstream-allocated labels must refer to a certain=20 > > context by the downstream router. And context resolution is part of=20 > > the data plane as well. > >=20 > > Regards, > > Sasha > >=20 > > =20 > > =20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Wednesday, February 03, 2010 9:06 AM > > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci,=20 > > Matthew > > (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Label alloc. Schemes in data-plane-draft' > >=20 > >=20 > >=20 > >=20 > > Hello Shasha > > Changed title from Comments on > > draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in=20 > > data-plane-draft' > >=20 > > In my view - This is a control plane issue and not a data=20 > plane issue.=20 > > How the labels are assigned is outside the scope of the draft. > >=20 > > ./ > > Lieven > > Label Allocation Schemes:=20 > > MPLS recognizes two label allocation schemes, each with its=20 > own area=20 > > of > > applicability:=20 > > Downstream label allocation as per RFC 3031 Upstream label=20 > allocation=20 > > as per RFC 5331 IMHO the label allocation scheme is=20 > essentially a data=20 > > plane issue: > > Label allocation scheme is reflected in the Ethertype in=20 > the case of=20 > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc.=20 > > It is not clear to me, which label allocation schemes can=20 > be used in=20 > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we use=20 > > upstream label allocation This issue is closely related to proposed=20 > > usage of a well-known multicast MAC destination address for=20 > P2P LSPs)=20 > > Status of this topic in the -00 draft: requires clarification > >=20 > >=20 > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=20 > On Behalf=20 > > Of Alexander Vainshtein > > Sent: 01 February 2010 18:00 > > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > >=20 > > Stewart, Dan, Matthew and all, > > First of all I'd like to say that the need for clear-cut=20 > definition of=20 > > the MPLS-TP data plane architecture has been quite clear to me. > > The draft is clearly the necessary first step in the right=20 > direction,=20 > > and I thank you for producing it. > >=20 > > That said, I think that quite a few issues have been left=20 > undecided in=20 > > this -00 version of the draft. > >=20 > > I will make a (hopefully, short) list of items that IMHO require=20 > > additional clarification and, eventually, codification. > >=20 > > LSP Merge:=20 > > In MPLS, nothing prevents LSPs from merging at some point:=20 > > One well-known usage of LSP merge is FRR PHP can be considered as a=20 > > special case of LSP merge One of the often repeated mantras=20 > of MPLS-TP=20 > > is that its LSPs cannot be merge. > > It is not clear (at least, to me):=20 > > Whether this limitation has to be respected at the data=20 > plane level,=20 > > and if yes, then how Whether it means that FRR cannot be used in=20 > > MPLS-TP Status of this topic in the -00 draft: not mentioned at all=20 > > Per-Interface Label Space: > > The draft states that per-interface label space MAY be used=20 > in MPLS-TP=20 > > AFAIK, in MPLS: > > This referred to data links (including bundles, e.g., produced by=20 > > LAG). As a consequence, the number of label contexts has been=20 > > reasonably low This has been only allowed on P2P links One of the=20 > > problems with MPLS-TP is that in many cases it does not=20 > differentiate=20 > > between data links and lower layer LSPs (see also my notes=20 > regarding=20 > > Sections). As a consequence, it is not clear (to me) whether=20 > > per-interface label space may become a label space per lower layer=20 > > LSP. (To the best of my understanding this is explicitly=20 > prohibited by=20 > > RFC 3031). > > Status of this topic in the -00 draft: requires clarification,=20 > > preferably aligned with RFC 3031. > > Sections:=20 > > The draft states that Sections could be data links (level 0 > > sections) or > > LSPs with N labels (level N Sections).=20 > > The following is not clear to me:=20 > > Can LAN-like data links be Sections in MPLS-TP (The Editors=20 > ask this=20 > > question themselves when they discuss MAC addresses) Which types of=20 > > LSPs can be Sections (e.g., can a P2P unidirectional LSP be=20 > a Section?=20 > > Can an associated bi-directional LSP be a section? etc.). > > If associated bi-directional LSPs can be Sections, can we treat the=20 > > LSPs rumming over these Sections as co-routed bidirectional? > > Per-data link (interface) label space is supported in MPLS.=20 > > Does MPLS-Tp > > allow per-Section label space (see above)?=20 > > Status of this topic in the -00 draft: requires clarification, one=20 > > aspect already recognized as such by the Editors. IMHO and FWIW=20 > > preferred resolution would be to equate Sections with data=20 > links Label=20 > > Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its=20 > own area=20 > > of > > applicability:=20 > > Downstream label allocation as per RFC 3031 Upstream label=20 > allocation=20 > > as per RFC 5331 IMHO the label allocation scheme is=20 > essentially a data=20 > > plane issue: > > Label allocation scheme is reflected in the Ethertype in=20 > the case of=20 > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc.=20 > > It is not clear to me, which label allocation schemes can=20 > be used in=20 > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we use=20 > > upstream label allocation This issue is closely related to proposed=20 > > usage of a well-known multicast MAC destination address for=20 > P2P LSPs)=20 > > Status of this topic in the -00 draft: requires clarification MAC=20 > > addresses on Ethernet data links in MPLS-TP: > > The draft discusses this topic, and proposes using a well-known=20 > > multicast DA in Ethernet encapsulations for for P2P LSPs=20 > IMHO and FWIW=20 > > if LAN interfaces are allowed in MPLS-TP, usage of well-known=20 > > multicast DA is not compatible with the downstream label allocation=20 > > scheme. > > Status of this topic in the -00-draft: partially recognized by the=20 > > Editors, there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > >=20 > > Regards, > > Sasha=3D > >=20 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > =3D >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From Alexander.Vainshtein@ecitele.com Mon Feb 8 04:37: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 063643A7393; Mon, 8 Feb 2010 04:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 9N4Q0bv5W6Xg; Mon, 8 Feb 2010 04:37:37 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id F014F3A738F; Mon, 8 Feb 2010 04:37:34 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-ca-4b70046814db Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id BA.D0.18464.964007B4; Mon, 8 Feb 2010 14:32:41 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 8 Feb 2010 14:38:35 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Mon, 8 Feb 2010 14:38:32 +0200 Thread-Topic: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwAAASzWg Message-ID: References: <006d01caa8b7$bde51930$ec7bfea9@china.huawei.com> In-Reply-To: <006d01caa8b7$bde51930$ec7bfea9@china.huawei.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 08 Feb 2010 12:37:40 -0000 Maarten, Lots of thanks for a good example. I assume that you speak about Ethernet "VP" and "VC" you mean PBB (a.k.a. M= AC-in-MAC or802.1ah). If this is correct, then your example illustrates the difference between th= e Ethernet and MPLS data planes. MAC addresses are absolute, and outer MAC address can= provide context for the inner one - by design. MPLS data plane has been designed differently. Whether one should or should= not expect certain limitations, they exist. The difference between an architectural limitation and limitation imposed b= y the (majority of) existing implementations is, of course, important. And things can go any each way: - some things are architecturally possible but not, typically, not used. E.= g., AFAIK, this is the case with L-LSPs which are perfectly OK from the architecture point of view but rarely use= d due to scalability problems. - some others are architecturally disallowed but may be supported by certai= n implementations. We should clearly understand where we stand on each such issue. Regards, Sasha > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, February 08, 2010 2:11 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > Sasha, > > An interesting limitation in the MPLS data plane architecture. > From a transport network perspective one should not expect > such limitation. > > E.g. in OTN I can set up a p2p HO ODU3 connection over which > I carry a p2mp > LO ODU2 connection, which carries up to 8 p2mp ODU0 signals > with e.g. 1GE > clients. > > And in an Ethernet network I can set up a p2p Ethernet VP > connection over > which I carry a p2mp Ethernet VC connection, which carries a > number of p2mp > Ethernet VLANs. > > The fact that both OTN and Ethernet can support the example, > I am wondering > if it is the MPLS data plane architecture that is not > capable, or if it are > the existing MPLS equipment that are not capable? > > Regards, > Maarten > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: maandag 8 februari 2010 9:45 > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > > Maarten, > In short: NOT CORRECT. > The construction you present violates the MPLS data plane > architecture as > defined in 3031. > > The LSR that terminates the outer P2P LSP cannot know that > the next label it > looks-up is upstream-allocated (and hence to be looked-up in > a different > context): > - the data link does not indicate that (otherwise the top > label would be > upstream-allocated) > - the terminated label CANNOT be used as the context label. It must be > processed > regardless of its position in the label stack. > > Aside: > Early LSRs have used a physical loopback interface for multiple label > look-ups. > I.e., when they received a labeled packet with two or more > labels in the > stack and wanted to look at the 2nd label, they physically > popped the top > label and forwarded the packet to a dedicated looped-back physical > interface. The packet received from that interface would have > the former 2nd > label as the top one, and would then process it as any other > top label. > Of course, the top label and the original ingress interface > would be lost in > this operation. > MPLS (and PW) architecture has been designed to allow this type of > processing. > Modern LSRs do not usually use a physical loopback interface > for multiple > label lookups, but neither do they prevent their downstream > peers from using > it as long as the downstream label allocation scheme is used. > > Hopefully this clarification will be helpful. > > Regards, > Sasha > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Maarten Vissers > > Sent: Monday, February 08, 2010 9:30 AM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > Sasha, > > > > If I am thinking of a set of p2mp PWs and/or service LSPs > carried in a > > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up > prior to > > service requests, and uses downstream allocated labels, whereas the > > p2mp PWs/serviceLSPs must use upstream allocated labels. The > > intermediate p2mp LSP can use downstream allocated labels. > > > > This implies that I have the top two labels with downstream > allocated > > and the bottom label with upstream allocated. Correct? > > > > Regards, > > Maarten > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: zaterdag 6 februari 2010 13:56 > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > Resending as plain text due to size limitations. > > > > Regards, > > Sasha > > > > > > > > From: Alexander Vainshtein > > Sent: Saturday, February 06, 2010 11:14 AM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Maarten, Lieven and all, > > On the second thought, it seems that if the data link code point > > indicates the downstream label allocation scheme for the top label, > > then the next label MUST be downstream-allocated as well. > > > > This is because processing of this label, as defined in > 3031, MUST NOT > > depend on any labels that have been present above it in the label > > stack and terminated (popped) by the LSR that looks it up. > > > > The relevant text in Section 3.9 states: > > > > Although, as we shall see, MPLS supports a hierarchy, the > processing > > of a labeled packet is completely independent of the level of > > hierarchy. The processing is always based on the top > label, without > > regard for the > > possibility that some number of other labels may have been > > "above it" in > > the past, or that some number of other labels may be below it at > > present. > > In other words, downstream label allocation scheme does not support > > "context labels" defined in 5331. They are only compatible with the > > upstream label allocation scheme. > > The bottom line: > > If the data link code point indicates downstream label > allocation of > > the top label, then all the labels in the stack MUST be > > downstream-allocated (by the appropriate LSRs) If the data > link code > > point indicates upstream label allocation of the top label, > then both > > upstream-allocated and downstream-allocated labels MAY > appear in the > > stack. In certain situations such a mix can result in undesirable > > behavior. > > Regards, > > Sasha > > > > > > > > > > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > > Sent: Friday, February 05, 2010 8:28 PM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > > > Maarten, > > Lots of thanks for an EXCELLENT question. > > > > I do not think I can answer it in full, but the following > > considerations may be useful. > > > > Downstream label allocation scheme is explicitly defined as the > > default in RFC 5331 and 5332. Hence, IMHO, if the code > point of the > > data link defines the top label as downstream-assigned, the router > > terminating this label will treat the next one(s) as > > downstream-assigned - unless it has been explicitly aware that they > > are upstream-assigned. In other words, the LSR terminating the top > > label must explicitly bind it to a context space for > > upstream-allocated ones. > > The primary usage of upstream-allocated labels in MPLS (but not > > necessary in > > MPLS-TP) is MPLS multicast, and the dedicated codepoints > are used in > > conjunction with multicast datalink addresses (or their > analogs as in > > the case of MPLS-in-GRE). This means that, generally speaking, more > > than one router can terminate the top upstream-allocated label and > > look at the next one. And this is only compatible with the upstream > > allocation scheme for the next label. > > > > Does this help? Did I miss something important? > > > > Regards, > > Sasha > > > > > > > > From: Maarten Vissers [maarten.vissers@huawei.com] > > Sent: Friday, February 05, 2010 12:59 PM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Sasha, > > > > There can/will be many labels in the label stack on MPSL-TP > > interfaces. > > Is the Ethernet code point application only to the top of > stack label, > > or to all labels in the stack? > > > > I would expect that the code point only applies to the top of stack > > label and not to the non-top of stack labels; is this correct? > > > > Regards, > > Maarten > > > > > > > > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein > > Sent: donderdag 4 februari 2010 14:12 > > To: LEVRAU, LIEVEN (LIEVEN) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Lieven, > > Lots of thanks for a prompt response. > > > > IMHO and FWIW the label allocation scheme is not just a > > control plane issue. > > Please note that, as per RFC 5332, MPLS packets with > > upstream-allocated > > labels use a different code point on Ethernet links and GRE tunnels. > > To me this is a data plane issue. > > > > What is more, upstream-allocated labels must refer to a > > certain context by > > the downstream router. And context resolution is part of the > > data plane as > > well. > > > > Regards, > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Wednesday, February 03, 2010 9:06 AM > > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; > > Bocci, Matthew > > (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Label alloc. Schemes in data-plane-draft' > > > > > > > > > > Hello Shasha > > Changed title from Comments on > > draft-fbb-mpls-tp-data-plane-00 -> Label > > alloc. Schemes in data-plane-draft' > > > > In my view - This is a control plane issue and not a data > > plane issue. How > > the labels are assigned is outside the scope of the draft. > > > > ./ > > Lieven > > Label Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its > > own area of > > applicability: > > Downstream label allocation as per RFC 3031 > > Upstream label allocation as per RFC 5331 > > IMHO the label allocation scheme is essentially a data plane issue: > > Label allocation scheme is reflected in the Ethertype in the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we > > use upstream > > label allocation > > This issue is closely related to proposed usage of a > > well-known multicast > > MAC destination address for P2P LSPs) > > Status of this topic in the -00 draft: requires clarification > > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of > > Alexander Vainshtein > > Sent: 01 February 2010 18:00 > > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > > > > Stewart, Dan, Matthew and all, > > First of all I'd like to say that the need for clear-cut > > definition of the > > MPLS-TP data plane architecture has been quite clear to me. > > The draft is clearly the necessary first step in the right > > direction, and I > > thank you for producing it. > > > > That said, I think that quite a few issues have been left > > undecided in this > > -00 version of the draft. > > > > I will make a (hopefully, short) list of items that IMHO > > require additional > > clarification and, eventually, codification. > > > > LSP Merge: > > In MPLS, nothing prevents LSPs from merging at some point: > > One well-known usage of LSP merge is FRR > > PHP can be considered as a special case of LSP merge > > One of the often repeated mantras of MPLS-TP is that its LSPs > > cannot be > > merge. > > It is not clear (at least, to me): > > Whether this limitation has to be respected at the data plane > > level, and if > > yes, then how > > Whether it means that FRR cannot be used in MPLS-TP > > Status of this topic in the -00 draft: not mentioned at all > > Per-Interface Label Space: > > The draft states that per-interface label space MAY be used > > in MPLS-TP > > AFAIK, in MPLS: > > This referred to data links (including bundles, e.g., > > produced by LAG). As a > > consequence, the number of label contexts has been reasonably low > > This has been only allowed on P2P links > > One of the problems with MPLS-TP is that in many cases it does not > > differentiate between data links and lower layer LSPs (see > > also my notes > > regarding Sections). As a consequence, it is not clear (to > me) whether > > per-interface label space may become a label space per lower > > layer LSP. (To > > the best of my understanding this is explicitly prohibited by > > RFC 3031). > > Status of this topic in the -00 draft: requires > > clarification, preferably > > aligned with RFC 3031. > > Sections: > > The draft states that Sections could be data links (level 0 > > sections) or > > LSPs with N labels (level N Sections). > > The following is not clear to me: > > Can LAN-like data links be Sections in MPLS-TP (The Editors ask this > > question themselves when they discuss MAC addresses) > > Which types of LSPs can be Sections (e.g., can a P2P > > unidirectional LSP be a > > Section? Can an associated bi-directional LSP be a section? etc.). > > If associated bi-directional LSPs can be Sections, can we > > treat the LSPs > > rumming over these Sections as co-routed bidirectional? > > Per-data link (interface) label space is supported in MPLS. > > Does MPLS-Tp > > allow per-Section label space (see above)? > > Status of this topic in the -00 draft: requires > > clarification, one aspect > > already recognized as such by the Editors. IMHO and FWIW preferred > > resolution would be to equate Sections with data links > > Label Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its > > own area of > > applicability: > > Downstream label allocation as per RFC 3031 > > Upstream label allocation as per RFC 5331 > > IMHO the label allocation scheme is essentially a data plane issue: > > Label allocation scheme is reflected in the Ethertype in the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we > > use upstream > > label allocation > > This issue is closely related to proposed usage of a > > well-known multicast > > MAC destination address for P2P LSPs) > > Status of this topic in the -00 draft: requires clarification > > MAC addresses on Ethernet data links in MPLS-TP: > > The draft discusses this topic, and proposes using a > > well-known multicast DA > > in Ethernet encapsulations for for P2P LSPs > > IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage > > of well-known > > multicast DA is not compatible with the downstream label > > allocation scheme. > > Status of this topic in the -00-draft: partially recognized > > by the Editors, > > there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > > > > Regards, > > Sasha=3D > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > =3D > > From maarten.vissers@huawei.com Mon Feb 8 22:50: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 0D8463A752F; Mon, 8 Feb 2010 22:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 WqAlAIxlYgSF; Mon, 8 Feb 2010 22:50:08 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6D4183A6FF9; Mon, 8 Feb 2010 22:50: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 <0KXK0046RB12F3@szxga03-in.huawei.com>; Tue, 09 Feb 2010 14:51:02 +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 <0KXK00G57B11UW@szxga03-in.huawei.com>; Tue, 09 Feb 2010 14:51:01 +0800 (CST) Received: from M00900002 ([81.253.41.4]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXK00JO6B0RR4@szxml02-in.huawei.com>; Tue, 09 Feb 2010 14:51:01 +0800 (CST) Date: Tue, 09 Feb 2010 07:50:38 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' Message-id: <000001caa954$3734bab0$ec7bfea9@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwAAASzWgACaZPEA= Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 09 Feb 2010 06:50:10 -0000 Sasha, See inline.. -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: maandag 8 februari 2010 13:39 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' Maarten, Lots of thanks for a good example. I assume that you speak about Ethernet "VP" and "VC" you mean PBB (a.k.a. MAC-in-MAC or802.1ah). If this is correct, then your example illustrates the difference between the Ethernet and MPLS data planes. MAC addresses are absolute, and outer MAC address can provide context for the inner one - by design. [maarten] I am not speaking of PBB. I am referring to deployment of stacked Ethernet VLANs in operator networks today. Operators require from their vendors that the equipment can insert up to 2 or 3 VLAN Tags onto every incoming VLAN signal. Some operators give those additional VLAN Tags the 81-00 EtherType value, some give it the 88-a8 EtherType value, some give it proprietary values (e.g. 91-00, 91-01, 91-02). Operators can do this because in their networks they use NMS and/or GMPLS to set up their internal VLAN connections (Ethernet VC connections, Ethernet VP connections, Ethernet VS connections). Because of this, there is no use of the 802.1Q control plane protocols that prevented the unrestricted stacking of VLANs, and stacking is no longer a problem in Ethernet networks. Furthermore, those operators run those stacked VLANs within their own networks; i.e. on their Intra Domain Interfaces (IaDIs), and on those interfaces operators have full control of the frame formats. Vendors are more then happy to support the opertor controlled configuration of the TPID fields in their VLAN Tag headers to enable this stacked VLAN approach. [maarten] This stacked VLAN based Ethernet data plane is as such very similar to the MPLS data plane... Ethernet uses stacked VLAN Tag headers, MPLS uses stack label stack entry headers... MPLS data plane has been designed differently. Whether one should or should not expect certain limitations, they exist. The difference between an architectural limitation and limitation imposed by the (majority of) existing implementations is, of course, important. And things can go any each way: - some things are architecturally possible but not, typically, not used. E.g., AFAIK, this is the case with L-LSPs which are perfectly OK from the architecture point of view but rarely used due to scalability problems. - some others are architecturally disallowed but may be supported by certain implementations. We should clearly understand where we stand on each such issue. [maarten] to me it seems that the limitation desribed by you of the MPLS data plane is not a fundamental limitation, as it is not present in the OTN and Ethernet cases. So important in my opinion to understand is if this limitation can be removed from the MPLS data plane. Regards, Maarten Regards, Sasha > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, February 08, 2010 2:11 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > Sasha, > > An interesting limitation in the MPLS data plane architecture. > From a transport network perspective one should not expect such > limitation. > > E.g. in OTN I can set up a p2p HO ODU3 connection over which I carry a > p2mp LO ODU2 connection, which carries up to 8 p2mp ODU0 signals with > e.g. 1GE clients. > > And in an Ethernet network I can set up a p2p Ethernet VP connection > over which I carry a p2mp Ethernet VC connection, which carries a > number of p2mp Ethernet VLANs. > > The fact that both OTN and Ethernet can support the example, I am > wondering if it is the MPLS data plane architecture that is not > capable, or if it are the existing MPLS equipment that are not > capable? > > Regards, > Maarten > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: maandag 8 februari 2010 9:45 > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > > Maarten, > In short: NOT CORRECT. > The construction you present violates the MPLS data plane architecture > as defined in 3031. > > The LSR that terminates the outer P2P LSP cannot know that the next > label it looks-up is upstream-allocated (and hence to be looked-up in > a different > context): > - the data link does not indicate that (otherwise the top label would > be > upstream-allocated) > - the terminated label CANNOT be used as the context label. It must be > processed > regardless of its position in the label stack. > > Aside: > Early LSRs have used a physical loopback interface for multiple label > look-ups. > I.e., when they received a labeled packet with two or more labels in > the stack and wanted to look at the 2nd label, they physically popped > the top label and forwarded the packet to a dedicated looped-back > physical interface. The packet received from that interface would have > the former 2nd label as the top one, and would then process it as any > other top label. > Of course, the top label and the original ingress interface would be > lost in this operation. > MPLS (and PW) architecture has been designed to allow this type of > processing. > Modern LSRs do not usually use a physical loopback interface for > multiple label lookups, but neither do they prevent their downstream > peers from using it as long as the downstream label allocation scheme > is used. > > Hopefully this clarification will be helpful. > > Regards, > Sasha > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Maarten Vissers > > Sent: Monday, February 08, 2010 9:30 AM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > Sasha, > > > > If I am thinking of a set of p2mp PWs and/or service LSPs > carried in a > > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up > prior to > > service requests, and uses downstream allocated labels, whereas the > > p2mp PWs/serviceLSPs must use upstream allocated labels. The > > intermediate p2mp LSP can use downstream allocated labels. > > > > This implies that I have the top two labels with downstream > allocated > > and the bottom label with upstream allocated. Correct? > > > > Regards, > > Maarten > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: zaterdag 6 februari 2010 13:56 > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > Resending as plain text due to size limitations. > > > > Regards, > > Sasha > > > > > > > > From: Alexander Vainshtein > > Sent: Saturday, February 06, 2010 11:14 AM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Maarten, Lieven and all, > > On the second thought, it seems that if the data link code point > > indicates the downstream label allocation scheme for the top label, > > then the next label MUST be downstream-allocated as well. > > > > This is because processing of this label, as defined in > 3031, MUST NOT > > depend on any labels that have been present above it in the label > > stack and terminated (popped) by the LSR that looks it up. > > > > The relevant text in Section 3.9 states: > > > > Although, as we shall see, MPLS supports a hierarchy, the > processing > > of a labeled packet is completely independent of the level of > > hierarchy. The processing is always based on the top > label, without > > regard for the > > possibility that some number of other labels may have been > > "above it" in > > the past, or that some number of other labels may be below it at > > present. > > In other words, downstream label allocation scheme does not support > > "context labels" defined in 5331. They are only compatible with the > > upstream label allocation scheme. > > The bottom line: > > If the data link code point indicates downstream label > allocation of > > the top label, then all the labels in the stack MUST be > > downstream-allocated (by the appropriate LSRs) If the data > link code > > point indicates upstream label allocation of the top label, > then both > > upstream-allocated and downstream-allocated labels MAY > appear in the > > stack. In certain situations such a mix can result in undesirable > > behavior. > > Regards, > > Sasha > > > > > > > > > > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > > Sent: Friday, February 05, 2010 8:28 PM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > > > Maarten, > > Lots of thanks for an EXCELLENT question. > > > > I do not think I can answer it in full, but the following > > considerations may be useful. > > > > Downstream label allocation scheme is explicitly defined as the > > default in RFC 5331 and 5332. Hence, IMHO, if the code > point of the > > data link defines the top label as downstream-assigned, the router > > terminating this label will treat the next one(s) as > > downstream-assigned - unless it has been explicitly aware that they > > are upstream-assigned. In other words, the LSR terminating the top > > label must explicitly bind it to a context space for > > upstream-allocated ones. > > The primary usage of upstream-allocated labels in MPLS (but not > > necessary in > > MPLS-TP) is MPLS multicast, and the dedicated codepoints > are used in > > conjunction with multicast datalink addresses (or their > analogs as in > > the case of MPLS-in-GRE). This means that, generally speaking, more > > than one router can terminate the top upstream-allocated label and > > look at the next one. And this is only compatible with the upstream > > allocation scheme for the next label. > > > > Does this help? Did I miss something important? > > > > Regards, > > Sasha > > > > > > > > From: Maarten Vissers [maarten.vissers@huawei.com] > > Sent: Friday, February 05, 2010 12:59 PM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Sasha, > > > > There can/will be many labels in the label stack on MPSL-TP > > interfaces. > > Is the Ethernet code point application only to the top of > stack label, > > or to all labels in the stack? > > > > I would expect that the code point only applies to the top of stack > > label and not to the non-top of stack labels; is this correct? > > > > Regards, > > Maarten > > > > > > > > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein > > Sent: donderdag 4 februari 2010 14:12 > > To: LEVRAU, LIEVEN (LIEVEN) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Lieven, > > Lots of thanks for a prompt response. > > > > IMHO and FWIW the label allocation scheme is not just a control > > plane issue. > > Please note that, as per RFC 5332, MPLS packets with > > upstream-allocated labels use a different code point on Ethernet > > links and GRE tunnels. > > To me this is a data plane issue. > > > > What is more, upstream-allocated labels must refer to a certain > > context by the downstream router. And context resolution is part of > > the data plane as well. > > > > Regards, > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Wednesday, February 03, 2010 9:06 AM > > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, > > Matthew > > (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Label alloc. Schemes in data-plane-draft' > > > > > > > > > > Hello Shasha > > Changed title from Comments on > > draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in > > data-plane-draft' > > > > In my view - This is a control plane issue and not a data plane > > issue. How the labels are assigned is outside the scope of the > > draft. > > > > ./ > > Lieven > > Label Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its own area > > of > > applicability: > > Downstream label allocation as per RFC 3031 Upstream label > > allocation as per RFC 5331 IMHO the label allocation scheme is > > essentially a data plane issue: > > Label allocation scheme is reflected in the Ethertype in the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we use > > upstream label allocation This issue is closely related to proposed > > usage of a well-known multicast MAC destination address for P2P > > LSPs) Status of this topic in the -00 draft: requires clarification > > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of > > Alexander Vainshtein > > Sent: 01 February 2010 18:00 > > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > > > > Stewart, Dan, Matthew and all, > > First of all I'd like to say that the need for clear-cut > > definition of the > > MPLS-TP data plane architecture has been quite clear to me. > > The draft is clearly the necessary first step in the right > > direction, and I > > thank you for producing it. > > > > That said, I think that quite a few issues have been left > > undecided in this > > -00 version of the draft. > > > > I will make a (hopefully, short) list of items that IMHO > > require additional > > clarification and, eventually, codification. > > > > LSP Merge: > > In MPLS, nothing prevents LSPs from merging at some point: > > One well-known usage of LSP merge is FRR > > PHP can be considered as a special case of LSP merge > > One of the often repeated mantras of MPLS-TP is that its LSPs > > cannot be > > merge. > > It is not clear (at least, to me): > > Whether this limitation has to be respected at the data plane > > level, and if > > yes, then how > > Whether it means that FRR cannot be used in MPLS-TP > > Status of this topic in the -00 draft: not mentioned at all > > Per-Interface Label Space: > > The draft states that per-interface label space MAY be used > > in MPLS-TP > > AFAIK, in MPLS: > > This referred to data links (including bundles, e.g., > > produced by LAG). As a > > consequence, the number of label contexts has been reasonably low > > This has been only allowed on P2P links > > One of the problems with MPLS-TP is that in many cases it does not > > differentiate between data links and lower layer LSPs (see > > also my notes > > regarding Sections). As a consequence, it is not clear (to > me) whether > > per-interface label space may become a label space per lower > > layer LSP. (To > > the best of my understanding this is explicitly prohibited by > > RFC 3031). > > Status of this topic in the -00 draft: requires > > clarification, preferably > > aligned with RFC 3031. > > Sections: > > The draft states that Sections could be data links (level 0 > > sections) or > > LSPs with N labels (level N Sections). > > The following is not clear to me: > > Can LAN-like data links be Sections in MPLS-TP (The Editors ask this > > question themselves when they discuss MAC addresses) > > Which types of LSPs can be Sections (e.g., can a P2P > > unidirectional LSP be a > > Section? Can an associated bi-directional LSP be a section? etc.). > > If associated bi-directional LSPs can be Sections, can we > > treat the LSPs > > rumming over these Sections as co-routed bidirectional? > > Per-data link (interface) label space is supported in MPLS. > > Does MPLS-Tp > > allow per-Section label space (see above)? > > Status of this topic in the -00 draft: requires > > clarification, one aspect > > already recognized as such by the Editors. IMHO and FWIW preferred > > resolution would be to equate Sections with data links > > Label Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its > > own area of > > applicability: > > Downstream label allocation as per RFC 3031 > > Upstream label allocation as per RFC 5331 > > IMHO the label allocation scheme is essentially a data plane issue: > > Label allocation scheme is reflected in the Ethertype in the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we > > use upstream > > label allocation > > This issue is closely related to proposed usage of a > > well-known multicast > > MAC destination address for P2P LSPs) > > Status of this topic in the -00 draft: requires clarification > > MAC addresses on Ethernet data links in MPLS-TP: > > The draft discusses this topic, and proposes using a > > well-known multicast DA > > in Ethernet encapsulations for for P2P LSPs > > IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage > > of well-known > > multicast DA is not compatible with the downstream label > > allocation scheme. > > Status of this topic in the -00-draft: partially recognized > > by the Editors, > > there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > > > > Regards, > > Sasha= > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > = > > From maarten.vissers@huawei.com Mon Feb 8 22:58: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 92F3028C1C0; Mon, 8 Feb 2010 22:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 DTwelEcB7vpg; Mon, 8 Feb 2010 22:58:02 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CD37C28C10F; Mon, 8 Feb 2010 22:58:01 -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 <0KXK00H1YBEHOJ@szxga04-in.huawei.com>; Tue, 09 Feb 2010 14:59:05 +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 <0KXK007VWBEHHR@szxga04-in.huawei.com>; Tue, 09 Feb 2010 14:59:05 +0800 (CST) Received: from M00900002 ([81.253.41.4]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXK00BVVBE9NJ@szxml01-in.huawei.com>; Tue, 09 Feb 2010 14:59:05 +0800 (CST) Date: Tue, 09 Feb 2010 07:58:48 +0100 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C05952566@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com Message-id: <000101caa955$57dc2540$ec7bfea9@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwAAASiRAACcR5YA= Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 09 Feb 2010 06:58:04 -0000 Neil, The internet drafts and RFCs assocaited with MPLS-TP are describing a tool set. Elements of this tool set can be used to construct a true packet transport network. It seems that such construction is outside the scope of IETF 9see the reactions to my proposals to add construction descriptions to the MPLS-TP framework). This implies that each operator is obliged to define its own packet transport network construct using the appropriate elements of the mpls-tp toolset and combine those with elements from other technologies, e.g. Ethernet and OTN. My recommendation to you is to define with your colleagues a BT packet transport network construct. My recommendation would be to use an Ethernet VC based transport service layer that supports all customer services and combine this with MPLS-TP VP, Ethernet VP and OTN VP based transport path layers. Manage it by means of NMS and GMPLS and you have an **excellent** packet transport network. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: maandag 8 februari 2010 13:23 To: maarten.vissers@huawei.com; Alexander.Vainshtein@ecitele.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] [mpls] Label alloc. Schemes in data-plane-draft' Maarten, As I remarked in my last mail to Sasha, I am not sure MPLS-TP will be delivering a transport network solution. It *could* do this (as CCAMPs folks have proved with GMPLS) but here it is a conscious choice not to do this....and the decisions that are being taken cannot appeal to technical naivety IMO. The difficulty I can see is that MPLS-TP is trying to be seen as a transport network whilst still retaining certain behaviours from MPLS that are not behaviours of a transport network. It's a pity IMO but it is an outcome I could see happening. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 08 February 2010 12:11 > To: 'Alexander Vainshtein' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [mpls] Label alloc. Schemes in > data-plane-draft' > > Sasha, > > An interesting limitation in the MPLS data plane architecture. > From a transport network perspective one should not expect such > limitation. > > E.g. in OTN I can set up a p2p HO ODU3 connection over which I carry a > p2mp LO ODU2 connection, which carries up to 8 p2mp ODU0 signals with > e.g. 1GE clients. > > And in an Ethernet network I can set up a p2p Ethernet VP connection > over which I carry a p2mp Ethernet VC connection, which carries a > number of p2mp Ethernet VLANs. > > The fact that both OTN and Ethernet can support the example, I am > wondering if it is the MPLS data plane architecture that is not > capable, or if it are the existing MPLS equipment that are not > capable? > > Regards, > Maarten > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: maandag 8 februari 2010 9:45 > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in > data-plane-draft' > > > Maarten, > In short: NOT CORRECT. > The construction you present violates the MPLS data plane architecture > as defined in 3031. > > The LSR that terminates the outer P2P LSP cannot know that the next > label it looks-up is upstream-allocated (and hence to be looked-up in > a different > context): > - the data link does not indicate that (otherwise the top label would > be > upstream-allocated) > - the terminated label CANNOT be used as the context label. > It must be processed > regardless of its position in the label stack. > > Aside: > Early LSRs have used a physical loopback interface for multiple label > look-ups. > I.e., when they received a labeled packet with two or more labels in > the stack and wanted to look at the 2nd label, they physically popped > the top label and forwarded the packet to a dedicated looped-back > physical interface. The packet received from that interface would have > the former 2nd label as the top one, and would then process it as any > other top label. > Of course, the top label and the original ingress interface would be > lost in this operation. > MPLS (and PW) architecture has been designed to allow this type of > processing. > Modern LSRs do not usually use a physical loopback interface for > multiple label lookups, but neither do they prevent their downstream > peers from using it as long as the downstream label allocation scheme > is used. > > Hopefully this clarification will be helpful. > > Regards, > Sasha > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Maarten Vissers > > Sent: Monday, February 08, 2010 9:30 AM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > Sasha, > > > > If I am thinking of a set of p2mp PWs and/or service LSPs > carried in a > > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up > prior to > > service requests, and uses downstream allocated labels, whereas the > > p2mp PWs/serviceLSPs must use upstream allocated labels. The > > intermediate p2mp LSP can use downstream allocated labels. > > > > This implies that I have the top two labels with downstream > allocated > > and the bottom label with upstream allocated. Correct? > > > > Regards, > > Maarten > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: zaterdag 6 februari 2010 13:56 > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > Resending as plain text due to size limitations. > > > > Regards, > > Sasha > > > > > > > > From: Alexander Vainshtein > > Sent: Saturday, February 06, 2010 11:14 AM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Maarten, Lieven and all, > > On the second thought, it seems that if the data link code point > > indicates the downstream label allocation scheme for the top label, > > then the next label MUST be downstream-allocated as well. > > > > This is because processing of this label, as defined in > 3031, MUST NOT > > depend on any labels that have been present above it in the label > > stack and terminated (popped) by the LSR that looks it up. > > > > The relevant text in Section 3.9 states: > > > > Although, as we shall see, MPLS supports a hierarchy, the > processing > > of a labeled packet is completely independent of the level of > > hierarchy. The processing is always based on the top > label, without > > regard for the > > possibility that some number of other labels may have been > > "above it" in > > the past, or that some number of other labels may be below it at > > present. > > In other words, downstream label allocation scheme does not support > > "context labels" defined in 5331. They are only compatible with the > > upstream label allocation scheme. > > The bottom line: > > If the data link code point indicates downstream label > allocation of > > the top label, then all the labels in the stack MUST be > > downstream-allocated (by the appropriate LSRs) If the data > link code > > point indicates upstream label allocation of the top label, > then both > > upstream-allocated and downstream-allocated labels MAY > appear in the > > stack. In certain situations such a mix can result in undesirable > > behavior. > > Regards, > > Sasha > > > > > > > > > > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > > Sent: Friday, February 05, 2010 8:28 PM > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in > > data-plane-draft' > > > > > > Maarten, > > Lots of thanks for an EXCELLENT question. > > > > I do not think I can answer it in full, but the following > > considerations may be useful. > > > > Downstream label allocation scheme is explicitly defined as the > > default in RFC 5331 and 5332. Hence, IMHO, if the code > point of the > > data link defines the top label as downstream-assigned, the router > > terminating this label will treat the next one(s) as > > downstream-assigned - unless it has been explicitly aware that they > > are upstream-assigned. In other words, the LSR terminating the top > > label must explicitly bind it to a context space for > > upstream-allocated ones. > > The primary usage of upstream-allocated labels in MPLS (but not > > necessary in > > MPLS-TP) is MPLS multicast, and the dedicated codepoints > are used in > > conjunction with multicast datalink addresses (or their > analogs as in > > the case of MPLS-in-GRE). This means that, generally speaking, more > > than one router can terminate the top upstream-allocated label and > > look at the next one. And this is only compatible with the upstream > > allocation scheme for the next label. > > > > Does this help? Did I miss something important? > > > > Regards, > > Sasha > > > > > > > > From: Maarten Vissers [maarten.vissers@huawei.com] > > Sent: Friday, February 05, 2010 12:59 PM > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Sasha, > > > > There can/will be many labels in the label stack on MPSL-TP > > interfaces. > > Is the Ethernet code point application only to the top of > stack label, > > or to all labels in the stack? > > > > I would expect that the code point only applies to the top of stack > > label and not to the non-top of stack labels; is this correct? > > > > Regards, > > Maarten > > > > > > > > > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander Vainshtein > > Sent: donderdag 4 februari 2010 14:12 > > To: LEVRAU, LIEVEN (LIEVEN) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Lieven, > > Lots of thanks for a prompt response. > > > > IMHO and FWIW the label allocation scheme is not just a > control plane > > issue. > > Please note that, as per RFC 5332, MPLS packets with > > upstream-allocated labels use a different code point on > Ethernet links > > and GRE tunnels. > > To me this is a data plane issue. > > > > What is more, upstream-allocated labels must refer to a certain > > context by the downstream router. And context resolution is part of > > the data plane as well. > > > > Regards, > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: LEVRAU, LIEVEN (LIEVEN) > > [mailto:lieven.levrau@alcatel-lucent.com] > > Sent: Wednesday, February 03, 2010 9:06 AM > > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci, > > Matthew > > (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: Label alloc. Schemes in data-plane-draft' > > > > > > > > > > Hello Shasha > > Changed title from Comments on > > draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in > > data-plane-draft' > > > > In my view - This is a control plane issue and not a data > plane issue. > > How the labels are assigned is outside the scope of the draft. > > > > ./ > > Lieven > > Label Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its > own area > > of > > applicability: > > Downstream label allocation as per RFC 3031 Upstream label > allocation > > as per RFC 5331 IMHO the label allocation scheme is > essentially a data > > plane issue: > > Label allocation scheme is reflected in the Ethertype in > the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can > be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we use > > upstream label allocation This issue is closely related to proposed > > usage of a well-known multicast MAC destination address for > P2P LSPs) > > Status of this topic in the -00 draft: requires clarification > > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > > Of Alexander Vainshtein > > Sent: 01 February 2010 18:00 > > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > > > > Stewart, Dan, Matthew and all, > > First of all I'd like to say that the need for clear-cut > definition of > > the MPLS-TP data plane architecture has been quite clear to me. > > The draft is clearly the necessary first step in the right > direction, > > and I thank you for producing it. > > > > That said, I think that quite a few issues have been left > undecided in > > this -00 version of the draft. > > > > I will make a (hopefully, short) list of items that IMHO require > > additional clarification and, eventually, codification. > > > > LSP Merge: > > In MPLS, nothing prevents LSPs from merging at some point: > > One well-known usage of LSP merge is FRR PHP can be considered as a > > special case of LSP merge One of the often repeated mantras > of MPLS-TP > > is that its LSPs cannot be merge. > > It is not clear (at least, to me): > > Whether this limitation has to be respected at the data > plane level, > > and if yes, then how Whether it means that FRR cannot be used in > > MPLS-TP Status of this topic in the -00 draft: not mentioned at all > > Per-Interface Label Space: > > The draft states that per-interface label space MAY be used > in MPLS-TP > > AFAIK, in MPLS: > > This referred to data links (including bundles, e.g., produced by > > LAG). As a consequence, the number of label contexts has been > > reasonably low This has been only allowed on P2P links One of the > > problems with MPLS-TP is that in many cases it does not > differentiate > > between data links and lower layer LSPs (see also my notes > regarding > > Sections). As a consequence, it is not clear (to me) whether > > per-interface label space may become a label space per lower layer > > LSP. (To the best of my understanding this is explicitly > prohibited by > > RFC 3031). > > Status of this topic in the -00 draft: requires clarification, > > preferably aligned with RFC 3031. > > Sections: > > The draft states that Sections could be data links (level 0 > > sections) or > > LSPs with N labels (level N Sections). > > The following is not clear to me: > > Can LAN-like data links be Sections in MPLS-TP (The Editors > ask this > > question themselves when they discuss MAC addresses) Which types of > > LSPs can be Sections (e.g., can a P2P unidirectional LSP be > a Section? > > Can an associated bi-directional LSP be a section? etc.). > > If associated bi-directional LSPs can be Sections, can we treat the > > LSPs rumming over these Sections as co-routed bidirectional? > > Per-data link (interface) label space is supported in MPLS. > > Does MPLS-Tp > > allow per-Section label space (see above)? > > Status of this topic in the -00 draft: requires clarification, one > > aspect already recognized as such by the Editors. IMHO and FWIW > > preferred resolution would be to equate Sections with data > links Label > > Allocation Schemes: > > MPLS recognizes two label allocation schemes, each with its > own area > > of > > applicability: > > Downstream label allocation as per RFC 3031 Upstream label > allocation > > as per RFC 5331 IMHO the label allocation scheme is > essentially a data > > plane issue: > > Label allocation scheme is reflected in the Ethertype in > the case of > > Ethernet encapsulation etc. > > Packets with invalid labels must be silently discarded etc. > > It is not clear to me, which label allocation schemes can > be used in > > MPLS-TP. > > This includes applicability of these schemes, e.g., can we use > > upstream label allocation This issue is closely related to proposed > > usage of a well-known multicast MAC destination address for > P2P LSPs) > > Status of this topic in the -00 draft: requires clarification MAC > > addresses on Ethernet data links in MPLS-TP: > > The draft discusses this topic, and proposes using a well-known > > multicast DA in Ethernet encapsulations for for P2P LSPs > IMHO and FWIW > > if LAN interfaces are allowed in MPLS-TP, usage of well-known > > multicast DA is not compatible with the downstream label allocation > > scheme. > > Status of this topic in the -00-draft: partially recognized by the > > Editors, there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > > > > Regards, > > Sasha= > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > = > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From neil.2.harrison@bt.com Tue Feb 9 01:07: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 1B25428C0DB; Tue, 9 Feb 2010 01:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 3jhanfaDv0+7; Tue, 9 Feb 2010 01:07:21 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 52F9428C0CE; Tue, 9 Feb 2010 01:07:21 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 09:08:25 +0000 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, 9 Feb 2010 09:08:22 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C059A439B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <000001caa954$3734bab0$ec7bfea9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Label alloc. Schemes in data-plane-draft' Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5QA9P+PwAFEGEOAALjI+0AAPFZeNAB8c2QoACEYw6gBY+CzwAAINJyAAB7+UwAAASzWgACaZPEAABHUq4A== From: To: , X-OriginalArrivalTime: 09 Feb 2010 09:08:25.0521 (UTC) FILETIME=[6FC24A10:01CAA967] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft' 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, 09 Feb 2010 09:07:24 -0000 A couple of observations Sasha/Maarten: 1 You are now getting round to discussing the detail that underpins why I believe that the carrying-over of the *arbitrary* sublayering of MPLS into a MPLS-TP transport network is not a sensible thing to do. However, this (S bit sublayering) is such an ingrained behaviour of MPLS that it seems too hard for many to let go of it. The TTL function is a similar issue. And so is the PW's CW 1st nibble ECMP hack (see 2 also below) and its 16 bit Seq No.s......and of course there is the rather larger, and actually far more important, observation that PWs themselves are not required. All we do here is generate a new form of 'MPLS-TP' that: (i) uses a different signalling protocol (which is an unnecessary duplication of function), (ii) promotes a bizarre form of access point addressing of a PW layer network, ie the AII stuff....which IMO is the real reason for the different signalling protocol, and (ii) inserts an essentially redundant 4 octet CW in the DP. All these things are quite unnecessary if MPLS-TP was designed correctly as a transport network. But it is now quite clear that this is not going to be the case. =20 2 If a fundamental architectural behaviour of MPLS is that one forwards only on the outer label and looks no deeper, then can someone explain to me how ECMP sits with this statement? =20 regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 09 February 2010 06:51 > To: 'Alexander Vainshtein' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [mpls] Label alloc. Schemes in=20 > data-plane-draft' >=20 > Sasha, >=20 > See inline..=20 >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: maandag 8 februari 2010 13:39 > To: Maarten Vissers > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in=20 > data-plane-draft' >=20 >=20 > Maarten, > Lots of thanks for a good example. >=20 > I assume that you speak about Ethernet "VP" and "VC" you mean=20 > PBB (a.k.a. > MAC-in-MAC or802.1ah). > If this is correct, then your example illustrates the=20 > difference between the > Ethernet and MPLS data planes. MAC addresses are absolute,=20 > and outer MAC > address can provide context for the inner one - by design. >=20 > [maarten] I am not speaking of PBB. I am referring to=20 > deployment of stacked > Ethernet VLANs in operator networks today. Operators require=20 > from their > vendors that the equipment can insert up to 2 or 3 VLAN Tags=20 > onto every > incoming VLAN signal. Some operators give those additional=20 > VLAN Tags the > 81-00 EtherType value, some give it the 88-a8 EtherType=20 > value, some give it > proprietary values (e.g. 91-00, 91-01, 91-02). Operators can=20 > do this because > in their networks they use NMS and/or GMPLS to set up their=20 > internal VLAN > connections (Ethernet VC connections, Ethernet VP=20 > connections, Ethernet VS > connections). Because of this, there is no use of the 802.1Q=20 > control plane > protocols that prevented the unrestricted stacking of VLANs,=20 > and stacking is > no longer a problem in Ethernet networks. Furthermore, those=20 > operators run > those stacked VLANs within their own networks; i.e. on their=20 > Intra Domain > Interfaces (IaDIs), and on those interfaces operators have=20 > full control of > the frame formats. Vendors are more then happy to support the opertor > controlled configuration of the TPID fields in their VLAN Tag=20 > headers to > enable this stacked VLAN approach. >=20 > [maarten] This stacked VLAN based Ethernet data plane is as such very > similar to the MPLS data plane... Ethernet uses stacked VLAN=20 > Tag headers, > MPLS uses stack label stack entry headers... >=20 > MPLS data plane has been designed differently. Whether one=20 > should or should > not expect certain limitations, they exist. >=20 > The difference between an architectural limitation and=20 > limitation imposed by > the (majority of) existing implementations is, of course,=20 > important. And > things can go any each way: > - some things are architecturally possible but not,=20 > typically, not used. > E.g., AFAIK, this is the case with L-LSPs > which are perfectly OK from the architecture point of view=20 > but rarely used > due to scalability problems. > - some others are architecturally disallowed but may be=20 > supported by certain > implementations. >=20 > We should clearly understand where we stand on each such issue. >=20 > [maarten] to me it seems that the limitation desribed by you=20 > of the MPLS > data plane is not a fundamental limitation, as it is not=20 > present in the OTN > and Ethernet cases. So important in my opinion to understand=20 > is if this > limitation can be removed from the MPLS data plane. >=20 > Regards, > Maarten >=20 > Regards, > Sasha >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Maarten Vissers [mailto:maarten.vissers@huawei.com] > > Sent: Monday, February 08, 2010 2:11 PM > > To: Alexander Vainshtein > > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > data-plane-draft' > > > > Sasha, > > > > An interesting limitation in the MPLS data plane architecture. > > From a transport network perspective one should not expect such=20 > > limitation. > > > > E.g. in OTN I can set up a p2p HO ODU3 connection over=20 > which I carry a=20 > > p2mp LO ODU2 connection, which carries up to 8 p2mp ODU0=20 > signals with=20 > > e.g. 1GE clients. > > > > And in an Ethernet network I can set up a p2p Ethernet VP=20 > connection=20 > > over which I carry a p2mp Ethernet VC connection, which carries a=20 > > number of p2mp Ethernet VLANs. > > > > The fact that both OTN and Ethernet can support the example, I am=20 > > wondering if it is the MPLS data plane architecture that is not=20 > > capable, or if it are the existing MPLS equipment that are not=20 > > capable? > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: maandag 8 februari 2010 9:45 > > To: Maarten Vissers > > Cc: mpls@ietf.org; mpls-tp@ietf.org; 'LEVRAU, LIEVEN (LIEVEN)' > > Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > data-plane-draft' > > > > > > Maarten, > > In short: NOT CORRECT. > > The construction you present violates the MPLS data plane=20 > architecture=20 > > as defined in 3031. > > > > The LSR that terminates the outer P2P LSP cannot know that the next=20 > > label it looks-up is upstream-allocated (and hence to be=20 > looked-up in=20 > > a different > > context): > > - the data link does not indicate that (otherwise the top=20 > label would=20 > > be > > upstream-allocated) > > - the terminated label CANNOT be used as the context label.=20 > It must be=20 > > processed > > regardless of its position in the label stack. > > > > Aside: > > Early LSRs have used a physical loopback interface for=20 > multiple label=20 > > look-ups. > > I.e., when they received a labeled packet with two or more=20 > labels in=20 > > the stack and wanted to look at the 2nd label, they=20 > physically popped=20 > > the top label and forwarded the packet to a dedicated looped-back=20 > > physical interface. The packet received from that interface=20 > would have=20 > > the former 2nd label as the top one, and would then process=20 > it as any=20 > > other top label. > > Of course, the top label and the original ingress interface=20 > would be=20 > > lost in this operation. > > MPLS (and PW) architecture has been designed to allow this type of=20 > > processing. > > Modern LSRs do not usually use a physical loopback interface for=20 > > multiple label lookups, but neither do they prevent their=20 > downstream=20 > > peers from using it as long as the downstream label=20 > allocation scheme=20 > > is used. > > > > Hopefully this clarification will be helpful. > > > > Regards, > > Sasha > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On Behalf > > > Of Maarten Vissers > > > Sent: Monday, February 08, 2010 9:30 AM > > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > > data-plane-draft' > > > > > > Sasha, > > > > > > If I am thinking of a set of p2mp PWs and/or service LSPs > > carried in a > > > p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up > > prior to > > > service requests, and uses downstream allocated labels,=20 > whereas the=20 > > > p2mp PWs/serviceLSPs must use upstream allocated labels. The=20 > > > intermediate p2mp LSP can use downstream allocated labels. > > > > > > This implies that I have the top two labels with downstream > > allocated > > > and the bottom label with upstream allocated. Correct? > > > > > > Regards, > > > Maarten > > > > > > > > > -----Original Message----- > > > From: Alexander Vainshtein=20 > [mailto:Alexander.Vainshtein@ecitele.com] > > > Sent: zaterdag 6 februari 2010 13:56 > > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > Resending as plain text due to size limitations. > > > > > > Regards, > > > Sasha > > > > > > > > > > > > From: Alexander Vainshtein > > > Sent: Saturday, February 06, 2010 11:14 AM > > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > > > > Maarten, Lieven and all, > > > On the second thought, it seems that if the data link code point=20 > > > indicates the downstream label allocation scheme for the=20 > top label,=20 > > > then the next label MUST be downstream-allocated as well. > > > > > > This is because processing of this label, as defined in > > 3031, MUST NOT > > > depend on any labels that have been present above it in the label=20 > > > stack and terminated (popped) by the LSR that looks it up. > > > > > > The relevant text in Section 3.9 states: > > > > > > Although, as we shall see, MPLS supports a hierarchy, the > > processing > > > of a labeled packet is completely independent of the level of=20 > > > hierarchy. The processing is always based on the top > > label, without > > > regard for the > > > possibility that some number of other labels may have been > > > "above it" in > > > the past, or that some number of other labels may be below it at=20 > > > present. > > > In other words, downstream label allocation scheme does=20 > not support=20 > > > "context labels" defined in 5331. They are only=20 > compatible with the=20 > > > upstream label allocation scheme. > > > The bottom line: > > > If the data link code point indicates downstream label > > allocation of > > > the top label, then all the labels in the stack MUST be=20 > > > downstream-allocated (by the appropriate LSRs) If the data > > link code > > > point indicates upstream label allocation of the top label, > > then both > > > upstream-allocated and downstream-allocated labels MAY > > appear in the > > > stack. In certain situations such a mix can result in undesirable=20 > > > behavior. > > > Regards, > > > Sasha > > > > > > > > > > > > > > > > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of=20 > > > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > > > Sent: Friday, February 05, 2010 8:28 PM > > > To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)' > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in=20 > > > data-plane-draft' > > > > > > > > > Maarten, > > > Lots of thanks for an EXCELLENT question. > > > > > > I do not think I can answer it in full, but the following=20 > > > considerations may be useful. > > > > > > Downstream label allocation scheme is explicitly defined as the=20 > > > default in RFC 5331 and 5332. Hence, IMHO, if the code > > point of the > > > data link defines the top label as downstream-assigned,=20 > the router=20 > > > terminating this label will treat the next one(s) as=20 > > > downstream-assigned - unless it has been explicitly aware=20 > that they=20 > > > are upstream-assigned. In other words, the LSR=20 > terminating the top=20 > > > label must explicitly bind it to a context space for=20 > > > upstream-allocated ones. > > > The primary usage of upstream-allocated labels in MPLS (but not=20 > > > necessary in > > > MPLS-TP) is MPLS multicast, and the dedicated codepoints > > are used in > > > conjunction with multicast datalink addresses (or their > > analogs as in > > > the case of MPLS-in-GRE). This means that, generally=20 > speaking, more=20 > > > than one router can terminate the top upstream-allocated=20 > label and=20 > > > look at the next one. And this is only compatible with=20 > the upstream=20 > > > allocation scheme for the next label. > > > > > > Does this help? Did I miss something important? > > > > > > Regards, > > > Sasha > > > > > > > > > > > > From: Maarten Vissers [maarten.vissers@huawei.com] > > > Sent: Friday, February 05, 2010 12:59 PM > > > To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)' > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > > > > Sasha, > > > > > > There can/will be many labels in the label stack on MPSL-TP=20 > > > interfaces. > > > Is the Ethernet code point application only to the top of > > stack label, > > > or to all labels in the stack? > > > > > > I would expect that the code point only applies to the=20 > top of stack=20 > > > label and not to the non-top of stack labels; is this correct? > > > > > > Regards, > > > Maarten > > > > > > > > > > > > > > > From: mpls-tp-bounces@ietf.org > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Alexander=20 > Vainshtein > > > Sent: donderdag 4 februari 2010 14:12 > > > To: LEVRAU, LIEVEN (LIEVEN) > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft' > > > > > > > > > Lieven, > > > Lots of thanks for a prompt response. > > > > > > IMHO and FWIW the label allocation scheme is not just a control=20 > > > plane issue. > > > Please note that, as per RFC 5332, MPLS packets with=20 > > > upstream-allocated labels use a different code point on Ethernet=20 > > > links and GRE tunnels. > > > To me this is a data plane issue. > > > > > > What is more, upstream-allocated labels must refer to a certain=20 > > > context by the downstream router. And context resolution=20 > is part of=20 > > > the data plane as well. > > > > > > Regards, > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: LEVRAU, LIEVEN (LIEVEN) > > > [mailto:lieven.levrau@alcatel-lucent.com] > > > Sent: Wednesday, February 03, 2010 9:06 AM > > > To: Alexander Vainshtein; stbryant@cisco.com; 'Dan Frost'; Bocci,=20 > > > Matthew > > > (Matthew) > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: Label alloc. Schemes in data-plane-draft' > > > > > > > > > > > > > > > Hello Shasha > > > Changed title from Comments on > > > draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in=20 > > > data-plane-draft' > > > > > > In my view - This is a control plane issue and not a data plane=20 > > > issue. How the labels are assigned is outside the scope of the=20 > > > draft. > > > > > > ./ > > > Lieven > > > Label Allocation Schemes: > > > MPLS recognizes two label allocation schemes, each with=20 > its own area=20 > > > of > > > applicability: > > > Downstream label allocation as per RFC 3031 Upstream label=20 > > > allocation as per RFC 5331 IMHO the label allocation scheme is=20 > > > essentially a data plane issue: > > > Label allocation scheme is reflected in the Ethertype in=20 > the case of=20 > > > Ethernet encapsulation etc. > > > Packets with invalid labels must be silently discarded etc. > > > It is not clear to me, which label allocation schemes can=20 > be used in=20 > > > MPLS-TP. > > > This includes applicability of these schemes, e.g., can we use=20 > > > upstream label allocation This issue is closely related=20 > to proposed=20 > > > usage of a well-known multicast MAC destination address for P2P=20 > > > LSPs) Status of this topic in the -00 draft: requires=20 > clarification > > > > > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > Behalf Of > > > Alexander Vainshtein > > > Sent: 01 February 2010 18:00 > > > To: stbryant@cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew) > > > Cc: mpls@ietf.org; mpls-tp@ietf.org > > > Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00 > > > > > > Stewart, Dan, Matthew and all, > > > First of all I'd like to say that the need for clear-cut > > > definition of the > > > MPLS-TP data plane architecture has been quite clear to me. > > > The draft is clearly the necessary first step in the right > > > direction, and I > > > thank you for producing it. > > > > > > That said, I think that quite a few issues have been left > > > undecided in this > > > -00 version of the draft. > > > > > > I will make a (hopefully, short) list of items that IMHO > > > require additional > > > clarification and, eventually, codification. > > > > > > LSP Merge: > > > In MPLS, nothing prevents LSPs from merging at some point: > > > One well-known usage of LSP merge is FRR > > > PHP can be considered as a special case of LSP merge > > > One of the often repeated mantras of MPLS-TP is that its LSPs > > > cannot be > > > merge. > > > It is not clear (at least, to me): > > > Whether this limitation has to be respected at the data plane > > > level, and if > > > yes, then how > > > Whether it means that FRR cannot be used in MPLS-TP > > > Status of this topic in the -00 draft: not mentioned at all > > > Per-Interface Label Space: > > > The draft states that per-interface label space MAY be used > > > in MPLS-TP > > > AFAIK, in MPLS: > > > This referred to data links (including bundles, e.g., > > > produced by LAG). As a > > > consequence, the number of label contexts has been reasonably low > > > This has been only allowed on P2P links > > > One of the problems with MPLS-TP is that in many cases it does not > > > differentiate between data links and lower layer LSPs (see > > > also my notes > > > regarding Sections). As a consequence, it is not clear (to > > me) whether > > > per-interface label space may become a label space per lower > > > layer LSP. (To > > > the best of my understanding this is explicitly prohibited by > > > RFC 3031). > > > Status of this topic in the -00 draft: requires > > > clarification, preferably > > > aligned with RFC 3031. > > > Sections: > > > The draft states that Sections could be data links (level 0 > > > sections) or > > > LSPs with N labels (level N Sections). > > > The following is not clear to me: > > > Can LAN-like data links be Sections in MPLS-TP (The=20 > Editors ask this > > > question themselves when they discuss MAC addresses) > > > Which types of LSPs can be Sections (e.g., can a P2P > > > unidirectional LSP be a > > > Section? Can an associated bi-directional LSP be a section? etc.). > > > If associated bi-directional LSPs can be Sections, can we > > > treat the LSPs > > > rumming over these Sections as co-routed bidirectional? > > > Per-data link (interface) label space is supported in MPLS. > > > Does MPLS-Tp > > > allow per-Section label space (see above)? > > > Status of this topic in the -00 draft: requires > > > clarification, one aspect > > > already recognized as such by the Editors. IMHO and FWIW preferred > > > resolution would be to equate Sections with data links > > > Label Allocation Schemes: > > > MPLS recognizes two label allocation schemes, each with its > > > own area of > > > applicability: > > > Downstream label allocation as per RFC 3031 > > > Upstream label allocation as per RFC 5331 > > > IMHO the label allocation scheme is essentially a data=20 > plane issue: > > > Label allocation scheme is reflected in the Ethertype in=20 > the case of > > > Ethernet encapsulation etc. > > > Packets with invalid labels must be silently discarded etc. > > > It is not clear to me, which label allocation schemes can=20 > be used in > > > MPLS-TP. > > > This includes applicability of these schemes, e.g., can we > > > use upstream > > > label allocation > > > This issue is closely related to proposed usage of a > > > well-known multicast > > > MAC destination address for P2P LSPs) > > > Status of this topic in the -00 draft: requires clarification > > > MAC addresses on Ethernet data links in MPLS-TP: > > > The draft discusses this topic, and proposes using a > > > well-known multicast DA > > > in Ethernet encapsulations for for P2P LSPs > > > IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage > > > of well-known > > > multicast DA is not compatible with the downstream label > > > allocation scheme. > > > Status of this topic in the -00-draft: partially recognized > > > by the Editors, > > > there seems to be a bug in the proposed solution. > > > Hopefully, these notes will be useful. > > > > > > Regards, > > > Sasha=3D > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > =3D > > > > >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From yaacov.weingarten@nsn.com Tue Feb 9 03:06: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 9B4343A72FA; Tue, 9 Feb 2010 03:06:44 -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, 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 e4xnEwpUN0r8; Tue, 9 Feb 2010 03:06:40 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6DD643A7304; Tue, 9 Feb 2010 03:06:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o19B7hea025264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2010 12:07:43 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o19B7gxm023885; Tue, 9 Feb 2010 12:07:43 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 12:07:36 +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_01CAA978.15D3B892" Date: Tue, 9 Feb 2010 12:03:34 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D01F9CD6F@DEMUEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] WG LC comments to draft-ietf-mpls-tp-framework-10 Thread-Index: Acqpd4XLpaHA2BA0SkOT4mwC1C4PZg== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 09 Feb 2010 11:07:36.0749 (UTC) FILETIME=[163915D0:01CAA978] Subject: [mpls] [mpls-tp] WG LC comments to draft-ietf-mpls-tp-framework-10 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, 09 Feb 2010 11:06:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA978.15D3B892 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 Here are some LC comments to the TP Framework draft: Section 1.3: Should add the Acronym "PST Path Segment Tunnel" Section 1.3.4: End of statement #5: s/permitted/supported/ Section 3.3: 3rd bullet - s/connectivity check/continuity check/ - but in general I think that the sentence should be changed to "Proactive and on-demand Operations, Administration, and Maintenance (OAM) functions to monitor and diagnose the MPLS-TP network, as outlined in [I-D.ietf-mpls-tp-oam-framework]." Similarly - 5th bullet could be appended with "as outlined in [I-D.ietf-mpls-tp-survive-fwk]", and 6th bullet could read "Network management functions as outlined in [I-D.ietf.mpls-tp-nm-framework]" Section 3.4.1: The paragraph directly after Figure 5 is a (word-for-word) repeat of the beginning of the paragraph two before the figure!! Appears different places in the document (e.g. 1.3, 3.6, 3.7, 3.12) - the Survivability Framework document specifies a Protection State Coordination (PSC) mechanism, but this document keeps referring to it as "Automatic Protection Switching (APS)", could we make a decision and be consistent on the terminology that should be used? Section 3.7: The OAM Framework defines MEP as Maintenance Entity Group (MEG) End Point and MIP as MEG Intermediate Point. Here again, consistency across the documents would be helpful. Also, in this section, the list of ME types should be coordinated with the latest version of the OAM Framework. Section 3.12: first sentence - s/requirements/architecture/ Best regards, =20 Yaacov Weingarten Industry Environment, Packet Transport Nokia Siemens Networks Hod Hasharon, Israel 45241 Tel: +972-9-775 1827 Mob: +972-54-220 0977 ------_=_NextPart_001_01CAA978.15D3B892 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mpls-tp] WG LC comments to = draft-ietf-mpls-tp-framework-10

Hi,

Here are = some LC comments to the TP Framework draft:

Section 1.3:  Should add the Acronym = "PST  Path Segment = Tunnel"

Section = 1.3.4:  End of statement #5:  = s/permitted/supported/

Section = 3.3:  3rd bullet – = s/connectivity check/continuity check/ - but in general I think that the = sentence should be changed to "Proactive and on-demand Operations, = Administration, and Maintenance = (OAM) functions to monitor and diagnose the MPLS-TP network, as outlined = in [I-D.ietf-mpls-tp-oam-framework]."

Similarly – = 5th bullet could be appended = with "as outlined in [I-D.ietf-mpls-tp-survive-fwk]",  = and 6th bullet could read "Network management functions as = outlined in [I-D.ietf.mpls-tp-nm-framework]"

Section = 3.4.1:  The paragraph directly after Figure 5 is a (word-for-word) = repeat of the beginning of the paragraph two before the = figure!!

Appears different places in the document (e.g. = 1.3, 3.6, 3.7, 3.12) – the Survivability = Framework = document specifies a Protection State Coordination (PSC) = mechanism, but this document keeps referring to it as "Automatic = Protection Switching (APS)", = could we make a decision and be consistent on the terminology that = should be used?

Section 3.7: The OAM Framework defines MEP as Maintenance Entity Group (MEG) End Point and MIP = as MEG = Intermediate Point.  Here again, consistency across the = documents would be helpful.

Also, in this section, the list of ME types = should be coordinated with the latest version of the OAM = Framework.

Section 3.12: first sentence – s/requirements/architecture/

Best regards,

 

Yaacov Weingarten

Industry = Environment, Packet Transport

Nokia Siemens = Networks

Hod Hasharon, Israel 45241

Tel: +972-9-775 = 1827

Mob: +972-54-220 = 0977

------_=_NextPart_001_01CAA978.15D3B892-- From wwwrun@core3.amsl.com Tue Feb 9 07:29:39 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 D340C28C112; Tue, 9 Feb 2010 07:29:39 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100209152939.D340C28C112@core3.amsl.com> Date: Tue, 9 Feb 2010 07:29:39 -0800 (PST) Cc: loa.andersson@ericsson.com, MPLS Working Group , Stewart Bryant , Greg Jones , Malcolm Betts , Yoichi Maeda , MPLS-TP Mailing list , ITU-T ad hoc team on MPLS-TP , Patrik Fältström , David Ward , Ross Callon , tsbsg15@itu.int, Huub Van Helvoort , Hing-Kam Lam , Adrian Farrel , Ghani Abbas Subject: [mpls] New Liaison Statement, "Request for early review of draft-ietf-mpls-tp-fault-00 (ref #016.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:29:39 -0000 Title: Request for early review of draft-ietf-mpls-tp-fault-00 (ref #016.01) Submission Date: 2010-02-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=638 Please reply by 2010-03-10 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q11, Q12 and Q14(greg.jones@itu.int) Cc: Yoichi Maeda Greg Jones Ghani Abbas Huub Van Helvoort Malcolm Betts Hing-Kam Lam ITU-T ad hoc team on MPLS-TP David Ward Adrian Farrel Ross Callon Patrik F�ltstr�m MPLS-TP Mailing list MPLS Working Group Stewart Bryant Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: The IETF MPLS Working Group want to request an early review of draft-ietf-mpls-tp-fault-00, the draft has been accepted as a working group draft and is now in a state where it is feasible to to have a review for early comments. We would like receive these comments March 10, 2010 the latest. Loa Andersson George Swallow IETF Working Group Co-chairs Attachment(s): No document has been attached From loa@pi.nu Tue Feb 9 07:50: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 DEB1228C127; Tue, 9 Feb 2010 07:50:15 -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 vEUxCZHNwM6o; Tue, 9 Feb 2010 07:50:15 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DFFCD28C11E; Tue, 9 Feb 2010 07:50:14 -0800 (PST) Received: from [192.168.2.21] (unknown [194.98.133.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2E6B9D4052; Tue, 9 Feb 2010 16:51:19 +0100 (CET) Message-ID: <4B718478.5030909@pi.nu> Date: Tue, 09 Feb 2010 16:51:20 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] early review of 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: Tue, 09 Feb 2010 15:50:16 -0000 All, The MPLS working group has requested an early review of draft-ietf-mpls-tp-fault-00.txt by ITU-T SG15. This is also a good time for people active in the work on MPLS in both IETF and ITU-T The draft is in a state stable enough to make an early feasible. However there is a set of comments that were received during the poll to make this document a working group document. These comments will be addressed along with any new comments. The ITU-T has been requested to send comments to the IETF by March 10, 2010. Please send your comments directly mpls-tp@ietf.org mailing list. /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 loa@pi.nu Tue Feb 9 08:05:00 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 CF2593A7368; Tue, 9 Feb 2010 08:05:00 -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 XhEgQJ23Wn3P; Tue, 9 Feb 2010 08:05:00 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id CFB1A3A73F5; Tue, 9 Feb 2010 08:04:59 -0800 (PST) Received: from [192.168.2.21] (unknown [194.98.133.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 94CF2D4052; Tue, 9 Feb 2010 17:06:04 +0100 (CET) Message-ID: <4B7187EE.30404@pi.nu> Date: Tue, 09 Feb 2010 17:06:06 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:05:01 -0000 All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 wwwrun@core3.amsl.com Tue Feb 9 08:14:04 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 C682E28C10D; Tue, 9 Feb 2010 08:14:03 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100209161404.C682E28C10D@core3.amsl.com> Date: Tue, 9 Feb 2010 08:14:03 -0800 (PST) Cc: loa.andersson@ericsson.com, MPLS Working Group , Stewart Bryant , Greg Jones , Malcolm Betts , Yoichi Maeda , MPLS-TP Mailing list , ITU-T ad hoc team on MPLS-TP , Patrik Fältström , David Ward , Ross Callon , tsbsg15@itu.int, Huub Van Helvoort , Hing-Kam Lam , Adrian Farrel , Ghani Abbas Subject: [mpls] New Liaison Statement, "Poll on making draft-fbb-mpls-tp-data-plane-00.txt an MPLS WG document (ref #017.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:14:05 -0000 Title: Poll on making draft-fbb-mpls-tp-data-plane-00.txt an MPLS WG document (ref #017.01) Submission Date: 2010-02-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=639 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q11, Q12 and Q14(greg.jones@itu.int) Cc: Yoichi Maeda Greg Jones Ghani Abbas Huub Van Helvoort Malcolm Betts Hing-Kam Lam ITU-T ad hoc team on MPLS-TP David Ward Adrian Farrel Ross Callon Patrik F�ltstr�m MPLS-TP Mailing list MPLS Working Group Stewart Bryant Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For information Body: We would like to inform you that we have started a poll on making draft-fbb-mpls-tp-data-plane-00.txt an MPLS Working Group document. Loa Andersson George Swallow IETF MPLS Working Group Co-chairs Attachment(s): No document has been attached From Alexander.Vainshtein@ecitele.com Tue Feb 9 08:25: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 481A23A73DC; Tue, 9 Feb 2010 08:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 FMeXUEUOtUo1; Tue, 9 Feb 2010 08:25:55 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 22CFB3A7223; Tue, 9 Feb 2010 08:25:53 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-6f-4b718b6b0b83 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 9F.71.18464.B6B817B4; Tue, 9 Feb 2010 18:20:59 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 9 Feb 2010 18:26:59 +0200 From: Alexander Vainshtein To: Loa Andersson Date: Tue, 9 Feb 2010 18:26:58 +0200 Thread-Topic: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqpodBPSODLwigiRiO34TcGNLqB6QAASfLQ Message-ID: References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "mpls-tp@ietf.org" , 'Dan Frost' , "pwe3@ietf.org" , Adrian, "stbryant@cisco.com" Subject: Re: [mpls] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:25:57 -0000 --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, I think that such a draft is absolutely required. At the same time I think the -00 revision is somewhat problematic. In particular, the proposal to use a well-known multicast MAC address for e= ncapsulation of MPLS-TP packets over Ethernet *simply will not work* together with the combination = of: (a) LAN interfaces between MPLS-TP routers (quite a common case for Etherne= t) and=20 (b) Downstream label assignment (which presumably is going to be used for P= 2P LSPs in MPLS-TP). I've already sent my comments on this (and some other points) to the author= s and the mailing lists (attached). IMHO at least the problem of Ethernet encapsulation should be acknowledged = (and resolved?) before the draft is accepted as a WG document. Regards, Sasha > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, February 09, 2010 6:06 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org;=20 > pwe3@ietf.org; Adrian Farrel > Subject: [mpls-tp] poll on making=20 > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >=20 > All, >=20 > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.txt > an mpls working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, > indicating "yes/support" or "no/do not support". >=20 > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. >=20 >=20 > /Loa >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > 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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > = --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_ Content-Type: message/rfc822 From: Alexander Vainshtein To: "stbryant@cisco.com" , 'Dan Frost' , 'BOCCI Matthew' CC: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Mon, 1 Feb 2010 18:59:57 +0200 Subject: Comments on draft-fbb-mpls-tp-data-plane-00 Thread-Topic: Comments on draft-fbb-mpls-tp-data-plane-00 Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6971727472716676656873657573696673797175776765797977756_" MIME-Version: 1.0 --_000_6971727472716676656873657573696673797175776765797977756_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 2. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 3. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 4. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 5. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_6971727472716676656873657573696673797175776765797977756_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Stewart, = Dan,=20 Matthew and all,
First of = all I'd=20 like to say that the need for clear-cut definition of the MPLS-TP data plan= e=20 architecture has been quite clear to me.
The draft= is clearly=20 the necessary first step in the right direction, and I thank you for produc= ing=20 it.
 
That said= , I think=20 that quite a few issues have been left undecided in this -00 version of the= =20 draft.
 
I will ma= ke a=20 (hopefully, short) list of items that IMHO require additional clarification= and,=20 eventually, codification.
 
  1. = LSP=20 Merge:
    • In MPL= S, nothing=20 prevents LSPs from merging at some point:
      • One = well-known=20 usage of LSP merge is FRR
      • PHP = can be=20 considered as a special case of LSP merge
    • One of= the often=20 repeated mantras of MPLS-TP is that its LSPs cannot be=20 merge. 
    • It is = not clear=20 (at least, to me):
      • Whet= her this=20 limitation has to be respected at the data plane level, and if yes, t= hen=20 how
      • Whet= her it=20 means that FRR cannot be used in MPLS-TP
    • Status= of this=20 topic in the -00 draft: not mentioned at all
  2. Per-Interface Label=20 Space:
    • The dr= aft states=20 that per-interface label space MAY be used in MPLS-TP
    • AFAIK,= in=20 MPLS:
      • This= referred=20 to data links (including bundles, e.g., produced by LAG). As a=20 consequence, the number of label contexts has been reasonably=20 low
      • This= has been=20 only allowed on P2P links
    • One of= the=20 problems with MPLS-TP is that in many cases it does not differenti= ate=20 between data links and lower layer LSPs (see also my notes regarding=20 Sections). As a consequence, it is not clear (to me) whether per-interf= ace=20 label space may become a label space per lower layer LSP. (To the best = of my=20 understanding this is explicitly prohibited by RFC=20 3031).
    • Status= of this=20 topic in the -00 draft: requires clarification, preferably aligned with= RFC=20 3031.
  3. Sections:
    • The dr= aft states=20 that Sections could be data links (level 0 sections) or LSPs with N lab= els=20 (level N Sections).
    • The fo= llowing=20 is not clear to me:
      • Can = LAN-like=20 data links be Sections in MPLS-TP (The Editors ask this question=20 themselves when they discuss MAC addresses)
      • Whic= h types of=20 LSPs can be Sections (e.g., can a P2P unidirectional LSP be a=20 Section? Can an associated bi-directional LSP be a section? etc.).=20
      • If a= ssociated=20 bi-directional LSPs can be Sections, can we treat the LSPs rumming ov= er=20 these Sections as co-routed bidirectional?
      • Per-= data link=20 (interface) label space is supported in MPLS. Does MPLS-Tp allow=20 per-Section label space (see above)?
    • Status= of this=20 topic in the -00 draft: requires clarification, one aspect already=20 recognized as such by the Editors. IMHO and FWIW preferred resolution w= ould=20 be to equate Sections with data links
  4. = Label=20 Allocation Schemes:
    • MPLS r= ecognizes=20 two label allocation schemes, each with its own area of=20 applicability:
      • Down= stream=20 label allocation as per RFC 3031
      • Upst= ream label=20 allocation as per RFC 5331
    • IMHO t= he label=20 allocation scheme is essentially a data plane issue:
      • Labe= l=20 allocation scheme is reflected in the Ethertype in the case of Ethern= et=20 encapsulation etc.
      • Packets with invalid labels mus= t be=20 silently discarded=20 etc.
    • It is = not clear=20 to me, which label allocation schemes can be used in= =20 MPLS-TP.
      • This= includes=20 applicability of these schemes, e.g., can we use upstream label alloc= ation=20
      • This= issue is=20 closely related to proposed usage of a well-known multicast= MAC=20 destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requi= res=20 clarification
  5. MAC addresses on Ethernet data links i= n=20 MPLS-TP:
    • The draft discusses this topic, and proposes= using=20 a well-known multicast DA in Ethernet encapsulations for for P2P=20 LSPs
    • IMHO and FWIW if LAN interfaces are all= owed in=20 MPLS-TP, usage of  well-known multicast DA is not compatible with = the=20 downstream label allocation scheme.
    • Status of this topic in the -00-draft: parti= ally=20 recognized by the Editors, there seems to be a bug in the proposed=20 solution.
Hopefully, these notes will be=20 useful.
 
Regards,
    =20 Sasha
    •  
--_000_6971727472716676656873657573696673797175776765797977756_-- --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_-- From danfrost@cisco.com Tue Feb 9 08:52: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 0806A28C23C; Tue, 9 Feb 2010 08:52:14 -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 Zu16u8nGBMMT; Tue, 9 Feb 2010 08:52:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A5DC828C237; Tue, 9 Feb 2010 08:52:12 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,437,1262563200"; d="scan'208";a="297457852" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2010 16:53:18 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o19GrIuD022527; Tue, 9 Feb 2010 16:53:18 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id o19GrIJ7017242; Tue, 9 Feb 2010 11:53:18 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id o19GrIGV017241; Tue, 9 Feb 2010 16:53:18 GMT Date: Tue, 9 Feb 2010 16:53:18 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20100209165318.GA9442@cisco.com> References: <4B7187EE.30404@pi.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:52:14 -0000 Hi Sasha, Many thanks for your comments! The authors will review them in detail when we next sit down to work on the document. Several of your points relate to open issues which we're aware need to be resolved, like the use of multipoint Ethernet interfaces and the definition and scope of MPLS-TP Sections. Your input is very helpful as always. -d On Tue, Feb 09, 2010 at 06:26:58PM +0200, Alexander Vainshtein wrote: > Loa, > I think that such a draft is absolutely required. > At the same time I think the -00 revision is somewhat problematic. > In particular, the proposal to use a well-known multicast MAC address for encapsulation of MPLS-TP > packets over Ethernet *simply will not work* together with the combination of: > (a) LAN interfaces between MPLS-TP routers (quite a common case for Ethernet) and > (b) Downstream label assignment (which presumably is going to be used for P2P LSPs in MPLS-TP). > > I've already sent my comments on this (and some other points) to the authors and the mailing lists (attached). > > IMHO at least the problem of Ethernet encapsulation should be acknowledged (and resolved?) before the draft is accepted as a WG document. > > Regards, > Sasha > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Tuesday, February 09, 2010 6:06 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; > > pwe3@ietf.org; Adrian Farrel > > Subject: [mpls-tp] poll on making > > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document > > > > All, > > > > This is to start two week poll on making > > draft-fbb-mpls-tp-data-plane-00.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". > > > > Note that this ID is a starting point for what needs to > > be documented on the MPLS data plane for the MPLS-TP > > project. The ID is largely based on the data plane specific > > text from the framework, together with some notes concerning > > how the Transport Profile of MPLS might operate over Ethernet. > > > > > > /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 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > Date: Mon, 1 Feb 2010 18:59:57 +0200 > From: Alexander Vainshtein > Subject: Comments on draft-fbb-mpls-tp-data-plane-00 > To: "stbryant@cisco.com" , 'Dan Frost' > , 'BOCCI Matthew' > CC: "mpls-tp@ietf.org" , "mpls@ietf.org" > > Stewart, Dan, Matthew and all, > First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me. > The draft is clearly the necessary first step in the right direction, and I thank you for producing it. > > That said, I think that quite a few issues have been left undecided in this -00 version of the draft. > > I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification. > > > 1. LSP Merge: > * In MPLS, nothing prevents LSPs from merging at some point: > * One well-known usage of LSP merge is FRR > * PHP can be considered as a special case of LSP merge > * One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. > * It is not clear (at least, to me): > * Whether this limitation has to be respected at the data plane level, and if yes, then how > * Whether it means that FRR cannot be used in MPLS-TP > * Status of this topic in the -00 draft: not mentioned at all > 2. Per-Interface Label Space: > * The draft states that per-interface label space MAY be used in MPLS-TP > * AFAIK, in MPLS: > * This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low > * This has been only allowed on P2P links > * One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031). > * Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031. > 3. Sections: > * The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections). > * The following is not clear to me: > * Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses) > * Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.). > * If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional? > * Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)? > * Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links > 4. Label Allocation Schemes: > * MPLS recognizes two label allocation schemes, each with its own area of applicability: > * Downstream label allocation as per RFC 3031 > * Upstream label allocation as per RFC 5331 > * IMHO the label allocation scheme is essentially a data plane issue: > * Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. > * Packets with invalid labels must be silently discarded etc. > * It is not clear to me, which label allocation schemes can be used in MPLS-TP. > * This includes applicability of these schemes, e.g., can we use upstream label allocation > * This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) > * Status of this topic in the -00 draft: requires clarification > 5. MAC addresses on Ethernet data links in MPLS-TP: > * The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs > * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-known multicast DA is not compatible with the downstream label allocation scheme. > * Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > > Regards, > Sasha > > * From maarten.vissers@huawei.com Tue Feb 9 12:48: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 2D9E63A748D; Tue, 9 Feb 2010 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 ZsPHyWNvaqYC; Tue, 9 Feb 2010 12:48:47 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B89333A7378; Tue, 9 Feb 2010 12:48:46 -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 <0KXL0069JDV56Z@szxga03-in.huawei.com>; Wed, 10 Feb 2010 04:49:53 +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 <0KXL00BYPDV5ZD@szxga03-in.huawei.com>; Wed, 10 Feb 2010 04:49:53 +0800 (CST) Received: from M00900002 ([81.253.59.83]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXL0098XDUZ21@szxml01-in.huawei.com>; Wed, 10 Feb 2010 04:49:53 +0800 (CST) Date: Tue, 09 Feb 2010 21:49:37 +0100 From: Maarten Vissers In-reply-to: <20100205154513.X25815@sapphire.juniper.net> To: 'Rahul Aggarwal' , 'Loa Andersson' Message-id: <000b01caa9c9$67575de0$ec7bfea9@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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acqmv3GyuMS5TyKNSz2jew5pAyrlMQDCUcAw Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 09 Feb 2010 20:48:49 -0000 Rahul, The MPLS-TP LSP is not a layer network. The LSP is a transport entity within either the transport service layer network, or the transport path layer network, or the section layer network. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal Sent: zaterdag 6 februari 2010 1:00 To: Loa Andersson Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 Here are my LC comments on draft-ietf-mpls-tp-framework-10, prefixed by : 1. 1.3.4. MPLS-TP Label Switched Path An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as set out in [RFC5654]. The characteristics of an MPLS-TP LSP are primarily that it: I would suggest adding: "A MPLS-TP LSP is the lowest server layer provided by MPLS-TP. The client layers of a MPLS-TP LSP maybe IP, MPLS or PWs. The client layers of a MPLS-TP LSP are described in detail in section 3.4" This is to make the client server relationship in MPLS-TP clearer. 2. 1.3.10. Additional Definitions and Terminology Detailed definitions and additional terminology may be found in [RFC5654]. I would suggest a section on "Service Interface". This is to clarify the applicability of the use of MPLS-TP LSPs and PWs as described in section 3.4. Furhter it is needed to clarify what is the interface exposed by MPLS-TP to the client network. "Service Interface The transport service provided by MPLS-TP is said to be provided by a service interface. The following are the service interfaces supported by MPLS-TP: - The service interface may a layer 2 interface that carries only network layer clients. MPLS-TP LSPs are both necessary and sufficient to support this service interface as described in section 3.4.3 - Or the service interface may be a layer 2 interface that carries both network layer and non-network layer clients. To support this service interface, a PW is required to adapt the client traffic received over the service interface. This PW in turn is a client of the MPLS-TP server layer. This is described in section 3.4.2. - Or the service interface may be a MPLS LSP or a PW. To support this case a MPLS-TP PE participates in the service interface signaling." 3. 1.4. Applicability MPLS-TP can be used to construct packet transport networks and is therefore applicable in any packet transport network context. It is also applicable to subsets of a packet network where the transport network operational model is deemed attractive. The following are examples of MPLS-TP applicability models: 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs and PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or LSRs), acting as a server for other layer 1, layer 2 and layer 3 networks (Figure 1). 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs and PWs (i.e. both LSPs and PWs that conform to the transport profile and those that do not, exist between the PEs), acting as a server for other layer 1, layer 2 and layer 3 networks (Figure 2). 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS networks which do not use functions of the MPLS transport profile. For MPLS traffic, the MPLS-TP server layer network uses PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that terminates the MPLS-TP server layer (Figure 3). I think figure 3 and case 3 as written currently are making an assumption that a MPLS-TP PE participates in the "service interface signaling" where the service interface provided by MPLS-TP is a MPLS LSP or a PW. This is a NNI model. Perhaps we need two sub-cases of case 3. One is a UNI model where the MPLS network just sees a P2P or P2MP link, which is provided by the MPLS-TP network. In this case mechanisms of section 3.4.3 are sufficient. The second case is the one which the current text seems to imply and in that case the MPLS-TP PE would participate in the MPLS signaling. In this case the MPLS-TP PE may use LSP hierarchy or LSP stitching to support the MPLS-LSP as a service interface and may use PW stitching to support PW as a service interface. So I would propose to replace example number 3 above with: "3. MPLS-TP as a server layer for client layer traffic of IP or MPLS networks which do not use functions of the MPLS transport profile. Here are two examples of applicability models of this: a) The client IP or MPLS network is provided a layer 2 P2P or P2MP link by the MPLS-TP network. In other words the service interface is a layer 2 inteface that carries only IP or MPLS packets. To support this case the MPLS-TP server layer network uses the mechanisms of section 3.4.3 to carry IP or MPLS client l layer traffic over MPLS-TP LSPs" b) The client IP or MPLS network is provided a LSP or a PW as a service interface by the MPLS-TP network. In this case the MPLS-TP PE would participate in the client MPLS signaling. In this case the MPLS-TP PE may use LSP hierarchy or LSP stitching to support the MPLS-LSP as a service interface and may use PW stitching to support PW as a service interface (Figure 3)" 4. 3.1 Packet Transport Services One objective of MPLS-TP is to enable MPLS networks to provide packet transport services with a similar degree of predictability to that found in existing transport networks. Such packet transport services inherit a number of characteristics, defined in [RFC5654]: o In an environment where an MPLS-TP layer network is supporting a client layer network, and the MPLS-TP layer network is supported by a server layer network then operation of the MPLS-TP layer network must be possible without any dependencies on either the server or client layer network. o The service provided by the MPLS-TP network to the client is guaranteed not to fall below the agreed level regardless of other client activity. o The control and management planes of any client network layer that uses the service is isolated from the control and management planes of the MPLS-TP layer network, where the client network layer is considered to be the native service of the MPLS-TP network. o Where a client network makes use of an MPLS-TP server that provides a packet transport service, the level of co-ordination required between the client and server layer networks is minimal (preferably no co-ordination will be required). o The complete set of packets generated by a client MPLS(-TP) layer network using the packet transport service, which may contain packets that are not MPLS packets (e.g. IP or CLNS packets used by the control/management plane of the client MPLS(-TP) layer Bocci, et al. Expires August 8, 2010 [Page 12] Internet-Draft MPLS Transport Profile Framework February 2010 network), are transported by the MPLS-TP server layer network. o The packet transport service enables the MPLS-TP layer network addressing and other information (e.g. topology) to be hidden from any client layer networks using that service, and vice-versa. These characteristics imply that a packet transport service does not support a connectionless packet-switched forwarding mode. However, this does not preclude it carrying client traffic associated with a connectionless service. Such packet transport services are very similar to Layer 2 Virtual Private Networks as defined by the IETF. The last sentence should be deleted. It doesn't add value and is in potential conflict with section 3.4.3. 5. 3.3. Architecture MPLS-TP comprises the following architectural elements: o A standard MPLS data plane [RFC3031] as profiled in [I-D.fbb-mpls-tp-data-plane]. Standard MPLS data plane also includes RFC 5331 and RFC 5332. Given draft-fbb is not a WG draft, I don't think we should add a reference to it here. 6. 3.4.2. Pseudowire Adaptation The architecture for an MPLS-TP network that provides PW emulated services is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures. I think instead of "PW emulated services", the section should start with the service interface that requires PWs. Something like: "If the MPLS-TP network provides a layer 2 interface, that carries both network layer and non-network layer traffic, as a service interface then a PW is required to support the service interface. The PW is a client of the MPLS-TP LSP server layer. The architecture of a MPLS-TP network that uses such PWs is is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures." The above is to make it very clear the applicability of 3.4.2 as compared to 3.4.3. Multi-segment pseudowires may optionally be used to provide a packet transport service, and their use is consistent with Bocci, et al. Expires August 8, 2010 [Page 18] Internet-Draft MPLS Transport Profile Framework February 2010 the MPLS-TP architecture. The use of MS-PWs may be motivated by, for example, the requirements specified in [RFC5254]. If MS-PWs are used, then the MS-PW architecture [RFC5659] also applies. Figure 6 shows the architecture for an MPLS-TP network using single- segment PWs. |<--------------- Emulated Service ----------------->| | | | |<-------- Pseudowire -------->| | | | encapsulated, packet | | | | transport service | | | | | | | | |<------ LSP ------->| | | | V V V V | V AC +----+ +-----+ +----+ AC V +-----+ | | PE1|=======\ /========| PE2| | +-----+ | |----------|.......PW1.| \ / |............|----------| | | CE1 | | | | | X | | | | | CE2 | | |----------|.......PW2.| / \ |............|----------| | +-----+ ^ | | |=======/ \========| | | ^ +-----+ ^ | +----+ +-----+ +----+ | ^ | | Provider Edge 1 ^ Provider Edge 2 | | | | | | | Customer | P Router | Customer Edge 1 | | Edge 2 | | | | Native service Native service Figure 6: MPLS-TP Architecture (Single Segment PW) Figure 7 shows the architecture for an MPLS-TP network when multi- segment pseudowires are used. Note that as in the SS-PW case, P-routers may also exist. This figure needs to clarify where the MPLS-TP PEs are and where the "service PEs" are. Or whether PE1 is actually both the MPLS-TP PE and the service PE. Bocci, et al. Expires August 8, 2010 [Page 19] Internet-Draft MPLS Transport Profile Framework February 2010 |<----------- Pseudowire encapsulated ------------->| | packet transport service | | | | | | | AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC | V V V V V V | | +----+ +-----+ +----+ +----+ | +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ | |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| | |CE1| | | | | X | | | | | | |CE2| | |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| | +---+ | | |===============/ \=====| |==========| | | +---+ ^ +----+ ^ +-----+ +----+ ^ +----+ ^ | | ^ | | | TE LSP | TE LSP | | P-router | | | |<-------------------- Emulated Service ------------------->| PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while PW2-segment1 and PW2-segment2 are segments of another MS-PW Figure 7: MPLS-TP Architecture (Multi-Segment PW) The corresponding MPLS-TP protocol stacks including PWs are shown in Figure 8. In this figure the Transport Service Layer [RFC5654] is identified by the PW demultiplexer (Demux) label and the Transport Path Layer [RFC5654] is identified by the LSP Demux Label. Bocci, et al. Expires August 8, 2010 [Page 20] Internet-Draft MPLS Transport Profile Framework February 2010 +-------------------+ /===================\ /===================\ | Client Layer | H OAM PDU H H OAM PDU H /===================\ H-------------------H H-------------------H H PW Encap H H GACh H H GACh H H-------------------H H-------------------H H-------------------H H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H H-------------------H H-------------------H H-------------------H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H \===================/ \===================/ \===================/ | Server Layer | | Server Layer | | Server Layer | +-------------------+ +-------------------+ +-------------------+ User Traffic PW OAM LSP OAM Note: H(ighlighted) indicates the part of the protocol stack we are considering in this document. Figure 8: MPLS-TP Layer Network using Pseudowires PWs and their associated labels may be configured or signaled. See Section 3.11 for additional details related to configured service types. See Section 3.9 for additional details related to signaled service types. 7. 3.4.2.1. Pseudowire Based Services When providing a Virtual Private Wire Service (VPWS) , Virtual Private Local Area Network Service (VPLS), Virtual Private Multicast Service (VPMS) or Internet Protocol Local Area Network Service (IPLS), pseudowires must be used to carry the client service. VPWS, VLPS, and IPLS are described in [RFC4664]. VPMS is described in [I-D.ietf-l2vpn-vpms-frmwk-requirements]. This section should be deleted. From a MPLS-TP network view point the service interface, that requires PWs, is a point-to-point layer 2 interface that carries both network layer and non-network layer traffic. This is orthogonal to the service which is being delivered to the end user. Hence this section doesn't belong here. 8. 3.4.3. Network Layer Adaptation MPLS-TP LSPs can be used to transport network layer clients. This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. The network layer protocols supported by [RFC3031] and [RFC3032] can be transported between service interfaces. Examples are shown in Figure 5 above. Support for network layer clients follows the MPLS architecture for support of network layer protocols as specified in [RFC3031] and [RFC3032]. With network layer adaptation, the MPLS-TP domain provides either a uni-directional or bidirectional point-to-point connection between two PEs in order to deliver a packet transport service to attached customer edge (CE) nodes. For example, a CE may be an IP, MPLS or Bocci, et al. Expires August 8, 2010 [Page 21] Internet-Draft MPLS Transport Profile Framework February 2010 MPLS-TP node. As shown in Figure 9, there is an attachment circuit between the CE node on the left and its corresponding provider edge (PE) node which provides the service interface, a bidirectional LSP across the MPLS-TP network to the corresponding PE node on the right, and an attachment circuit between that PE node and the corresponding CE node for this service. The attachment circuits may be heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads arrive at the service interface encapsulated in the Layer1/Layer2 encoding defined for that access link type. It should be noted that the set of network layer protocols includes MPLS and hence MPLS encoded packets with an MPLS label stack (the client MPLS stack), may appear at the service interface. |<------------- Client Network Layer ------------->| | | | |<---- Pkt Xport Service --->| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +---+ +----+ AC V +-----+ | |PE1 | | | |PE2 | | +-----+ | | |LSP | | | | | | | | | | CE1 |----------| |========X=========| |----------| CE2 | | | ^ |IP | | ^ | | ^ | | | ^ | | +-----+ | | | | | | | | | | | | +-----+ ^ | +----+ | +---+ | +----+ | | ^ | | Provider | ^ | Provider | | | | Edge | | | Edge | | Customer | 1 | P-router | 2 | Customer Edge 1 | TE TE | Edge 2 | LSP LSP | | | Native service Native service Figure 9: MPLS-TP Architecture for Network Layer Clients PE1 and PE2 should be specifically labeled as MPLS-TP PEs. At the ingress service interface the client packets are received . The PE pushes one or more labels onto the client packets which are then label switched over the transport network. Correspondingly the egress PE pops any labels added by the MPLS-TP networks and transmits the packet for delivery to the attached CE via the egress service interface. 9. 3.6. Generic Associated Channel (G-ACh) For correct operation of the OAM it is important that the OAM packets fate-share with the data packets. In addition in MPLS-TP it is necessary to discriminate between user data payloads and other types of payload. For example, a packet may be associated with a Signaling Communication Channel (SCC), or a channel used for Automatic Protection Switching (APS) data. This is achieved by carrying such packets on a generic control channel associated to the LSP, PW or section. Suggest replacing the last sentence with: "This is achieved by either carrying such packets in an IP encapsulation that provides the necessary discrimination, or by carrying such packets on a generic control channel associated to the LSP, PW or section. Rest of this section describes the latter mechanism." Also please see related comment in section 3.7. 10. 3.7. Operations, Administration and Maintenance (OAM) MPLS-TP must be able to operate in environments where IP is not used in the forwarding plane. Therefore, the default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated Channel (Section 3.6). Forwarding based on IP addresses for user or OAM packets is not required for MPLS-TP. [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when the OAM packets are encapsulated in an IP header. These alert mechanisms are based on TTL expiration and/or use an IP destination address in the range 127/8 for IPv4 and that same range embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the OAM packets are encapsulated in an IP header, these mechanisms are the default mechanisms for MPLS networks in general for identifying MPLS OAM packets. MPLS-TP must be able to operate in an environments where IP forwarding is not supported, and thus the G-ACh/GAL is the default mechanism to demultiplex OAM packets in MPLS-TP. The last sentence is in conflict with the following from section 4.1 of RFC 5586: "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header although the mechanism defined in this document MAY also be used." Hence the last sentence of the above paragraph must be removed. rahul _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From neil.2.harrison@bt.com Tue Feb 9 13:24:26 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 BD3A83A7489; Tue, 9 Feb 2010 13:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 NiH04LwvNLKT; Tue, 9 Feb 2010 13:24:24 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B5CFF3A6919; Tue, 9 Feb 2010 13:24:23 -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); Tue, 9 Feb 2010 21:25:29 +0000 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, 9 Feb 2010 21:25:26 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <000b01caa9c9$67575de0$ec7bfea9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 Thread-Index: Acqmv3GyuMS5TyKNSz2jew5pAyrlMQDCUcAwAADD7UA= From: To: , , X-OriginalArrivalTime: 09 Feb 2010 21:25:29.0722 (UTC) FILETIME=[676FD5A0:01CAA9CE] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 09 Feb 2010 21:24:26 -0000 Maarten, Please let us not confuse folks with terms like 'transport entity'....we all know that MPLS-TP will only be using proper connections because we want to *deterministically and simply* manage resource. However, you are absolutely right to pick-up on the point that an LSP is *not necessarily* a layer network. AFAIK we now have no way of telling from looking at the DP whether a suite of nested LSPs is sublayered or layered...seems one can mix up sublayering and proper client/server layering of LSPs at will. This is not great architectural design practice IMO but this seems to be happening because we cannot easily satisfy the real transport requirement whilst clinging on to some old MPLS behaviours. Some while ago I suggested (at least to Stewart) that if folks want to keep sublayering in MPLS-TP, then we should have an unambiguous way of identifying when one sublayer stack of LSPs ends (say a client layer MPLS-TP network belonging to party X) and a different sublayer stack of LSPs begins (say a server layer MPLS-TP network belonging to party Y). I suggested we should allocate a globally well-known functional label from the 0-15 set for this important client/server case. We could also use the same reserved label in MPLS. Note this is consistent with respecting consistent CI as the label is globally well-known. I still think this idea should be given serious consideration due to the importance (to operators) of being able to have a quite clear client/server relationship in MPLS-TP between different operating parties.=20 regards, Neil=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 09 February 2010 20:50 > To: 'Rahul Aggarwal'; 'Loa Andersson' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >=20 > Rahul, >=20 > The MPLS-TP LSP is not a layer network. The LSP is a=20 > transport entity within either the transport service layer=20 > network, or the transport path layer network, or the section=20 > layer network.=20 >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal > Sent: zaterdag 6 februari 2010 1:00 > To: Loa Andersson > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >=20 >=20 > Here are my LC comments on draft-ietf-mpls-tp-framework-10,=20 > prefixed by > : >=20 >=20 > 1. 1.3.4. MPLS-TP Label Switched Path >=20 > An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a > subset of the capabilities of an MPLS LSP in order to meet the > requirements of an MPLS transport network as set out in [RFC5654]. > The characteristics of an MPLS-TP LSP are primarily that it: >=20 > I would suggest adding: "A MPLS-TP LSP is the lowest=20 > server layer provided by MPLS-TP. The client layers of a=20 > MPLS-TP LSP maybe IP, MPLS or PWs. The client layers of a=20 > MPLS-TP LSP are described in detail in section 3.4" >=20 > This is to make the client server relationship in MPLS-TP clearer. >=20 > 2. 1.3.10. Additional Definitions and Terminology >=20 > Detailed definitions and additional terminology may be found in > [RFC5654]. >=20 > I would suggest a section on "Service Interface". This=20 > is to clarify the applicability of the use of MPLS-TP LSPs=20 > and PWs as described in section 3.4. Furhter it is needed to=20 > clarify what is the interface exposed by MPLS-TP to the=20 > client network. >=20 > "Service Interface >=20 > The transport service provided by MPLS-TP is said to be=20 > provided by a service interface. The following are the=20 > service interfaces supported by > MPLS-TP: >=20 > - The service interface may a layer 2 interface that carries=20 > only network layer clients. MPLS-TP LSPs are both necessary=20 > and sufficient to support this service interface as described=20 > in section 3.4.3 >=20 > - Or the service interface may be a layer 2 interface that=20 > carries both network layer and non-network layer clients. To=20 > support this service interface, a PW is required to adapt the=20 > client traffic received over the service interface. This PW=20 > in turn is a client of the MPLS-TP server layer. > This is described in section 3.4.2. >=20 > - Or the service interface may be a MPLS LSP or a PW. To=20 > support this case a MPLS-TP PE participates in the service=20 > interface signaling." >=20 > 3. 1.4. Applicability >=20 > MPLS-TP can be used to construct packet transport networks and is > therefore applicable in any packet transport network=20 > context. It is > also applicable to subsets of a packet network where the transport > network operational model is deemed attractive. The following are > examples of MPLS-TP applicability models: >=20 > 1. MPLS-TP provided by a network that only supports=20 > MPLS-TP LSPs and > PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or > LSRs), acting as a server for other layer 1, layer 2=20 > and layer 3 > networks (Figure 1). >=20 > 2. MPLS-TP provided by a network that also supports=20 > non-MPLS-TP LSPs > and PWs (i.e. both LSPs and PWs that conform to the transport > profile and those that do not, exist between the PEs),=20 > acting as > a server for other layer 1, layer 2 and layer 3 networks > (Figure 2). >=20 > 3. MPLS-TP as a server layer for client layer traffic of=20 > IP or MPLS > networks which do not use functions of the MPLS transport > profile. For MPLS traffic, the MPLS-TP server layer=20 > network uses > PW switching [RFC5659] or LSP stitching [RFC5150] at=20 > the PE that > terminates the MPLS-TP server layer (Figure 3). >=20 >=20 > I think figure 3 and case 3 as written currently are=20 > making an assumption that a MPLS-TP PE participates in the=20 > "service interface signaling" where the service interface=20 > provided by MPLS-TP is a MPLS LSP or a PW. This is a NNI=20 > model. Perhaps we need two sub-cases of case 3. > One is a UNI model where the MPLS network just sees a P2P or=20 > P2MP link, which is provided by the MPLS-TP network. In this=20 > case mechanisms of section > 3.4.3 are sufficient. The second case is the one which the=20 > current text seems to imply and in that case the MPLS-TP PE=20 > would participate in the MPLS signaling. In this case the=20 > MPLS-TP PE may use LSP hierarchy or LSP stitching to support=20 > the MPLS-LSP as a service interface and may use PW stitching=20 > to support PW as a service interface. >=20 > So I would propose to replace example number 3 above with: >=20 > "3. MPLS-TP as a server layer for client layer traffic of=20 > IP or MPLS > networks which do not use functions of the MPLS transport > profile. Here are two examples of applicability models of this: >=20 > a) The client IP or MPLS network is provided a layer 2 P2P or > P2MP link by the MPLS-TP network. In other words the service > interface is a layer 2 inteface that carries only IP or MPLS > packets. To support this case the MPLS-TP server=20 > layer network uses > the mechanisms of section 3.4.3 to carry IP or MPLS client l > layer traffic over MPLS-TP LSPs" >=20 > b) The client IP or MPLS network is provided a LSP or a PW as a > service interface by the MPLS-TP network. In this case > the MPLS-TP PE would participate in the client MPLS=20 > signaling. > In this case the MPLS-TP PE may use LSP hierarchy or LSP > stitching to support the MPLS-LSP as a service interface and > may use PW stitching to support PW as a service interface > (Figure 3)" >=20 > 4. 3.1 Packet Transport Services >=20 > One objective of MPLS-TP is to enable MPLS networks to=20 > provide packet > transport services with a similar degree of predictability to that > found in existing transport networks. Such packet=20 > transport services > inherit a number of characteristics, defined in [RFC5654]: >=20 > o In an environment where an MPLS-TP layer network is supporting a > client layer network, and the MPLS-TP layer network is supported > by a server layer network then operation of the MPLS-TP layer > network must be possible without any dependencies on either the > server or client layer network. >=20 > o The service provided by the MPLS-TP network to the client is > guaranteed not to fall below the agreed level=20 > regardless of other > client activity. >=20 > o The control and management planes of any client network=20 > layer that > uses the service is isolated from the control and management > planes of the MPLS-TP layer network, where the client network > layer is considered to be the native service of the MPLS-TP > network. >=20 > o Where a client network makes use of an MPLS-TP server that > provides a packet transport service, the level of co-ordination > required between the client and server layer networks is minimal > (preferably no co-ordination will be required). >=20 > o The complete set of packets generated by a client=20 > MPLS(-TP) layer > network using the packet transport service, which may contain > packets that are not MPLS packets (e.g. IP or CLNS packets used > by the control/management plane of the client MPLS(-TP) layer >=20 >=20 >=20 > Bocci, et al. Expires August 8, 2010 =20 > [Page 12] >=20 > Internet-Draft MPLS Transport Profile Framework =20 > February 2010 >=20 >=20 > network), are transported by the MPLS-TP server layer network. >=20 > o The packet transport service enables the MPLS-TP layer network > addressing and other information (e.g. topology) to be=20 > hidden from > any client layer networks using that service, and vice-versa. >=20 > These characteristics imply that a packet transport=20 > service does not > support a connectionless packet-switched forwarding mode. However, > this does not preclude it carrying client traffic associated with a > connectionless service. >=20 > Such packet transport services are very similar to Layer 2 Virtual > Private Networks as defined by the IETF. >=20 > The last sentence should be deleted. It doesn't add=20 > value and is in potential conflict with section 3.4.3. >=20 >=20 > 5. 3.3. Architecture >=20 > MPLS-TP comprises the following architectural elements: >=20 > o A standard MPLS data plane [RFC3031] as profiled in > [I-D.fbb-mpls-tp-data-plane]. >=20 > Standard MPLS data plane also includes RFC 5331 and RFC 5332. > Given draft-fbb is not a WG draft, I don't think we should=20 > add a reference to it here. >=20 >=20 > 6. 3.4.2. Pseudowire Adaptation >=20 > The architecture for an MPLS-TP network that provides PW emulated > services is based on the MPLS [RFC3031] and pseudowire [RFC3985] > architectures. >=20 > I think instead of "PW emulated services", the section=20 > should start with the service interface that requires PWs.=20 > Something like: >=20 > "If the MPLS-TP network provides a layer 2 interface, that=20 > carries both network layer and non-network layer traffic, as=20 > a service interface then a PW is required to support the=20 > service interface. > The PW is a client of the MPLS-TP LSP server layer. The=20 > architecture of a MPLS-TP network that uses such PWs is is=20 > based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures." >=20 > The above is to make it very clear the applicability of=20 > 3.4.2 as compared to 3.4.3. >=20 > Multi-segment pseudowires may optionally be used to > provide a packet transport service, and their use is=20 > consistent with >=20 >=20 >=20 > Bocci, et al. Expires August 8, 2010 =20 > [Page 18] >=20 > Internet-Draft MPLS Transport Profile Framework =20 > February 2010 >=20 >=20 > the MPLS-TP architecture. The use of MS-PWs may be=20 > motivated by, for > example, the requirements specified in [RFC5254]. If MS-PWs are > used, then the MS-PW architecture [RFC5659] also applies. >=20 > Figure 6 shows the architecture for an MPLS-TP network=20 > using single- > segment PWs. >=20 > |<--------------- Emulated Service ----------------->| > | | > | |<-------- Pseudowire -------->| | > | | encapsulated, packet | | > | | transport service | | > | | | | > | | |<------ LSP ------->| | | > | V V V V | > V AC +----+ +-----+ +----+ AC V > +-----+ | | PE1|=3D=3D=3D=3D=3D=3D=3D\ = /=3D=3D=3D=3D=3D=3D=3D=3D| PE2| |=20 > +-----+ > | |----------|.......PW1.| \ /=20 > |............|----------| | > | CE1 | | | | | X | | | |=20 > | CE2 | > | |----------|.......PW2.| / \=20 > |............|----------| | > +-----+ ^ | | |=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D| | |=20 > ^ +-----+ > ^ | +----+ +-----+ +----+ | ^ > | | Provider Edge 1 ^ Provider Edge 2 | | > | | | | | > Customer | P Router =20 > | Customer > Edge 1 | =20 > | Edge 2 > | | > | | > Native service Native service >=20 >=20 > Figure 6: MPLS-TP Architecture (Single Segment PW) >=20 > Figure 7 shows the architecture for an MPLS-TP network when multi- > segment pseudowires are used. Note that as in the SS-PW case, > P-routers may also exist. >=20 > This figure needs to clarify where the MPLS-TP PEs are=20 > and where the "service PEs" are. Or whether PE1 is actually=20 > both the MPLS-TP PE and the service PE. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bocci, et al. Expires August 8, 2010 =20 > [Page 19] >=20 > Internet-Draft MPLS Transport Profile Framework =20 > February 2010 >=20 >=20 > |<----------- Pseudowire encapsulated ------------->| > | packet transport service | > | | > | | > | | > AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC > | V V V V V V | > | +----+ +-----+ +----+ +----+ | > +---+ | |TPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ =20 > /=3D=3D=3D=3D=3D|SPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|TPE2| | +---+ > | |---|......PW1-Seg1.... | \ / |=20 > ......X...PW1-Seg2......|---| | > |CE1| | | | | X | | | | =20 > | | |CE2| > | |---|......PW2-Seg1.... | / \ |=20 > ......X...PW2-Seg2......|---| | > +---+ | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D| |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > | | +---+ > ^ +----+ ^ +-----+ +----+ ^ +----+ ^ > | | ^ | | > | TE LSP | TE LSP | > | P-router | > | | > |<-------------------- Emulated Service ------------------->| >=20 > PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while > PW2-segment1 and PW2-segment2 are segments of another MS-PW >=20 >=20 > Figure 7: MPLS-TP Architecture (Multi-Segment PW) >=20 > The corresponding MPLS-TP protocol stacks including PWs=20 > are shown in > Figure 8. In this figure the Transport Service Layer [RFC5654] is > identified by the PW demultiplexer (Demux) label and the Transport > Path Layer [RFC5654] is identified by the LSP Demux Label. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bocci, et al. Expires August 8, 2010 =20 > [Page 20] >=20 > Internet-Draft MPLS Transport Profile Framework =20 > February 2010 >=20 >=20 > +-------------------+ = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ =20 > /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ > | Client Layer | H OAM PDU H H OAM=20 > PDU H > /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ = H-------------------H =20 > H-------------------H > H PW Encap H H GACh H H =20 > GACh H > H-------------------H H-------------------H =20 > H-------------------H > H PW Demux (S=3D1) H H PW Demux (S=3D1) H H GAL=20 > (S=3D1) H > H-------------------H H-------------------H =20 > H-------------------H > H LSP Demux(s) H H LSP Demux(s) H H LSP=20 > Demux(s) H > \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ =20 > \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ > | Server Layer | | Server Layer | | Server=20 > Layer | > +-------------------+ +-------------------+ =20 > +-------------------+ >=20 > User Traffic PW OAM LSP OAM >=20 > Note: H(ighlighted) indicates the part of the protocol stack=20 > we are considering in this document. >=20 >=20 > Figure 8: MPLS-TP Layer Network using Pseudowires >=20 > PWs and their associated labels may be configured or signaled. See > Section 3.11 for additional details related to configured service > types. See Section 3.9 for additional details related to signaled > service types. >=20 > 7. 3.4.2.1. Pseudowire Based Services >=20 > When providing a Virtual Private Wire Service (VPWS) , Virtual > Private Local Area Network Service (VPLS), Virtual Private=20 > Multicast > Service (VPMS) or Internet Protocol Local Area Network Service > (IPLS), pseudowires must be used to carry the client=20 > service. VPWS, > VLPS, and IPLS are described in [RFC4664]. VPMS is described in > [I-D.ietf-l2vpn-vpms-frmwk-requirements]. >=20 > This section should be deleted. From a MPLS-TP network=20 > view point the service interface, that requires PWs, is a=20 > point-to-point layer 2 interface that carries both network=20 > layer and non-network layer traffic. This is orthogonal to=20 > the service which is being delivered to the end user. Hence=20 > this section doesn't belong here. >=20 >=20 > 8. 3.4.3. Network Layer Adaptation >=20 > MPLS-TP LSPs can be used to transport network layer clients. This > document uses the term Network Layer in the same sense as=20 > it is used > in [RFC3031] and [RFC3032]. The network layer protocols=20 > supported by > [RFC3031] and [RFC3032] can be transported between service > interfaces. Examples are shown in Figure 5 above. Support for > network layer clients follows the MPLS architecture for support of > network layer protocols as specified in [RFC3031] and [RFC3032]. >=20 > With network layer adaptation, the MPLS-TP domain provides either a > uni-directional or bidirectional point-to-point connection between > two PEs in order to deliver a packet transport service to attached > customer edge (CE) nodes. For example, a CE may be an IP, MPLS or >=20 >=20 >=20 > Bocci, et al. Expires August 8, 2010 =20 > [Page 21] >=20 > Internet-Draft MPLS Transport Profile Framework =20 > February 2010 >=20 >=20 > MPLS-TP node. As shown in Figure 9, there is an attachment circuit > between the CE node on the left and its corresponding provider edge > (PE) node which provides the service interface, a bidirectional LSP > across the MPLS-TP network to the corresponding PE node on=20 > the right, > and an attachment circuit between that PE node and the=20 > corresponding > CE node for this service. >=20 > The attachment circuits may be heterogeneous (e.g., any combination > of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads > arrive at the service interface encapsulated in the Layer1/Layer2 > encoding defined for that access link type. It should be=20 > noted that > the set of network layer protocols includes MPLS and hence MPLS > encoded packets with an MPLS label stack (the client MPLS=20 > stack), may > appear at the service interface. >=20 > |<------------- Client Network Layer ------------->| > | | > | |<---- Pkt Xport Service --->| | > | | | | > | | |<-- PSN Tunnel -->| | | > | V V V V | > V AC +----+ +---+ +----+ AC V > +-----+ | |PE1 | | | |PE2 | | =20 > +-----+ > | | |LSP | | | | | | | =20 > | | > | CE1 |----------| = |=3D=3D=3D=3D=3D=3D=3D=3DX=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > |----------| CE2 | > | | ^ |IP | | ^ | | ^ | | | =20 > ^ | | > +-----+ | | | | | | | | | | | =20 > | +-----+ > ^ | +----+ | +---+ | +----+ | | ^ > | | Provider | ^ | Provider | | > | | Edge | | | Edge | | > Customer | 1 | P-router | 2 =20 > | Customer > Edge 1 | TE TE | Edge 2 > | LSP LSP | > | | > Native service Native service >=20 >=20 > Figure 9: MPLS-TP Architecture for Network Layer Clients >=20 > PE1 and PE2 should be specifically labeled as MPLS-TP PEs. >=20 > At the ingress service interface the client packets are received . > The PE pushes one or more labels onto the client packets which are > then label switched over the transport network. =20 > Correspondingly the > egress PE pops any labels added by the MPLS-TP networks=20 > and transmits > the packet for delivery to the attached CE via the egress service > interface. >=20 > 9. 3.6. Generic Associated Channel (G-ACh) >=20 > For correct operation of the OAM it is important that the=20 > OAM packets > fate-share with the data packets. In addition in MPLS-TP it is > necessary to discriminate between user data payloads and=20 > other types > of payload. For example, a packet may be associated with=20 > a Signaling > Communication Channel (SCC), or a channel used for Automatic > Protection Switching (APS) data. This is achieved by carrying such > packets on a generic control channel associated to the LSP, PW or > section. >=20 > Suggest replacing the last sentence with: >=20 > "This is achieved by either carrying such packets in an IP=20 > encapsulation that provides the necessary discrimination, or=20 > by carrying such packets on a generic control channel=20 > associated to the LSP, PW or section. Rest of this section=20 > describes the latter mechanism." >=20 > Also please see related comment in section 3.7. >=20 >=20 > 10. 3.7. Operations, Administration and Maintenance (OAM) >=20 > MPLS-TP must be able to operate in environments where IP=20 > is not used > in the forwarding plane. Therefore, the default mechanism for OAM > demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated > Channel (Section 3.6). Forwarding based on IP addresses=20 > for user or > OAM packets is not required for MPLS-TP. >=20 > [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined > alert mechanisms that enable an MPLS LSR to identify and=20 > process MPLS > OAM packets when the OAM packets are encapsulated in an IP header. > These alert mechanisms are based on TTL expiration and/or use an IP > destination address in the range 127/8 for IPv4 and that same range > embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379].=20 > When the > OAM packets are encapsulated in an IP header, these mechanisms are > the default mechanisms for MPLS networks in general for identifying > MPLS OAM packets. MPLS-TP must be able to operate in an=20 > environments > where IP forwarding is not supported, and thus the G-ACh/GAL is the > default mechanism to demultiplex OAM packets in MPLS-TP. >=20 > The last sentence is in conflict with the following from section > 4.1 of RFC 5586: >=20 > "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms > that enable an MPLS LSR to identify and process MPLS OAM=20 > packets when > these are encapsulated in an IP header. These alert mechanisms are > based, for example, on Time To Live (TTL) expiration and/or on the > use of an IP destination address in the range of=20 > 127.0.0.0/8 or 0:0: > 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. >=20 > These mechanisms are the default mechanisms for=20 > identifying MPLS OAM > packets when encapsulated in an IP header although the mechanism > defined in this document MAY also be used." >=20 > Hence the last sentence of the above paragraph must be removed. >=20 >=20 > rahul >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From mngpl@singnet.com.sg Wed Feb 10 01:43: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 761943A7698; Wed, 10 Feb 2010 01:43:46 -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 44lg2JH--95R; Wed, 10 Feb 2010 01:43:45 -0800 (PST) Received: from comsmtp1.singnet.com.sg (comsmtp1.singnet.com.sg [165.21.101.74]) by core3.amsl.com (Postfix) with ESMTP id 5EFD83A7670; Wed, 10 Feb 2010 01:43:45 -0800 (PST) Received: from pike.singnet.com.sg (pike.singnet.com.sg [165.21.101.112]) by comsmtp1.singnet.com.sg (8.14.1/8.13.6) with ESMTP id o1A9ioUa010166; Wed, 10 Feb 2010 17:44:50 +0800 Received: from pike.singnet.com.sg (localhost.localdomain [127.0.0.1]) by pike.singnet.com.sg (8.14.3/8.14.2) with ESMTP id o1A9igMf003363; Wed, 10 Feb 2010 17:44:52 +0800 Received: (from cooluser@localhost) by pike.singnet.com.sg (8.14.3/8.14.2/Submit) id o1A9ifoM003359; Wed, 10 Feb 2010 17:44:41 +0800 X-Authentication-Warning: pike.singnet.com.sg: cooluser set sender to mngpl@singnet.com.sg using -f To: Loa Andersson Message-ID: <1265795081.4b72800940ab5@discus.singnet.com.sg> Date: Wed, 10 Feb 2010 17:44:41 +0800 (SGT) From: mngpl@singnet.com.sg References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@pi.nu> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: SingNet WebMail Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mngpl@singnet.com.sg List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:43:46 -0000 Hi Loa and the authors, >From what I read, the main key aspect of this draft defines a new ethernet MAC discovery through the use of multicast MAC. The rest of the drafts discuss about specific dataplane implementation that is align with draft-ietf-mpls-tp-framework-10, which calls it profiling. Suggestion, why not put profile details into the framework draft? This improves readability? Or unless there can other type of profiling. /Max --- Loa Andersson wrote: > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From mngpl@singnet.com.sg Wed Feb 10 01:44: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 921A13A6E79; Wed, 10 Feb 2010 01:44:17 -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 cdGO9SYC3iwp; Wed, 10 Feb 2010 01:44:17 -0800 (PST) Received: from comsmtp2.singnet.com.sg (comsmtp2.singnet.com.sg [165.21.101.75]) by core3.amsl.com (Postfix) with ESMTP id D84473A6B82; Wed, 10 Feb 2010 01:44:16 -0800 (PST) Received: from pike.singnet.com.sg (pike.singnet.com.sg [165.21.101.112]) by comsmtp2.singnet.com.sg (8.13.8/8.13.6) with ESMTP id o1A9jRvi028987; Wed, 10 Feb 2010 17:45:27 +0800 Received: from pike.singnet.com.sg (localhost.localdomain [127.0.0.1]) by pike.singnet.com.sg (8.14.3/8.14.2) with ESMTP id o1A9jEEv004779; Wed, 10 Feb 2010 17:45:24 +0800 Received: (from cooluser@localhost) by pike.singnet.com.sg (8.14.3/8.14.2/Submit) id o1A9jEqV004776; Wed, 10 Feb 2010 17:45:14 +0800 X-Authentication-Warning: pike.singnet.com.sg: cooluser set sender to mngpl@singnet.com.sg using -f To: Loa Andersson Message-ID: <1265795114.4b72802ab7a84@discus.singnet.com.sg> Date: Wed, 10 Feb 2010 17:45:14 +0800 (SGT) From: mngpl@singnet.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: SingNet WebMail Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mngpl@singnet.com.sg List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:44:17 -0000 Hi Loa and the authors, >From what I read, the main key aspect of this draft defines a new ethernet MAC discovery through the use of multicast MAC. The rest of the drafts discuss about specific dataplane implementation that is align with draft-ietf-mpls-tp-framework-10, which calls it profiling. Suggestion, why not put profile details into the framework draft? This improves readability? Or unless there can other type of profiling. /Max --- Loa Andersson wrote: > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From lberger@labn.net Wed Feb 10 06:03: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 0372728C1EC for ; Wed, 10 Feb 2010 06:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 1V6H7H8+EdRl for ; Wed, 10 Feb 2010 06:03:08 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id BC68928C1E2 for ; Wed, 10 Feb 2010 06:03:08 -0800 (PST) Received: (qmail 14811 invoked by uid 0); 10 Feb 2010 13:57:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 10 Feb 2010 13:57:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=qtbQrX2U5YwRmQ4c2gTyG/VlepvpdSYDID/NvIeYnIG/Qn2PjsHxxiiNrkCiNpfoklqVopZ4p/IFojW7zrUJ3cT3GFkqFdrGdeMA99osLt9Yk7XJIzsvZsbWgJvABldW; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NfD4T-00008h-No; Wed, 10 Feb 2010 06:57:38 -0700 Message-ID: <4B72BB9C.6060309@labn.net> Date: Wed, 10 Feb 2010 08:58:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 10 Feb 2010 14:03:09 -0000 Neil, I have to say I agree 100% with your comments. Particularly that: (a) that there "should" be "an unambiguous way of identifying when one sublayer stack of LSPs ends" -- personally I think the S-bit is perfect for this purpose, and (b) more importantly, that we're limited (as you say, "clinging") to current MPLS practices. It is really (b), the current usage of the MPLS label stack, that has driven me to pragmatically accept that (a) is not achievable in the current MPLS-TP efforts. Lou On 2/9/2010 4:25 PM, neil.2.harrison@bt.com wrote: > Maarten, Please let us not confuse folks with terms like 'transport > entity'....we all know that MPLS-TP will only be using proper > connections because we want to *deterministically and simply* manage > resource. > > However, you are absolutely right to pick-up on the point that an LSP is > *not necessarily* a layer network. AFAIK we now have no way of telling > from looking at the DP whether a suite of nested LSPs is sublayered or > layered...seems one can mix up sublayering and proper client/server > layering of LSPs at will. > > This is not great architectural design practice IMO but this seems to be > happening because we cannot easily satisfy the real transport > requirement whilst clinging on to some old MPLS behaviours. > > Some while ago I suggested (at least to Stewart) that if folks want to > keep sublayering in MPLS-TP, then we should have an unambiguous way of > identifying when one sublayer stack of LSPs ends (say a client layer > MPLS-TP network belonging to party X) and a different sublayer stack of > LSPs begins (say a server layer MPLS-TP network belonging to party Y). > I suggested we should allocate a globally well-known functional label > from the 0-15 set for this important client/server case. We could also > use the same reserved label in MPLS. Note this is consistent with > respecting consistent CI as the label is globally well-known. > > I still think this idea should be given serious consideration due to the > importance (to operators) of being able to have a quite clear > client/server relationship in MPLS-TP between different operating > parties. > > regards, Neil > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers >> Sent: 09 February 2010 20:50 >> To: 'Rahul Aggarwal'; 'Loa Andersson' >> Cc: mpls@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >> >> Rahul, >> >> The MPLS-TP LSP is not a layer network. The LSP is a >> transport entity within either the transport service layer >> network, or the transport path layer network, or the section >> layer network. >> >> Regards, >> Maarten >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal >> Sent: zaterdag 6 februari 2010 1:00 >> To: Loa Andersson >> Cc: mpls@ietf.org; mpls-tp@ietf.org >> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >> >> >> Here are my LC comments on draft-ietf-mpls-tp-framework-10, >> prefixed by >> : >> >> >> 1. 1.3.4. MPLS-TP Label Switched Path >> >> An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a >> subset of the capabilities of an MPLS LSP in order to meet the >> requirements of an MPLS transport network as set out in [RFC5654]. >> The characteristics of an MPLS-TP LSP are primarily that it: >> >> I would suggest adding: "A MPLS-TP LSP is the lowest >> server layer provided by MPLS-TP. The client layers of a >> MPLS-TP LSP maybe IP, MPLS or PWs. The client layers of a >> MPLS-TP LSP are described in detail in section 3.4" >> >> This is to make the client server relationship in MPLS-TP clearer. >> >> 2. 1.3.10. Additional Definitions and Terminology >> >> Detailed definitions and additional terminology may be found in >> [RFC5654]. >> >> I would suggest a section on "Service Interface". This >> is to clarify the applicability of the use of MPLS-TP LSPs >> and PWs as described in section 3.4. Furhter it is needed to >> clarify what is the interface exposed by MPLS-TP to the >> client network. >> >> "Service Interface >> >> The transport service provided by MPLS-TP is said to be >> provided by a service interface. The following are the >> service interfaces supported by >> MPLS-TP: >> >> - The service interface may a layer 2 interface that carries >> only network layer clients. MPLS-TP LSPs are both necessary >> and sufficient to support this service interface as described >> in section 3.4.3 >> >> - Or the service interface may be a layer 2 interface that >> carries both network layer and non-network layer clients. To >> support this service interface, a PW is required to adapt the >> client traffic received over the service interface. This PW >> in turn is a client of the MPLS-TP server layer. >> This is described in section 3.4.2. >> >> - Or the service interface may be a MPLS LSP or a PW. To >> support this case a MPLS-TP PE participates in the service >> interface signaling." >> >> 3. 1.4. Applicability >> >> MPLS-TP can be used to construct packet transport networks and is >> therefore applicable in any packet transport network >> context. It is >> also applicable to subsets of a packet network where the transport >> network operational model is deemed attractive. The following are >> examples of MPLS-TP applicability models: >> >> 1. MPLS-TP provided by a network that only supports >> MPLS-TP LSPs and >> PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or >> LSRs), acting as a server for other layer 1, layer 2 >> and layer 3 >> networks (Figure 1). >> >> 2. MPLS-TP provided by a network that also supports >> non-MPLS-TP LSPs >> and PWs (i.e. both LSPs and PWs that conform to the transport >> profile and those that do not, exist between the PEs), >> acting as >> a server for other layer 1, layer 2 and layer 3 networks >> (Figure 2). >> >> 3. MPLS-TP as a server layer for client layer traffic of >> IP or MPLS >> networks which do not use functions of the MPLS transport >> profile. For MPLS traffic, the MPLS-TP server layer >> network uses >> PW switching [RFC5659] or LSP stitching [RFC5150] at >> the PE that >> terminates the MPLS-TP server layer (Figure 3). >> >> >> I think figure 3 and case 3 as written currently are >> making an assumption that a MPLS-TP PE participates in the >> "service interface signaling" where the service interface >> provided by MPLS-TP is a MPLS LSP or a PW. This is a NNI >> model. Perhaps we need two sub-cases of case 3. >> One is a UNI model where the MPLS network just sees a P2P or >> P2MP link, which is provided by the MPLS-TP network. In this >> case mechanisms of section >> 3.4.3 are sufficient. The second case is the one which the >> current text seems to imply and in that case the MPLS-TP PE >> would participate in the MPLS signaling. In this case the >> MPLS-TP PE may use LSP hierarchy or LSP stitching to support >> the MPLS-LSP as a service interface and may use PW stitching >> to support PW as a service interface. >> >> So I would propose to replace example number 3 above with: >> >> "3. MPLS-TP as a server layer for client layer traffic of >> IP or MPLS >> networks which do not use functions of the MPLS transport >> profile. Here are two examples of applicability models of this: >> >> a) The client IP or MPLS network is provided a layer 2 P2P or >> P2MP link by the MPLS-TP network. In other words the service >> interface is a layer 2 inteface that carries only IP or MPLS >> packets. To support this case the MPLS-TP server >> layer network uses >> the mechanisms of section 3.4.3 to carry IP or MPLS client l >> layer traffic over MPLS-TP LSPs" >> >> b) The client IP or MPLS network is provided a LSP or a PW as a >> service interface by the MPLS-TP network. In this case >> the MPLS-TP PE would participate in the client MPLS >> signaling. >> In this case the MPLS-TP PE may use LSP hierarchy or LSP >> stitching to support the MPLS-LSP as a service interface and >> may use PW stitching to support PW as a service interface >> (Figure 3)" >> >> 4. 3.1 Packet Transport Services >> >> One objective of MPLS-TP is to enable MPLS networks to >> provide packet >> transport services with a similar degree of predictability to that >> found in existing transport networks. Such packet >> transport services >> inherit a number of characteristics, defined in [RFC5654]: >> >> o In an environment where an MPLS-TP layer network is supporting a >> client layer network, and the MPLS-TP layer network is supported >> by a server layer network then operation of the MPLS-TP layer >> network must be possible without any dependencies on either the >> server or client layer network. >> >> o The service provided by the MPLS-TP network to the client is >> guaranteed not to fall below the agreed level >> regardless of other >> client activity. >> >> o The control and management planes of any client network >> layer that >> uses the service is isolated from the control and management >> planes of the MPLS-TP layer network, where the client network >> layer is considered to be the native service of the MPLS-TP >> network. >> >> o Where a client network makes use of an MPLS-TP server that >> provides a packet transport service, the level of co-ordination >> required between the client and server layer networks is minimal >> (preferably no co-ordination will be required). >> >> o The complete set of packets generated by a client >> MPLS(-TP) layer >> network using the packet transport service, which may contain >> packets that are not MPLS packets (e.g. IP or CLNS packets used >> by the control/management plane of the client MPLS(-TP) layer >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 12] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> network), are transported by the MPLS-TP server layer network. >> >> o The packet transport service enables the MPLS-TP layer network >> addressing and other information (e.g. topology) to be >> hidden from >> any client layer networks using that service, and vice-versa. >> >> These characteristics imply that a packet transport >> service does not >> support a connectionless packet-switched forwarding mode. However, >> this does not preclude it carrying client traffic associated with a >> connectionless service. >> >> Such packet transport services are very similar to Layer 2 Virtual >> Private Networks as defined by the IETF. >> >> The last sentence should be deleted. It doesn't add >> value and is in potential conflict with section 3.4.3. >> >> >> 5. 3.3. Architecture >> >> MPLS-TP comprises the following architectural elements: >> >> o A standard MPLS data plane [RFC3031] as profiled in >> [I-D.fbb-mpls-tp-data-plane]. >> >> Standard MPLS data plane also includes RFC 5331 and RFC 5332. >> Given draft-fbb is not a WG draft, I don't think we should >> add a reference to it here. >> >> >> 6. 3.4.2. Pseudowire Adaptation >> >> The architecture for an MPLS-TP network that provides PW emulated >> services is based on the MPLS [RFC3031] and pseudowire [RFC3985] >> architectures. >> >> I think instead of "PW emulated services", the section >> should start with the service interface that requires PWs. >> Something like: >> >> "If the MPLS-TP network provides a layer 2 interface, that >> carries both network layer and non-network layer traffic, as >> a service interface then a PW is required to support the >> service interface. >> The PW is a client of the MPLS-TP LSP server layer. The >> architecture of a MPLS-TP network that uses such PWs is is >> based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures." >> >> The above is to make it very clear the applicability of >> 3.4.2 as compared to 3.4.3. >> >> Multi-segment pseudowires may optionally be used to >> provide a packet transport service, and their use is >> consistent with >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 18] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> the MPLS-TP architecture. The use of MS-PWs may be >> motivated by, for >> example, the requirements specified in [RFC5254]. If MS-PWs are >> used, then the MS-PW architecture [RFC5659] also applies. >> >> Figure 6 shows the architecture for an MPLS-TP network >> using single- >> segment PWs. >> >> |<--------------- Emulated Service ----------------->| >> | | >> | |<-------- Pseudowire -------->| | >> | | encapsulated, packet | | >> | | transport service | | >> | | | | >> | | |<------ LSP ------->| | | >> | V V V V | >> V AC +----+ +-----+ +----+ AC V >> +-----+ | | PE1|=======\ /========| PE2| | >> +-----+ >> | |----------|.......PW1.| \ / >> |............|----------| | >> | CE1 | | | | | X | | | | >> | CE2 | >> | |----------|.......PW2.| / \ >> |............|----------| | >> +-----+ ^ | | |=======/ \========| | | >> ^ +-----+ >> ^ | +----+ +-----+ +----+ | ^ >> | | Provider Edge 1 ^ Provider Edge 2 | | >> | | | | | >> Customer | P Router >> | Customer >> Edge 1 | >> | Edge 2 >> | | >> | | >> Native service Native service >> >> >> Figure 6: MPLS-TP Architecture (Single Segment PW) >> >> Figure 7 shows the architecture for an MPLS-TP network when multi- >> segment pseudowires are used. Note that as in the SS-PW case, >> P-routers may also exist. >> >> This figure needs to clarify where the MPLS-TP PEs are >> and where the "service PEs" are. Or whether PE1 is actually >> both the MPLS-TP PE and the service PE. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 19] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> |<----------- Pseudowire encapsulated ------------->| >> | packet transport service | >> | | >> | | >> | | >> AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC >> | V V V V V V | >> | +----+ +-----+ +----+ +----+ | >> +---+ | |TPE1|===============\ >> /=====|SPE1|==========|TPE2| | +---+ >> | |---|......PW1-Seg1.... | \ / | >> ......X...PW1-Seg2......|---| | >> |CE1| | | | | X | | | | >> | | |CE2| >> | |---|......PW2-Seg1.... | / \ | >> ......X...PW2-Seg2......|---| | >> +---+ | | |===============/ \=====| |==========| >> | | +---+ >> ^ +----+ ^ +-----+ +----+ ^ +----+ ^ >> | | ^ | | >> | TE LSP | TE LSP | >> | P-router | >> | | >> |<-------------------- Emulated Service ------------------->| >> >> PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while >> PW2-segment1 and PW2-segment2 are segments of another MS-PW >> >> >> Figure 7: MPLS-TP Architecture (Multi-Segment PW) >> >> The corresponding MPLS-TP protocol stacks including PWs >> are shown in >> Figure 8. In this figure the Transport Service Layer [RFC5654] is >> identified by the PW demultiplexer (Demux) label and the Transport >> Path Layer [RFC5654] is identified by the LSP Demux Label. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 20] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> +-------------------+ /===================\ >> /===================\ >> | Client Layer | H OAM PDU H H OAM >> PDU H >> /===================\ H-------------------H >> H-------------------H >> H PW Encap H H GACh H H >> GACh H >> H-------------------H H-------------------H >> H-------------------H >> H PW Demux (S=1) H H PW Demux (S=1) H H GAL >> (S=1) H >> H-------------------H H-------------------H >> H-------------------H >> H LSP Demux(s) H H LSP Demux(s) H H LSP >> Demux(s) H >> \===================/ \===================/ >> \===================/ >> | Server Layer | | Server Layer | | Server >> Layer | >> +-------------------+ +-------------------+ >> +-------------------+ >> >> User Traffic PW OAM LSP OAM >> >> Note: H(ighlighted) indicates the part of the protocol stack >> we are considering in this document. >> >> >> Figure 8: MPLS-TP Layer Network using Pseudowires >> >> PWs and their associated labels may be configured or signaled. See >> Section 3.11 for additional details related to configured service >> types. See Section 3.9 for additional details related to signaled >> service types. >> >> 7. 3.4.2.1. Pseudowire Based Services >> >> When providing a Virtual Private Wire Service (VPWS) , Virtual >> Private Local Area Network Service (VPLS), Virtual Private >> Multicast >> Service (VPMS) or Internet Protocol Local Area Network Service >> (IPLS), pseudowires must be used to carry the client >> service. VPWS, >> VLPS, and IPLS are described in [RFC4664]. VPMS is described in >> [I-D.ietf-l2vpn-vpms-frmwk-requirements]. >> >> This section should be deleted. From a MPLS-TP network >> view point the service interface, that requires PWs, is a >> point-to-point layer 2 interface that carries both network >> layer and non-network layer traffic. This is orthogonal to >> the service which is being delivered to the end user. Hence >> this section doesn't belong here. >> >> >> 8. 3.4.3. Network Layer Adaptation >> >> MPLS-TP LSPs can be used to transport network layer clients. This >> document uses the term Network Layer in the same sense as >> it is used >> in [RFC3031] and [RFC3032]. The network layer protocols >> supported by >> [RFC3031] and [RFC3032] can be transported between service >> interfaces. Examples are shown in Figure 5 above. Support for >> network layer clients follows the MPLS architecture for support of >> network layer protocols as specified in [RFC3031] and [RFC3032]. >> >> With network layer adaptation, the MPLS-TP domain provides either a >> uni-directional or bidirectional point-to-point connection between >> two PEs in order to deliver a packet transport service to attached >> customer edge (CE) nodes. For example, a CE may be an IP, MPLS or >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 21] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> MPLS-TP node. As shown in Figure 9, there is an attachment circuit >> between the CE node on the left and its corresponding provider edge >> (PE) node which provides the service interface, a bidirectional LSP >> across the MPLS-TP network to the corresponding PE node on >> the right, >> and an attachment circuit between that PE node and the >> corresponding >> CE node for this service. >> >> The attachment circuits may be heterogeneous (e.g., any combination >> of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads >> arrive at the service interface encapsulated in the Layer1/Layer2 >> encoding defined for that access link type. It should be >> noted that >> the set of network layer protocols includes MPLS and hence MPLS >> encoded packets with an MPLS label stack (the client MPLS >> stack), may >> appear at the service interface. >> >> |<------------- Client Network Layer ------------->| >> | | >> | |<---- Pkt Xport Service --->| | >> | | | | >> | | |<-- PSN Tunnel -->| | | >> | V V V V | >> V AC +----+ +---+ +----+ AC V >> +-----+ | |PE1 | | | |PE2 | | >> +-----+ >> | | |LSP | | | | | | | >> | | >> | CE1 |----------| |========X=========| >> |----------| CE2 | >> | | ^ |IP | | ^ | | ^ | | | >> ^ | | >> +-----+ | | | | | | | | | | | >> | +-----+ >> ^ | +----+ | +---+ | +----+ | | ^ >> | | Provider | ^ | Provider | | >> | | Edge | | | Edge | | >> Customer | 1 | P-router | 2 >> | Customer >> Edge 1 | TE TE | Edge 2 >> | LSP LSP | >> | | >> Native service Native service >> >> >> Figure 9: MPLS-TP Architecture for Network Layer Clients >> >> PE1 and PE2 should be specifically labeled as MPLS-TP PEs. >> >> At the ingress service interface the client packets are received . >> The PE pushes one or more labels onto the client packets which are >> then label switched over the transport network. >> Correspondingly the >> egress PE pops any labels added by the MPLS-TP networks >> and transmits >> the packet for delivery to the attached CE via the egress service >> interface. >> >> 9. 3.6. Generic Associated Channel (G-ACh) >> >> For correct operation of the OAM it is important that the >> OAM packets >> fate-share with the data packets. In addition in MPLS-TP it is >> necessary to discriminate between user data payloads and >> other types >> of payload. For example, a packet may be associated with >> a Signaling >> Communication Channel (SCC), or a channel used for Automatic >> Protection Switching (APS) data. This is achieved by carrying such >> packets on a generic control channel associated to the LSP, PW or >> section. >> >> Suggest replacing the last sentence with: >> >> "This is achieved by either carrying such packets in an IP >> encapsulation that provides the necessary discrimination, or >> by carrying such packets on a generic control channel >> associated to the LSP, PW or section. Rest of this section >> describes the latter mechanism." >> >> Also please see related comment in section 3.7. >> >> >> 10. 3.7. Operations, Administration and Maintenance (OAM) >> >> MPLS-TP must be able to operate in environments where IP >> is not used >> in the forwarding plane. Therefore, the default mechanism for OAM >> demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated >> Channel (Section 3.6). Forwarding based on IP addresses >> for user or >> OAM packets is not required for MPLS-TP. >> >> [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined >> alert mechanisms that enable an MPLS LSR to identify and >> process MPLS >> OAM packets when the OAM packets are encapsulated in an IP header. >> These alert mechanisms are based on TTL expiration and/or use an IP >> destination address in the range 127/8 for IPv4 and that same range >> embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. >> When the >> OAM packets are encapsulated in an IP header, these mechanisms are >> the default mechanisms for MPLS networks in general for identifying >> MPLS OAM packets. MPLS-TP must be able to operate in an >> environments >> where IP forwarding is not supported, and thus the G-ACh/GAL is the >> default mechanism to demultiplex OAM packets in MPLS-TP. >> >> The last sentence is in conflict with the following from section >> 4.1 of RFC 5586: >> >> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms >> that enable an MPLS LSR to identify and process MPLS OAM >> packets when >> these are encapsulated in an IP header. These alert mechanisms are >> based, for example, on Time To Live (TTL) expiration and/or on the >> use of an IP destination address in the range of >> 127.0.0.0/8 or 0:0: >> 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. >> >> These mechanisms are the default mechanisms for >> identifying MPLS OAM >> packets when encapsulated in an IP header although the mechanism >> defined in this document MAY also be used." >> >> Hence the last sentence of the above paragraph must be removed. >> >> >> rahul >> >> _______________________________________________ >> 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 >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > From neil.2.harrison@bt.com Wed Feb 10 06:12:59 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 6821E3A71D6; Wed, 10 Feb 2010 06:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, 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 XOnf1-0rxPWG; Wed, 10 Feb 2010 06:12:56 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A040C3A76E7; Wed, 10 Feb 2010 06:12:55 -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); Wed, 10 Feb 2010 14:14:05 +0000 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, 10 Feb 2010 14:14:01 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C059A4A1A@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <4B72BB9C.6060309@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 Thread-Index: AcqqWQYORXp+HrXoS8aCsoRJYHk3QQAAGibg From: To: X-OriginalArrivalTime: 10 Feb 2010 14:14:05.0540 (UTC) FILETIME=[4DACDA40:01CAAA5B] Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 10 Feb 2010 14:12:59 -0000 Thanks Lou, Just to be really clear here: - standards must look to the future...they should not be hampered by poor/wrong arch decisions made in the past - MPLS-TP is supposed to addressing a transport network role.....a transport network does not require the sublayering behaviour of MPLS (nor PWs, nor TTL...) but not being able to clearly differentiate sublayering and (self) layering is almost unforgivable IMO. This should have been a top priority requirement of this work.=20 - the S bit is a non-issue in what I have proposed. One can have multiple S bits (ie set in the reserved label header plus at true end of stack) or just the single S bit at the end of the stack. In fact what I originally proposed was the latter to be in-keeping with the original MPLS premise of just a single occurrence of the S bit...so we could keep sublayering whilst introducing very efficient layering. - you can recurse the idea as many times as is necessary. The reserved label idea also has many operational advantages, eg: - no need to run a degenerate 1-hop Ethernet/PW network (as per Stewart's original ID on this client/server issue)...less to configure, less to go wrong, less cost. - one can use any technology to connect MPLS client and server layer nodes at each end. - the label does not cause a lack of consistent characteristic information in the DP as it has a globally well-known semantic. regards, Neil=09 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: 10 February 2010 13:59 > To: Harrison,N,Neil,DKQ7 R > Cc: maarten.vissers@huawei.com; rahul@juniper.net; loa@pi.nu;=20 > mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >=20 > Neil, > I have to say I agree 100% with your comments. =20 > Particularly that: >=20 > (a) that there "should" be "an unambiguous way of identifying=20 > when one sublayer stack of LSPs ends" -- personally I think=20 > the S-bit is perfect for this purpose, and >=20 > (b) more importantly, that we're limited (as you say,=20 > "clinging") to current MPLS practices. >=20 > It is really (b), the current usage of the MPLS label stack,=20 > that has driven me to pragmatically accept that (a) is not=20 > achievable in the current MPLS-TP efforts. >=20 > Lou >=20 > On 2/9/2010 4:25 PM, neil.2.harrison@bt.com wrote: > > Maarten, Please let us not confuse folks with terms like=20 > 'transport=20 > > entity'....we all know that MPLS-TP will only be using proper=20 > > connections because we want to *deterministically and=20 > simply* manage=20 > > resource. > >=20 > > However, you are absolutely right to pick-up on the point=20 > that an LSP=20 > > is *not necessarily* a layer network. AFAIK we now have no way of=20 > > telling from looking at the DP whether a suite of nested LSPs is=20 > > sublayered or layered...seems one can mix up sublayering and proper=20 > > client/server layering of LSPs at will. > >=20 > > This is not great architectural design practice IMO but=20 > this seems to=20 > > be happening because we cannot easily satisfy the real transport=20 > > requirement whilst clinging on to some old MPLS behaviours. > >=20 > > Some while ago I suggested (at least to Stewart) that if=20 > folks want to=20 > > keep sublayering in MPLS-TP, then we should have an=20 > unambiguous way of=20 > > identifying when one sublayer stack of LSPs ends (say a=20 > client layer=20 > > MPLS-TP network belonging to party X) and a different=20 > sublayer stack=20 > > of LSPs begins (say a server layer MPLS-TP network=20 > belonging to party Y). > > I suggested we should allocate a globally well-known=20 > functional label=20 > > from the 0-15 set for this important client/server case. We could=20 > > also use the same reserved label in MPLS. Note this is consistent=20 > > with respecting consistent CI as the label is globally well-known. > >=20 > > I still think this idea should be given serious=20 > consideration due to=20 > > the importance (to operators) of being able to have a quite clear=20 > > client/server relationship in MPLS-TP between different operating=20 > > parties. > >=20 > > regards, Neil > >=20 > >> -----Original Message----- > >> From: mpls-tp-bounces@ietf.org > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > >> Sent: 09 February 2010 20:50 > >> To: 'Rahul Aggarwal'; 'Loa Andersson' > >> Cc: mpls@ietf.org; mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] LC comments on=20 > draft-ietf-mpls-tp-framework-10 > >> > >> Rahul, > >> > >> The MPLS-TP LSP is not a layer network. The LSP is a=20 > transport entity=20 > >> within either the transport service layer network, or the=20 > transport=20 > >> path layer network, or the section layer network. > >> > >> Regards, > >> Maarten > >> > >> -----Original Message----- > >> From: mpls-tp-bounces@ietf.org > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal > >> Sent: zaterdag 6 februari 2010 1:00 > >> To: Loa Andersson > >> Cc: mpls@ietf.org; mpls-tp@ietf.org > >> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 > >> > >> > >> Here are my LC comments on=20 > draft-ietf-mpls-tp-framework-10, prefixed=20 > >> by > >> : > >> > >> > >> 1. 1.3.4. MPLS-TP Label Switched Path > >> > >> An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP=20 > that uses a > >> subset of the capabilities of an MPLS LSP in order to meet the > >> requirements of an MPLS transport network as set out in=20 > [RFC5654]. > >> The characteristics of an MPLS-TP LSP are primarily that it: > >> > >> I would suggest adding: "A MPLS-TP LSP is the lowest server=20 > >> layer provided by MPLS-TP. The client layers of a MPLS-TP=20 > LSP maybe=20 > >> IP, MPLS or PWs. The client layers of a MPLS-TP LSP are=20 > described in=20 > >> detail in section 3.4" > >> > >> This is to make the client server relationship in MPLS-TP clearer. > >> > >> 2. 1.3.10. Additional Definitions and Terminology > >> > >> Detailed definitions and additional terminology may be found in > >> [RFC5654]. > >> > >> I would suggest a section on "Service Interface". This is to=20 > >> clarify the applicability of the use of MPLS-TP LSPs and PWs as=20 > >> described in section 3.4. Furhter it is needed to clarify=20 > what is the=20 > >> interface exposed by MPLS-TP to the client network. > >> > >> "Service Interface > >> > >> The transport service provided by MPLS-TP is said to be=20 > provided by a=20 > >> service interface. The following are the service=20 > interfaces supported=20 > >> by > >> MPLS-TP: > >> > >> - The service interface may a layer 2 interface that carries only=20 > >> network layer clients. MPLS-TP LSPs are both necessary and=20 > sufficient=20 > >> to support this service interface as described in section 3.4.3 > >> > >> - Or the service interface may be a layer 2 interface that carries=20 > >> both network layer and non-network layer clients. To support this=20 > >> service interface, a PW is required to adapt the client traffic=20 > >> received over the service interface. This PW in turn is a=20 > client of=20 > >> the MPLS-TP server layer. > >> This is described in section 3.4.2. > >> > >> - Or the service interface may be a MPLS LSP or a PW. To=20 > support this=20 > >> case a MPLS-TP PE participates in the service interface signaling." > >> > >> 3. 1.4. Applicability > >> > >> MPLS-TP can be used to construct packet transport=20 > networks and is > >> therefore applicable in any packet transport network=20 > context. It=20 > >> is > >> also applicable to subsets of a packet network where=20 > the transport > >> network operational model is deemed attractive. The=20 > following are > >> examples of MPLS-TP applicability models: > >> > >> 1. MPLS-TP provided by a network that only supports=20 > MPLS-TP LSPs=20 > >> and > >> PWs (i.e. Only MPLS-TP LSPs and PWs exist between=20 > the PEs or > >> LSRs), acting as a server for other layer 1, layer=20 > 2 and layer=20 > >> 3 > >> networks (Figure 1). > >> > >> 2. MPLS-TP provided by a network that also supports=20 > non-MPLS-TP=20 > >> LSPs > >> and PWs (i.e. both LSPs and PWs that conform to the=20 > transport > >> profile and those that do not, exist between the=20 > PEs), acting=20 > >> as > >> a server for other layer 1, layer 2 and layer 3 networks > >> (Figure 2). > >> > >> 3. MPLS-TP as a server layer for client layer traffic of IP or=20 > >> MPLS > >> networks which do not use functions of the MPLS transport > >> profile. For MPLS traffic, the MPLS-TP server=20 > layer network=20 > >> uses > >> PW switching [RFC5659] or LSP stitching [RFC5150] at the PE=20 > >> that > >> terminates the MPLS-TP server layer (Figure 3). > >> > >> > >> I think figure 3 and case 3 as written currently are=20 > making an=20 > >> assumption that a MPLS-TP PE participates in the "service=20 > interface=20 > >> signaling" where the service interface provided by MPLS-TP=20 > is a MPLS=20 > >> LSP or a PW. This is a NNI model. Perhaps we need two sub-cases of=20 > >> case 3. > >> One is a UNI model where the MPLS network just sees a P2P or P2MP=20 > >> link, which is provided by the MPLS-TP network. In this case=20 > >> mechanisms of section > >> 3.4.3 are sufficient. The second case is the one which the current=20 > >> text seems to imply and in that case the MPLS-TP PE would=20 > participate=20 > >> in the MPLS signaling. In this case the MPLS-TP PE may use LSP=20 > >> hierarchy or LSP stitching to support the MPLS-LSP as a service=20 > >> interface and may use PW stitching to support PW as a service=20 > >> interface. > >> > >> So I would propose to replace example number 3 above with: > >> > >> "3. MPLS-TP as a server layer for client layer traffic=20 > of IP or=20 > >> MPLS > >> networks which do not use functions of the MPLS transport > >> profile. Here are two examples of applicability=20 > models of this: > >> > >> a) The client IP or MPLS network is provided a=20 > layer 2 P2P or > >> P2MP link by the MPLS-TP network. In other words=20 > the service > >> interface is a layer 2 inteface that carries=20 > only IP or MPLS > >> packets. To support this case the MPLS-TP server layer=20 > >> network uses > >> the mechanisms of section 3.4.3 to carry IP or=20 > MPLS client l > >> layer traffic over MPLS-TP LSPs" > >> > >> b) The client IP or MPLS network is provided a LSP=20 > or a PW as a > >> service interface by the MPLS-TP network. In this case > >> the MPLS-TP PE would participate in the client MPLS=20 > >> signaling. > >> In this case the MPLS-TP PE may use LSP hierarchy or LSP > >> stitching to support the MPLS-LSP as a service=20 > interface and > >> may use PW stitching to support PW as a service interface > >> (Figure 3)" > >> > >> 4. 3.1 Packet Transport Services > >> > >> One objective of MPLS-TP is to enable MPLS networks to provide=20 > >> packet > >> transport services with a similar degree of=20 > predictability to that > >> found in existing transport networks. Such packet transport=20 > >> services > >> inherit a number of characteristics, defined in [RFC5654]: > >> > >> o In an environment where an MPLS-TP layer network is=20 > supporting a > >> client layer network, and the MPLS-TP layer network=20 > is supported > >> by a server layer network then operation of the MPLS-TP layer > >> network must be possible without any dependencies on=20 > either the > >> server or client layer network. > >> > >> o The service provided by the MPLS-TP network to the client is > >> guaranteed not to fall below the agreed level regardless of=20 > >> other > >> client activity. > >> > >> o The control and management planes of any client=20 > network layer=20 > >> that > >> uses the service is isolated from the control and management > >> planes of the MPLS-TP layer network, where the client network > >> layer is considered to be the native service of the MPLS-TP > >> network. > >> > >> o Where a client network makes use of an MPLS-TP server that > >> provides a packet transport service, the level of=20 > co-ordination > >> required between the client and server layer=20 > networks is minimal > >> (preferably no co-ordination will be required). > >> > >> o The complete set of packets generated by a client > >> MPLS(-TP) layer > >> network using the packet transport service, which may contain > >> packets that are not MPLS packets (e.g. IP or CLNS=20 > packets used > >> by the control/management plane of the client MPLS(-TP) layer > >> > >> > >> > >> Bocci, et al. Expires August 8, 2010 =20 > >> [Page 12] > >> > >> Internet-Draft MPLS Transport Profile Framework =20 > >> February 2010 > >> > >> > >> network), are transported by the MPLS-TP server=20 > layer network. > >> > >> o The packet transport service enables the MPLS-TP=20 > layer network > >> addressing and other information (e.g. topology) to=20 > be hidden=20 > >> from > >> any client layer networks using that service, and vice-versa. > >> > >> These characteristics imply that a packet transport=20 > service does=20 > >> not > >> support a connectionless packet-switched forwarding=20 > mode. However, > >> this does not preclude it carrying client traffic=20 > associated with a > >> connectionless service. > >> > >> Such packet transport services are very similar to=20 > Layer 2 Virtual > >> Private Networks as defined by the IETF. > >> > >> The last sentence should be deleted. It doesn't add=20 > value and is=20 > >> in potential conflict with section 3.4.3. > >> > >> > >> 5. 3.3. Architecture > >> > >> MPLS-TP comprises the following architectural elements: > >> > >> o A standard MPLS data plane [RFC3031] as profiled in > >> [I-D.fbb-mpls-tp-data-plane]. > >> > >> Standard MPLS data plane also includes RFC 5331 and RFC 5332. > >> Given draft-fbb is not a WG draft, I don't think we should add a=20 > >> reference to it here. > >> > >> > >> 6. 3.4.2. Pseudowire Adaptation > >> > >> The architecture for an MPLS-TP network that provides=20 > PW emulated > >> services is based on the MPLS [RFC3031] and pseudowire [RFC3985] > >> architectures. > >> > >> I think instead of "PW emulated services", the section should=20 > >> start with the service interface that requires PWs. > >> Something like: > >> > >> "If the MPLS-TP network provides a layer 2 interface, that carries=20 > >> both network layer and non-network layer traffic, as a service=20 > >> interface then a PW is required to support the service interface. > >> The PW is a client of the MPLS-TP LSP server layer. The=20 > architecture=20 > >> of a MPLS-TP network that uses such PWs is is based on the MPLS=20 > >> [RFC3031] and pseudowire [RFC3985] architectures." > >> > >> The above is to make it very clear the applicability of > >> 3.4.2 as compared to 3.4.3. > >> > >> Multi-segment pseudowires may optionally be used to > >> provide a packet transport service, and their use is consistent=20 > >> with > >> > >> > >> > >> Bocci, et al. Expires August 8, 2010 =20 > >> [Page 18] > >> > >> Internet-Draft MPLS Transport Profile Framework =20 > >> February 2010 > >> > >> > >> the MPLS-TP architecture. The use of MS-PWs may be=20 > motivated by,=20 > >> for > >> example, the requirements specified in [RFC5254]. If MS-PWs are > >> used, then the MS-PW architecture [RFC5659] also applies. > >> > >> Figure 6 shows the architecture for an MPLS-TP network using=20 > >> single- > >> segment PWs. > >> > >> |<--------------- Emulated Service ----------------->| > >> | | > >> | |<-------- Pseudowire -------->| | > >> | | encapsulated, packet | | > >> | | transport service | | > >> | | | | > >> | | |<------ LSP ------->| | | > >> | V V V V | > >> V AC +----+ +-----+ +----+ AC V > >> +-----+ | | PE1|=3D=3D=3D=3D=3D=3D=3D\ = /=3D=3D=3D=3D=3D=3D=3D=3D| PE2| |=20 > >> +-----+ > >> | |----------|.......PW1.| \ /=20 > >> |............|----------| | > >> | CE1 | | | | | X | | | |=20 > >> | CE2 | > >> | |----------|.......PW2.| / \=20 > >> |............|----------| | > >> +-----+ ^ | | |=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D| | |=20 > >> ^ +-----+ > >> ^ | +----+ +-----+ +----+ | ^ > >> | | Provider Edge 1 ^ Provider Edge 2 | | > >> | | | | | > >> Customer | P Router =20 > >> | Customer > >> Edge 1 | =20 > >> | Edge 2 > >> | | > >> | | > >> Native service =20 > Native service > >> > >> > >> Figure 6: MPLS-TP Architecture (Single Segment PW) > >> > >> Figure 7 shows the architecture for an MPLS-TP network=20 > when multi- > >> segment pseudowires are used. Note that as in the SS-PW case, > >> P-routers may also exist. > >> > >> This figure needs to clarify where the MPLS-TP PEs=20 > are and where=20 > >> the "service PEs" are. Or whether PE1 is actually both the=20 > MPLS-TP PE=20 > >> and the service PE. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Bocci, et al. Expires August 8, 2010 =20 > >> [Page 19] > >> > >> Internet-Draft MPLS Transport Profile Framework =20 > >> February 2010 > >> > >> > >> |<----------- Pseudowire encapsulated ------------->| > >> | packet transport service | > >> | | > >> | | > >> | | > >> AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC > >> | V V V V V V | > >> | +----+ +-----+ +----+ +----+ | > >> +---+ | |TPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ =20 > >> /=3D=3D=3D=3D=3D|SPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|TPE2| | +---+ > >> | |---|......PW1-Seg1.... | \ / |=20 > >> ......X...PW1-Seg2......|---| | > >> |CE1| | | | | X | | | | =20 > >> | | |CE2| > >> | |---|......PW2-Seg1.... | / \ |=20 > >> ......X...PW2-Seg2......|---| | > >> +---+ | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D| |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > >> | | +---+ > >> ^ +----+ ^ +-----+ +----+ ^ =20 > +----+ ^ > >> | | ^ | =20 > | > >> | TE LSP | TE LSP =20 > | > >> | P-router =20 > | > >> | =20 > | > >> |<-------------------- Emulated Service=20 > ------------------->| > >> > >> PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while > >> PW2-segment1 and PW2-segment2 are segments of another MS-PW > >> > >> > >> Figure 7: MPLS-TP Architecture (Multi-Segment PW) > >> > >> The corresponding MPLS-TP protocol stacks including PWs=20 > are shown=20 > >> in > >> Figure 8. In this figure the Transport Service Layer=20 > [RFC5654] is > >> identified by the PW demultiplexer (Demux) label and=20 > the Transport > >> Path Layer [RFC5654] is identified by the LSP Demux Label. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Bocci, et al. Expires August 8, 2010 =20 > >> [Page 20] > >> > >> Internet-Draft MPLS Transport Profile Framework =20 > >> February 2010 > >> > >> > >> +-------------------+ = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ =20 > >> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ > >> | Client Layer | H OAM PDU H H OAM=20 > >> PDU H > >> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ = H-------------------H =20 > >> H-------------------H > >> H PW Encap H H GACh H H =20 > >> GACh H > >> H-------------------H H-------------------H =20 > >> H-------------------H > >> H PW Demux (S=3D1) H H PW Demux (S=3D1) H H GAL=20 > >> (S=3D1) H > >> H-------------------H H-------------------H =20 > >> H-------------------H > >> H LSP Demux(s) H H LSP Demux(s) H H LSP=20 > >> Demux(s) H > >> \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ =20 > >> \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ > >> | Server Layer | | Server Layer | | Server=20 > >> Layer | > >> +-------------------+ +-------------------+ =20 > >> +-------------------+ > >> > >> User Traffic PW OAM LSP OAM > >> > >> Note: H(ighlighted) indicates the part of the protocol=20 > stack we are=20 > >> considering in this document. > >> > >> > >> Figure 8: MPLS-TP Layer Network using Pseudowires > >> > >> PWs and their associated labels may be configured or=20 > signaled. See > >> Section 3.11 for additional details related to=20 > configured service > >> types. See Section 3.9 for additional details related=20 > to signaled > >> service types. > >> > >> 7. 3.4.2.1. Pseudowire Based Services > >> > >> When providing a Virtual Private Wire Service (VPWS) , Virtual > >> Private Local Area Network Service (VPLS), Virtual Private=20 > >> Multicast > >> Service (VPMS) or Internet Protocol Local Area Network Service > >> (IPLS), pseudowires must be used to carry the client service. =20 > >> VPWS, > >> VLPS, and IPLS are described in [RFC4664]. VPMS is described in > >> [I-D.ietf-l2vpn-vpms-frmwk-requirements]. > >> > >> This section should be deleted. From a MPLS-TP network view=20 > >> point the service interface, that requires PWs, is a=20 > point-to-point=20 > >> layer 2 interface that carries both network layer and non-network=20 > >> layer traffic. This is orthogonal to the service which is being=20 > >> delivered to the end user. Hence this section doesn't belong here. > >> > >> > >> 8. 3.4.3. Network Layer Adaptation > >> > >> MPLS-TP LSPs can be used to transport network layer=20 > clients. This > >> document uses the term Network Layer in the same sense as it is=20 > >> used > >> in [RFC3031] and [RFC3032]. The network layer=20 > protocols supported=20 > >> by > >> [RFC3031] and [RFC3032] can be transported between service > >> interfaces. Examples are shown in Figure 5 above. Support for > >> network layer clients follows the MPLS architecture for=20 > support of > >> network layer protocols as specified in [RFC3031] and [RFC3032]. > >> > >> With network layer adaptation, the MPLS-TP domain=20 > provides either a > >> uni-directional or bidirectional point-to-point=20 > connection between > >> two PEs in order to deliver a packet transport service=20 > to attached > >> customer edge (CE) nodes. For example, a CE may be an=20 > IP, MPLS or > >> > >> > >> > >> Bocci, et al. Expires August 8, 2010 =20 > >> [Page 21] > >> > >> Internet-Draft MPLS Transport Profile Framework =20 > >> February 2010 > >> > >> > >> MPLS-TP node. As shown in Figure 9, there is an=20 > attachment circuit > >> between the CE node on the left and its corresponding=20 > provider edge > >> (PE) node which provides the service interface, a=20 > bidirectional LSP > >> across the MPLS-TP network to the corresponding PE node on the=20 > >> right, > >> and an attachment circuit between that PE node and the=20 > >> corresponding > >> CE node for this service. > >> > >> The attachment circuits may be heterogeneous (e.g., any=20 > combination > >> of SDH, PPP, Frame Relay, etc.) and network layer=20 > protocol payloads > >> arrive at the service interface encapsulated in the=20 > Layer1/Layer2 > >> encoding defined for that access link type. It should be noted=20 > >> that > >> the set of network layer protocols includes MPLS and hence MPLS > >> encoded packets with an MPLS label stack (the client=20 > MPLS stack),=20 > >> may > >> appear at the service interface. > >> > >> |<------------- Client Network Layer ------------->| > >> | | > >> | |<---- Pkt Xport Service --->| | > >> | | | | > >> | | |<-- PSN Tunnel -->| | | > >> | V V V V | > >> V AC +----+ +---+ +----+ AC V > >> +-----+ | |PE1 | | | |PE2 | | =20 > >> +-----+ > >> | | |LSP | | | | | | | =20 > >> | | > >> | CE1 |----------| = |=3D=3D=3D=3D=3D=3D=3D=3DX=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > >> |----------| CE2 | > >> | | ^ |IP | | ^ | | ^ | | | =20 > >> ^ | | > >> +-----+ | | | | | | | | | | | =20 > >> | +-----+ > >> ^ | +----+ | +---+ | +----+ | | ^ > >> | | Provider | ^ | Provider | | > >> | | Edge | | | Edge | | > >> Customer | 1 | P-router | 2 =20 > >> | Customer > >> Edge 1 | TE TE =20 > | Edge 2 > >> | LSP LSP | > >> | | > >> Native service =20 > Native service > >> > >> > >> Figure 9: MPLS-TP Architecture for Network Layer Clients > >> > >> PE1 and PE2 should be specifically labeled as MPLS-TP PEs. > >> > >> At the ingress service interface the client packets are=20 > received . > >> The PE pushes one or more labels onto the client=20 > packets which are > >> then label switched over the transport network. =20 > >> Correspondingly the > >> egress PE pops any labels added by the MPLS-TP networks and=20 > >> transmits > >> the packet for delivery to the attached CE via the=20 > egress service > >> interface. > >> > >> 9. 3.6. Generic Associated Channel (G-ACh) > >> > >> For correct operation of the OAM it is important that the OAM=20 > >> packets > >> fate-share with the data packets. In addition in MPLS-TP it is > >> necessary to discriminate between user data payloads and other=20 > >> types > >> of payload. For example, a packet may be associated with a=20 > >> Signaling > >> Communication Channel (SCC), or a channel used for Automatic > >> Protection Switching (APS) data. This is achieved by=20 > carrying such > >> packets on a generic control channel associated to the=20 > LSP, PW or > >> section. > >> > >> Suggest replacing the last sentence with: > >> > >> "This is achieved by either carrying such packets in an IP=20 > >> encapsulation that provides the necessary discrimination, or by=20 > >> carrying such packets on a generic control channel=20 > associated to the=20 > >> LSP, PW or section. Rest of this section describes the latter=20 > >> mechanism." > >> > >> Also please see related comment in section 3.7. > >> > >> > >> 10. 3.7. Operations, Administration and Maintenance (OAM) > >> > >> MPLS-TP must be able to operate in environments where IP is not=20 > >> used > >> in the forwarding plane. Therefore, the default=20 > mechanism for OAM > >> demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated > >> Channel (Section 3.6). Forwarding based on IP=20 > addresses for user=20 > >> or > >> OAM packets is not required for MPLS-TP. > >> > >> [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined > >> alert mechanisms that enable an MPLS LSR to identify=20 > and process=20 > >> MPLS > >> OAM packets when the OAM packets are encapsulated in an=20 > IP header. > >> These alert mechanisms are based on TTL expiration=20 > and/or use an IP > >> destination address in the range 127/8 for IPv4 and=20 > that same range > >> embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379].=20 > >> When the > >> OAM packets are encapsulated in an IP header, these=20 > mechanisms are > >> the default mechanisms for MPLS networks in general for=20 > identifying > >> MPLS OAM packets. MPLS-TP must be able to operate in an=20 > >> environments > >> where IP forwarding is not supported, and thus the=20 > G-ACh/GAL is the > >> default mechanism to demultiplex OAM packets in MPLS-TP. > >> > >> The last sentence is in conflict with the following=20 > from section > >> 4.1 of RFC 5586: > >> > >> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms > >> that enable an MPLS LSR to identify and process MPLS=20 > OAM packets=20 > >> when > >> these are encapsulated in an IP header. These alert=20 > mechanisms are > >> based, for example, on Time To Live (TTL) expiration=20 > and/or on the > >> use of an IP destination address in the range of > >> 127.0.0.0/8 or 0:0: > >> 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. > >> > >> These mechanisms are the default mechanisms for=20 > identifying MPLS=20 > >> OAM > >> packets when encapsulated in an IP header although the mechanism > >> defined in this document MAY also be used." > >> > >> Hence the last sentence of the above paragraph must=20 > be removed. > >> > >> > >> rahul > >> > >> _______________________________________________ > >> 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 > >> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > >=20 > >=20 >=20 From lberger@labn.net Wed Feb 10 06:36: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 7DD2E3A7331 for ; Wed, 10 Feb 2010 06:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 OmqDtH8s4kst for ; Wed, 10 Feb 2010 06:36:08 -0800 (PST) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id DD9003A758C for ; Wed, 10 Feb 2010 06:36:07 -0800 (PST) Received: (qmail 30376 invoked by uid 0); 10 Feb 2010 14:37:18 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 10 Feb 2010 14:37:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ijzlThhHw0EfC/sDZdeFtDFOVSh8eFGXQg5FWe/N+I+WxPwlJmqPxFwq0tdqzBINXTNiskxDtgrJaY2TdabMh0MRqInY5xKmPfMcIgpLqJ/J513qBI1plemiy579+8zM; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NfDgs-0002YK-68; Wed, 10 Feb 2010 07:37:18 -0700 Message-ID: <4B72C4EB.6030400@labn.net> Date: Wed, 10 Feb 2010 09:38:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <2ECAA42C79676B42AEBAC11229CA7D0C059A4A1A@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C059A4A1A@E03MVB2-UKBR.domain1.systemhost.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 10 Feb 2010 14:36:10 -0000 Neil, See below for in-line response. Also just to be be clear, as much as I'm in favor of it, at this point I don't see a change in forwarding behavior being agreed to by all the parties. Although, perhaps I'm wrong. On 2/10/2010 9:14 AM, neil.2.harrison@bt.com wrote: > Thanks Lou, > > Just to be really clear here: > > - standards must look to the future...they should not be hampered > by poor/wrong arch decisions made in the past > MPLS-TP is a bit unusual as it is being defined as a profile of an existing technology, so we don't have a chance for a clean slate design. In particular, the requirement for the TP data plane to be equal to the MPLS data plane means that there is very limited change possible. (See the first few requirements of RFC 5654.) > - MPLS-TP is supposed to addressing a transport network role.....a > transport network does not require the sublayering behaviour of MPLS > (nor PWs, nor TTL...) but not being able to clearly differentiate > sublayering and (self) layering is almost unforgivable IMO. This should > have been a top priority requirement of this work. > > - the S bit is a non-issue in what I have proposed. One can have > multiple S bits (ie set in the reserved label header plus at true end of > stack) or just the single S bit at the end of the stack. In fact what I > originally proposed was the latter to be in-keeping with the original > MPLS premise of just a single occurrence of the S bit... I don't think this premise is correct. RFC3032 states that the S-bit indicates that a network layer packet immediately follows the LSE, but neither 3032 nor 3031 define what a "network layer" packet can be. If we look at RFC3209 we see that a "network layer", as indicated by the L3PID, can be anything represented by a Standard Ethertype value which includes MPLS (0x8847 for unicast and 0x8848 for multicast). I think together, this shows that the original definition of MPLS allowed another Label stack to be in the "network layer packet", i.e., to have one label stack (with s=1) follow another label stack with (s=1). Now this said, current practice precludes an MPLS stack to be carried after an LSE with S=1. Oh well. > so we could keep > sublayering whilst introducing very efficient layering. > > - you can recurse the idea as many times as is necessary. > > > The reserved label idea also has many operational advantages, eg: > > - no need to run a degenerate 1-hop Ethernet/PW network (as per > Stewart's original ID on this client/server issue)...less to configure, > less to go wrong, less cost. > > - one can use any technology to connect MPLS client and server > layer nodes at each end. > > - the label does not cause a lack of consistent characteristic > information in the DP as it has a globally well-known semantic. > I think your reserved label approach is valid from a technical approach, but is unlikely to be accepted by most from the perspective of meeting the MPLS compatibility requirements of RFC 5654. Lou > regards, Neil > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: 10 February 2010 13:59 >> To: Harrison,N,Neil,DKQ7 R >> Cc: maarten.vissers@huawei.com; rahul@juniper.net; loa@pi.nu; >> mpls@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >> >> Neil, >> I have to say I agree 100% with your comments. >> Particularly that: >> >> (a) that there "should" be "an unambiguous way of identifying >> when one sublayer stack of LSPs ends" -- personally I think >> the S-bit is perfect for this purpose, and >> >> (b) more importantly, that we're limited (as you say, >> "clinging") to current MPLS practices. >> >> It is really (b), the current usage of the MPLS label stack, >> that has driven me to pragmatically accept that (a) is not >> achievable in the current MPLS-TP efforts. >> >> Lou >> >> On 2/9/2010 4:25 PM, neil.2.harrison@bt.com wrote: >>> Maarten, Please let us not confuse folks with terms like >> 'transport >>> entity'....we all know that MPLS-TP will only be using proper >>> connections because we want to *deterministically and >> simply* manage >>> resource. >>> >>> However, you are absolutely right to pick-up on the point >> that an LSP >>> is *not necessarily* a layer network. AFAIK we now have no way of >>> telling from looking at the DP whether a suite of nested LSPs is >>> sublayered or layered...seems one can mix up sublayering and proper >>> client/server layering of LSPs at will. >>> >>> This is not great architectural design practice IMO but >> this seems to >>> be happening because we cannot easily satisfy the real transport >>> requirement whilst clinging on to some old MPLS behaviours. >>> >>> Some while ago I suggested (at least to Stewart) that if >> folks want to >>> keep sublayering in MPLS-TP, then we should have an >> unambiguous way of >>> identifying when one sublayer stack of LSPs ends (say a >> client layer >>> MPLS-TP network belonging to party X) and a different >> sublayer stack >>> of LSPs begins (say a server layer MPLS-TP network >> belonging to party Y). >>> I suggested we should allocate a globally well-known >> functional label >>> from the 0-15 set for this important client/server case. We could >>> also use the same reserved label in MPLS. Note this is consistent >>> with respecting consistent CI as the label is globally well-known. >>> >>> I still think this idea should be given serious >> consideration due to >>> the importance (to operators) of being able to have a quite clear >>> client/server relationship in MPLS-TP between different operating >>> parties. >>> >>> regards, Neil >>> >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers >>>> Sent: 09 February 2010 20:50 >>>> To: 'Rahul Aggarwal'; 'Loa Andersson' >>>> Cc: mpls@ietf.org; mpls-tp@ietf.org >>>> Subject: Re: [mpls-tp] LC comments on >> draft-ietf-mpls-tp-framework-10 >>>> >>>> Rahul, >>>> >>>> The MPLS-TP LSP is not a layer network. The LSP is a >> transport entity >>>> within either the transport service layer network, or the >> transport >>>> path layer network, or the section layer network. >>>> >>>> Regards, >>>> Maarten >>>> >>>> -----Original Message----- >>>> From: mpls-tp-bounces@ietf.org >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal >>>> Sent: zaterdag 6 februari 2010 1:00 >>>> To: Loa Andersson >>>> Cc: mpls@ietf.org; mpls-tp@ietf.org >>>> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >>>> >>>> >>>> Here are my LC comments on >> draft-ietf-mpls-tp-framework-10, prefixed >>>> by >>>> : >>>> >>>> >>>> 1. 1.3.4. MPLS-TP Label Switched Path >>>> >>>> An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP >> that uses a >>>> subset of the capabilities of an MPLS LSP in order to meet the >>>> requirements of an MPLS transport network as set out in >> [RFC5654]. >>>> The characteristics of an MPLS-TP LSP are primarily that it: >>>> >>>> I would suggest adding: "A MPLS-TP LSP is the lowest server >>>> layer provided by MPLS-TP. The client layers of a MPLS-TP >> LSP maybe >>>> IP, MPLS or PWs. The client layers of a MPLS-TP LSP are >> described in >>>> detail in section 3.4" >>>> >>>> This is to make the client server relationship in MPLS-TP clearer. >>>> >>>> 2. 1.3.10. Additional Definitions and Terminology >>>> >>>> Detailed definitions and additional terminology may be found in >>>> [RFC5654]. >>>> >>>> I would suggest a section on "Service Interface". This is to >>>> clarify the applicability of the use of MPLS-TP LSPs and PWs as >>>> described in section 3.4. Furhter it is needed to clarify >> what is the >>>> interface exposed by MPLS-TP to the client network. >>>> >>>> "Service Interface >>>> >>>> The transport service provided by MPLS-TP is said to be >> provided by a >>>> service interface. The following are the service >> interfaces supported >>>> by >>>> MPLS-TP: >>>> >>>> - The service interface may a layer 2 interface that carries only >>>> network layer clients. MPLS-TP LSPs are both necessary and >> sufficient >>>> to support this service interface as described in section 3.4.3 >>>> >>>> - Or the service interface may be a layer 2 interface that carries >>>> both network layer and non-network layer clients. To support this >>>> service interface, a PW is required to adapt the client traffic >>>> received over the service interface. This PW in turn is a >> client of >>>> the MPLS-TP server layer. >>>> This is described in section 3.4.2. >>>> >>>> - Or the service interface may be a MPLS LSP or a PW. To >> support this >>>> case a MPLS-TP PE participates in the service interface signaling." >>>> >>>> 3. 1.4. Applicability >>>> >>>> MPLS-TP can be used to construct packet transport >> networks and is >>>> therefore applicable in any packet transport network >> context. It >>>> is >>>> also applicable to subsets of a packet network where >> the transport >>>> network operational model is deemed attractive. The >> following are >>>> examples of MPLS-TP applicability models: >>>> >>>> 1. MPLS-TP provided by a network that only supports >> MPLS-TP LSPs >>>> and >>>> PWs (i.e. Only MPLS-TP LSPs and PWs exist between >> the PEs or >>>> LSRs), acting as a server for other layer 1, layer >> 2 and layer >>>> 3 >>>> networks (Figure 1). >>>> >>>> 2. MPLS-TP provided by a network that also supports >> non-MPLS-TP >>>> LSPs >>>> and PWs (i.e. both LSPs and PWs that conform to the >> transport >>>> profile and those that do not, exist between the >> PEs), acting >>>> as >>>> a server for other layer 1, layer 2 and layer 3 networks >>>> (Figure 2). >>>> >>>> 3. MPLS-TP as a server layer for client layer traffic of IP or >>>> MPLS >>>> networks which do not use functions of the MPLS transport >>>> profile. For MPLS traffic, the MPLS-TP server >> layer network >>>> uses >>>> PW switching [RFC5659] or LSP stitching [RFC5150] at the PE >>>> that >>>> terminates the MPLS-TP server layer (Figure 3). >>>> >>>> >>>> I think figure 3 and case 3 as written currently are >> making an >>>> assumption that a MPLS-TP PE participates in the "service >> interface >>>> signaling" where the service interface provided by MPLS-TP >> is a MPLS >>>> LSP or a PW. This is a NNI model. Perhaps we need two sub-cases of >>>> case 3. >>>> One is a UNI model where the MPLS network just sees a P2P or P2MP >>>> link, which is provided by the MPLS-TP network. In this case >>>> mechanisms of section >>>> 3.4.3 are sufficient. The second case is the one which the current >>>> text seems to imply and in that case the MPLS-TP PE would >> participate >>>> in the MPLS signaling. In this case the MPLS-TP PE may use LSP >>>> hierarchy or LSP stitching to support the MPLS-LSP as a service >>>> interface and may use PW stitching to support PW as a service >>>> interface. >>>> >>>> So I would propose to replace example number 3 above with: >>>> >>>> "3. MPLS-TP as a server layer for client layer traffic >> of IP or >>>> MPLS >>>> networks which do not use functions of the MPLS transport >>>> profile. Here are two examples of applicability >> models of this: >>>> >>>> a) The client IP or MPLS network is provided a >> layer 2 P2P or >>>> P2MP link by the MPLS-TP network. In other words >> the service >>>> interface is a layer 2 inteface that carries >> only IP or MPLS >>>> packets. To support this case the MPLS-TP server layer >>>> network uses >>>> the mechanisms of section 3.4.3 to carry IP or >> MPLS client l >>>> layer traffic over MPLS-TP LSPs" >>>> >>>> b) The client IP or MPLS network is provided a LSP >> or a PW as a >>>> service interface by the MPLS-TP network. In this case >>>> the MPLS-TP PE would participate in the client MPLS >>>> signaling. >>>> In this case the MPLS-TP PE may use LSP hierarchy or LSP >>>> stitching to support the MPLS-LSP as a service >> interface and >>>> may use PW stitching to support PW as a service interface >>>> (Figure 3)" >>>> >>>> 4. 3.1 Packet Transport Services >>>> >>>> One objective of MPLS-TP is to enable MPLS networks to provide >>>> packet >>>> transport services with a similar degree of >> predictability to that >>>> found in existing transport networks. Such packet transport >>>> services >>>> inherit a number of characteristics, defined in [RFC5654]: >>>> >>>> o In an environment where an MPLS-TP layer network is >> supporting a >>>> client layer network, and the MPLS-TP layer network >> is supported >>>> by a server layer network then operation of the MPLS-TP layer >>>> network must be possible without any dependencies on >> either the >>>> server or client layer network. >>>> >>>> o The service provided by the MPLS-TP network to the client is >>>> guaranteed not to fall below the agreed level regardless of >>>> other >>>> client activity. >>>> >>>> o The control and management planes of any client >> network layer >>>> that >>>> uses the service is isolated from the control and management >>>> planes of the MPLS-TP layer network, where the client network >>>> layer is considered to be the native service of the MPLS-TP >>>> network. >>>> >>>> o Where a client network makes use of an MPLS-TP server that >>>> provides a packet transport service, the level of >> co-ordination >>>> required between the client and server layer >> networks is minimal >>>> (preferably no co-ordination will be required). >>>> >>>> o The complete set of packets generated by a client >>>> MPLS(-TP) layer >>>> network using the packet transport service, which may contain >>>> packets that are not MPLS packets (e.g. IP or CLNS >> packets used >>>> by the control/management plane of the client MPLS(-TP) layer >>>> >>>> >>>> >>>> Bocci, et al. Expires August 8, 2010 >>>> [Page 12] >>>> >>>> Internet-Draft MPLS Transport Profile Framework >>>> February 2010 >>>> >>>> >>>> network), are transported by the MPLS-TP server >> layer network. >>>> >>>> o The packet transport service enables the MPLS-TP >> layer network >>>> addressing and other information (e.g. topology) to >> be hidden >>>> from >>>> any client layer networks using that service, and vice-versa. >>>> >>>> These characteristics imply that a packet transport >> service does >>>> not >>>> support a connectionless packet-switched forwarding >> mode. However, >>>> this does not preclude it carrying client traffic >> associated with a >>>> connectionless service. >>>> >>>> Such packet transport services are very similar to >> Layer 2 Virtual >>>> Private Networks as defined by the IETF. >>>> >>>> The last sentence should be deleted. It doesn't add >> value and is >>>> in potential conflict with section 3.4.3. >>>> >>>> >>>> 5. 3.3. Architecture >>>> >>>> MPLS-TP comprises the following architectural elements: >>>> >>>> o A standard MPLS data plane [RFC3031] as profiled in >>>> [I-D.fbb-mpls-tp-data-plane]. >>>> >>>> Standard MPLS data plane also includes RFC 5331 and RFC 5332. >>>> Given draft-fbb is not a WG draft, I don't think we should add a >>>> reference to it here. >>>> >>>> >>>> 6. 3.4.2. Pseudowire Adaptation >>>> >>>> The architecture for an MPLS-TP network that provides >> PW emulated >>>> services is based on the MPLS [RFC3031] and pseudowire [RFC3985] >>>> architectures. >>>> >>>> I think instead of "PW emulated services", the section should >>>> start with the service interface that requires PWs. >>>> Something like: >>>> >>>> "If the MPLS-TP network provides a layer 2 interface, that carries >>>> both network layer and non-network layer traffic, as a service >>>> interface then a PW is required to support the service interface. >>>> The PW is a client of the MPLS-TP LSP server layer. The >> architecture >>>> of a MPLS-TP network that uses such PWs is is based on the MPLS >>>> [RFC3031] and pseudowire [RFC3985] architectures." >>>> >>>> The above is to make it very clear the applicability of >>>> 3.4.2 as compared to 3.4.3. >>>> >>>> Multi-segment pseudowires may optionally be used to >>>> provide a packet transport service, and their use is consistent >>>> with >>>> >>>> >>>> >>>> Bocci, et al. Expires August 8, 2010 >>>> [Page 18] >>>> >>>> Internet-Draft MPLS Transport Profile Framework >>>> February 2010 >>>> >>>> >>>> the MPLS-TP architecture. The use of MS-PWs may be >> motivated by, >>>> for >>>> example, the requirements specified in [RFC5254]. If MS-PWs are >>>> used, then the MS-PW architecture [RFC5659] also applies. >>>> >>>> Figure 6 shows the architecture for an MPLS-TP network using >>>> single- >>>> segment PWs. >>>> >>>> |<--------------- Emulated Service ----------------->| >>>> | | >>>> | |<-------- Pseudowire -------->| | >>>> | | encapsulated, packet | | >>>> | | transport service | | >>>> | | | | >>>> | | |<------ LSP ------->| | | >>>> | V V V V | >>>> V AC +----+ +-----+ +----+ AC V >>>> +-----+ | | PE1|=======\ /========| PE2| | >>>> +-----+ >>>> | |----------|.......PW1.| \ / >>>> |............|----------| | >>>> | CE1 | | | | | X | | | | >>>> | CE2 | >>>> | |----------|.......PW2.| / \ >>>> |............|----------| | >>>> +-----+ ^ | | |=======/ \========| | | >>>> ^ +-----+ >>>> ^ | +----+ +-----+ +----+ | ^ >>>> | | Provider Edge 1 ^ Provider Edge 2 | | >>>> | | | | | >>>> Customer | P Router >>>> | Customer >>>> Edge 1 | >>>> | Edge 2 >>>> | | >>>> | | >>>> Native service >> Native service >>>> >>>> >>>> Figure 6: MPLS-TP Architecture (Single Segment PW) >>>> >>>> Figure 7 shows the architecture for an MPLS-TP network >> when multi- >>>> segment pseudowires are used. Note that as in the SS-PW case, >>>> P-routers may also exist. >>>> >>>> This figure needs to clarify where the MPLS-TP PEs >> are and where >>>> the "service PEs" are. Or whether PE1 is actually both the >> MPLS-TP PE >>>> and the service PE. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bocci, et al. Expires August 8, 2010 >>>> [Page 19] >>>> >>>> Internet-Draft MPLS Transport Profile Framework >>>> February 2010 >>>> >>>> >>>> |<----------- Pseudowire encapsulated ------------->| >>>> | packet transport service | >>>> | | >>>> | | >>>> | | >>>> AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC >>>> | V V V V V V | >>>> | +----+ +-----+ +----+ +----+ | >>>> +---+ | |TPE1|===============\ >>>> /=====|SPE1|==========|TPE2| | +---+ >>>> | |---|......PW1-Seg1.... | \ / | >>>> ......X...PW1-Seg2......|---| | >>>> |CE1| | | | | X | | | | >>>> | | |CE2| >>>> | |---|......PW2-Seg1.... | / \ | >>>> ......X...PW2-Seg2......|---| | >>>> +---+ | | |===============/ \=====| |==========| >>>> | | +---+ >>>> ^ +----+ ^ +-----+ +----+ ^ >> +----+ ^ >>>> | | ^ | >> | >>>> | TE LSP | TE LSP >> | >>>> | P-router >> | >>>> | >> | >>>> |<-------------------- Emulated Service >> ------------------->| >>>> >>>> PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while >>>> PW2-segment1 and PW2-segment2 are segments of another MS-PW >>>> >>>> >>>> Figure 7: MPLS-TP Architecture (Multi-Segment PW) >>>> >>>> The corresponding MPLS-TP protocol stacks including PWs >> are shown >>>> in >>>> Figure 8. In this figure the Transport Service Layer >> [RFC5654] is >>>> identified by the PW demultiplexer (Demux) label and >> the Transport >>>> Path Layer [RFC5654] is identified by the LSP Demux Label. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bocci, et al. Expires August 8, 2010 >>>> [Page 20] >>>> >>>> Internet-Draft MPLS Transport Profile Framework >>>> February 2010 >>>> >>>> >>>> +-------------------+ /===================\ >>>> /===================\ >>>> | Client Layer | H OAM PDU H H OAM >>>> PDU H >>>> /===================\ H-------------------H >>>> H-------------------H >>>> H PW Encap H H GACh H H >>>> GACh H >>>> H-------------------H H-------------------H >>>> H-------------------H >>>> H PW Demux (S=1) H H PW Demux (S=1) H H GAL >>>> (S=1) H >>>> H-------------------H H-------------------H >>>> H-------------------H >>>> H LSP Demux(s) H H LSP Demux(s) H H LSP >>>> Demux(s) H >>>> \===================/ \===================/ >>>> \===================/ >>>> | Server Layer | | Server Layer | | Server >>>> Layer | >>>> +-------------------+ +-------------------+ >>>> +-------------------+ >>>> >>>> User Traffic PW OAM LSP OAM >>>> >>>> Note: H(ighlighted) indicates the part of the protocol >> stack we are >>>> considering in this document. >>>> >>>> >>>> Figure 8: MPLS-TP Layer Network using Pseudowires >>>> >>>> PWs and their associated labels may be configured or >> signaled. See >>>> Section 3.11 for additional details related to >> configured service >>>> types. See Section 3.9 for additional details related >> to signaled >>>> service types. >>>> >>>> 7. 3.4.2.1. Pseudowire Based Services >>>> >>>> When providing a Virtual Private Wire Service (VPWS) , Virtual >>>> Private Local Area Network Service (VPLS), Virtual Private >>>> Multicast >>>> Service (VPMS) or Internet Protocol Local Area Network Service >>>> (IPLS), pseudowires must be used to carry the client service. >>>> VPWS, >>>> VLPS, and IPLS are described in [RFC4664]. VPMS is described in >>>> [I-D.ietf-l2vpn-vpms-frmwk-requirements]. >>>> >>>> This section should be deleted. From a MPLS-TP network view >>>> point the service interface, that requires PWs, is a >> point-to-point >>>> layer 2 interface that carries both network layer and non-network >>>> layer traffic. This is orthogonal to the service which is being >>>> delivered to the end user. Hence this section doesn't belong here. >>>> >>>> >>>> 8. 3.4.3. Network Layer Adaptation >>>> >>>> MPLS-TP LSPs can be used to transport network layer >> clients. This >>>> document uses the term Network Layer in the same sense as it is >>>> used >>>> in [RFC3031] and [RFC3032]. The network layer >> protocols supported >>>> by >>>> [RFC3031] and [RFC3032] can be transported between service >>>> interfaces. Examples are shown in Figure 5 above. Support for >>>> network layer clients follows the MPLS architecture for >> support of >>>> network layer protocols as specified in [RFC3031] and [RFC3032]. >>>> >>>> With network layer adaptation, the MPLS-TP domain >> provides either a >>>> uni-directional or bidirectional point-to-point >> connection between >>>> two PEs in order to deliver a packet transport service >> to attached >>>> customer edge (CE) nodes. For example, a CE may be an >> IP, MPLS or >>>> >>>> >>>> >>>> Bocci, et al. Expires August 8, 2010 >>>> [Page 21] >>>> >>>> Internet-Draft MPLS Transport Profile Framework >>>> February 2010 >>>> >>>> >>>> MPLS-TP node. As shown in Figure 9, there is an >> attachment circuit >>>> between the CE node on the left and its corresponding >> provider edge >>>> (PE) node which provides the service interface, a >> bidirectional LSP >>>> across the MPLS-TP network to the corresponding PE node on the >>>> right, >>>> and an attachment circuit between that PE node and the >>>> corresponding >>>> CE node for this service. >>>> >>>> The attachment circuits may be heterogeneous (e.g., any >> combination >>>> of SDH, PPP, Frame Relay, etc.) and network layer >> protocol payloads >>>> arrive at the service interface encapsulated in the >> Layer1/Layer2 >>>> encoding defined for that access link type. It should be noted >>>> that >>>> the set of network layer protocols includes MPLS and hence MPLS >>>> encoded packets with an MPLS label stack (the client >> MPLS stack), >>>> may >>>> appear at the service interface. >>>> >>>> |<------------- Client Network Layer ------------->| >>>> | | >>>> | |<---- Pkt Xport Service --->| | >>>> | | | | >>>> | | |<-- PSN Tunnel -->| | | >>>> | V V V V | >>>> V AC +----+ +---+ +----+ AC V >>>> +-----+ | |PE1 | | | |PE2 | | >>>> +-----+ >>>> | | |LSP | | | | | | | >>>> | | >>>> | CE1 |----------| |========X=========| >>>> |----------| CE2 | >>>> | | ^ |IP | | ^ | | ^ | | | >>>> ^ | | >>>> +-----+ | | | | | | | | | | | >>>> | +-----+ >>>> ^ | +----+ | +---+ | +----+ | | ^ >>>> | | Provider | ^ | Provider | | >>>> | | Edge | | | Edge | | >>>> Customer | 1 | P-router | 2 >>>> | Customer >>>> Edge 1 | TE TE >> | Edge 2 >>>> | LSP LSP | >>>> | | >>>> Native service >> Native service >>>> >>>> >>>> Figure 9: MPLS-TP Architecture for Network Layer Clients >>>> >>>> PE1 and PE2 should be specifically labeled as MPLS-TP PEs. >>>> >>>> At the ingress service interface the client packets are >> received . >>>> The PE pushes one or more labels onto the client >> packets which are >>>> then label switched over the transport network. >>>> Correspondingly the >>>> egress PE pops any labels added by the MPLS-TP networks and >>>> transmits >>>> the packet for delivery to the attached CE via the >> egress service >>>> interface. >>>> >>>> 9. 3.6. Generic Associated Channel (G-ACh) >>>> >>>> For correct operation of the OAM it is important that the OAM >>>> packets >>>> fate-share with the data packets. In addition in MPLS-TP it is >>>> necessary to discriminate between user data payloads and other >>>> types >>>> of payload. For example, a packet may be associated with a >>>> Signaling >>>> Communication Channel (SCC), or a channel used for Automatic >>>> Protection Switching (APS) data. This is achieved by >> carrying such >>>> packets on a generic control channel associated to the >> LSP, PW or >>>> section. >>>> >>>> Suggest replacing the last sentence with: >>>> >>>> "This is achieved by either carrying such packets in an IP >>>> encapsulation that provides the necessary discrimination, or by >>>> carrying such packets on a generic control channel >> associated to the >>>> LSP, PW or section. Rest of this section describes the latter >>>> mechanism." >>>> >>>> Also please see related comment in section 3.7. >>>> >>>> >>>> 10. 3.7. Operations, Administration and Maintenance (OAM) >>>> >>>> MPLS-TP must be able to operate in environments where IP is not >>>> used >>>> in the forwarding plane. Therefore, the default >> mechanism for OAM >>>> demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated >>>> Channel (Section 3.6). Forwarding based on IP >> addresses for user >>>> or >>>> OAM packets is not required for MPLS-TP. >>>> >>>> [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined >>>> alert mechanisms that enable an MPLS LSR to identify >> and process >>>> MPLS >>>> OAM packets when the OAM packets are encapsulated in an >> IP header. >>>> These alert mechanisms are based on TTL expiration >> and/or use an IP >>>> destination address in the range 127/8 for IPv4 and >> that same range >>>> embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. >>>> When the >>>> OAM packets are encapsulated in an IP header, these >> mechanisms are >>>> the default mechanisms for MPLS networks in general for >> identifying >>>> MPLS OAM packets. MPLS-TP must be able to operate in an >>>> environments >>>> where IP forwarding is not supported, and thus the >> G-ACh/GAL is the >>>> default mechanism to demultiplex OAM packets in MPLS-TP. >>>> >>>> The last sentence is in conflict with the following >> from section >>>> 4.1 of RFC 5586: >>>> >>>> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms >>>> that enable an MPLS LSR to identify and process MPLS >> OAM packets >>>> when >>>> these are encapsulated in an IP header. These alert >> mechanisms are >>>> based, for example, on Time To Live (TTL) expiration >> and/or on the >>>> use of an IP destination address in the range of >>>> 127.0.0.0/8 or 0:0: >>>> 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. >>>> >>>> These mechanisms are the default mechanisms for >> identifying MPLS >>>> OAM >>>> packets when encapsulated in an IP header although the mechanism >>>> defined in this document MAY also be used." >>>> >>>> Hence the last sentence of the above paragraph must >> be removed. >>>> >>>> >>>> rahul >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> >>> >> > > > From neil.2.harrison@bt.com Wed Feb 10 07:20: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 E95503A772A; Wed, 10 Feb 2010 07:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, 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 0kWXDF3-cCG0; Wed, 10 Feb 2010 07:20:18 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9718F3A7720; Wed, 10 Feb 2010 07:20:17 -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); Wed, 10 Feb 2010 15:21:27 +0000 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, 10 Feb 2010 15:21:25 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C059A4A83@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <4B72C4EB.6030400@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 Thread-Index: AcqqXpNWVkazAw5+Sx6gG/xUEWiCqQAADFdg From: To: X-OriginalArrivalTime: 10 Feb 2010 15:21:27.0680 (UTC) FILETIME=[B6FA7800:01CAAA64] Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 10 Feb 2010 15:20:21 -0000 Just one comment Lou: We are at a watershed opportunity...just how many co-ps mode technologies do you think the industry has stomach for (ie can afford) if we screw-up and waste this one? But if what you say holds sway, then I think it a little disingenuous to claim MPLS-TP is a 'transport network'...it's just another spin of MPLS as-is. regards, Neil =20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: 10 February 2010 14:39 > To: Harrison,N,Neil,DKQ7 R > Cc: maarten.vissers@huawei.com; rahul@juniper.net; loa@pi.nu;=20 > mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >=20 > Neil, > See below for in-line response. Also just to be be=20 > clear, as much as I'm in favor of it, at this point I don't=20 > see a change in forwarding behavior being agreed to by all=20 > the parties. Although, perhaps I'm wrong. >=20 > On 2/10/2010 9:14 AM, neil.2.harrison@bt.com wrote: > > Thanks Lou, > >=20 > > Just to be really clear here: > >=20 > > - standards must look to the future...they should not be hampered > > by poor/wrong arch decisions made in the past > >=20 >=20 > MPLS-TP is a bit unusual as it is being defined as a profile=20 > of an existing technology, so we don't have a chance for a=20 > clean slate design. > In particular, the requirement for the TP data plane to be=20 > equal to the MPLS data plane means that there is very limited=20 > change possible. (See the first few requirements of RFC 5654.) >=20 > > - MPLS-TP is supposed to addressing a transport network role.....a > > transport network does not require the sublayering=20 > behaviour of MPLS=20 > > (nor PWs, nor TTL...) but not being able to clearly differentiate=20 > > sublayering and (self) layering is almost unforgivable IMO. This=20 > > should have been a top priority requirement of this work. > >=20 > > - the S bit is a non-issue in what I have proposed. One can have > > multiple S bits (ie set in the reserved label header plus=20 > at true end=20 > > of > > stack) or just the single S bit at the end of the stack. =20 > In fact what=20 > > I originally proposed was the latter to be in-keeping with the=20 > > original MPLS premise of just a single occurrence of the S bit... >=20 > I don't think this premise is correct. RFC3032 states that=20 > the S-bit indicates that a network layer packet immediately=20 > follows the LSE, but neither 3032 nor 3031 define what a=20 > "network layer" packet can be. If we look at RFC3209 we see=20 > that a "network layer", as indicated by the L3PID, can be=20 > anything represented by a Standard Ethertype value which=20 > includes MPLS (0x8847 for unicast and 0x8848 for multicast). =20 > I think together, this shows that the original definition of=20 > MPLS allowed another Label stack to be in the "network layer=20 > packet", i.e., to have one label stack (with s=3D1) follow=20 > another label stack with (s=3D1). >=20 > Now this said, current practice precludes an MPLS stack to be=20 > carried after an LSE with S=3D1. Oh well. >=20 > > so we could keep > > sublayering whilst introducing very efficient layering. > >=20 > > - you can recurse the idea as many times as is necessary. > >=20 > >=20 > > The reserved label idea also has many operational advantages, eg: > >=20 > > - no need to run a degenerate 1-hop Ethernet/PW network (as per > > Stewart's original ID on this client/server issue)...less to=20 > > configure, less to go wrong, less cost. > >=20 > > - one can use any technology to connect MPLS client and server > > layer nodes at each end. > >=20 > > - the label does not cause a lack of consistent characteristic > > information in the DP as it has a globally well-known semantic. > >=20 >=20 > I think your reserved label approach is valid from a=20 > technical approach, but is unlikely to be accepted by most=20 > from the perspective of meeting the MPLS compatibility=20 > requirements of RFC 5654. >=20 > Lou >=20 > > regards, Neil=09 > >=20 > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: 10 February 2010 13:59 > >> To: Harrison,N,Neil,DKQ7 R > >> Cc: maarten.vissers@huawei.com; rahul@juniper.net; loa@pi.nu;=20 > >> mpls@ietf.org; mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] LC comments on=20 > draft-ietf-mpls-tp-framework-10 > >> > >> Neil, > >> I have to say I agree 100% with your comments. =20 > >> Particularly that: > >> > >> (a) that there "should" be "an unambiguous way of identifying when=20 > >> one sublayer stack of LSPs ends" -- personally I think the=20 > S-bit is=20 > >> perfect for this purpose, and > >> > >> (b) more importantly, that we're limited (as you say, > >> "clinging") to current MPLS practices. > >> > >> It is really (b), the current usage of the MPLS label=20 > stack, that has=20 > >> driven me to pragmatically accept that (a) is not=20 > achievable in the=20 > >> current MPLS-TP efforts. > >> > >> Lou > >> > >> On 2/9/2010 4:25 PM, neil.2.harrison@bt.com wrote: > >>> Maarten, Please let us not confuse folks with terms like > >> 'transport > >>> entity'....we all know that MPLS-TP will only be using proper=20 > >>> connections because we want to *deterministically and > >> simply* manage > >>> resource. > >>> > >>> However, you are absolutely right to pick-up on the point > >> that an LSP > >>> is *not necessarily* a layer network. AFAIK we now have=20 > no way of=20 > >>> telling from looking at the DP whether a suite of nested LSPs is=20 > >>> sublayered or layered...seems one can mix up sublayering=20 > and proper=20 > >>> client/server layering of LSPs at will. > >>> > >>> This is not great architectural design practice IMO but > >> this seems to > >>> be happening because we cannot easily satisfy the real transport=20 > >>> requirement whilst clinging on to some old MPLS behaviours. > >>> > >>> Some while ago I suggested (at least to Stewart) that if > >> folks want to > >>> keep sublayering in MPLS-TP, then we should have an > >> unambiguous way of > >>> identifying when one sublayer stack of LSPs ends (say a > >> client layer > >>> MPLS-TP network belonging to party X) and a different > >> sublayer stack > >>> of LSPs begins (say a server layer MPLS-TP network > >> belonging to party Y). > >>> I suggested we should allocate a globally well-known > >> functional label > >>> from the 0-15 set for this important client/server case. =20 > We could=20 > >>> also use the same reserved label in MPLS. Note this is=20 > consistent=20 > >>> with respecting consistent CI as the label is globally well-known. > >>> > >>> I still think this idea should be given serious > >> consideration due to > >>> the importance (to operators) of being able to have a quite clear=20 > >>> client/server relationship in MPLS-TP between different operating=20 > >>> parties. > >>> > >>> regards, Neil > >>> > >>>> -----Original Message----- > >>>> From: mpls-tp-bounces@ietf.org > >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > >>>> Sent: 09 February 2010 20:50 > >>>> To: 'Rahul Aggarwal'; 'Loa Andersson' > >>>> Cc: mpls@ietf.org; mpls-tp@ietf.org > >>>> Subject: Re: [mpls-tp] LC comments on > >> draft-ietf-mpls-tp-framework-10 > >>>> > >>>> Rahul, > >>>> > >>>> The MPLS-TP LSP is not a layer network. The LSP is a > >> transport entity > >>>> within either the transport service layer network, or the > >> transport > >>>> path layer network, or the section layer network. > >>>> > >>>> Regards, > >>>> Maarten > >>>> > >>>> -----Original Message----- > >>>> From: mpls-tp-bounces@ietf.org > >>>> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal > >>>> Sent: zaterdag 6 februari 2010 1:00 > >>>> To: Loa Andersson > >>>> Cc: mpls@ietf.org; mpls-tp@ietf.org > >>>> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 > >>>> > >>>> > >>>> Here are my LC comments on > >> draft-ietf-mpls-tp-framework-10, prefixed > >>>> by > >>>> : > >>>> > >>>> > >>>> 1. 1.3.4. MPLS-TP Label Switched Path > >>>> > >>>> An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP > >> that uses a > >>>> subset of the capabilities of an MPLS LSP in order to meet the > >>>> requirements of an MPLS transport network as set out in > >> [RFC5654]. > >>>> The characteristics of an MPLS-TP LSP are primarily that it: > >>>> > >>>> I would suggest adding: "A MPLS-TP LSP is the lowest server=20 > >>>> layer provided by MPLS-TP. The client layers of a MPLS-TP > >> LSP maybe > >>>> IP, MPLS or PWs. The client layers of a MPLS-TP LSP are > >> described in > >>>> detail in section 3.4" > >>>> > >>>> This is to make the client server relationship in=20 > MPLS-TP clearer. > >>>> > >>>> 2. 1.3.10. Additional Definitions and Terminology > >>>> > >>>> Detailed definitions and additional terminology may=20 > be found in > >>>> [RFC5654]. > >>>> > >>>> I would suggest a section on "Service Interface".=20 > This is to=20 > >>>> clarify the applicability of the use of MPLS-TP LSPs and PWs as=20 > >>>> described in section 3.4. Furhter it is needed to clarify > >> what is the > >>>> interface exposed by MPLS-TP to the client network. > >>>> > >>>> "Service Interface > >>>> > >>>> The transport service provided by MPLS-TP is said to be > >> provided by a > >>>> service interface. The following are the service > >> interfaces supported > >>>> by > >>>> MPLS-TP: > >>>> > >>>> - The service interface may a layer 2 interface that=20 > carries only=20 > >>>> network layer clients. MPLS-TP LSPs are both necessary and > >> sufficient > >>>> to support this service interface as described in section 3.4.3 > >>>> > >>>> - Or the service interface may be a layer 2 interface=20 > that carries=20 > >>>> both network layer and non-network layer clients. To=20 > support this=20 > >>>> service interface, a PW is required to adapt the client traffic=20 > >>>> received over the service interface. This PW in turn is a > >> client of > >>>> the MPLS-TP server layer. > >>>> This is described in section 3.4.2. > >>>> > >>>> - Or the service interface may be a MPLS LSP or a PW. To > >> support this > >>>> case a MPLS-TP PE participates in the service interface=20 > signaling." > >>>> > >>>> 3. 1.4. Applicability > >>>> > >>>> MPLS-TP can be used to construct packet transport > >> networks and is > >>>> therefore applicable in any packet transport network > >> context. It > >>>> is > >>>> also applicable to subsets of a packet network where > >> the transport > >>>> network operational model is deemed attractive. The > >> following are > >>>> examples of MPLS-TP applicability models: > >>>> > >>>> 1. MPLS-TP provided by a network that only supports > >> MPLS-TP LSPs > >>>> and > >>>> PWs (i.e. Only MPLS-TP LSPs and PWs exist between > >> the PEs or > >>>> LSRs), acting as a server for other layer 1, layer > >> 2 and layer > >>>> 3 > >>>> networks (Figure 1). > >>>> > >>>> 2. MPLS-TP provided by a network that also supports > >> non-MPLS-TP > >>>> LSPs > >>>> and PWs (i.e. both LSPs and PWs that conform to the > >> transport > >>>> profile and those that do not, exist between the > >> PEs), acting > >>>> as > >>>> a server for other layer 1, layer 2 and layer 3 networks > >>>> (Figure 2). > >>>> > >>>> 3. MPLS-TP as a server layer for client layer=20 > traffic of IP or=20 > >>>> MPLS > >>>> networks which do not use functions of the MPLS transport > >>>> profile. For MPLS traffic, the MPLS-TP server > >> layer network > >>>> uses > >>>> PW switching [RFC5659] or LSP stitching [RFC5150]=20 > at the PE=20 > >>>> that > >>>> terminates the MPLS-TP server layer (Figure 3). > >>>> > >>>> > >>>> I think figure 3 and case 3 as written currently are > >> making an > >>>> assumption that a MPLS-TP PE participates in the "service > >> interface > >>>> signaling" where the service interface provided by MPLS-TP > >> is a MPLS > >>>> LSP or a PW. This is a NNI model. Perhaps we need two=20 > sub-cases of=20 > >>>> case 3. > >>>> One is a UNI model where the MPLS network just sees a=20 > P2P or P2MP=20 > >>>> link, which is provided by the MPLS-TP network. In this case=20 > >>>> mechanisms of section > >>>> 3.4.3 are sufficient. The second case is the one which=20 > the current=20 > >>>> text seems to imply and in that case the MPLS-TP PE would > >> participate > >>>> in the MPLS signaling. In this case the MPLS-TP PE may use LSP=20 > >>>> hierarchy or LSP stitching to support the MPLS-LSP as a service=20 > >>>> interface and may use PW stitching to support PW as a service=20 > >>>> interface. > >>>> > >>>> So I would propose to replace example number 3 above with: > >>>> > >>>> "3. MPLS-TP as a server layer for client layer traffic > >> of IP or > >>>> MPLS > >>>> networks which do not use functions of the MPLS transport > >>>> profile. Here are two examples of applicability > >> models of this: > >>>> > >>>> a) The client IP or MPLS network is provided a > >> layer 2 P2P or > >>>> P2MP link by the MPLS-TP network. In other words > >> the service > >>>> interface is a layer 2 inteface that carries > >> only IP or MPLS > >>>> packets. To support this case the MPLS-TP server layer=20 > >>>> network uses > >>>> the mechanisms of section 3.4.3 to carry IP or > >> MPLS client l > >>>> layer traffic over MPLS-TP LSPs" > >>>> > >>>> b) The client IP or MPLS network is provided a LSP > >> or a PW as a > >>>> service interface by the MPLS-TP network. In this case > >>>> the MPLS-TP PE would participate in the client MPLS=20 > >>>> signaling. > >>>> In this case the MPLS-TP PE may use LSP=20 > hierarchy or LSP > >>>> stitching to support the MPLS-LSP as a service > >> interface and > >>>> may use PW stitching to support PW as a=20 > service interface > >>>> (Figure 3)" > >>>> > >>>> 4. 3.1 Packet Transport Services > >>>> > >>>> One objective of MPLS-TP is to enable MPLS networks=20 > to provide=20 > >>>> packet > >>>> transport services with a similar degree of > >> predictability to that > >>>> found in existing transport networks. Such packet transport=20 > >>>> services > >>>> inherit a number of characteristics, defined in [RFC5654]: > >>>> > >>>> o In an environment where an MPLS-TP layer network is > >> supporting a > >>>> client layer network, and the MPLS-TP layer network > >> is supported > >>>> by a server layer network then operation of the=20 > MPLS-TP layer > >>>> network must be possible without any dependencies on > >> either the > >>>> server or client layer network. > >>>> > >>>> o The service provided by the MPLS-TP network to the=20 > client is > >>>> guaranteed not to fall below the agreed level=20 > regardless of=20 > >>>> other > >>>> client activity. > >>>> > >>>> o The control and management planes of any client > >> network layer > >>>> that > >>>> uses the service is isolated from the control and=20 > management > >>>> planes of the MPLS-TP layer network, where the=20 > client network > >>>> layer is considered to be the native service of the MPLS-TP > >>>> network. > >>>> > >>>> o Where a client network makes use of an MPLS-TP server that > >>>> provides a packet transport service, the level of > >> co-ordination > >>>> required between the client and server layer > >> networks is minimal > >>>> (preferably no co-ordination will be required). > >>>> > >>>> o The complete set of packets generated by a client > >>>> MPLS(-TP) layer > >>>> network using the packet transport service, which=20 > may contain > >>>> packets that are not MPLS packets (e.g. IP or CLNS > >> packets used > >>>> by the control/management plane of the client=20 > MPLS(-TP) layer > >>>> > >>>> > >>>> > >>>> Bocci, et al. Expires August 8, 2010 =20 > >>>> [Page 12] > >>>> > >>>> Internet-Draft MPLS Transport Profile Framework =20 > >>>> February 2010 > >>>> > >>>> > >>>> network), are transported by the MPLS-TP server > >> layer network. > >>>> > >>>> o The packet transport service enables the MPLS-TP > >> layer network > >>>> addressing and other information (e.g. topology) to > >> be hidden > >>>> from > >>>> any client layer networks using that service, and=20 > vice-versa. > >>>> > >>>> These characteristics imply that a packet transport > >> service does > >>>> not > >>>> support a connectionless packet-switched forwarding > >> mode. However, > >>>> this does not preclude it carrying client traffic > >> associated with a > >>>> connectionless service. > >>>> > >>>> Such packet transport services are very similar to > >> Layer 2 Virtual > >>>> Private Networks as defined by the IETF. > >>>> > >>>> The last sentence should be deleted. It doesn't add > >> value and is > >>>> in potential conflict with section 3.4.3. > >>>> > >>>> > >>>> 5. 3.3. Architecture > >>>> > >>>> MPLS-TP comprises the following architectural elements: > >>>> > >>>> o A standard MPLS data plane [RFC3031] as profiled in > >>>> [I-D.fbb-mpls-tp-data-plane]. > >>>> > >>>> Standard MPLS data plane also includes RFC 5331 and=20 > RFC 5332. > >>>> Given draft-fbb is not a WG draft, I don't think we should add a=20 > >>>> reference to it here. > >>>> > >>>> > >>>> 6. 3.4.2. Pseudowire Adaptation > >>>> > >>>> The architecture for an MPLS-TP network that provides > >> PW emulated > >>>> services is based on the MPLS [RFC3031] and=20 > pseudowire [RFC3985] > >>>> architectures. > >>>> > >>>> I think instead of "PW emulated services", the=20 > section should=20 > >>>> start with the service interface that requires PWs. > >>>> Something like: > >>>> > >>>> "If the MPLS-TP network provides a layer 2 interface,=20 > that carries=20 > >>>> both network layer and non-network layer traffic, as a service=20 > >>>> interface then a PW is required to support the service interface. > >>>> The PW is a client of the MPLS-TP LSP server layer. The > >> architecture > >>>> of a MPLS-TP network that uses such PWs is is based on the MPLS=20 > >>>> [RFC3031] and pseudowire [RFC3985] architectures." > >>>> > >>>> The above is to make it very clear the applicability of > >>>> 3.4.2 as compared to 3.4.3. > >>>> > >>>> Multi-segment pseudowires may optionally be used to > >>>> provide a packet transport service, and their use is=20 > consistent=20 > >>>> with > >>>> > >>>> > >>>> > >>>> Bocci, et al. Expires August 8, 2010 =20 > >>>> [Page 18] > >>>> > >>>> Internet-Draft MPLS Transport Profile Framework =20 > >>>> February 2010 > >>>> > >>>> > >>>> the MPLS-TP architecture. The use of MS-PWs may be > >> motivated by, > >>>> for > >>>> example, the requirements specified in [RFC5254]. If=20 > MS-PWs are > >>>> used, then the MS-PW architecture [RFC5659] also applies. > >>>> > >>>> Figure 6 shows the architecture for an MPLS-TP network using > >>>> single- > >>>> segment PWs. > >>>> > >>>> |<--------------- Emulated Service=20 > ----------------->| > >>>> | =20 > | > >>>> | |<-------- Pseudowire -------->| =20 > | > >>>> | | encapsulated, packet | =20 > | > >>>> | | transport service | =20 > | > >>>> | | | =20 > | > >>>> | | |<------ LSP ------->| | =20 > | > >>>> | V V V V =20 > | > >>>> V AC +----+ +-----+ +----+ =20 > AC V > >>>> +-----+ | | PE1|=3D=3D=3D=3D=3D=3D=3D\ = /=3D=3D=3D=3D=3D=3D=3D=3D| PE2| |=20 > >>>> +-----+ > >>>> | |----------|.......PW1.| \ /=20 > >>>> |............|----------| | > >>>> | CE1 | | | | | X | | | |=20 > >>>> | CE2 | > >>>> | |----------|.......PW2.| / \=20 > >>>> |............|----------| | > >>>> +-----+ ^ | | |=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D| | |=20 > >>>> ^ +-----+ > >>>> ^ | +----+ +-----+ +----+ =20 > | ^ > >>>> | | Provider Edge 1 ^ Provider=20 > Edge 2 | | > >>>> | | | =20 > | | > >>>> Customer | P Router =20 > >>>> | Customer > >>>> Edge 1 | =20 > >>>> | Edge 2 > >>>> | | > >>>> | | > >>>> Native service =20 > >> Native service > >>>> > >>>> > >>>> Figure 6: MPLS-TP Architecture (Single Segment PW) > >>>> > >>>> Figure 7 shows the architecture for an MPLS-TP network > >> when multi- > >>>> segment pseudowires are used. Note that as in the SS-PW case, > >>>> P-routers may also exist. > >>>> > >>>> This figure needs to clarify where the MPLS-TP PEs > >> are and where > >>>> the "service PEs" are. Or whether PE1 is actually both the > >> MPLS-TP PE > >>>> and the service PE. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Bocci, et al. Expires August 8, 2010 =20 > >>>> [Page 19] > >>>> > >>>> Internet-Draft MPLS Transport Profile Framework =20 > >>>> February 2010 > >>>> > >>>> > >>>> |<----------- Pseudowire encapsulated ------------->| > >>>> | packet transport service | > >>>> | | > >>>> | | > >>>> | | > >>>> AC | |<-------- LSP1 -------->| =20 > |<--LSP2-->| | AC > >>>> | V V V V =20 > V V | > >>>> | +----+ +-----+ +----+ =20 > +----+ | > >>>> +---+ | |TPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ = > >>>> /=3D=3D=3D=3D=3D|SPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|TPE2| | = +---+ > >>>> | |---|......PW1-Seg1.... | \ / |=20 > >>>> ......X...PW1-Seg2......|---| | > >>>> |CE1| | | | | X | | | | =20 > >>>> | | |CE2| > >>>> | |---|......PW2-Seg1.... | / \ |=20 > >>>> ......X...PW2-Seg2......|---| | > >>>> +---+ | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D| |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > >>>> | | +---+ > >>>> ^ +----+ ^ +-----+ +----+ ^ =20 > >> +----+ ^ > >>>> | | ^ | =20 > >> | > >>>> | TE LSP | TE LSP =20 > >> | > >>>> | P-router =20 > >> | > >>>> | =20 > >> | > >>>> |<-------------------- Emulated Service > >> ------------------->| > >>>> > >>>> PW1-segment1 and PW1-segment2 are segments of the same=20 > MS-PW, while > >>>> PW2-segment1 and PW2-segment2 are segments of another MS-PW > >>>> > >>>> > >>>> Figure 7: MPLS-TP Architecture (Multi-Segment PW) > >>>> > >>>> The corresponding MPLS-TP protocol stacks including PWs > >> are shown > >>>> in > >>>> Figure 8. In this figure the Transport Service Layer > >> [RFC5654] is > >>>> identified by the PW demultiplexer (Demux) label and > >> the Transport > >>>> Path Layer [RFC5654] is identified by the LSP Demux Label. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Bocci, et al. Expires August 8, 2010 =20 > >>>> [Page 20] > >>>> > >>>> Internet-Draft MPLS Transport Profile Framework =20 > >>>> February 2010 > >>>> > >>>> > >>>> +-------------------+ = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ =20 > >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ > >>>> | Client Layer | H OAM PDU H H OAM=20 > >>>> PDU H > >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ = H-------------------H =20 > >>>> H-------------------H > >>>> H PW Encap H H GACh H H =20 > >>>> GACh H > >>>> H-------------------H H-------------------H =20 > >>>> H-------------------H > >>>> H PW Demux (S=3D1) H H PW Demux (S=3D1) H H GAL=20 > >>>> (S=3D1) H > >>>> H-------------------H H-------------------H =20 > >>>> H-------------------H > >>>> H LSP Demux(s) H H LSP Demux(s) H H LSP=20 > >>>> Demux(s) H > >>>> \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ = \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ =20 > >>>> \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ > >>>> | Server Layer | | Server Layer | | Server=20 > >>>> Layer | > >>>> +-------------------+ +-------------------+ =20 > >>>> +-------------------+ > >>>> > >>>> User Traffic PW OAM LSP OAM > >>>> > >>>> Note: H(ighlighted) indicates the part of the protocol > >> stack we are > >>>> considering in this document. > >>>> > >>>> > >>>> Figure 8: MPLS-TP Layer Network using Pseudowires > >>>> > >>>> PWs and their associated labels may be configured or > >> signaled. See > >>>> Section 3.11 for additional details related to > >> configured service > >>>> types. See Section 3.9 for additional details related > >> to signaled > >>>> service types. > >>>> > >>>> 7. 3.4.2.1. Pseudowire Based Services > >>>> > >>>> When providing a Virtual Private Wire Service (VPWS) , Virtual > >>>> Private Local Area Network Service (VPLS), Virtual Private=20 > >>>> Multicast > >>>> Service (VPMS) or Internet Protocol Local Area Network Service > >>>> (IPLS), pseudowires must be used to carry the client=20 > service. =20 > >>>> VPWS, > >>>> VLPS, and IPLS are described in [RFC4664]. VPMS is=20 > described in > >>>> [I-D.ietf-l2vpn-vpms-frmwk-requirements]. > >>>> > >>>> This section should be deleted. From a MPLS-TP network view=20 > >>>> point the service interface, that requires PWs, is a > >> point-to-point > >>>> layer 2 interface that carries both network layer and=20 > non-network=20 > >>>> layer traffic. This is orthogonal to the service which is being=20 > >>>> delivered to the end user. Hence this section doesn't=20 > belong here. > >>>> > >>>> > >>>> 8. 3.4.3. Network Layer Adaptation > >>>> > >>>> MPLS-TP LSPs can be used to transport network layer > >> clients. This > >>>> document uses the term Network Layer in the same=20 > sense as it is=20 > >>>> used > >>>> in [RFC3031] and [RFC3032]. The network layer > >> protocols supported > >>>> by > >>>> [RFC3031] and [RFC3032] can be transported between service > >>>> interfaces. Examples are shown in Figure 5 above. =20 > Support for > >>>> network layer clients follows the MPLS architecture for > >> support of > >>>> network layer protocols as specified in [RFC3031] and=20 > [RFC3032]. > >>>> > >>>> With network layer adaptation, the MPLS-TP domain > >> provides either a > >>>> uni-directional or bidirectional point-to-point > >> connection between > >>>> two PEs in order to deliver a packet transport service > >> to attached > >>>> customer edge (CE) nodes. For example, a CE may be an > >> IP, MPLS or > >>>> > >>>> > >>>> > >>>> Bocci, et al. Expires August 8, 2010 =20 > >>>> [Page 21] > >>>> > >>>> Internet-Draft MPLS Transport Profile Framework =20 > >>>> February 2010 > >>>> > >>>> > >>>> MPLS-TP node. As shown in Figure 9, there is an > >> attachment circuit > >>>> between the CE node on the left and its corresponding > >> provider edge > >>>> (PE) node which provides the service interface, a > >> bidirectional LSP > >>>> across the MPLS-TP network to the corresponding PE=20 > node on the=20 > >>>> right, > >>>> and an attachment circuit between that PE node and the=20 > >>>> corresponding > >>>> CE node for this service. > >>>> > >>>> The attachment circuits may be heterogeneous (e.g., any > >> combination > >>>> of SDH, PPP, Frame Relay, etc.) and network layer > >> protocol payloads > >>>> arrive at the service interface encapsulated in the > >> Layer1/Layer2 > >>>> encoding defined for that access link type. It=20 > should be noted=20 > >>>> that > >>>> the set of network layer protocols includes MPLS and=20 > hence MPLS > >>>> encoded packets with an MPLS label stack (the client > >> MPLS stack), > >>>> may > >>>> appear at the service interface. > >>>> > >>>> |<------------- Client Network Layer=20 > ------------->| > >>>> | =20 > | > >>>> | |<---- Pkt Xport Service --->| =20 > | > >>>> | | | =20 > | > >>>> | | |<-- PSN Tunnel -->| | =20 > | > >>>> | V V V V =20 > | > >>>> V AC +----+ +---+ +----+ =20 > AC V > >>>> +-----+ | |PE1 | | | |PE2 | | =20 > >>>> +-----+ > >>>> | | |LSP | | | | | | | =20 > >>>> | | > >>>> | CE1 |----------| = |=3D=3D=3D=3D=3D=3D=3D=3DX=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 > >>>> |----------| CE2 | > >>>> | | ^ |IP | | ^ | | ^ | | | =20 > >>>> ^ | | > >>>> +-----+ | | | | | | | | | | | =20 > >>>> | +-----+ > >>>> ^ | +----+ | +---+ | +----+ =20 > | | ^ > >>>> | | Provider | ^ | Provider=20 > | | > >>>> | | Edge | | | Edge =20 > | | > >>>> Customer | 1 | P-router | 2 =20 > >>>> | Customer > >>>> Edge 1 | TE TE =20 > >> | Edge 2 > >>>> | LSP LSP | > >>>> | | > >>>> Native service =20 > >> Native service > >>>> > >>>> > >>>> Figure 9: MPLS-TP Architecture for Network Layer Clients > >>>> > >>>> PE1 and PE2 should be specifically labeled as MPLS-TP PEs. > >>>> > >>>> At the ingress service interface the client packets are > >> received . > >>>> The PE pushes one or more labels onto the client > >> packets which are > >>>> then label switched over the transport network. =20 > >>>> Correspondingly the > >>>> egress PE pops any labels added by the MPLS-TP networks and=20 > >>>> transmits > >>>> the packet for delivery to the attached CE via the > >> egress service > >>>> interface. > >>>> > >>>> 9. 3.6. Generic Associated Channel (G-ACh) > >>>> > >>>> For correct operation of the OAM it is important that the OAM=20 > >>>> packets > >>>> fate-share with the data packets. In addition in=20 > MPLS-TP it is > >>>> necessary to discriminate between user data payloads=20 > and other=20 > >>>> types > >>>> of payload. For example, a packet may be associated with a=20 > >>>> Signaling > >>>> Communication Channel (SCC), or a channel used for Automatic > >>>> Protection Switching (APS) data. This is achieved by > >> carrying such > >>>> packets on a generic control channel associated to the > >> LSP, PW or > >>>> section. > >>>> > >>>> Suggest replacing the last sentence with: > >>>> > >>>> "This is achieved by either carrying such packets in an IP=20 > >>>> encapsulation that provides the necessary discrimination, or by=20 > >>>> carrying such packets on a generic control channel > >> associated to the > >>>> LSP, PW or section. Rest of this section describes the latter=20 > >>>> mechanism." > >>>> > >>>> Also please see related comment in section 3.7. > >>>> > >>>> > >>>> 10. 3.7. Operations, Administration and Maintenance (OAM) > >>>> > >>>> MPLS-TP must be able to operate in environments where=20 > IP is not=20 > >>>> used > >>>> in the forwarding plane. Therefore, the default > >> mechanism for OAM > >>>> demultiplexing in MPLS-TP LSPs and PWs is the Generic=20 > Associated > >>>> Channel (Section 3.6). Forwarding based on IP > >> addresses for user > >>>> or > >>>> OAM packets is not required for MPLS-TP. > >>>> > >>>> [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls]=20 > have defined > >>>> alert mechanisms that enable an MPLS LSR to identify > >> and process > >>>> MPLS > >>>> OAM packets when the OAM packets are encapsulated in an > >> IP header. > >>>> These alert mechanisms are based on TTL expiration > >> and/or use an IP > >>>> destination address in the range 127/8 for IPv4 and > >> that same range > >>>> embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379].=20 > >>>> When the > >>>> OAM packets are encapsulated in an IP header, these > >> mechanisms are > >>>> the default mechanisms for MPLS networks in general for > >> identifying > >>>> MPLS OAM packets. MPLS-TP must be able to operate in an=20 > >>>> environments > >>>> where IP forwarding is not supported, and thus the > >> G-ACh/GAL is the > >>>> default mechanism to demultiplex OAM packets in MPLS-TP. > >>>> > >>>> The last sentence is in conflict with the following > >> from section > >>>> 4.1 of RFC 5586: > >>>> > >>>> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert=20 > mechanisms > >>>> that enable an MPLS LSR to identify and process MPLS > >> OAM packets > >>>> when > >>>> these are encapsulated in an IP header. These alert > >> mechanisms are > >>>> based, for example, on Time To Live (TTL) expiration > >> and/or on the > >>>> use of an IP destination address in the range of > >>>> 127.0.0.0/8 or 0:0: > >>>> 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. > >>>> > >>>> These mechanisms are the default mechanisms for > >> identifying MPLS > >>>> OAM > >>>> packets when encapsulated in an IP header although=20 > the mechanism > >>>> defined in this document MAY also be used." > >>>> > >>>> Hence the last sentence of the above paragraph must > >> be removed. > >>>> > >>>> > >>>> rahul > >>>> > >>>> _______________________________________________ > >>>> 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 > >>>> > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>> > >>> > >>> > >> > >=20 > >=20 > >=20 >=20 From Alexander.Vainshtein@ecitele.com Wed Feb 10 07:29: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 D17313A76F6; Wed, 10 Feb 2010 07:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0evrv3HFg39R; Wed, 10 Feb 2010 07:29:53 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id B5EDB3A73BC; Wed, 10 Feb 2010 07:29:52 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-07-4b72cfc93cd5 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id EB.E7.18464.9CFC27B4; Wed, 10 Feb 2010 17:24:57 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 10 Feb 2010 17:31:01 +0200 From: Alexander Vainshtein To: "mngpl@singnet.com.sg" Date: Wed, 10 Feb 2010 17:31:00 +0200 Thread-Topic: [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqqNdRunFpgX6gqRoCnGTyKaohzqwALnCGw Message-ID: References: <1265795114.4b72802ab7a84@discus.singnet.com.sg> In-Reply-To: <1265795114.4b72802ab7a84@discus.singnet.com.sg> 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 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , Loa, "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 10 Feb 2010 15:29:55 -0000 Max, The MPLS-TP framework draft is defined as Informational while the MPLS-TP d= ata plane draft is defined as Standard Track. This seems to be one good reason not to= merge them. On the other hand, it makes sense to me move all the data-plane issues from= the Framework draft to the data plane one and just to reference in in the Frame= work draft. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of mngpl@singnet.com.sg > Sent: Wednesday, February 10, 2010 11:45 AM > To: Loa Andersson > Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org > Subject: Re: [PWE3] [mpls-tp] poll on making=20 > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >=20 > Hi Loa and the authors, >=20 > From what I read, the main key aspect of this draft defines a=20 > new ethernet MAC discovery through the use of multicast MAC.=20 > The rest of the drafts discuss about specific dataplane=20 > implementation that is align with=20 > draft-ietf-mpls-tp-framework-10, which calls it profiling. >=20 > Suggestion, why not put profile details into the framework=20 > draft? This improves readability? Or unless there can other=20 > type of profiling. >=20 > /Max=20 > --- Loa Andersson wrote: >=20 > > All, > >=20 > > This is to start two week poll on making > > draft-fbb-mpls-tp-data-plane-00.txt > > an mpls working group document. > >=20 > > Send a mail to the mpls-tp@ietf.org mailing list, > > indicating "yes/support" or "no/do not support". > >=20 > > Note that this ID is a starting point for what needs to > > be documented on the MPLS data plane for the MPLS-TP > > project. The ID is largely based on the data plane specific > > text from the framework, together with some notes concerning > > how the Transport Profile of MPLS might operate over Ethernet. > >=20 > >=20 > > /Loa > >=20 > >=20 > > --=20 > >=20 > >=20 > > 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 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > = From ldunbar@huawei.com Wed Feb 10 08:30: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 A76833A7759 for ; Wed, 10 Feb 2010 08:30: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 2XfnDQokPevl for ; Wed, 10 Feb 2010 08:30:23 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id D0AFD3A7757 for ; Wed, 10 Feb 2010 08:30:23 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXM004IAVT4KX@usaga02-in.huawei.com> for mpls@ietf.org; Wed, 10 Feb 2010 08:15:04 -0800 (PST) Received: from L735042 ([10.124.12.68]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXM000YQVT3JC@usaga02-in.huawei.com> for mpls@ietf.org; Wed, 10 Feb 2010 08:15:03 -0800 (PST) Date: Wed, 10 Feb 2010 10:15:03 -0600 From: Linda Dunbar To: mpls@ietf.org Message-id: <005d01caaa6c$33fb2f50$440c7c0a@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_cIJHIYllh79Vq9LKbVSULw)" Thread-index: Acqp4xk5QdTJOgyZR8miH8gmfjjjZQAiRHoA Subject: [mpls] Questions on "draft-ietf-mpls-tp-fault-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, 10 Feb 2010 16:30:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_cIJHIYllh79Vq9LKbVSULw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT George and others, AIS is introduced in the draft-fbb-mpls-tp-data-plane-00 (Section 2.1). Question: Is it Source LSR or any intermediate LSR to send AIS upon detecting adjacent link failure? Same question goes to Link Down Indication. Is it the Source LSR who indicates its adjacent link being Down? Thanks, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_cIJHIYllh79Vq9LKbVSULw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

 

George and others,

 

AIS is introduced in the draft-fbb-mpls-tp-data-plane-00 (Section 2.1).

 

Question: Is it Source LSR or any intermediate LSR to send AIS upon detecting adjacent link failure?

 

Same question goes to Link Down Indication. Is it the Source LSR who indicates its adjacent link being Down?

 

Thanks, Linda Dunbar

 

 

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_cIJHIYllh79Vq9LKbVSULw)-- From nitinb@juniper.net Wed Feb 10 12:01:34 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 5C95428C240; Wed, 10 Feb 2010 12:01:34 -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 kMlKD4gMXkO0; Wed, 10 Feb 2010 12:01:33 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 6E0C528C22B; Wed, 10 Feb 2010 12:01:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS3MQ24JcfvW/MnsjoNCOq9RvFAMBNpjs@postini.com; Wed, 10 Feb 2010 12:02:38 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 10 Feb 2010 12:02:23 -0800 From: Nitin Bahadur To: 'MachChen 55527' , 'George Swallow' Date: Wed, 10 Feb 2010 12:02:23 -0800 Thread-Topic: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: AcoPgpDaCUUivjTVR5+oke4yoWVXQSa/esLw Message-ID: <05542EC42316164383B5180707A489EE1D0AC2F6AA@EMBX02-HQ.jnpr.net> References: 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] Comments for 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: Wed, 10 Feb 2010 20:01:34 -0000 Hi Mach, =20 Please see inline below for comments. > There are two issues that our draft tries to resolve: > 1. Current LSP Ping mechanisms are lack of the capability of specifying t= he return path=20 > of an echo reply, hence some time it may bring difficuties in faults = localization.=20 NB> This is only a problem for uni-directional LSPs. Also, the problem onl= y exists if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path is DOWN, then lsp traceroute should help in fault localization. See my comm= ents below for=20 bi-directional LSPs. =20 > 2. A bidirectional path checking needs at least two LSP pings(inefficient= ), and sometime > difficut even fail to check the reverse direction of a bidirectional= path.=20 NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, the egre= ss SHOULD=20 send the packet over the LSP itself. For bidirectional associated LSP, the egress again SHOULD send the packet = over the=20 associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-lsp-pi= ng-extensions-00. Even if the specifications in the draft above are not used, I presume= there will *some* way that one will specify the LSP "association". One could use that w= ay to ensure that lsp-ping responses always use that association. So additional protoco= l machinery is not needed. For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP is un= i-directional..... so you are testing only the forward direction..... there is no concept of reverse direction for uni-directional LSPs. Other comments -------------- The draft talks about specifying ways in which ingress could specify how th= e egress should respond. I fail to see how operators will use this *ability* = in the field. How does the operator know which LSP should be used for return-p= ath? If the operator knows this via config, then the same config could be added = at LSP egress as well.=20 If the operator is just going to loop through (in return-path tlv) all the = egress=20 initated LSPs hoping for at least 1 successful response, then the scheme is= broken. One should use BFD (or some other mechanism) to ensure that both ingress in= itiated and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress can respond back via any UP LSP and the echo response will reach the ingres= s...since the LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP),=20 then I guess you could add a code-point that says "reply via lsp" or someth= ing like that. >From a practical operator persecptive, I need to understand more on how som= eone would use the feature/flexibility that you are proposing. Thanks Nitin= From maarten.vissers@huawei.com Wed Feb 10 14:44: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 334083A77C0; Wed, 10 Feb 2010 14:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 wJF9Rd1f5MqD; Wed, 10 Feb 2010 14:44:19 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 827853A73A6; Wed, 10 Feb 2010 14:44:18 -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 <0KXN00IWDDVSJ7@szxga03-in.huawei.com>; Thu, 11 Feb 2010 06:45:28 +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 <0KXN00DGQDVSMP@szxga03-in.huawei.com>; Thu, 11 Feb 2010 06:45:28 +0800 (CST) Received: from M00900002 ([81.253.33.106]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN00EAODVLEM@szxml01-in.huawei.com>; Thu, 11 Feb 2010 06:45:28 +0800 (CST) Date: Wed, 10 Feb 2010 23:45:12 +0100 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, rahul@juniper.net, loa@pi.nu Message-id: <001a01caaaa2$b7ba3c60$36b912ac@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: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acqmv3GyuMS5TyKNSz2jew5pAyrlMQDCUcAwAADD7UAANW1HEA== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 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, 10 Feb 2010 22:44:21 -0000 Neil, As I have been describing on this mailinglist some time ago, it is technically possible to use a reserved label to mark MEG levels. This would allow us to identify layer boundaries from sublayer boundaries. There was no support for it... This implies that the data plane packet format will not be descriptive. It seems that the operator and vendor communities don't need a descriptive packet format. Let's accept that verdict and focus our effort on the remaining open issues; e.g. on more explicit descriptions of the functionality in the transport service layer, the transport path layer and the section layer. Interoperability in an MPLS-TP network will only be simple when we specify unambiguously an MPLS-TP NNI format (i.e. a MPLS-TP Transport Module (MTM-n) network node interface specification), in analogy to the STM-N and OTM-n network node interface specifications in G.707 and G.709. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: dinsdag 9 februari 2010 22:25 To: maarten.vissers@huawei.com; rahul@juniper.net; loa@pi.nu Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: RE: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 Maarten, Please let us not confuse folks with terms like 'transport entity'....we all know that MPLS-TP will only be using proper connections because we want to *deterministically and simply* manage resource. However, you are absolutely right to pick-up on the point that an LSP is *not necessarily* a layer network. AFAIK we now have no way of telling from looking at the DP whether a suite of nested LSPs is sublayered or layered...seems one can mix up sublayering and proper client/server layering of LSPs at will. This is not great architectural design practice IMO but this seems to be happening because we cannot easily satisfy the real transport requirement whilst clinging on to some old MPLS behaviours. Some while ago I suggested (at least to Stewart) that if folks want to keep sublayering in MPLS-TP, then we should have an unambiguous way of identifying when one sublayer stack of LSPs ends (say a client layer MPLS-TP network belonging to party X) and a different sublayer stack of LSPs begins (say a server layer MPLS-TP network belonging to party Y). I suggested we should allocate a globally well-known functional label from the 0-15 set for this important client/server case. We could also use the same reserved label in MPLS. Note this is consistent with respecting consistent CI as the label is globally well-known. I still think this idea should be given serious consideration due to the importance (to operators) of being able to have a quite clear client/server relationship in MPLS-TP between different operating parties. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 09 February 2010 20:50 > To: 'Rahul Aggarwal'; 'Loa Andersson' > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 > > Rahul, > > The MPLS-TP LSP is not a layer network. The LSP is a transport entity > within either the transport service layer network, or the transport > path layer network, or the section layer network. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal > Sent: zaterdag 6 februari 2010 1:00 > To: Loa Andersson > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 > > > Here are my LC comments on draft-ietf-mpls-tp-framework-10, prefixed > by > : > > > 1. 1.3.4. MPLS-TP Label Switched Path > > An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a > subset of the capabilities of an MPLS LSP in order to meet the > requirements of an MPLS transport network as set out in [RFC5654]. > The characteristics of an MPLS-TP LSP are primarily that it: > > I would suggest adding: "A MPLS-TP LSP is the lowest server layer > provided by MPLS-TP. The client layers of a MPLS-TP LSP maybe IP, MPLS > or PWs. The client layers of a MPLS-TP LSP are described in detail in > section 3.4" > > This is to make the client server relationship in MPLS-TP clearer. > > 2. 1.3.10. Additional Definitions and Terminology > > Detailed definitions and additional terminology may be found in > [RFC5654]. > > I would suggest a section on "Service Interface". This is to > clarify the applicability of the use of MPLS-TP LSPs and PWs as > described in section 3.4. Furhter it is needed to clarify what is the > interface exposed by MPLS-TP to the client network. > > "Service Interface > > The transport service provided by MPLS-TP is said to be provided by a > service interface. The following are the service interfaces supported > by > MPLS-TP: > > - The service interface may a layer 2 interface that carries only > network layer clients. MPLS-TP LSPs are both necessary and sufficient > to support this service interface as described in section 3.4.3 > > - Or the service interface may be a layer 2 interface that carries > both network layer and non-network layer clients. To support this > service interface, a PW is required to adapt the client traffic > received over the service interface. This PW in turn is a client of > the MPLS-TP server layer. > This is described in section 3.4.2. > > - Or the service interface may be a MPLS LSP or a PW. To support this > case a MPLS-TP PE participates in the service interface signaling." > > 3. 1.4. Applicability > > MPLS-TP can be used to construct packet transport networks and is > therefore applicable in any packet transport network context. It > is > also applicable to subsets of a packet network where the transport > network operational model is deemed attractive. The following are > examples of MPLS-TP applicability models: > > 1. MPLS-TP provided by a network that only supports MPLS-TP LSPs > and > PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or > LSRs), acting as a server for other layer 1, layer 2 and layer > 3 > networks (Figure 1). > > 2. MPLS-TP provided by a network that also supports non-MPLS-TP > LSPs > and PWs (i.e. both LSPs and PWs that conform to the transport > profile and those that do not, exist between the PEs), acting > as > a server for other layer 1, layer 2 and layer 3 networks > (Figure 2). > > 3. MPLS-TP as a server layer for client layer traffic of IP or > MPLS > networks which do not use functions of the MPLS transport > profile. For MPLS traffic, the MPLS-TP server layer network > uses > PW switching [RFC5659] or LSP stitching [RFC5150] at the PE > that > terminates the MPLS-TP server layer (Figure 3). > > > I think figure 3 and case 3 as written currently are making an > assumption that a MPLS-TP PE participates in the "service interface > signaling" where the service interface provided by MPLS-TP is a MPLS > LSP or a PW. This is a NNI model. Perhaps we need two sub-cases of > case 3. > One is a UNI model where the MPLS network just sees a P2P or P2MP > link, which is provided by the MPLS-TP network. In this case > mechanisms of section > 3.4.3 are sufficient. The second case is the one which the current > text seems to imply and in that case the MPLS-TP PE would participate > in the MPLS signaling. In this case the MPLS-TP PE may use LSP > hierarchy or LSP stitching to support the MPLS-LSP as a service > interface and may use PW stitching to support PW as a service > interface. > > So I would propose to replace example number 3 above with: > > "3. MPLS-TP as a server layer for client layer traffic of IP or > MPLS > networks which do not use functions of the MPLS transport > profile. Here are two examples of applicability models of this: > > a) The client IP or MPLS network is provided a layer 2 P2P or > P2MP link by the MPLS-TP network. In other words the service > interface is a layer 2 inteface that carries only IP or MPLS > packets. To support this case the MPLS-TP server layer > network uses > the mechanisms of section 3.4.3 to carry IP or MPLS client l > layer traffic over MPLS-TP LSPs" > > b) The client IP or MPLS network is provided a LSP or a PW as a > service interface by the MPLS-TP network. In this case > the MPLS-TP PE would participate in the client MPLS > signaling. > In this case the MPLS-TP PE may use LSP hierarchy or LSP > stitching to support the MPLS-LSP as a service interface and > may use PW stitching to support PW as a service interface > (Figure 3)" > > 4. 3.1 Packet Transport Services > > One objective of MPLS-TP is to enable MPLS networks to provide > packet > transport services with a similar degree of predictability to that > found in existing transport networks. Such packet transport > services > inherit a number of characteristics, defined in [RFC5654]: > > o In an environment where an MPLS-TP layer network is supporting a > client layer network, and the MPLS-TP layer network is supported > by a server layer network then operation of the MPLS-TP layer > network must be possible without any dependencies on either the > server or client layer network. > > o The service provided by the MPLS-TP network to the client is > guaranteed not to fall below the agreed level regardless of > other > client activity. > > o The control and management planes of any client network layer > that > uses the service is isolated from the control and management > planes of the MPLS-TP layer network, where the client network > layer is considered to be the native service of the MPLS-TP > network. > > o Where a client network makes use of an MPLS-TP server that > provides a packet transport service, the level of co-ordination > required between the client and server layer networks is minimal > (preferably no co-ordination will be required). > > o The complete set of packets generated by a client > MPLS(-TP) layer > network using the packet transport service, which may contain > packets that are not MPLS packets (e.g. IP or CLNS packets used > by the control/management plane of the client MPLS(-TP) layer > > > > Bocci, et al. Expires August 8, 2010 > [Page 12] > > Internet-Draft MPLS Transport Profile Framework > February 2010 > > > network), are transported by the MPLS-TP server layer network. > > o The packet transport service enables the MPLS-TP layer network > addressing and other information (e.g. topology) to be hidden > from > any client layer networks using that service, and vice-versa. > > These characteristics imply that a packet transport service does > not > support a connectionless packet-switched forwarding mode. However, > this does not preclude it carrying client traffic associated with a > connectionless service. > > Such packet transport services are very similar to Layer 2 Virtual > Private Networks as defined by the IETF. > > The last sentence should be deleted. It doesn't add value and is > in potential conflict with section 3.4.3. > > > 5. 3.3. Architecture > > MPLS-TP comprises the following architectural elements: > > o A standard MPLS data plane [RFC3031] as profiled in > [I-D.fbb-mpls-tp-data-plane]. > > Standard MPLS data plane also includes RFC 5331 and RFC 5332. > Given draft-fbb is not a WG draft, I don't think we should add a > reference to it here. > > > 6. 3.4.2. Pseudowire Adaptation > > The architecture for an MPLS-TP network that provides PW emulated > services is based on the MPLS [RFC3031] and pseudowire [RFC3985] > architectures. > > I think instead of "PW emulated services", the section should > start with the service interface that requires PWs. > Something like: > > "If the MPLS-TP network provides a layer 2 interface, that carries > both network layer and non-network layer traffic, as a service > interface then a PW is required to support the service interface. > The PW is a client of the MPLS-TP LSP server layer. The architecture > of a MPLS-TP network that uses such PWs is is based on the MPLS > [RFC3031] and pseudowire [RFC3985] architectures." > > The above is to make it very clear the applicability of > 3.4.2 as compared to 3.4.3. > > Multi-segment pseudowires may optionally be used to > provide a packet transport service, and their use is consistent > with > > > > Bocci, et al. Expires August 8, 2010 > [Page 18] > > Internet-Draft MPLS Transport Profile Framework > February 2010 > > > the MPLS-TP architecture. The use of MS-PWs may be motivated by, > for > example, the requirements specified in [RFC5254]. If MS-PWs are > used, then the MS-PW architecture [RFC5659] also applies. > > Figure 6 shows the architecture for an MPLS-TP network using > single- > segment PWs. > > |<--------------- Emulated Service ----------------->| > | | > | |<-------- Pseudowire -------->| | > | | encapsulated, packet | | > | | transport service | | > | | | | > | | |<------ LSP ------->| | | > | V V V V | > V AC +----+ +-----+ +----+ AC V > +-----+ | | PE1|=======\ /========| PE2| | > +-----+ > | |----------|.......PW1.| \ / > |............|----------| | > | CE1 | | | | | X | | | | > | CE2 | > | |----------|.......PW2.| / \ > |............|----------| | > +-----+ ^ | | |=======/ \========| | | > ^ +-----+ > ^ | +----+ +-----+ +----+ | ^ > | | Provider Edge 1 ^ Provider Edge 2 | | > | | | | | > Customer | P Router > | Customer > Edge 1 | > | Edge 2 > | | > | | > Native service Native service > > > Figure 6: MPLS-TP Architecture (Single Segment PW) > > Figure 7 shows the architecture for an MPLS-TP network when multi- > segment pseudowires are used. Note that as in the SS-PW case, > P-routers may also exist. > > This figure needs to clarify where the MPLS-TP PEs are and where > the "service PEs" are. Or whether PE1 is actually both the MPLS-TP PE > and the service PE. > > > > > > > > > > > > > > > Bocci, et al. Expires August 8, 2010 > [Page 19] > > Internet-Draft MPLS Transport Profile Framework > February 2010 > > > |<----------- Pseudowire encapsulated ------------->| > | packet transport service | > | | > | | > | | > AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC > | V V V V V V | > | +----+ +-----+ +----+ +----+ | > +---+ | |TPE1|===============\ > /=====|SPE1|==========|TPE2| | +---+ > | |---|......PW1-Seg1.... | \ / | > ......X...PW1-Seg2......|---| | > |CE1| | | | | X | | | | > | | |CE2| > | |---|......PW2-Seg1.... | / \ | > ......X...PW2-Seg2......|---| | > +---+ | | |===============/ \=====| |==========| > | | +---+ > ^ +----+ ^ +-----+ +----+ ^ +----+ ^ > | | ^ | | > | TE LSP | TE LSP | > | P-router | > | | > |<-------------------- Emulated Service ------------------->| > > PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while > PW2-segment1 and PW2-segment2 are segments of another MS-PW > > > Figure 7: MPLS-TP Architecture (Multi-Segment PW) > > The corresponding MPLS-TP protocol stacks including PWs are shown > in > Figure 8. In this figure the Transport Service Layer [RFC5654] is > identified by the PW demultiplexer (Demux) label and the Transport > Path Layer [RFC5654] is identified by the LSP Demux Label. > > > > > > > > > > > > > > > > > > > > > > Bocci, et al. Expires August 8, 2010 > [Page 20] > > Internet-Draft MPLS Transport Profile Framework > February 2010 > > > +-------------------+ /===================\ > /===================\ > | Client Layer | H OAM PDU H H OAM > PDU H > /===================\ H-------------------H > H-------------------H > H PW Encap H H GACh H H > GACh H > H-------------------H H-------------------H > H-------------------H > H PW Demux (S=1) H H PW Demux (S=1) H H GAL > (S=1) H > H-------------------H H-------------------H > H-------------------H > H LSP Demux(s) H H LSP Demux(s) H H LSP > Demux(s) H > \===================/ \===================/ > \===================/ > | Server Layer | | Server Layer | | Server > Layer | > +-------------------+ +-------------------+ > +-------------------+ > > User Traffic PW OAM LSP OAM > > Note: H(ighlighted) indicates the part of the protocol stack we are > considering in this document. > > > Figure 8: MPLS-TP Layer Network using Pseudowires > > PWs and their associated labels may be configured or signaled. See > Section 3.11 for additional details related to configured service > types. See Section 3.9 for additional details related to signaled > service types. > > 7. 3.4.2.1. Pseudowire Based Services > > When providing a Virtual Private Wire Service (VPWS) , Virtual > Private Local Area Network Service (VPLS), Virtual Private > Multicast > Service (VPMS) or Internet Protocol Local Area Network Service > (IPLS), pseudowires must be used to carry the client service. > VPWS, > VLPS, and IPLS are described in [RFC4664]. VPMS is described in > [I-D.ietf-l2vpn-vpms-frmwk-requirements]. > > This section should be deleted. From a MPLS-TP network view point > the service interface, that requires PWs, is a point-to-point layer 2 > interface that carries both network layer and non-network layer > traffic. This is orthogonal to the service which is being delivered to > the end user. Hence this section doesn't belong here. > > > 8. 3.4.3. Network Layer Adaptation > > MPLS-TP LSPs can be used to transport network layer clients. This > document uses the term Network Layer in the same sense as > it is used > in [RFC3031] and [RFC3032]. The network layer protocols > supported by > [RFC3031] and [RFC3032] can be transported between service > interfaces. Examples are shown in Figure 5 above. Support for > network layer clients follows the MPLS architecture for support of > network layer protocols as specified in [RFC3031] and [RFC3032]. > > With network layer adaptation, the MPLS-TP domain provides either a > uni-directional or bidirectional point-to-point connection between > two PEs in order to deliver a packet transport service to attached > customer edge (CE) nodes. For example, a CE may be an IP, MPLS or > > > > Bocci, et al. Expires August 8, 2010 > [Page 21] > > Internet-Draft MPLS Transport Profile Framework > February 2010 > > > MPLS-TP node. As shown in Figure 9, there is an attachment circuit > between the CE node on the left and its corresponding provider edge > (PE) node which provides the service interface, a bidirectional LSP > across the MPLS-TP network to the corresponding PE node on > the right, > and an attachment circuit between that PE node and the > corresponding > CE node for this service. > > The attachment circuits may be heterogeneous (e.g., any combination > of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads > arrive at the service interface encapsulated in the Layer1/Layer2 > encoding defined for that access link type. It should be > noted that > the set of network layer protocols includes MPLS and hence MPLS > encoded packets with an MPLS label stack (the client MPLS > stack), may > appear at the service interface. > > |<------------- Client Network Layer ------------->| > | | > | |<---- Pkt Xport Service --->| | > | | | | > | | |<-- PSN Tunnel -->| | | > | V V V V | > V AC +----+ +---+ +----+ AC V > +-----+ | |PE1 | | | |PE2 | | > +-----+ > | | |LSP | | | | | | | > | | > | CE1 |----------| |========X=========| > |----------| CE2 | > | | ^ |IP | | ^ | | ^ | | | > ^ | | > +-----+ | | | | | | | | | | | > | +-----+ > ^ | +----+ | +---+ | +----+ | | ^ > | | Provider | ^ | Provider | | > | | Edge | | | Edge | | > Customer | 1 | P-router | 2 > | Customer > Edge 1 | TE TE | Edge 2 > | LSP LSP | > | | > Native service Native service > > > Figure 9: MPLS-TP Architecture for Network Layer Clients > > PE1 and PE2 should be specifically labeled as MPLS-TP PEs. > > At the ingress service interface the client packets are received . > The PE pushes one or more labels onto the client packets which are > then label switched over the transport network. > Correspondingly the > egress PE pops any labels added by the MPLS-TP networks > and transmits > the packet for delivery to the attached CE via the egress service > interface. > > 9. 3.6. Generic Associated Channel (G-ACh) > > For correct operation of the OAM it is important that the > OAM packets > fate-share with the data packets. In addition in MPLS-TP it is > necessary to discriminate between user data payloads and > other types > of payload. For example, a packet may be associated with > a Signaling > Communication Channel (SCC), or a channel used for Automatic > Protection Switching (APS) data. This is achieved by carrying such > packets on a generic control channel associated to the LSP, PW or > section. > > Suggest replacing the last sentence with: > > "This is achieved by either carrying such packets in an IP > encapsulation that provides the necessary discrimination, or > by carrying such packets on a generic control channel > associated to the LSP, PW or section. Rest of this section > describes the latter mechanism." > > Also please see related comment in section 3.7. > > > 10. 3.7. Operations, Administration and Maintenance (OAM) > > MPLS-TP must be able to operate in environments where IP > is not used > in the forwarding plane. Therefore, the default mechanism for OAM > demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated > Channel (Section 3.6). Forwarding based on IP addresses > for user or > OAM packets is not required for MPLS-TP. > > [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined > alert mechanisms that enable an MPLS LSR to identify and > process MPLS > OAM packets when the OAM packets are encapsulated in an IP header. > These alert mechanisms are based on TTL expiration and/or use an IP > destination address in the range 127/8 for IPv4 and that same range > embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. > When the > OAM packets are encapsulated in an IP header, these mechanisms are > the default mechanisms for MPLS networks in general for identifying > MPLS OAM packets. MPLS-TP must be able to operate in an > environments > where IP forwarding is not supported, and thus the G-ACh/GAL is the > default mechanism to demultiplex OAM packets in MPLS-TP. > > The last sentence is in conflict with the following from section > 4.1 of RFC 5586: > > "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms > that enable an MPLS LSR to identify and process MPLS OAM > packets when > these are encapsulated in an IP header. These alert mechanisms are > based, for example, on Time To Live (TTL) expiration and/or on the > use of an IP destination address in the range of > 127.0.0.0/8 or 0:0: > 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. > > These mechanisms are the default mechanisms for > identifying MPLS OAM > packets when encapsulated in an IP header although the mechanism > defined in this document MAY also be used." > > Hence the last sentence of the above paragraph must be removed. > > > rahul > > _______________________________________________ > 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 > From gregimirsky@gmail.com Wed Feb 10 18:16: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 2AA8528C0E8; Wed, 10 Feb 2010 18:16:22 -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 kgVBGw+U6usv; Wed, 10 Feb 2010 18:16:19 -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 D445128C114; Wed, 10 Feb 2010 18:16:18 -0800 (PST) Received: by bwz19 with SMTP id 19so788291bwz.28 for ; Wed, 10 Feb 2010 18:17:25 -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=z+L5PU+Nhbuz4DRSbxRHWaV6AgbU67j2vPgt5kDmQ9o=; b=kCcshrFiM8f6qbbGTMlj0ZYookYtoafb3NvBEvqQiT2MNENzKvbJKCIirlOIrxvGty TqJM1npflwtySQZkY7nY//bSa4/lBtTeC13NNRsfIkw5bBazDtQ0TqDQwLaeY1oMva5i NmCoGIUWL24Mzxo6EyBkiDA4hL43oy07FmmSo= 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=GwQs2HpieZGUq3RezoiQTTMh4WzS4BVnyp+x6JC7Mn5cEE0tq5QMcKxJTBbL79/bvq 2vhj7JDnEJNCRZ9Hx4S08dHaPN+ioEKV4QdjU/iUYIsDG7feH9ZWcra3hTEr7PTEAdic ws68Ng+tY5GEWcVJwBqbBBJuUdD0p++VgFwWc= MIME-Version: 1.0 Received: by 10.204.33.206 with SMTP id i14mr761188bkd.52.1265854645185; Wed, 10 Feb 2010 18:17:25 -0800 (PST) In-Reply-To: <05542EC42316164383B5180707A489EE1D0AC2F6AA@EMBX02-HQ.jnpr.net> References: <05542EC42316164383B5180707A489EE1D0AC2F6AA@EMBX02-HQ.jnpr.net> Date: Wed, 10 Feb 2010 18:17:25 -0800 Message-ID: <787be2781002101817i29c97f44o2ffd3a080be8f817@mail.gmail.com> From: Greg Mirsky To: Nitin Bahadur Content-Type: multipart/alternative; boundary=0003255579ea76af0b047f49c059 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] Comments for 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, 11 Feb 2010 02:16:22 -0000 --0003255579ea76af0b047f49c059 Content-Type: text/plain; charset=ISO-8859-1 Dear Nitin, the LSP Ping might not be the only option but I believe that there must be a Control Plane mechanism to direct return path of BFD session (egress to ingress) of unidirectional LSP onto specified path (IP routed, LSP or else). There certainly could be local policy that will select such return path but that does not preclude from driving selection from headend or NMS. Would LSP Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expect to see appropriate extensions being proposed for RSVP-TE some time soon. (There's already proposal to bootstrap BFD session via RSVP-TE) Regards, Greg On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur wrote: > Hi Mach, > > Please see inline below for comments. > > > There are two issues that our draft tries to resolve: > > 1. Current LSP Ping mechanisms are lack of the capability of > specifying the return path > > of an echo reply, hence some time it may bring difficuties in > faults localization. > > NB> This is only a problem for uni-directional LSPs. Also, the > problem only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. See my > comments below for > bi-directional LSPs. > > > > 2. A bidirectional path checking needs at least two LSP > pings(inefficient), and sometime > > difficut even fail to check the reverse direction of a bidirectional > path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, > the egress SHOULD > send the packet over the LSP itself. > > For bidirectional associated LSP, the egress again SHOULD send the > packet over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presume > there will *some* > way that one will specify the LSP "association". One could use that > way to ensure that > lsp-ping responses always use that association. So additional protocol > machinery is not > needed. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP > is uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability* > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be added > at > LSP egress as well. > > If the operator is just going to loop through (in return-path tlv) all the > egress > initated LSPs hoping for at least 1 successful response, then the scheme is > broken. > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. > > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0003255579ea76af0b047f49c059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Nitin,
the LSP Ping might not be the only option but I believe that= there must be a Control Plane mechanism to direct return path of BFD sessi= on (egress to ingress) of unidirectional LSP onto specified path (IP routed= , LSP or else). There certainly could be local policy that will select such= return path but that does not preclude from driving selection from headend= or NMS. Would LSP Ping be the only such mechanism? Considering work on MPL= S-TP OAM I'd expect to see appropriate extensions being proposed for RS= VP-TE some time soon. (There's already proposal to bootstrap BFD sessio= n via RSVP-TE)

Regards,
Greg

On Wed, Feb 10, 2010= at 12:02 PM, Nitin Bahadur <nitinb@juniper.net> wrote:
Hi Mach,

=A0 =A0Please see inline below for comments.

> =A0 =A0 =A0 =A0There are two issues that our draft tries to resolve: > =A0 =A0 =A0 1. Current LSP Ping mechanisms are lack of the capability = of specifying the return path
> =A0 =A0 =A0 =A0 =A0of an echo reply, hence some time it may bring diff= icuties in faults localization.

=A0 =A0 =A0 =A0NB> This is only a problem for uni-directional LSPs. Als= o, the problem only exists
if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path
is DOWN, then lsp traceroute should help in fault localization. See my comm= ents below for
bi-directional LSPs.


> =A0 =A0 =A0 2. A bidirectional path checking needs at least two LSP pi= ngs(inefficient), and sometime
> =A0 =A0 =A0difficut even fail to check the reverse direction of a bidi= rectional path.

=A0 =A0 =A0 =A0NB> You don't need 2 LSP-Pings. For bidirectional co= -routed LSPs, the egress SHOULD
=A0 =A0 =A0send the packet over the LSP itself.

=A0 =A0 =A0 =A0For bidirectional associated LSP, the egress again SHOULD s= end the packet over the
=A0 =A0 =A0associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-= lsp-ping-extensions-00.
=A0 =A0 =A0Even if the specifications in the draft above are not used, I p= resume there will *some*
=A0 =A0 =A0way that one will specify the LSP "association". One = could use that way to ensure that
=A0 =A0 =A0lsp-ping responses always use that association. So additional p= rotocol machinery is not
=A0 =A0 =A0needed.

=A0 =A0 =A0 =A0For uni-directional LSPs, yes you will need 2 lsp-pings. Bu= t the LSP is uni-directional.....
=A0 =A0 =A0so you are testing only the forward direction.....
=A0 =A0 =A0there is no concept of reverse direction for uni-directional LS= Ps.


Other comments
--------------
The draft talks about specifying ways in which ingress could specify how th= e
egress should respond. I fail to see how operators will use this *ability* = in
the field. How does the operator know which LSP should be used for return-p= ath?
If the operator knows this via config, then the same config could be added = at
LSP egress as well.

If the operator is just going to loop through (in return-path tlv) all the = egress
initated LSPs hoping for at least 1 successful response, then the scheme is= broken.
One should use BFD (or some other mechanism) to ensure that both ingress in= itiated
and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress
can respond back via any UP LSP and the echo response will reach the ingres= s...since the
LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP),
then I guess you could add a code-point that says "reply via lsp"= or something like that.

>From a practical operator persecptive, I need to understand more on how som= eone would
use the feature/flexibility that you are proposing.

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

--0003255579ea76af0b047f49c059-- From nitinb@juniper.net Wed Feb 10 22:11: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 AC7E43A73C7; Wed, 10 Feb 2010 22:11:16 -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 wt-MR0L7eqCo; Wed, 10 Feb 2010 22:11:13 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 9798C28C0EE; Wed, 10 Feb 2010 22:11:12 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS3Ofxmfcs92zoMZdJb+6g0cYtqt3XhNp@postini.com; Wed, 10 Feb 2010 22:12:26 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, 10 Feb 2010 22:11:40 -0800 From: Nitin Bahadur To: Greg Mirsky Date: Wed, 10 Feb 2010 22:11:36 -0800 Thread-Topic: [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: AcqqwFyTN/OJxDrzSvOagOcBf6eC2wAILQ9V Message-ID: In-Reply-To: <787be2781002101817i29c97f44o2ffd3a080be8f817@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] Comments for 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, 11 Feb 2010 06:11:16 -0000 Hi Greg, It doesn=92t matter what the OAM protocol is...it could be LSP-Ping or s= omething else....and I agree with you on that. I also agree that there should be a control plane mechanism. Currently t= he drafts/RFC specify 2 mechanisms that apply to MPLS-TP LSPs =96 Reply via IP/UDP and Reply via control channel (ACH). In context of MPLS-TP, we are talking mainly about bidirectional co-rout= ed and associated LSPs. And the above 2 techniques apply well to both of them. In fact for co-routed and associated LSPs, we should = NOT be specifying a return path and instead ensure/validate that the echo response is received on the correct reverse path (if ACH is used).= Not explicitly specifying the path and validation will ensure that both ingress and egress have the same idea of the forward and reverse path. In s= hort, I do not see the use of this extension for MPLS-TP LSPs. For regular uni-directional LSPs, my main question is what is the operat= or going to gain by specifying the return path policy on the ingress (via signaling or NMS). This policy shoul= d be on the egress (rather than ingress). For uni-directional LSPs if you put the policy on the ingress, then you are adding state (on th= e ingress) regarding which LSPs exist on the egress. I might be missing the real intention and am definitely open to understa= nding the problem statement in more detail. Thanks Nitin On 2/10/10 6:17 PM, "Greg Mirsky" wrote: Dear Nitin, the LSP Ping might not be the only option but I believe that there must be = a Control Plane mechanism to direct return path of BFD session (egress to i= ngress) of unidirectional LSP onto specified path (IP routed, LSP or else).= There certainly could be local policy that will select such return path bu= t that does not preclude from driving selection from headend or NMS. Would = LSP Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd ex= pect to see appropriate extensions being proposed for RSVP-TE some time soo= n. (There's already proposal to bootstrap BFD session via RSVP-TE) Regards, Greg On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur wrote: Hi Mach, Please see inline below for comments. > There are two issues that our draft tries to resolve: > 1. Current LSP Ping mechanisms are lack of the capability of specif= ying the return path > of an echo reply, hence some time it may bring difficuties in fa= ults localization. NB> This is only a problem for uni-directional LSPs. Also, the prob= lem only exists if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path is DOWN, then lsp traceroute should help in fault localization. See my comm= ents below for bi-directional LSPs. > 2. A bidirectional path checking needs at least two LSP pings(ineff= icient), and sometime > difficut even fail to check the reverse direction of a bidirectional= path. NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, t= he egress SHOULD send the packet over the LSP itself. For bidirectional associated LSP, the egress again SHOULD send the = packet over the associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-lsp-pi= ng-extensions-00. Even if the specifications in the draft above are not used, I presume= there will *some* way that one will specify the LSP "association". One could use that w= ay to ensure that lsp-ping responses always use that association. So additional protoco= l machinery is not needed. For uni-directional LSPs, yes you will need 2 lsp-pings. But the LS= P is uni-directional..... so you are testing only the forward direction..... there is no concept of reverse direction for uni-directional LSPs. Other comments -------------- The draft talks about specifying ways in which ingress could specify how th= e egress should respond. I fail to see how operators will use this *ability* = in the field. How does the operator know which LSP should be used for return-p= ath? If the operator knows this via config, then the same config could be added = at LSP egress as well. If the operator is just going to loop through (in return-path tlv) all the = egress initated LSPs hoping for at least 1 successful response, then the scheme is= broken. One should use BFD (or some other mechanism) to ensure that both ingress in= itiated and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress can respond back via any UP LSP and the echo response will reach the ingres= s...since the LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP), then I guess you could add a code-point that says "reply via lsp" or someth= ing like that. >From a practical operator persecptive, I need to understand more on how som= eone would use the feature/flexibility that you are proposing. Thanks Nitin _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From vishwas.ietf@gmail.com Wed Feb 10 22:45: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 DE7F63A73C7; Wed, 10 Feb 2010 22:45:21 -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 Ct4rxY9nqFMP; Wed, 10 Feb 2010 22:45:11 -0800 (PST) Received: from mail-yx0-f195.google.com (mail-yx0-f195.google.com [209.85.210.195]) by core3.amsl.com (Postfix) with ESMTP id ED07A3A682F; Wed, 10 Feb 2010 22:45:10 -0800 (PST) Received: by yxe33 with SMTP id 33so852662yxe.5 for ; Wed, 10 Feb 2010 22:46:21 -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=gdXIRLd0AN/+t+eWipmXHJFdinUzE873qmYE4Q3qp7Y=; b=JHY8EgiF8XwfIF9Rcu7zv30cCUr4QkW8hil9ix7NYGpoR0WNw6X25hjY92YFArY7Yk LLmVvPN6x9Iu0FK52HofBY6UBvIowRLybU4GJOV9YJHdoVQf++VejJ+ehe0i34CnE6d3 3eJWGNTGOMZ96PP4hRtITDUhaQQPlG7DxjqAI= 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=w/cEq9p0nv9LBsOoeHBvFct8Ni47pNQ5ExXXuiA7YLVhtmse+PwK37brI9R/h1gVYq UtWDrWb6ecWXvljqbphhhxXce9BD921Ldg9heqZXrWaNapiWLZJzw+sB/gokvHs6Vwl7 f9aC8xRcQvyGX0I7sm6q34thb9hkBnHa6ZK78= MIME-Version: 1.0 Received: by 10.150.128.38 with SMTP id a38mr3430536ybd.217.1265870781012; Wed, 10 Feb 2010 22:46:21 -0800 (PST) In-Reply-To: References: <787be2781002101817i29c97f44o2ffd3a080be8f817@mail.gmail.com> Date: Wed, 10 Feb 2010 22:46:20 -0800 Message-ID: <77ead0ec1002102246v28f971a7p812e62e3934e2f57@mail.gmail.com> From: Vishwas Manral To: Nitin Bahadur Content-Type: multipart/alternative; boundary=000e0cd61e643bda16047f4d8254 Cc: "mpls-tp@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comments for 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, 11 Feb 2010 06:45:22 -0000 --000e0cd61e643bda16047f4d8254 Content-Type: text/plain; charset=ISO-8859-1 Hi Nitin, > > For regular uni-directional LSPs, my main question is what is the > operator going to gain by specifying the > return path policy on the ingress (via signaling or NMS). This policy > should be on the egress (rather than ingress). For uni-directional > LSPs if you put the policy on the ingress, then you are adding state (on > the ingress) regarding which LSPs exist on the egress. > > > Dont we generally want the ingress to specify policy because that is where the OAM initiated? Thanks, Vishwas > > On 2/10/10 6:17 PM, "Greg Mirsky" wrote: > > Dear Nitin, > the LSP Ping might not be the only option but I believe that there must be > a Control Plane mechanism to direct return path of BFD session (egress to > ingress) of unidirectional LSP onto specified path (IP routed, LSP or else). > There certainly could be local policy that will select such return path but > that does not preclude from driving selection from headend or NMS. Would LSP > Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expect > to see appropriate extensions being proposed for RSVP-TE some time soon. > (There's already proposal to bootstrap BFD session via RSVP-TE) > > Regards, > Greg > > On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur > wrote: > Hi Mach, > > Please see inline below for comments. > > > There are two issues that our draft tries to resolve: > > 1. Current LSP Ping mechanisms are lack of the capability of > specifying the return path > > of an echo reply, hence some time it may bring difficuties in > faults localization. > > NB> This is only a problem for uni-directional LSPs. Also, the > problem only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. See my > comments below for > bi-directional LSPs. > > > > 2. A bidirectional path checking needs at least two LSP > pings(inefficient), and sometime > > difficut even fail to check the reverse direction of a bidirectional > path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, > the egress SHOULD > send the packet over the LSP itself. > > For bidirectional associated LSP, the egress again SHOULD send the > packet over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presume > there will *some* > way that one will specify the LSP "association". One could use that > way to ensure that > lsp-ping responses always use that association. So additional protocol > machinery is not > needed. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP > is uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability* > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be added > at > LSP egress as well. > > If the operator is just going to loop through (in return-path tlv) all the > egress > initated LSPs hoping for at least 1 successful response, then the scheme is > broken. > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. > > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --000e0cd61e643bda16047f4d8254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nitin,

=A0 For regular uni-directio= nal LSPs, my main question is what is the operator going to gain by specify= ing the
return path policy on the ingress (via signaling or NMS). This policy shoul= d be on the egress (rather than ingress). =A0For uni-directional
LSPs if= you put the policy on the ingress, then you are adding state (on the ingre= ss) regarding which LSPs exist on the egress.

=A0
Dont we generally want the ingress to specify policy because that is w= here the OAM initiated?
=A0
Thanks,
Vishwas

On 2/10/10 6:17 PM, "Greg Mirsky" <gregimirsky@gmail.com> wrote:
Dear Nitin,
the LSP Ping might not be the only option but I believe= that there must be a Control Plane mechanism to direct return path of BFD = session (egress to ingress) of unidirectional LSP onto specified path (IP r= outed, LSP or else). There certainly could be local policy that will select= such return path but that does not preclude from driving selection from he= adend or NMS. Would LSP Ping be the only such mechanism? Considering work o= n MPLS-TP OAM I'd expect to see appropriate extensions being proposed f= or RSVP-TE some time soon. (There's already proposal to bootstrap BFD s= ession via RSVP-TE)

Regards,
Greg

On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur= <nitinb@juniper.net> wrote= :
Hi Mach,

=A0 =A0Please see inline below for comments.

&g= t; =A0 =A0 =A0 =A0There are two issues that our draft tries to resolve:
> =A0 =A0 =A0 1. Current LSP Ping mechanisms are lack of the capability = of specifying the return path
> =A0 =A0 =A0 =A0 =A0of an echo reply, = hence some time it may bring difficuties in faults localization.

=A0= =A0 =A0 =A0NB> This is only a problem for uni-directional LSPs. Also, t= he problem only exists
if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path
is DOWN, then lsp traceroute should help in fault localizati= on. See my comments below for
bi-directional LSPs.


> =A0 = =A0 =A0 2. A bidirectional path checking needs at least two LSP pings(ineff= icient), and sometime
> =A0 =A0 =A0difficut even fail to check the reverse direction of a bidi= rectional path.

=A0 =A0 =A0 =A0NB> You don't need 2 LSP-Pings= . For bidirectional co-routed LSPs, the egress SHOULD
=A0 =A0 =A0send th= e packet over the LSP itself.

=A0 =A0 =A0 =A0For bidirectional associated LSP, the egress again SHOUL= D send the packet over the
=A0 =A0 =A0associated LSP itself. See Section= 3.1 of draft-nitinb-mpls-tp-lsp-ping-extensions-00.
=A0 =A0 =A0Even if = the specifications in the draft above are not used, I presume there will *s= ome*
=A0 =A0 =A0way that one will specify the LSP "association". One c= ould use that way to ensure that
=A0 =A0 =A0lsp-ping responses always us= e that association. So additional protocol machinery is not
=A0 =A0 =A0n= eeded.

=A0 =A0 =A0 =A0For uni-directional LSPs, yes you will need 2 lsp-pings. But= the LSP is uni-directional.....
=A0 =A0 =A0so you are testing only the = forward direction.....
=A0 =A0 =A0there is no concept of reverse directi= on for uni-directional LSPs.


Other comments
--------------
The draft talks about specifyin= g ways in which ingress could specify how the
egress should respond. I f= ail to see how operators will use this *ability* in
the field. How does = the operator know which LSP should be used for return-path?
If the operator knows this via config, then the same config could be added = at
LSP egress as well.

If the operator is just going to loop thro= ugh (in return-path tlv) all the egress
initated LSPs hoping for at leas= t 1 successful response, then the scheme is broken.
One should use BFD (or some other mechanism) to ensure that both ingress in= itiated
and egress initiated (uni-directional) LSPs are UP. If a LSP is = UP, then the egress
can respond back via any UP LSP and the echo respons= e will reach the ingress...since the
LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP),
then I guess you could add a code-point that says "= reply via lsp" or something like that.

From a practical operato= r persecptive, I need to understand more on how someone would
use the feature/flexibility that you are proposing.

Thanks
Nitin<= br>_______________________________________________
mpls mailing list
= mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls


_______________________________________________
mpls mailing lis= t
mpls@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mpls

--000e0cd61e643bda16047f4d8254-- From nitinb@juniper.net Wed Feb 10 23:41:59 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 273133A7352; Wed, 10 Feb 2010 23:41:59 -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 Ke7aGBsHxYJL; Wed, 10 Feb 2010 23:41:58 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id A283C3A7166; Wed, 10 Feb 2010 23:41:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKS3O1CEubz7DvRgb742BCDM4UrbpumGgO@postini.com; Wed, 10 Feb 2010 23:43:11 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; Wed, 10 Feb 2010 23:43:04 -0800 From: Nitin Bahadur To: Vishwas Manral Date: Wed, 10 Feb 2010 23:43:01 -0800 Thread-Topic: [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acqq5f67nnW0APJjRpqdbr2EcL8LDQAB9dmH Message-ID: In-Reply-To: <77ead0ec1002102246v28f971a7p812e62e3934e2f57@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-tp@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comments for 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, 11 Feb 2010 07:41:59 -0000 There is a subtle difference. OAM is initiated in the direction of the LSP.= ..which is setup by the ingress. OAM response is sent by the egress in the reverse direction....so the polic= y should be on the egress. Deploying ingress based policy can be a nightmare. Suppose you have a LSP (= called lsp-1) from San Francisco to New York. And suppose you have a LSP (called lsp-2) from NY to SF. You could (in the= ory) instruct in the OAM msg that NY should use lsp-2 for reverse path. Now if the operator in NY wants to rename lsp-2= to lsp-from-ny-to-sf, then the operator has to make a change even in the router in San Francisco. Isn=92t = this a deployment hassle? You can say that NMS will take care of it....but even the NMS has to be programmed with this dep= endency.....maintenance has to be scheduled In both NY and SF. Instead if the policy was only in NY (say =96 for all OAMs coming on any LS= P from SF, reply using lsp-2), then the operator could easily change the lsp name and the policy, without scheduling potential down-time/= maintenance time in SF. If the operator wanted to bring down the LSP in NY, then he could do that and get rid of the policy in NY..= ..instead of having to go to SF and change the policy there. Again, above applies only to uni-directional LSPs. Nitin On 2/10/10 10:46 PM, "Vishwas Manral" wrote: Hi Nitin, For regular uni-directional LSPs, my main question is what is the operato= r going to gain by specifying the return path policy on the ingress (via signaling or NMS). This policy shoul= d be on the egress (rather than ingress). For uni-directional LSPs if you put the policy on the ingress, then you are adding state (on th= e ingress) regarding which LSPs exist on the egress. Dont we generally want the ingress to specify policy because that is where = the OAM initiated? Thanks, Vishwas On 2/10/10 6:17 PM, "Greg Mirsky" wrote: Dear Nitin, the LSP Ping might not be the only option but I believe that there must be = a Control Plane mechanism to direct return path of BFD session (egress to i= ngress) of unidirectional LSP onto specified path (IP routed, LSP or else).= There certainly could be local policy that will select such return path bu= t that does not preclude from driving selection from headend or NMS. Would = LSP Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd ex= pect to see appropriate extensions being proposed for RSVP-TE some time soo= n. (There's already proposal to bootstrap BFD session via RSVP-TE) Regards, Greg On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur wrote: Hi Mach, Please see inline below for comments. > There are two issues that our draft tries to resolve: > 1. Current LSP Ping mechanisms are lack of the capability of specif= ying the return path > of an echo reply, hence some time it may bring difficuties in fa= ults localization. NB> This is only a problem for uni-directional LSPs. Also, the probl= em only exists if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path is DOWN, then lsp traceroute should help in fault localization. See my comm= ents below for bi-directional LSPs. > 2. A bidirectional path checking needs at least two LSP pings(ineff= icient), and sometime > difficut even fail to check the reverse direction of a bidirectional= path. NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, th= e egress SHOULD send the packet over the LSP itself. For bidirectional associated LSP, the egress again SHOULD send the p= acket over the associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-lsp-pin= g-extensions-00. Even if the specifications in the draft above are not used, I presume = there will *some* way that one will specify the LSP "association". One could use that wa= y to ensure that lsp-ping responses always use that association. So additional protocol= machinery is not needed. For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP= is uni-directional..... so you are testing only the forward direction..... there is no concept of reverse direction for uni-directional LSPs. Other comments -------------- The draft talks about specifying ways in which ingress could specify how th= e egress should respond. I fail to see how operators will use this *ability* = in the field. How does the operator know which LSP should be used for return-p= ath? If the operator knows this via config, then the same config could be added = at LSP egress as well. If the operator is just going to loop through (in return-path tlv) all the = egress initated LSPs hoping for at least 1 successful response, then the scheme is= broken. One should use BFD (or some other mechanism) to ensure that both ingress in= itiated and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress can respond back via any UP LSP and the echo response will reach the ingres= s...since the LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP), then I guess you could add a code-point that says "reply via lsp" or someth= ing like that. >From a practical operator persecptive, I need to understand more on how som= eone would use the feature/flexibility that you are proposing. Thanks Nitin _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mach@huawei.com Thu Feb 11 01:31: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 CE9B028C10E; Thu, 11 Feb 2010 01:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_63=0.6, 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 5JmcPAhdM6GB; Thu, 11 Feb 2010 01:31:27 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 6F6253A7689; Thu, 11 Feb 2010 01:31:27 -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 <0KXO00BC47U6O8@szxga02-in.huawei.com>; Thu, 11 Feb 2010 17:32: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 <0KXO00DQI7U582@szxga02-in.huawei.com>; Thu, 11 Feb 2010 17:32:30 +0800 (CST) Date: Thu, 11 Feb 2010 17:32:30 +0800 From: Mach Chen In-reply-to: <05542EC42316164383B5180707A489EE1D0AC2F6AA@EMBX02-HQ.jnpr.net> To: Nitin Bahadur , 'George Swallow' Message-id: <69DE8D9579C64DAC82CD3431C588E76A@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=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <05542EC42316164383B5180707A489EE1D0AC2F6AA@EMBX02-HQ.jnpr.net> Cc: mpls@ietf.org, So Ning , Simon.A.DeLord@team.telstra.com, mpls-tp@ietf.org Subject: Re: [mpls] Comments for 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, 11 Feb 2010 09:31:28 -0000 Hi Nitin Thanks for your comments! Please see my reply inline... -------------------------------------------------- From: "Nitin Bahadur" Sent: Thursday, February 11, 2010 4:02 AM To: "'MachChen 55527'" ; "'George Swallow'" Cc: ; Subject: RE: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > Hi Mach, > > Please see inline below for comments. > >> There are two issues that our draft tries to resolve: >> 1. Current LSP Ping mechanisms are lack of the capability of specifying >> the return path >> of an echo reply, hence some time it may bring difficuties in faults >> localization. > > NB> This is only a problem for uni-directional LSPs. Also, the problem > only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. There are several conditions that may lead to problems, not just only the reverse IP path is down. The return path of the echo reply could be either IP or LSP path that depends on the local routing policy. And the LSP traceroute may not help in fault localization sometimes, take a simple topology(A--B--C--D) for example, there is an LSP from A to D and maybe an LSP from D to A, no matter what the failure is at the hop between C and D or at the reverse path or at D, there will no different in the trace result(A..B..C). That means the operator can not yet determine whether the forward LSP is with failure. > See my comments below for bi-directional LSPs. > >> 2. A bidirectional path checking needs at least two LSP >> pings(inefficient), and sometime >> difficut even fail to check the reverse direction of a bidirectional >> path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, the > egress SHOULD > send the packet over the LSP itself. Since the echo reply will not carry the FEC stack information of the reverse direction, one LSP-Ping could only complete cv checking of the forward direction of the LSP. In order to do cv checking of the reverse direction, another LSP-Ping is necessary. With this RPS(Return Path Specified) extension, it's really that only one LSP-Ping is enough. And for inter-AS/inter-domain LSP, the operators of one side may have no right to log on to the remote side to perfom any actions, hence make it impossiable to check the reserve direction without the help of the operators of the other domain/AS. With this RPS extension, a single LSP-Ping could finish both directions checking. BTW, for co-routed bidirectional LSP, even if the egress will send packets over the LSP itself, but when failures occur, the operators still need to further locate which direction is failed. So, changing the return path is an alternate method. > > For bidirectional associated LSP, the egress again SHOULD send the packet > over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presume > there will *some* > way that one will specify the LSP "association". One could use that > way to ensure that > lsp-ping responses always use that association. So additional > protocol machinery is not > needed. For associated LSP, it has the same issues/requirements as co-routed LSP as said above. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the LSP is > uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. For the operators, they use unidirectional LSPs to provide bidirectional service, most of the time, they just see there is a bidirectional path. If there is light/easier way to perform bidirectional path checking within a single operation, I think it should be good. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability* > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be added > at > LSP egress as well. The operators could based on their experence and the on-site conditions to choose the specific LSP for return-path. > > If the operator is just going to loop through (in return-path tlv) all the > egress > initated LSPs hoping for at least 1 successful response, then the scheme > is broken. Loop through all the egress initated LSPs is the worsest situation, and for most of the time, there will not be too many LSPs. For me this is reasonable. Why do you think the scheme is broken? > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress IMO, it's not possible to provision BFD session for every LSP and route, it's not scale. And if it is only for selection a proper return path to send the echo reply, IMHO, provision too many BFD sessions is not cost-effective. > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. Force the echo reply to be sent along pure lsp path sounds reasonable, it could be an option. BTW, from my understanding, normally, the echo reply is always trying to follow lsp(it have higher priority the IP path). So, in the RPS draft, we define a mechanism to force the echo reply follow pure IP path(at least the egress uses IP path), hence to verify whether the LSP path is OK. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. In short, with our RPS extensions, it has the following benifits: 1. Enable to change/exclude the return paths freely, improve the robustness of LSP Ping; 2. Return path could be force to along IP-only path; 3. Improve the efficient for bidirectional path checking; 4. Enable to check a bidirectional inter-domain/AS path; 5. Could be used for enhancing "BFD for MPLS" bootstrap signaling: enable to provision a single(not two) BFD session for a bidirectional LSP. More specific information could be found at: http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00. Any comments and suggestions are welcomed! Best regards, Mach > > Thanks > Nitin= From gregimirsky@gmail.com Thu Feb 11 10:19:11 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 1DB1828C0FC; Thu, 11 Feb 2010 10:19:11 -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 E3Mi0mv9xwmK; Thu, 11 Feb 2010 10:19:10 -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 C584B3A7741; Thu, 11 Feb 2010 10:19:09 -0800 (PST) Received: by bwz19 with SMTP id 19so710997bwz.28 for ; Thu, 11 Feb 2010 10:20:19 -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=u5CqeddgQyTHvqzn7Weu73qCQha+PDh9MKc3E6bA27A=; b=EDyMhldSDT9Uqm1hAnakebMIRY5s4AsZrM4nO56HzZq9qXubGrJg7BMn+pIzdTO75K /DjjD145w11DZ9FLhH9tV/w9oimeEYZJoLthieNAeOZFB6yaHyAWb4nbQKEQo+TaI4EH 3P9gYx/JUuKrJsLY+a33LWrTEk+p63VlvYPFA= 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=WUcNuhkEwyeGYOhnP938dLLqQdO7FzMbjP7LIyxq8gtjt9gaC3aRaD9zpD60kz84Ok t3/ltBRkXcWlg1+6E4NGLgAlN4ushXQo5dUhGMa2WsfR3Ak7pFI4FlUXF70+ZWBFoc/o 6lPbSnCC3YfrGfyHg22RTBWfit48o3aSDEtXM= MIME-Version: 1.0 Received: by 10.204.33.206 with SMTP id i14mr155197bkd.52.1265912419801; Thu, 11 Feb 2010 10:20:19 -0800 (PST) Date: Thu, 11 Feb 2010 10:20:17 -0800 Message-ID: <787be2781002111020i5decf119i186beae1ec7e2f0@mail.gmail.com> From: Greg Mirsky To: swallow@cisco.com, annamaria.fulignoli@ericsson.com, martin.vigoureux@alcatel-lucent.com Content-Type: multipart/alternative; boundary=0003255579ea195a96047f57340c Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [mpls] Question on MPLS Fault Mangement OAM 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, 11 Feb 2010 18:19:11 -0000 --0003255579ea195a96047f57340c Content-Type: text/plain; charset=ISO-8859-1 Dear Editors, Authors and All, as this document defines MPLS Fault Management Channel and the format of MPLS FM Message I'm looking at how FM channel can be used. Could it be used by MPLS LSP and by unidirectional MPLS-TP LSP? If an FM channel between LERs/MEPs is associated with a unidirectional LSP or multiple such LSPs that are terminated on these LERs, then LSP TLV, as outlined in Definition of ACH TLV Structure (note - the document is listed in Normative References section but is not actually referenced in the document), can be used to demultiplex FM messages. Further, if an FM channel may be associated with arbitrary mix of LSPs and PWs then LSP TLV and PW TLV must be used to demultiplex FM messages.If these are valid scenarios, then description of how LSP and PW TLVs used can be added in sections 5.1 and 5.3. Regards, Greg --0003255579ea195a96047f57340c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Editors, Authors and All,
as this document defines MPLS Fault Manag= ement Channel and the format of MPLS FM Message I'm looking at how FM c= hannel can be used. Could it be used by MPLS LSP and by unidirectional MPLS= -TP LSP? If an FM channel between LERs/MEPs is associated with a unidirecti= onal LSP or multiple such LSPs that are terminated on these LERs, then LSP = TLV, as outlined in Definition of ACH TLV Structure (note - the document is= listed in Normative References section but is not actually referenced in t= he document), can be used to demultiplex FM messages. Further, if an FM cha= nnel may be associated with arbitrary mix of LSPs and PWs then LSP TLV and = PW TLV must be used to demultiplex FM messages.If these are valid scenarios= , then description of how LSP and PW TLVs used can be added in sections 5.1= and 5.3.

Regards,
Greg
--0003255579ea195a96047f57340c-- From gregimirsky@gmail.com Thu Feb 11 14:40: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 4CCAF3A682A; Thu, 11 Feb 2010 14:40: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=[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 err4ysQBMh4k; Thu, 11 Feb 2010 14:40:47 -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 08FA33A726B; Thu, 11 Feb 2010 14:40:46 -0800 (PST) Received: by bwz19 with SMTP id 19so992360bwz.28 for ; Thu, 11 Feb 2010 14:41:59 -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=xwosXmOSsVY3VRTI2pL+UpXEaCMWgOWjCoMWQXWM9NU=; b=lyMCechm5MbJV5bAeo6uhv5sbfaXffqePXOGK7rMK9pOBBjEQSKV6PPhUuachbBeOb Cz4VgeWq9zF+ifs+6O0dF+9WUvLLNiTrU6uR+zqKgd/GtDahUo1AXlf4yQ6W0eJQmEmm jWJmwhwwnMF1jqgi+ciisv4AuyPm+jbSpUDY8= 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=xVvgKJf7wCbJWu4S5Gm139Ft2Cbl8mHf2HjhkLNk7tr2txL/yRZKhz4w189WSDPbUQ NwWGnRNm1P9FUh6Wd8Ng0pXxacIFZ8j0cFc3xOVcrkEZcPipBIKvtfEQ6hrj0oUU3jae 7QHOO4NcX+8prmMQtpGSL3DVzZ+zu3al7yO0A= MIME-Version: 1.0 Received: by 10.204.20.76 with SMTP id e12mr338280bkb.126.1265928118190; Thu, 11 Feb 2010 14:41:58 -0800 (PST) In-Reply-To: References: <787be2781002101817i29c97f44o2ffd3a080be8f817@mail.gmail.com> Date: Thu, 11 Feb 2010 14:41:58 -0800 Message-ID: <787be2781002111441u2d4ed86bic1af17ca1caf18d@mail.gmail.com> From: Greg Mirsky To: Nitin Bahadur Content-Type: multipart/alternative; boundary=0003255592b6cbc285047f5adb31 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] Comments for 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, 11 Feb 2010 22:40:49 -0000 --0003255592b6cbc285047f5adb31 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Nitin, I agree on your perspective regarding co-routed bi-directional LSP. As it was intentionally built with fate sharing between ingress/egress directions I don't see why operator will need to specify return path other than opposite direction of LSP under examination. Troubleshooting bi-directional associated connection might have different requirements. (Wish we have someone from operators community to speak here)= . As directions, in general case, are diversly routed, so I see value in specifying return path. It is logical to name opposite direction of associated connection as default return path but explicit, one-time overwrite seems to have value. And now we get to unidirectional LSP. Since such construct exists and is listed in MPLS-TP I consider tools to troubleshoot them be of value. If one applies bi-directional p2p BFD (aka "classical") to unidirectional LSP then the question of return path comes up sooner than later. What might be interesting to explore, I think, is whether BFD Multipoint model can be applied to unidirectional LSP (unidirectional LSP as special case of unidirectional p2mp). Regards, Greg On Wed, Feb 10, 2010 at 10:11 PM, Nitin Bahadur wrote: > Hi Greg, > > It doesn=92t matter what the OAM protocol is...it could be LSP-Ping or > something else....and I agree with you on that. > > I also agree that there should be a control plane mechanism. Currently > the drafts/RFC specify 2 mechanisms that apply to > MPLS-TP LSPs =96 Reply via IP/UDP and Reply via control channel (ACH). > > In context of MPLS-TP, we are talking mainly about bidirectional > co-routed and associated LSPs. And the above 2 techniques apply > well to both of them. In fact for co-routed and associated LSPs, we shoul= d > NOT be specifying a return path and instead ensure/validate that > the echo response is received on the correct reverse path (if ACH is used= ). > Not explicitly specifying the path and validation will ensure that both > ingress and egress have the same idea of the forward and reverse path. In > short, I do not see the use of this extension for MPLS-TP LSPs. > > For regular uni-directional LSPs, my main question is what is the > operator going to gain by specifying the > return path policy on the ingress (via signaling or NMS). This policy > should be on the egress (rather than ingress). For uni-directional > LSPs if you put the policy on the ingress, then you are adding state (on > the ingress) regarding which LSPs exist on the egress. > > I might be missing the real intention and am definitely open to > understanding the problem statement in more detail. > > Thanks > Nitin > > > On 2/10/10 6:17 PM, "Greg Mirsky" wrote: > > Dear Nitin, > the LSP Ping might not be the only option but I believe that there must b= e > a Control Plane mechanism to direct return path of BFD session (egress to > ingress) of unidirectional LSP onto specified path (IP routed, LSP or els= e). > There certainly could be local policy that will select such return path b= ut > that does not preclude from driving selection from headend or NMS. Would = LSP > Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expe= ct > to see appropriate extensions being proposed for RSVP-TE some time soon. > (There's already proposal to bootstrap BFD session via RSVP-TE) > > Regards, > Greg > > On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur > wrote: > Hi Mach, > > Please see inline below for comments. > > > There are two issues that our draft tries to resolve: > > 1. Current LSP Ping mechanisms are lack of the capability of > specifying the return path > > of an echo reply, hence some time it may bring difficuties in > faults localization. > > NB> This is only a problem for uni-directional LSPs. Also, the > problem only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. See my > comments below for > bi-directional LSPs. > > > > 2. A bidirectional path checking needs at least two LSP > pings(inefficient), and sometime > > difficut even fail to check the reverse direction of a bidirection= al > path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, > the egress SHOULD > send the packet over the LSP itself. > > For bidirectional associated LSP, the egress again SHOULD send the > packet over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presum= e > there will *some* > way that one will specify the LSP "association". One could use that > way to ensure that > lsp-ping responses always use that association. So additional protoc= ol > machinery is not > needed. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the L= SP > is uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability= * > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be adde= d > at > LSP egress as well. > > If the operator is just going to loop through (in return-path tlv) all th= e > egress > initated LSPs hoping for at least 1 successful response, then the scheme = is > broken. > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. > > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --0003255592b6cbc285047f5adb31 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Nitin,
I agree on your perspective regarding co-routed bi-direction= al LSP. As it was intentionally built with fate sharing between ingress/egr= ess directions I don't see why operator will need to specify return pat= h other than opposite direction of LSP under examination.
Troubleshooting bi-directional associated connection might have different r= equirements. (Wish we have someone from operators community to speak here).= As directions, in general case, are diversly routed, so I see value in spe= cifying return path. It is logical to name opposite direction of associated= connection as default return path but explicit, one-time overwrite seems t= o have value.
And now we get to unidirectional LSP. Since such construct exists and is li= sted in MPLS-TP I consider tools to troubleshoot them be of value. If one a= pplies bi-directional p2p BFD (aka "classical") to unidirectional= LSP then the question of return path comes up sooner than later. What migh= t be interesting to explore, I think, is whether BFD Multipoint model can b= e applied to unidirectional LSP (unidirectional LSP as special case of unid= irectional p2mp).

Regards,
Greg

On Wed, Feb 10, 2010= at 10:11 PM, Nitin Bahadur <nitinb@juniper.net> wrote:
Hi Greg,

=A0 It doesn=92t matter what the OAM protocol is...it could be LSP-Ping or= something else....and I agree with you on that.

=A0 I also agree that there should be a control plane mechanism. Currently= the drafts/RFC specify 2 mechanisms that apply to
MPLS-TP LSPs =96 Reply via IP/UDP and Reply via control channel (ACH).

=A0 In context of MPLS-TP, we are talking mainly about bidirectional co-ro= uted and associated LSPs. And the above 2 techniques apply
well to both of them. In fact for co-routed and associated LSPs, we should = NOT be specifying a return path and instead ensure/validate that
the echo response is received on the correct reverse path (if ACH is used).= Not explicitly specifying the path and validation will ensure that both ingress and egress have the same idea of the forward and reverse path. In s= hort, I do not see the use of this extension for MPLS-TP LSPs.

=A0 For regular uni-directional LSPs, my main question is what is the oper= ator going to gain by specifying the
return path policy on the ingress (via signaling or NMS). This policy shoul= d be on the egress (rather than ingress). =A0For uni-directional
LSPs if you put the policy on the ingress, then you are adding state (on th= e ingress) regarding which LSPs exist on the egress.

=A0 I might be missing the real intention and am definitely open to unders= tanding the problem statement in more detail.

Thanks
Nitin


On 2/10/10 6:17 PM, "Greg Mirsky" <gregimirsky@gmail.com> wrote:

Dear Nitin,
the LSP Ping might not be the only option but I believe that there must be = a Control Plane mechanism to direct return path of BFD session (egress to i= ngress) of unidirectional LSP onto specified path (IP routed, LSP or else).= There certainly could be local policy that will select such return path bu= t that does not preclude from driving selection from headend or NMS. Would = LSP Ping be the only such mechanism? Considering work on MPLS-TP OAM I'= d expect to see appropriate extensions being proposed for RSVP-TE some time= soon. (There's already proposal to bootstrap BFD session via RSVP-TE)<= br>
Regards,
Greg

On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur <nitinb@juniper.net> wrote:
Hi Mach,

=A0 =A0Please see inline below for comments.

> =A0 =A0 =A0 =A0There are two issues that our draft tries to resolve: > =A0 =A0 =A0 1. Current LSP Ping mechanisms are lack of the capability = of specifying the return path
> =A0 =A0 =A0 =A0 =A0of an echo reply, hence some time it may bring diff= icuties in faults localization.

=A0 =A0 =A0 =A0NB> This is only a problem for uni-directional LSPs. Als= o, the problem only exists
if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path
is DOWN, then lsp traceroute should help in fault localization. See my comm= ents below for
bi-directional LSPs.


> =A0 =A0 =A0 2. A bidirectional path checking needs at least two LSP pi= ngs(inefficient), and sometime
> =A0 =A0 =A0difficut even fail to check the reverse direction of a bidi= rectional path.

=A0 =A0 =A0 =A0NB> You don't need 2 LSP-Pings. For bidirectional co= -routed LSPs, the egress SHOULD
=A0 =A0 =A0send the packet over the LSP itself.

=A0 =A0 =A0 =A0For bidirectional associated LSP, the egress again SHOULD s= end the packet over the
=A0 =A0 =A0associated LSP itself. See Section 3.1 of draft-nitinb-mpls-tp-= lsp-ping-extensions-00.
=A0 =A0 =A0Even if the specifications in the draft above are not used, I p= resume there will *some*
=A0 =A0 =A0way that one will specify the LSP "association". One = could use that way to ensure that
=A0 =A0 =A0lsp-ping responses always use that association. So additional p= rotocol machinery is not
=A0 =A0 =A0needed.

=A0 =A0 =A0 =A0For uni-directional LSPs, yes you will need 2 lsp-pings. Bu= t the LSP is uni-directional.....
=A0 =A0 =A0so you are testing only the forward direction.....
=A0 =A0 =A0there is no concept of reverse direction for uni-directional LS= Ps.


Other comments
--------------
The draft talks about specifying ways in which ingress could specify how th= e
egress should respond. I fail to see how operators will use this *ability* = in
the field. How does the operator know which LSP should be used for return-p= ath?
If the operator knows this via config, then the same config could be added = at
LSP egress as well.

If the operator is just going to loop through (in return-path tlv) all the = egress
initated LSPs hoping for at least 1 successful response, then the scheme is= broken.
One should use BFD (or some other mechanism) to ensure that both ingress in= itiated
and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress
can respond back via any UP LSP and the echo response will reach the ingres= s...since the
LSP is UP. If you want to ensure that the echo response comes back via a LS= P (and not IP),
then I guess you could add a code-point that says "reply via lsp"= or something like that.

>From a practical operator persecptive, I need to understand more on how som= eone would
use the feature/flexibility that you are proposing.

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



--0003255592b6cbc285047f5adb31-- From mach@huawei.com Thu Feb 11 18:40: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 DC1633A74ED; Thu, 11 Feb 2010 18:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_93=0.6, 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 qchbABgv0wLM; Thu, 11 Feb 2010 18:40:26 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 77DD33A67D4; Thu, 11 Feb 2010 18:40:26 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXP00I8FJHH9J@szxga01-in.huawei.com>; Fri, 12 Feb 2010 10:41:41 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXP00MR9JHGSJ@szxga01-in.huawei.com>; Fri, 12 Feb 2010 10:41:41 +0800 (CST) Date: Fri, 12 Feb 2010 10:41:38 +0800 From: Mach Chen In-reply-to: To: Nitin Bahadur , 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=windows-1252; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: Cc: mpls@ietf.org, So Ning , mpls-tp@ietf.org Subject: Re: [mpls] Comments for 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: Fri, 12 Feb 2010 02:40:28 -0000 Hi Nitin, -------------------------------------------------- From: "Nitin Bahadur" Sent: Thursday, February 11, 2010 2:11 PM To: "Greg Mirsky" Cc: "MachChen 55527" ; "George Swallow" ; ; Subject: Re: [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > In context of MPLS-TP, we are talking mainly about bidirectional > co-routed and associated LSPs. And the above 2 techniques apply > well to both of them. In fact for co-routed and associated LSPs, we should > NOT be specifying a return path and instead ensure/validate that > the echo response is received on the correct reverse path (if ACH is > used). Not explicitly specifying the path and validation will ensure that > both > ingress and egress have the same idea of the forward and reverse path. In > short, I do not see the use of this extension for MPLS-TP LSPs. If the LSP-Ping message could be only sent along the bidirectional LSP, when failures occur, it's hard to differentiate which direction is failed(especially for associated bidirectional LSP). > > For regular uni-directional LSPs, my main question is what is the > operator going to gain by specifying the > return path policy on the ingress (via signaling or NMS). This policy > should be on the egress (rather than ingress). For uni-directional > LSPs if you put the policy on the ingress, then you are adding state (on > the ingress) regarding which LSPs exist on the egress. > > I might be missing the real intention and am definitely open to > understanding the problem statement in more detail. The orginal intention of specifying return path is for enhancing LSP-Ping in fault localization. Normally, LSP-Ping echo reply follows a relative stable path(default return path that follows the egress routing), as said in my previous email, failures at forward LSP, egress, reverse path will lead to LSP-Ping failing, and sometime, from the result of ping or trace, there is no difference, hence it's hard to differiate where is the failure point. By specifying an alternate return path of the echo reply, it could help a lot to judge whether the "default" return path is OK or not, hence to determine or eliminate the suspect of the return path. In addition, when having this return path specified capability, it could help to check a bidirectional LSP or a pair of unidirectional LSPs within a single operation(the echo reply is extended to check the reverse lsp by carrying the FEC information of that LSP), hence to reduce the workload of the operators. This is particular useful in inter-domain/AS scenarios where the operators from one side of the LSP are impossible to log on the remote side to operate. Best regards, Mach > > Thanks > Nitin > > > On 2/10/10 6:17 PM, "Greg Mirsky" wrote: > > Dear Nitin, > the LSP Ping might not be the only option but I believe that there must be > a Control Plane mechanism to direct return path of BFD session (egress to > ingress) of unidirectional LSP onto specified path (IP routed, LSP or > else). There certainly could be local policy that will select such return > path but that does not preclude from driving selection from headend or > NMS. Would LSP Ping be the only such mechanism? Considering work on > MPLS-TP OAM I'd expect to see appropriate extensions being proposed for > RSVP-TE some time soon. (There's already proposal to bootstrap BFD session > via RSVP-TE) > > Regards, > Greg > > On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur > wrote: > Hi Mach, > > Please see inline below for comments. > >> There are two issues that our draft tries to resolve: >> 1. Current LSP Ping mechanisms are lack of the capability of >> specifying the return path >> of an echo reply, hence some time it may bring difficuties in >> faults localization. > > NB> This is only a problem for uni-directional LSPs. Also, the > problem only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. See my > comments below for > bi-directional LSPs. > > >> 2. A bidirectional path checking needs at least two LSP >> pings(inefficient), and sometime >> difficut even fail to check the reverse direction of a bidirectional >> path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, > the egress SHOULD > send the packet over the LSP itself. > > For bidirectional associated LSP, the egress again SHOULD send the > packet over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presume > there will *some* > way that one will specify the LSP "association". One could use that > way to ensure that > lsp-ping responses always use that association. So additional > protocol machinery is not > needed. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the > LSP is uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability* > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be added > at > LSP egress as well. > > If the operator is just going to loop through (in return-path tlv) all the > egress > initated LSPs hoping for at least 1 successful response, then the scheme > is broken. > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. > > Thanks > Nitin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From nitinb@juniper.net Fri Feb 12 00:30: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 998823A68E9; Fri, 12 Feb 2010 00:30: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=[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 Tm8ZZF3cRqqH; Fri, 12 Feb 2010 00:30:24 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 1005D28C170; Fri, 12 Feb 2010 00:30:17 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS3UR5LHxJQFOUBkRtAb7V6Wn9t/Q9bFO@postini.com; Fri, 12 Feb 2010 00:31: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; Fri, 12 Feb 2010 00:30:01 -0800 From: Nitin Bahadur To: Mach Chen , 'George Swallow' Date: Fri, 12 Feb 2010 00:29:58 -0800 Thread-Topic: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acqq/Srgbjaz0wsER+GvU0PUyZEUyAAwGS7W Message-ID: In-Reply-To: <69DE8D9579C64DAC82CD3431C588E76A@m55527c> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Ning , "mpls-tp@ietf.org" , So, "Simon.A.DeLord@team.telstra.com" Subject: Re: [mpls] Comments for 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: Fri, 12 Feb 2010 08:30:25 -0000 Hi Mach, I'm splitting my replies into multiple emails to address topics separately. >>> There are two issues that our draft tries to resolve: >>> 1. Current LSP Ping mechanisms are lack of the capability of specifying >>> the return path >>> of an echo reply, hence some time it may bring difficuties in faults >>> localization. >>=20 >> NB> This is only a problem for uni-directional LSPs. Also, the problem >> only exists >> if the LSP forward path is UP and the reverse IP path is down. If the >> forward LSP path >> is DOWN, then lsp traceroute should help in fault localization. >=20 > There are several conditions that may lead to problems, not just only the > reverse IP path is down. The return path of the echo reply could be eithe= r > IP or LSP path that depends on the local routing policy. >=20 > And the LSP traceroute may not help in fault localization sometimes, take= a > simple topology(A--B--C--D) for example, there is an LSP from A to D and > maybe an LSP from D to A, no matter what the failure is at the hop betwee= n C > and D or at the reverse path or at D, there will no different in the trac= e > result(A..B..C). That means the operator can not yet determine whether th= e > forward LSP is with failure. Agreed that with current mechanisms you cannot figure out if a failure is with the forward path or reverse path. That's a good problem statement to have. I don't agree with the solution presented. The solution presented makes the ingress node have detailed knowledge of FECs originating at the egress and creates an implicit binding betweens multiple return paths. Instead maybe you can just have a new return mode called "Reply via alternate path" in which the egress will rely using the non-default path. If even the non-default path is broken, then you have a problem. I'm not convinced if that problem is worth addressing.... There might be other ways to address the problem statement...my main intent is to reduce the coupling between the ingress and egress and reduce configuration overhead. I see that some operators have been cc'ed on this email. So it would be goo= d to get their input on how much complex configuration they want to do on their mpls boxes to effectively use oam. Thanks Nitin From nitinb@juniper.net Fri Feb 12 01:14: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 441813A77DE; Fri, 12 Feb 2010 01:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_63=0.6, 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 4eVx7+SKoF4N; Fri, 12 Feb 2010 01:14:52 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id B46E93A7664; Fri, 12 Feb 2010 01:14:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS3UcUeqt1dC5/ZW6E+LTmBpsZs4qgYdu@postini.com; Fri, 12 Feb 2010 01:16:10 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 12 Feb 2010 01:13:56 -0800 From: Nitin Bahadur To: Mach Chen , 'George Swallow' Date: Fri, 12 Feb 2010 01:13:54 -0800 Thread-Topic: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acqq/Srgbjaz0wsER+GvU0PUyZEUyAAxofq4 Message-ID: In-Reply-To: <69DE8D9579C64DAC82CD3431C588E76A@m55527c> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Ning , "mpls-tp@ietf.org" , So, "Simon.A.DeLord@team.telstra.com" Subject: Re: [mpls] Comments for 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: Fri, 12 Feb 2010 09:14:54 -0000 Hi Mach, > Since the echo reply will not carry the FEC stack information of the reve= rse > direction, one LSP-Ping could only complete cv checking of the forward > direction of the LSP. I'm not an RSVP expert, but I believe, for co-routed bi-directional LSPs, the FEC stack for the reverse direction will be the same. So CV checking on the reverse path involves 2 things: 1) Ensuring that received echo response is for the echo request sent 2) Ensuring that echo response is received on the reverse path of the bi-directional LSP. For associated bi-directional LSPs, the ingress node already knows which egress LSP has been associated with the ingress LSP. So the ingress node needs to validate: 1) Received echo response is for the echo request sent 2) Echo response is received on the egress LSP. More details are not needed IMO. In echo request, we need the FEC stack to identify the LSP under test (to catch a case where an OAM packet arrives at an un-intended destination). Note that regular uni-directional LSPs use PHP and hence FEC determination cannot be based off a label (since there will be no label received on egress).=20 In echo response, if the packet is dropped, then the receiver (ingress) wil= l time out. If the packet is mis-routed, then the receiver (some random node) will drop it since it won't be expecting an echo response. In addition, RFC 4379 specifies, "The FEC Stack TLV from the echo request MAY be copied to the reply." This has huge implications. This means that fo= r bi-directional co-routed LSPs, one can copy the incoming FEC stack TLV (if one wants to) and for bi-directional associated LSPs, once can insert a new FEC stack TLV identifying the reverse path FEC. The ingress has information regarding the association, so it can perform any CV validations. > In order to do cv checking of the reverse direction, > another LSP-Ping is necessary. With this RPS(Return Path Specified) > extension, it's really that only one LSP-Ping is enough. See above. > And for=20 > inter-AS/inter-domain LSP, the operators of one side may have no right to > log on to the remote side to perfom any actions, hence make it impossiabl= e > to check the reserve direction without the help of the operators of the > other domain/AS. With this RPS extension, a single LSP-Ping could finish > both directions checking. See below=20 =20 > For the operators, they use unidirectional LSPs to provide bidirectional > service, most of the time, they just see there is a bidirectional path. I= f > there is light/easier way to perform bidirectional path checking within a > single operation, I think it should be good. Bi-directional associated LSPs will give the operators exactly that. They just need to add that association. >> Other comments >> -------------- >> The draft talks about specifying ways in which ingress could specify how >> the >> egress should respond. I fail to see how operators will use this *abilit= y* >> in >> the field. How does the operator know which LSP should be used for >> return-path? >> If the operator knows this via config, then the same config could be add= ed >> at >> LSP egress as well. >=20 > The operators could based on their experence and the on-site conditions t= o > choose the specific LSP for return-path. Experience and on-site conditions =3D> complicated NMS systems and more maintenance windows. OAM should be simple and stupid...otherwise it will no= t be deployable. =20 >> If the operator is just going to loop through (in return-path tlv) all t= he >> egress >> initated LSPs hoping for at least 1 successful response, then the scheme >> is broken. >=20 > Loop through all the egress initated LSPs is the worsest situation, and f= or > most of the time, there will not be too many LSPs. For me this is > reasonable. Why do you think the scheme is broken? It's broken because now the ingress needs to know about all the "egress initiated LSPs". It's too much coupling. As I said in my other email, all you need is an alternate way of sending the response. Multiple alternate ways will not provide you with too much benefit. The cost vs benefit equation doesn't favor multiple alternate paths. >> One should use BFD (or some other mechanism) to ensure that both ingress >> initiated >> and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then >> the egress >=20 > IMO, it's not possible to provision BFD session for every LSP and route, > it's not scale.=20 I happily disagree with that statement. I know more than 1 vendor that has simplified BFD provisioning for LSPs and routes. Scaling yes, every system will have scaling limits. Some boxes will do better than others. If you don't provision BFD for every LSP, then you won't know if a particular LSP is down and you might black-hole traffic. If you round-robin packets of 1 bfd session between multiple LSPs, then you are effectively (i= n forwarding plane) increasing the time interval between packets sent on a particular LSP....which is the same as multiple BFD sessions (without additional control plane state). Again, as I said, it's my opinion. > And if it is only for selection a proper return path to send > the echo reply, IMHO, provision too many BFD sessions is not cost-effecti= ve. > BTW, from my understanding, normally, the echo reply is always trying to > follow lsp(it have higher priority the IP path). That's your assumption...you can have a box that has different policies for different things. There is nothing in the echo rely that specifies that it must go over a LSP. > So, in the RPS draft, we > define a mechanism to force the echo reply follow pure IP path(at least t= he > egress uses IP path), hence to verify whether the LSP path is OK. I think you just need an alternate path....there is no guarantee that your IP path won't be the same as the LSP path...so it's no better than an alternate path. =20 > In short, with our RPS extensions, it has the following benifits: > 1. Enable to change/exclude the return paths freely, improve the robustne= ss > of LSP Ping; Hard to deploy IMO....need operators to comment. This looks more like a solution looking for a problem. > 2. Return path could be force to along IP-only path; Why not a good ol' L2 path...why IP? In MPLS-TP, there might be no IP forwarding. So IP-only path might not be useful for MPLS-TP. > 3. Improve the efficient for bidirectional path checking; Some benefit exists here. > 4. Enable to check a bidirectional inter-domain/AS path; Inter-domain lsp-ping still needs to be worked out. Regular uni-directional LSP lsp-ping is currently broken for many cases of inter-domain LSPs. I don't think we should half bake an inter-as solution as part of this draft. You are welcome to work on an inter-as solution. > 5. Could be used for enhancing "BFD for MPLS" bootstrap signaling: enable= to > provision a single(not two) BFD session for a bidirectional LSP. More > specific information could be found at: > http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00. That's a separate draft anyways. =20 Thanks Nitin From nitinb@juniper.net Fri Feb 12 01:23: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 818423A7243; Fri, 12 Feb 2010 01:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 fdhBpHIB15Mb; Fri, 12 Feb 2010 01:23:45 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 733503A7885; Fri, 12 Feb 2010 01:23:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS3UebFNckXlDH1UojbyKtK5j0jewdie/@postini.com; Fri, 12 Feb 2010 01:25:03 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; Fri, 12 Feb 2010 01:21:56 -0800 From: Nitin Bahadur To: Greg Mirsky Date: Fri, 12 Feb 2010 01:21:50 -0800 Thread-Topic: [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acqra2ybVFoateF8S1iKYDSXfwcsgAAWWHlH Message-ID: In-Reply-To: <787be2781002111441u2d4ed86bic1af17ca1caf18d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] Comments for 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: Fri, 12 Feb 2010 09:23:46 -0000 On 2/11/10 2:41 PM, "Greg Mirsky" wrote: Dear Nitin, I agree on your perspective regarding co-routed bi-directional LSP. As it w= as intentionally built with fate sharing between ingress/egress directions = I don't see why operator will need to specify return path other than opposi= te direction of LSP under examination. Troubleshooting bi-directional associated connection might have different r= equirements. (Wish we have someone from operators community to speak here). NB> I agree As directions, in general case, are diversly routed, so I see value in spe= cifying return path. It is logical to name opposite direction of associated= connection as default return path but explicit, one-time overwrite seems t= o have value. And now we get to unidirectional LSP. Since such construct exists and is li= sted in MPLS-TP I consider tools to troubleshoot them be of value. If one a= pplies bi-directional p2p BFD (aka "classical") to unidirectional LSP then = the question of return path comes up sooner than later. What might be inter= esting to explore, I think, is whether BFD Multipoint model can be applied = to unidirectional LSP (unidirectional LSP as special case of unidirectional= p2mp). NB> I think the BFD multipoint model can be broken down and represented as = a bfd p2p model. In BFD p2mp, leaf nodes do not necessarily need to send pa= ckets to the root (ingress) node. In BFD p2p, egress (leaf) node can advert= ise a very high tx value so that it doesn=92t necessarily need to send pack= ets that often to the ingress (root). NB> Return path is always an issue for p2p mpls bfd sessions....since it ca= n be anything and it can break. Explicitly specifying the return path might= not help, since if the return path breaks (permanently), you will need to = introduce new logic to instruct the ingress to now ask the egress to send p= ackets on a different return path. It=92s going to complicate your state ma= chine more than you want to...and introduce corner cases and timing issues. Nitin From elisa.bellagamba@ericsson.com Fri Feb 12 03:27: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 A123828C1AE; Fri, 12 Feb 2010 03:27:16 -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 Xbc8WuJrabOe; Fri, 12 Feb 2010 03:27:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B29BF28C198; Fri, 12 Feb 2010 03:27:14 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-55-4b753b5edfc2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 04.8B.31641.E5B357B4; Fri, 12 Feb 2010 12:28:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.221]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Feb 2010 12:28:26 +0100 From: Elisa Bellagamba To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , Adrian Farrel Date: Fri, 12 Feb 2010 12:28:23 +0100 Thread-Topic: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpoc0GbBr7At2GSTqdy72jzVYwGgCNHuBA Message-ID: <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Fri, 12 Feb 2010 11:27:16 -0000 Hello, Yes/support I'll provide comments soon. Elisa -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: den 9 februari 2010 17:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /Loa --=20 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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jeff.tantsura@ericsson.com Fri Feb 12 06:55: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 E11003A78BC; Fri, 12 Feb 2010 06:55: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=[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 AG+GtNi3L2rt; Fri, 12 Feb 2010 06:55:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C91403A76F3; Fri, 12 Feb 2010 06:55:24 -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 o1CEwFPX017673; Fri, 12 Feb 2010 08:58:15 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 12 Feb 2010 09:56:40 -0500 From: Jeff Tantsura To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Fri, 12 Feb 2010 09:56:38 -0500 Thread-Topic: [mpls-tp] [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpoc0GbBr7At2GSTqdy72jzVYwGgCNHuBAAAdE4LA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6047FC0066C@EUSAACMS0701.eamcs.ericsson.se> References: <4B7187EE.30404@pi.nu> <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> 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] [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Fri, 12 Feb 2010 14:55:26 -0000 Hi, Yes/support Cheers, Jeff -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: den 9 februari 2010 17:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /Loa --=20 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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Adrian.Farrel@huawei.com Fri Feb 12 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 60CF43A737D; Fri, 12 Feb 2010 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 uKHALjXjWs+Y; Fri, 12 Feb 2010 07:52:49 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A988D3A6A8A; Fri, 12 Feb 2010 07:52:49 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXQ00A0KK67BX@usaga01-in.huawei.com>; Fri, 12 Feb 2010 07:54:08 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXQ004SIK64B7@usaga01-in.huawei.com>; Fri, 12 Feb 2010 07:54:07 -0800 (PST) Date: Fri, 12 Feb 2010 11:36:26 +0000 From: Adrian Farrel To: mpls@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: mpls-chairs@tools.ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-mpls-explicit-resource-control-bundle@tools.ietf.org, ccamp@ietf.org Subject: [mpls] draft-ietf-mpls-explicit-resource-control-bundle X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 15:52:50 -0000 Hi MPLS working group, I received a publication request from the MPLS co-chairs for draft-ietf-mpls-explicit-resource-control-bundle at the end of November, and (after a period on my queue) I spent some time trying to understand the history of this draft and why it has popped out now. What I find is: MPLS WG last call was held in May 2006. This last call was made on the -01 revision. There were no comments during the last call. We are now at version -06 and, while I don't think the document has change substantially over the last 5 revisions, it is clearly not the revision that was lat called. Since it has been 3.5 since the last call, I am returning the draft to the WG and asking the chairs to do some things for me. 1. Poll the MPLS and CCAMP WGs to make sure that there really is interest and support for this work. 2. Re-issue the WG last call and ensure that CCAMP is involved in the last call. The next action should be an email from the MPLS chairs. Thanks, Adrian From wwwrun@core3.amsl.com Fri Feb 12 07:58:10 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 54C1C3A76C0; Fri, 12 Feb 2010 07:58:10 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100212155810.54C1C3A76C0@core3.amsl.com> Date: Fri, 12 Feb 2010 07:58:10 -0800 (PST) Cc: loa.andersson@ericsson.com, MPLS Working Group , Stewart Bryant , Greg Jones , Malcolm Betts , Yoichi Maeda , MPLS-TP Mailing list , ITU-T ad hoc team on MPLS-TP , Patrik Fältström , David Ward , Ross Callon , tsbsg15@itu.int, Huub Van Helvoort , Hing-Kam Lam , Adrian Farrel , Ghani Abbas Subject: [mpls] New Liaison Statement, "Dependency between ITU-T MPLS-TP Recommendations (ref # 010.04)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 15:58:10 -0000 Title: Dependency between ITU-T MPLS-TP Recommendations (ref # 010.04) Submission Date: 2010-02-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=642 Please reply by 2010-03-15 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12, Q14(greg.jones@itu.int) Cc: Yoichi Maeda Greg Jones Ghani Abbas Huub Van Helvoort Malcolm Betts Hing-Kam Lam ITU-T ad hoc team on MPLS-TP David Ward Adrian Farrel Ross Callon Patrik F�ltstr�m MPLS-TP Mailing list MPLS Working Group Stewart Bryant Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com Purpose: For action Body: see attachment Attachment(s): Dependency between ITU-T MPLS-TP Recommendations (ref # 010.04) (https://datatracker.ietf.org/documents/LIAISON/file762.doc) From autumn.liu@ericsson.com Fri Feb 12 10:55: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 55ACE28C1BB; Fri, 12 Feb 2010 10:55:58 -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 8nHSPnn0jukp; Fri, 12 Feb 2010 10:55:57 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 74F3A3A78E7; Fri, 12 Feb 2010 10:55:53 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1CIwkea006258; Fri, 12 Feb 2010 12:58:46 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 12 Feb 2010 13:57:12 -0500 From: Autumn Liu To: "mpls@ietf.org" , "ccamp@ietf.org" Date: Fri, 12 Feb 2010 13:57:11 -0500 Thread-Topic: Ask for comments on draft-liu-mpls-rsvp-te-gr-frr Thread-Index: AcqsFS63w9mrjrbmQ2GtZOUxGHr7hA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.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_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_" MIME-Version: 1.0 Subject: [mpls] Ask for comments on draft-liu-mpls-rsvp-te-gr-frr 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, 12 Feb 2010 18:55:58 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi MPLSers, We'd appreciate any comments and suggestions on the draft http://www.ietf.o= rg/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt. This draft describes a mechanism to extend RSVP-TE Graceful Restart to work= under conditions where FRR has occurred. Regards, Autumn --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi MPLSers,
 
We'd appreciate any comments and suggestions on the draft http://www.ietf.org/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt= .
 
This draft describes a mechanism to extend RSVP-TE Graceful Restart to= work under conditions where FRR has occurred.
 
Regards,
Autumn
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_-- From gregimirsky@gmail.com Fri Feb 12 14:38: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 4B35B28C1FC; Fri, 12 Feb 2010 14:38:37 -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 CipmDf7QXoTO; Fri, 12 Feb 2010 14:38:36 -0800 (PST) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id F2B3428C1FB; Fri, 12 Feb 2010 14:38:35 -0800 (PST) Received: by bwz28 with SMTP id 28so1195594bwz.34 for ; Fri, 12 Feb 2010 14:39:52 -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=CpYPvnUuVHQjPvWrlDaySbjK4TwUZ0Aq+Jyf7kAbg+c=; b=E24DQGbbBN3QVJz+3H12glmdx4EJ503JAfjoJjU6u8/E3XaL2eixI61qi04VGdisig /a9mZCv+4m3UhJOO1RsNL0J//3y6vp68EN3aQhawozyyJBKpKPow7PlVEWbYnORvkbPf Qfcy1tYinyk3rHSM2oj85ljwXG0EU6ucdtrhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=r6f0Dc7wH5wwaxjc5qeqIyWrWIlHeaCGdbOGZ2pyQs0X0NnquGkRWUg2WrpGJrG1ww GqldoATrxYEe7CB/5QVAcbzI4aqTgAqb489bzVY9QKL403iWi5U6hjSX41E5nxTl1UDx wTXX5Jd0hhbiuuVNtdxXMwC3/0FsKt9pklOgI= MIME-Version: 1.0 Received: by 10.204.131.210 with SMTP id y18mr1288326bks.100.1266014391916; Fri, 12 Feb 2010 14:39:51 -0800 (PST) Date: Fri, 12 Feb 2010 14:39:51 -0800 Message-ID: <787be2781002121439y7afba1achf3b69306070ddad7@mail.gmail.com> From: Greg Mirsky To: annamaria.fulignoli@ericsson.com, sboutros@cisco.com, martin.vigoureux@alcatel-lucent.com, mpls@ietf.org, mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=0015174733f81c5a35047f6ef2bd Subject: [mpls] Questions on draft-asm-mpls-tp-bfd-cc-cv 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, 12 Feb 2010 22:38:37 -0000 --0015174733f81c5a35047f6ef2bd Content-Type: text/plain; charset=ISO-8859-1 Dear Editors, Authors and All, please find my comments and questions to the document below: - section 3.3 lists BFD states as UP, DOWN and INIT for p2p bidirectional, as well as, p2p and p2mp unidirectional LSPs. But Section 4.6 of BFD for Multipoint Networks says that p2mp BFD State Machine doesn't have Init state (the diagram of the State Machine is in your document on page 7). - the last sentence of Section 3.3 says that a new BFD session initiated when an operator re-enables CC/CV monitoring. Though it might be an implementation issue, I think, that wording is not accurate, especially because unidirectional BFD doesn't have Init state. Can I propose to say "A BFD session is being brought up when the operator enables or re-enables the CC or CV/CC functionality on the same ME" - section 3.4.2 addresses issue of manipulating with BFD Discriminator value for MPLS-TP CV/CC. On the other hand, BFD for Multipoint Networks proposes to change demultiplexing process for unidirectional links, LSPs and to use source address in addition to Your Discriminator. Obviously, proposed format of CV/CC message doesn't use IP encapsulation and can not use procedure described in Section 4.8 of draft-katz-ward-bfd-multipoint-02 if leaf (egress) sends BFD control packet to root (ingress), i.e. in response to Poll. Since I could find reference to Poll function and believe that Timer Negotiation can be enabled, how the root/ingress LSR will demultiplex MPLS-TP CV/CC message sent from a leaf? Regards, Greg --0015174733f81c5a35047f6ef2bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Editors, Authors and All,
please find my comments and questions to = the document below:
  • section 3.3 lists BFD states as UP, DOWN and= INIT for p2p bidirectional, as well as, p2p and p2mp unidirectional LSPs. = But Section 4.6 of BFD for Multipoint Networks says that p2mp BFD State Mac= hine doesn't have Init state (the diagram of the State Machine is in yo= ur document on page 7).
  • the last sentence of Section 3.3 says that a new BFD session initi= ated when an operator re-enables CC/CV monitoring. Though it might be an im= plementation issue, I think, that wording is not accurate, especially becau= se unidirectional BFD doesn't have Init state. Can I propose to say &qu= ot;A BFD session is being brought up when the operator enables or re-enable= s the CC or CV/CC functionality on the same ME"
  • section 3.4.2 addresses issue of manipulating with BFD Discriminator va= lue for MPLS-TP CV/CC. On the other hand, BFD for Multipoint Networks propo= ses to change demultiplexing process for unidirectional links, LSPs and to = use source address in addition to Your Discriminator. Obviously, proposed f= ormat of CV/CC message doesn't use IP encapsulation and can not use pro= cedure described in Section 4.8 of draft-katz-ward-bfd-multipoint-02 if lea= f (egress) sends BFD control packet to root (ingress), i.e. in response to = Poll. Since I could find reference to Poll function and believe that Timer = Negotiation can be enabled, how the root/ingress LSR will demultiplex MPLS-= TP CV/CC message sent from a leaf?

Regards,
Greg
--0015174733f81c5a35047f6ef2bd-- From gregimirsky@gmail.com Fri Feb 12 15:29: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 34B353A7916; Fri, 12 Feb 2010 15:29:37 -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 WMG-GpgB0fmt; Fri, 12 Feb 2010 15:29:36 -0800 (PST) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id E24783A75F1; Fri, 12 Feb 2010 15:29:35 -0800 (PST) Received: by bwz28 with SMTP id 28so2506121bwz.14 for ; Fri, 12 Feb 2010 15:30: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=ukdOqH9wvV367aBeAp78mQF1pd3DcGkwGCYnvUudpeo=; b=fNCgEX16/7opgYwVQGF9TcowlMAQ6y73d3VD/6uvWGRwFODBinWGXiKmYA2tM67375 fDzPht9CuhokKgO9cundNl/UfxoEG6FojtyUQRpZTaRknAsFOq485Q2eyZ7OU0WxHbqi 40U2MtwT7tN7vAF+p4PLG0rH8vZyzhhmO8LnM= 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=ALg/IICYBzWAUcuYqGlHk37Ccr8Njg4Zy3ZxCBXGSzPEvY3gOGN6ovRLoChCIkUck6 15nonDY0M0TAbWwsOi8dblBgM1ukltOfZVuq34SiesJkqWyyYmpgF/hzS6I7irhWMNNM XuorZMkjFSbHupcQdQWrWeHwdFp+xXWstD4xI= MIME-Version: 1.0 Received: by 10.204.49.88 with SMTP id u24mr1340064bkf.44.1266017452361; Fri, 12 Feb 2010 15:30:52 -0800 (PST) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 12 Feb 2010 15:30:52 -0800 Message-ID: <787be2781002121530g74ea76c1j6a29897177493842@mail.gmail.com> From: Greg Mirsky To: Autumn Liu Content-Type: multipart/alternative; boundary=000325556df2870871047f6fa8e0 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] Ask for comments on draft-liu-mpls-rsvp-te-gr-frr 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, 12 Feb 2010 23:29:37 -0000 --000325556df2870871047f6fa8e0 Content-Type: text/plain; charset=ISO-8859-1 Dear Autumn, I would appreciate you you help me to understand the problem that your work addresses. As I understand scenario described in Section 3 (will refer to Fig.1) the protected LSP have failed, local repair is in use. And then Control plane on either node R2 or on node R4 restarts. Further the documet states the problem as "the protected LSP is not preserved" during GR recovery. Before the GR the working LSP is R1-R2-R6-R4-R5 and it is preserved. Correct? Do you see the problem that information about segment R2-R3-R4 will not be preserved after GR? But that would not affect the traffic or working path. Correct? Regards, Greg On Fri, Feb 12, 2010 at 10:57 AM, Autumn Liu wrote: > Hi MPLSers, > > We'd appreciate any comments and suggestions on the draft * > http://www.ietf.org/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt* > . > > This draft describes a mechanism to extend RSVP-TE Graceful Restart to work > under conditions where FRR has occurred. > > Regards, > Autumn > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --000325556df2870871047f6fa8e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Autumn,
I would appreciate you you help me to understand the proble= m that your work addresses. As I understand scenario described in Section 3= (will refer to Fig.1) the protected LSP have failed, local repair is in us= e. And then Control plane on either node R2 or on node R4 restarts. Further= the documet states the problem as "the protected LSP is not preserved= " during GR recovery. Before the GR the working LSP is R1-R2-R6-R4-R5 = and it is preserved. Correct? Do you see the problem that information about= segment R2-R3-R4 will not be preserved after GR? But that would not affect= the traffic or working path. Correct?

Regards,
Greg

On Fri, Feb 12, 2010= at 10:57 AM, Autumn Liu <autumn.liu@ericsson.com> wrote:
Hi MPLSers,
=A0
We'd appreciate any comments and suggestions on the draft http://www.ietf.org/id/draft-liu-mpls-rs= vp-te-gr-frr-00.txt.
=A0
This draft describes a mechanism to extend RSVP-TE Graceful Restart to= work under conditions where FRR has occurred.
=A0
Regards,
Autumn
=A0
=A0
=A0

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


--000325556df2870871047f6fa8e0-- From vishwas.ietf@gmail.com Fri Feb 12 23:25: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 DD9553A7969; Fri, 12 Feb 2010 23:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_63=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 kdnng1UTPkVm; Fri, 12 Feb 2010 23:25:36 -0800 (PST) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by core3.amsl.com (Postfix) with ESMTP id D7E4D3A7965; Fri, 12 Feb 2010 23:25:35 -0800 (PST) Received: by ywh17 with SMTP id 17so3187526ywh.23 for ; Fri, 12 Feb 2010 23:26:54 -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=hAiwWM4wm8uXLnEqTDVaD7MuWzik8r7cveTg8CTkjbM=; b=BR8c3Mx38lLMLL1XnHHzBbKUrfXFMZb8oBsHsdKPAvFx0NIqwdrAf41FL+7eEiIcSL Du8Crwb2Cm/UhcTXWKH9oUE2B0rYFlKP2Zhu5tm1BXjiKLFMpIZtuKuR7aAwuj5+g/79 htBDgDGyFxfHnY5TjN7j1z6Gf0oL0WWPubb8c= 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=YGe4GMscRwXanXzLCp12DHxtdOq37ICy9PD8ZxQ5zA9qqkZqbLLpRRU9Pr5LCGr4yh G5VHoblmBZYhMUHpFyI24ftYxmKORRnoEznVBbKFz9uUniDtBRZPc9h+tysud0Lgsrg0 lzpOCibFedE5eF1zF6tfF68t4nSf3K7y88ugM= MIME-Version: 1.0 Received: by 10.150.242.2 with SMTP id p2mr690809ybh.292.1266046010780; Fri, 12 Feb 2010 23:26:50 -0800 (PST) In-Reply-To: References: <69DE8D9579C64DAC82CD3431C588E76A@m55527c> Date: Fri, 12 Feb 2010 23:26:50 -0800 Message-ID: <77ead0ec1002122326y259c3cdeqa54ab99cb70ce09b@mail.gmail.com> From: Vishwas Manral To: Nitin Bahadur Content-Type: multipart/alternative; boundary=000e0cd6a7aabdeeac047f764e2a Cc: "mpls@ietf.org" , So@core3.amsl.com, Ning , "mpls-tp@ietf.org" , "Simon.A.DeLord@team.telstra.com" Subject: Re: [mpls] Comments for 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: Sat, 13 Feb 2010 07:25:38 -0000 --000e0cd6a7aabdeeac047f764e2a Content-Type: text/plain; charset=ISO-8859-1 Hi Nitin, > Since the echo reply will not carry the FEC stack information of the > reverse > > direction, one LSP-Ping could only complete cv checking of the forward > > direction of the LSP. > > I'm not an RSVP expert, but I believe, for co-routed bi-directional LSPs, > the FEC stack for the reverse direction will be the same. So CV checking on > the reverse path involves 2 things: > > 1) Ensuring that received echo response is for the echo request sent > 2) Ensuring that echo response is received on the reverse path of the > bi-directional LSP. I am not sure what you mean the FEC in both directions of a bidirectional LSP is the same. The FEC of an FTN entry tells what traffic is to be mapped to a particular LSP and they are bound to be different depending on the FEC's on each side of the tunnel. Thanks, Vishwas > > For associated bi-directional LSPs, the ingress node already knows which > egress LSP has been associated with the ingress LSP. So the ingress node > needs to validate: > 1) Received echo response is for the echo request sent > 2) Echo response is received on the egress LSP. > > More details are not needed IMO. > > In echo request, we need the FEC stack to identify the LSP under test (to > catch a case where an OAM packet arrives at an un-intended destination). > Note that regular uni-directional LSPs use PHP and hence FEC determination > cannot be based off a label (since there will be no label received on > egress). > > In echo response, if the packet is dropped, then the receiver (ingress) > will > time out. If the packet is mis-routed, then the receiver (some random node) > will drop it since it won't be expecting an echo response. > > In addition, RFC 4379 specifies, "The FEC Stack TLV from the echo request > MAY be copied to the reply." This has huge implications. This means that > for > bi-directional co-routed LSPs, one can copy the incoming FEC stack TLV (if > one wants to) and for bi-directional associated LSPs, once can insert a new > FEC stack TLV identifying the reverse path FEC. The ingress has information > regarding the association, so it can perform any CV validations. > > > > In order to do cv checking of the reverse direction, > > another LSP-Ping is necessary. With this RPS(Return Path Specified) > > extension, it's really that only one LSP-Ping is enough. > > See above. > > > And for > > inter-AS/inter-domain LSP, the operators of one side may have no right to > > log on to the remote side to perfom any actions, hence make it > impossiable > > to check the reserve direction without the help of the operators of the > > other domain/AS. With this RPS extension, a single LSP-Ping could finish > > both directions checking. > > See below > > > For the operators, they use unidirectional LSPs to provide bidirectional > > service, most of the time, they just see there is a bidirectional path. > If > > there is light/easier way to perform bidirectional path checking within a > > single operation, I think it should be good. > > Bi-directional associated LSPs will give the operators exactly that. They > just need to add that association. > > > >> Other comments > >> -------------- > >> The draft talks about specifying ways in which ingress could specify how > >> the > >> egress should respond. I fail to see how operators will use this > *ability* > >> in > >> the field. How does the operator know which LSP should be used for > >> return-path? > >> If the operator knows this via config, then the same config could be > added > >> at > >> LSP egress as well. > > > > The operators could based on their experence and the on-site conditions > to > > choose the specific LSP for return-path. > > Experience and on-site conditions => complicated NMS systems and more > maintenance windows. OAM should be simple and stupid...otherwise it will > not > be deployable. > > > >> If the operator is just going to loop through (in return-path tlv) all > the > >> egress > >> initated LSPs hoping for at least 1 successful response, then the scheme > >> is broken. > > > > Loop through all the egress initated LSPs is the worsest situation, and > for > > most of the time, there will not be too many LSPs. For me this is > > reasonable. Why do you think the scheme is broken? > > It's broken because now the ingress needs to know about all the "egress > initiated LSPs". It's too much coupling. As I said in my other email, all > you need is an alternate way of sending the response. Multiple alternate > ways will not provide you with too much benefit. The cost vs benefit > equation doesn't favor multiple alternate paths. > > >> One should use BFD (or some other mechanism) to ensure that both ingress > >> initiated > >> and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > >> the egress > > > > IMO, it's not possible to provision BFD session for every LSP and route, > > it's not scale. > > I happily disagree with that statement. I know more than 1 vendor that has > simplified BFD provisioning for LSPs and routes. > > Scaling yes, every system will have scaling limits. Some boxes will do > better than others. > > If you don't provision BFD for every LSP, then you won't know if a > particular LSP is down and you might black-hole traffic. If you round-robin > packets of 1 bfd session between multiple LSPs, then you are effectively > (in > forwarding plane) increasing the time interval between packets sent on a > particular LSP....which is the same as multiple BFD sessions (without > additional control plane state). > > Again, as I said, it's my opinion. > > > And if it is only for selection a proper return path to send > > the echo reply, IMHO, provision too many BFD sessions is not > cost-effective. > > > BTW, from my understanding, normally, the echo reply is always trying to > > follow lsp(it have higher priority the IP path). > > That's your assumption...you can have a box that has different policies for > different things. There is nothing in the echo rely that specifies that it > must go over a LSP. > > > So, in the RPS draft, we > > define a mechanism to force the echo reply follow pure IP path(at least > the > > egress uses IP path), hence to verify whether the LSP path is OK. > > I think you just need an alternate path....there is no guarantee that your > IP path won't be the same as the LSP path...so it's no better than an > alternate path. > > > In short, with our RPS extensions, it has the following benifits: > > > 1. Enable to change/exclude the return paths freely, improve the > robustness > > of LSP Ping; > > Hard to deploy IMO....need operators to comment. This looks more like a > solution looking for a problem. > > > 2. Return path could be force to along IP-only path; > > Why not a good ol' L2 path...why IP? In MPLS-TP, there might be no IP > forwarding. So IP-only path might not be useful for MPLS-TP. > > > 3. Improve the efficient for bidirectional path checking; > > Some benefit exists here. > > > 4. Enable to check a bidirectional inter-domain/AS path; > > Inter-domain lsp-ping still needs to be worked out. Regular uni-directional > LSP lsp-ping is currently broken for many cases of inter-domain LSPs. I > don't think we should half bake an inter-as solution as part of this draft. > You are welcome to work on an inter-as solution. > > > 5. Could be used for enhancing "BFD for MPLS" bootstrap signaling: enable > to > > provision a single(not two) BFD session for a bidirectional LSP. More > > specific information could be found at: > > http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00. > > That's a separate draft anyways. > > Thanks > Nitin > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --000e0cd6a7aabdeeac047f764e2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0 Nitin,

> Since the echo reply will not carry the FEC stack in= formation of the reverse
> direction, one LSP-Ping could only complet= e cv checking of the forward
> direction of the LSP.

I'm not an RSVP expert, but I believe, for co-routed bi-directional LSP= s,
the FEC stack for the reverse direction will be the same. So CV check= ing on
the reverse path involves 2 things:

1) Ensuring that recei= ved echo response is for the echo request sent
2) Ensuring that echo response is received on the reverse path of the
= =A0 bi-directional LSP.
I am not sure what you mean the FEC in both directions of a bidirectio= nal LSP is the same. The FEC of an FTN entry tells what traffic is to be ma= pped to a particular LSP and they are bound to be different depending on th= e FEC's on each side of the tunnel.
=A0
Thanks,
Vishwas
=A0

For associated bi-directiona= l LSPs, the ingress node already knows which
egress LSP has been associa= ted with the ingress LSP. So the ingress node
needs to validate:
1) Received echo response is for the echo request sen= t
2) Echo response is received on the egress LSP.

More details ar= e not needed IMO.

In echo request, we need the FEC stack to identify= the LSP under test (to
catch a case where an OAM packet arrives at an un-intended destination).Note that regular uni-directional LSPs use PHP and hence FEC determination=
cannot be based off a label (since there will be no label received on egress).

In echo response, if the packet is dropped, then the receiv= er (ingress) will
time out. If the packet is mis-routed, then the receiv= er (some random node)
will drop it since it won't be expecting an ec= ho response.

In addition, RFC 4379 specifies, "The FEC Stack TLV from the echo = request
MAY be copied to the reply." This has huge implications. Th= is means that for
bi-directional co-routed LSPs, one can copy the incomi= ng FEC stack TLV (if
one wants to) and for bi-directional associated LSPs, once can insert a new=
FEC stack TLV identifying the reverse path FEC. The ingress has informa= tion
regarding the association, so it can perform any CV validations.


> In order to do cv checking of the reverse di= rection,
> another LSP-Ping is necessary. With this RPS(Return Path S= pecified)
> extension, it's really that only one LSP-Ping is enou= gh.

See above.

> And for
> inter-AS/inter-domain LSP, the o= perators of one side may have no right to
> log on to the remote side= to perfom any actions, hence make it impossiable
> to check the rese= rve direction without the help of the operators of the
> other domain/AS. =A0With this RPS extension, a single LSP-Ping could f= inish
> both directions checking.

See below

> For the operators, they use unidirectional LSPs = to provide bidirectional
> service, most of the time, they just see t= here is a bidirectional path. If
> there is light/easier way to perfo= rm bidirectional path checking within a
> single operation, I think it should be good.

Bi-direction= al associated LSPs will give the operators exactly that. They
just need = to add that association.


>> Other comments
>> -------------= -
>> The draft talks about specifying ways in which ingress could = specify how
>> the
>> egress should respond. I fail to se= e how operators will use this *ability*
>> in
>> the field. How does the operator know which LSP sho= uld be used for
>> return-path?
>> If the operator knows = this via config, then the same config could be added
>> at
>> LSP egress as well.
>
> The operators could based on t= heir experence and the on-site conditions to
> choose the specific LS= P for return-path.

Experience and on-site conditions =3D> c= omplicated NMS systems and more
maintenance windows. OAM should be simple and stupid...otherwise it will no= t
be deployable.


>> If the operator is just going to loop th= rough (in return-path tlv) all the
>> egress
>> initated = LSPs hoping for at least 1 successful response, then the scheme
>>= is broken.
>
> Loop through all the egress initated LSPs is the worsest situa= tion, and for
> most of the time, there will not be too many LSPs. Fo= r me this is
> reasonable. Why do you think the scheme is broken?

It's broken because now the ingress needs to know about all t= he "egress
initiated LSPs". It's too much coupling. As I s= aid in my other email, all
you need is an alternate way of sending the r= esponse. Multiple alternate
ways will not provide you with too much benefit. The cost vs benefit
equ= ation doesn't favor multiple alternate paths.

>> One should use BFD (or some other mechanism)= to ensure that both ingress
>> initiated
>> and egress i= nitiated (uni-directional) LSPs are UP. If a LSP is UP, then
>> th= e egress
>
> IMO, it's not possible to provision BFD session for every = LSP and route,
> it's not scale.

I happily disagree = with that statement. I know more than 1 vendor that has
simplified BFD p= rovisioning for LSPs and routes.

Scaling yes, every system will have scaling limits. Some boxes will do<= br>better than others.

If you don't provision BFD for every LSP,= then you won't know if a
particular LSP is down and you might black= -hole traffic. If you round-robin
packets of 1 bfd session between multiple LSPs, then you are effectively (i= n
forwarding plane) increasing the time interval between packets sent on= a
particular LSP....which is the same as multiple BFD sessions (without=
additional control plane state).

Again, as I said, it's my opini= on.

> And if it is only for selection a proper return = path to send
> the echo reply, IMHO, provision too many BFD sessions = is not cost-effective.

> BTW, from my understanding, normally, the echo reply= is always trying to
> follow lsp(it have higher priority the IP path= ).

That's your assumption...you can have a box that has di= fferent policies for
different things. There is nothing in the echo rely that specifies that it<= br>must go over a LSP.

> So, in the RPS draft, we
> define a mechan= ism to force the echo reply follow pure IP path(at least the
> egress= uses IP path), hence to verify whether the LSP path is OK.

I think you just need an alternate path....there is no guarantee that your<= br>IP path won't be the same as the LSP path...so it's no better th= an an
alternate path.

> In short, with our RPS extensions, it has the fo= llowing benifits:

> 1. Enable to change/exclude the return paths = freely, improve the robustness
> of LSP Ping;

Hard to de= ploy IMO....need operators to comment. This looks more like a
solution looking for a problem.

> 2. Return path could be force to along IP-only p= ath;

Why not a good ol' L2 path...why IP? In MPLS-TP, ther= e might be no IP
forwarding. So IP-only path might not be useful for MPL= S-TP.

> 3. Improve the efficient for bidirectional path = checking;

Some benefit exists here.

> 4. Enable to check a bidirectional inter-domain/= AS path;

Inter-domain lsp-ping still needs to be worked out. R= egular uni-directional
LSP lsp-ping is currently broken for many cases o= f inter-domain LSPs. I
don't think we should half bake an inter-as solution as part of this dr= aft.
You are welcome to work on an inter-as solution.

> 5. Could be used for enhancing "BFD for MPL= S" bootstrap signaling: enable to
> provision a single(not two) = BFD session for a bidirectional LSP. More
> specific information coul= d be found at:
> http://tools.ietf.org/html/draft-chen-mpls-bfd-enhanc= ement-00.

That's a separate draft anyways.

Thanks
Nitin

______________________________= _________________
mpls mailing list
mpls@ietf.org

--000e0cd6a7aabdeeac047f764e2a-- From vishwas.ietf@gmail.com Fri Feb 12 23:39: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 2E13928B797; Fri, 12 Feb 2010 23:39:13 -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 NcMFyyCU86DC; Fri, 12 Feb 2010 23:39:11 -0800 (PST) Received: from mail-yx0-f178.google.com (mail-yx0-f178.google.com [209.85.210.178]) by core3.amsl.com (Postfix) with ESMTP id 5586128B56A; Fri, 12 Feb 2010 23:39:11 -0800 (PST) Received: by yxe8 with SMTP id 8so3792586yxe.17 for ; Fri, 12 Feb 2010 23:40:29 -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=OIOwRJV0V0H42oa6dsT1Bz0tuNY+E9q2Apt/nLmWwLY=; b=I/UB4OAX06EspY/BYFIF6juvLSEW22n8gw+d1srGW9nokL1oYkoKHBNCBfXG/RQ+us oWnKDgHK8BvFe9FkuVN/tesPuIaUXNrCh+uN6/cmEhNVKlbAlx3NF2iLS7fJzZ2noEJ8 p1GQtzPnGeIH6fRKUOU6zxttChjXBRBGJZyxg= 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=jl1tBvzqmiuKVQBrjkUjMhjeA5ESTg6kPwI5Swv6UK0LyedvUTu2Ai/g1ZzTZoBUxf zPJ8Jk00LCwogrIvQtLu9Q4xiqVsBttMkn9UycLg6jYtc36CCGLqS7PKGuFbqcMMtJHf xoGrszbxWWTHZUz3z66h7eL1CLzpsET9iErto= MIME-Version: 1.0 Received: by 10.150.128.30 with SMTP id a30mr4015068ybd.252.1266046829210; Fri, 12 Feb 2010 23:40:29 -0800 (PST) In-Reply-To: References: <77ead0ec1002102246v28f971a7p812e62e3934e2f57@mail.gmail.com> Date: Fri, 12 Feb 2010 23:40:29 -0800 Message-ID: <77ead0ec1002122340p67bd79acke626a3a2327f3bf2@mail.gmail.com> From: Vishwas Manral To: Nitin Bahadur Content-Type: multipart/alternative; boundary=000e0cd71a6a862d6f047f767f8e Cc: "mpls-tp@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comments for 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: Sat, 13 Feb 2010 07:39:13 -0000 --000e0cd71a6a862d6f047f767f8e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Nitin, Interesting example. If an operator specifies the name does not mean the name is what is signalled across. We could use the LSP Key for signalling and keep a mappin= g in the code from the name to the LSP Key, which could be called different/ same names in either direction. Am I missing the point here? However I liked the points Mach brought about the fault direction detection= . Thanks, Vishwas On Wed, Feb 10, 2010 at 11:43 PM, Nitin Bahadur wrote: > > There is a subtle difference. OAM is initiated in the direction of the > LSP...which is setup by the ingress. > OAM response is sent by the egress in the reverse direction....so the > policy should be on the egress. > > Deploying ingress based policy can be a nightmare. Suppose you have a LSP > (called lsp-1) from San Francisco to New York. > And suppose you have a LSP (called lsp-2) from NY to SF. You could (in > theory) instruct in the OAM msg that NY should > use lsp-2 for reverse path. Now if the operator in NY wants to rename lsp= -2 > to lsp-from-ny-to-sf, then the > operator has to make a change even in the router in San Francisco. Isn=92= t > this a deployment hassle? You can say that NMS > will take care of it....but even the NMS has to be programmed with this > dependency.....maintenance has to be scheduled > In both NY and SF. > > Instead if the policy was only in NY (say =96 for all OAMs coming on any = LSP > from SF, reply using lsp-2), then the operator could easily > change the lsp name and the policy, without scheduling potential > down-time/maintenance time in SF. If the operator wanted to bring > down the LSP in NY, then he could do that and get rid of the policy in > NY....instead of having to go to SF and change the policy there. > > Again, above applies only to uni-directional LSPs. > > Nitin > > > On 2/10/10 10:46 PM, "Vishwas Manral" wrote: > > Hi Nitin, > > For regular uni-directional LSPs, my main question is what is the operat= or > going to gain by specifying the > return path policy on the ingress (via signaling or NMS). This policy > should be on the egress (rather than ingress). For uni-directional > LSPs if you put the policy on the ingress, then you are adding state (on > the ingress) regarding which LSPs exist on the egress. > > > Dont we generally want the ingress to specify policy because that is wher= e > the OAM initiated? > > Thanks, > Vishwas > > On 2/10/10 6:17 PM, "Greg Mirsky" wrote: > > Dear Nitin, > the LSP Ping might not be the only option but I believe that there must b= e > a Control Plane mechanism to direct return path of BFD session (egress to > ingress) of unidirectional LSP onto specified path (IP routed, LSP or els= e). > There certainly could be local policy that will select such return path b= ut > that does not preclude from driving selection from headend or NMS. Would = LSP > Ping be the only such mechanism? Considering work on MPLS-TP OAM I'd expe= ct > to see appropriate extensions being proposed for RSVP-TE some time soon. > (There's already proposal to bootstrap BFD session via RSVP-TE) > > Regards, > Greg > > On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur > wrote: > Hi Mach, > > Please see inline below for comments. > > > There are two issues that our draft tries to resolve: > > 1. Current LSP Ping mechanisms are lack of the capability of > specifying the return path > > of an echo reply, hence some time it may bring difficuties in > faults localization. > > NB> This is only a problem for uni-directional LSPs. Also, the > problem only exists > if the LSP forward path is UP and the reverse IP path is down. If the > forward LSP path > is DOWN, then lsp traceroute should help in fault localization. See my > comments below for > bi-directional LSPs. > > > > 2. A bidirectional path checking needs at least two LSP > pings(inefficient), and sometime > > difficut even fail to check the reverse direction of a bidirection= al > path. > > NB> You don't need 2 LSP-Pings. For bidirectional co-routed LSPs, t= he > egress SHOULD > send the packet over the LSP itself. > > For bidirectional associated LSP, the egress again SHOULD send the > packet over the > associated LSP itself. See Section 3.1 of > draft-nitinb-mpls-tp-lsp-ping-extensions-00. > Even if the specifications in the draft above are not used, I presume > there will *some* > way that one will specify the LSP "association". One could use that w= ay > to ensure that > lsp-ping responses always use that association. So additional protoco= l > machinery is not > needed. > > For uni-directional LSPs, yes you will need 2 lsp-pings. But the LS= P > is uni-directional..... > so you are testing only the forward direction..... > there is no concept of reverse direction for uni-directional LSPs. > > > Other comments > -------------- > The draft talks about specifying ways in which ingress could specify how > the > egress should respond. I fail to see how operators will use this *ability= * > in > the field. How does the operator know which LSP should be used for > return-path? > If the operator knows this via config, then the same config could be adde= d > at > LSP egress as well. > > If the operator is just going to loop through (in return-path tlv) all th= e > egress > initated LSPs hoping for at least 1 successful response, then the scheme = is > broken. > One should use BFD (or some other mechanism) to ensure that both ingress > initiated > and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then > the egress > can respond back via any UP LSP and the echo response will reach the > ingress...since the > LSP is UP. If you want to ensure that the echo response comes back via a > LSP (and not IP), > then I guess you could add a code-point that says "reply via lsp" or > something like that. > > From a practical operator persecptive, I need to understand more on how > someone would > use the feature/flexibility that you are proposing. > > Thanks > Nitin > --000e0cd71a6a862d6f047f767f8e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Nitin,
=A0
Interesting example.
=A0
If an operator specifies the name does not mean the name is what is si= gnalled across. We could use the LSP Key for signalling and keep a mapping = in the code from the name to the LSP Key, which could be called different/ = same names in either direction. Am I missing the point here?
=A0
However I liked the points Mach brought about the fault direction dete= ction.
=A0
Thanks,
Vishwas
On Wed, Feb 10, 2010 at 11:43 PM, Nitin Bahadur = <nitinb@juniper.= net> wrote:

There is a subtle difference= . OAM is initiated in the direction of the LSP...which is setup by the ingr= ess.
OAM response is sent by the egress in the reverse direction....so the polic= y should be on the egress.

Deploying ingress based policy can be a n= ightmare. Suppose you have a LSP (called lsp-1) from San Francisco to New Y= ork.
And suppose you have a LSP (called lsp-2) from NY to SF. You could (in =A0t= heory) instruct in the OAM msg that NY should
use lsp-2 for reverse path= . Now if the operator in NY wants to rename lsp-2 to lsp-from-ny-to-sf, the= n the
operator has to make a change even in the router in San Francisco. Isn=92t = this a deployment hassle? You can say that NMS
will take care of it....b= ut even the NMS has to be programmed with this dependency.....maintenance h= as to be scheduled
In both NY and SF.

Instead if the policy was only in NY (say =96 for= all OAMs coming on any LSP from SF, =A0reply using lsp-2), then the operat= or could easily
change the lsp name and the policy, without scheduling p= otential down-time/maintenance time in SF. If the operator wanted to bring<= br> down the LSP in NY, then he could do that and get rid of the policy in NY..= ..instead of having to go to SF and change the policy there.

Again, = above applies only to uni-directional LSPs.

Nitin


On 2/10/10 10:46 PM, "Vishwas Manral" &= lt;vishwas.ietf@gmail.com>= wrote:

Hi Nitin,

=A0For regular uni-directional LSPs, my mai= n question is what is the operator going to gain by specifying the
return path policy on the ingress (via signaling or NMS). This policy shoul= d be on the egress (rather than ingress). =A0For uni-directional
LSPs if= you put the policy on the ingress, then you are adding state (on the ingre= ss) regarding which LSPs exist on the egress.


Dont we generally want the ingress to specify policy because that i= s where the OAM initiated?

Thanks,
Vishwas

On 2/10/10 6:17= PM, "Greg Mirsky" <g= regimirsky@gmail.com> wrote:

Dear Nitin,
the LSP Ping might not be the only option but I believe = that there must be a Control Plane mechanism to direct return path of BFD s= ession (egress to ingress) of unidirectional LSP onto specified path (IP ro= uted, LSP or else). There certainly could be local policy that will select = such return path but that does not preclude from driving selection from hea= dend or NMS. Would LSP Ping be the only such mechanism? Considering work on= MPLS-TP OAM I'd expect to see appropriate extensions being proposed fo= r RSVP-TE some time soon. (There's already proposal to bootstrap BFD se= ssion via RSVP-TE)

Regards,
Greg

On Wed, Feb 10, 2010 at 12:02 PM, Nitin Bahadur= <nitinb@juniper.net> wrote= :
Hi Mach,

=A0 Please see inline below for comments.

> = =A0 =A0 =A0 =A0There are two issues that our draft tries to resolve:
> =A0 =A0 =A0 1. Current LSP Ping mechanisms are lack of the capability = of specifying the return path
> =A0 =A0 =A0 =A0 =A0of an echo reply, = hence some time it may bring difficuties in faults localization.

=A0= =A0 =A0 NB> This is only a problem for uni-directional LSPs. Also, the = problem only exists
if the LSP forward path is UP and the reverse IP path is down. If the forwa= rd LSP path
is DOWN, then lsp traceroute should help in fault localizati= on. See my comments below for
bi-directional LSPs.


> =A0 = =A0 =A0 2. A bidirectional path checking needs at least two LSP pings(ineff= icient), and sometime
> =A0 =A0 =A0difficut even fail to check the reverse direction of a bidi= rectional path.

=A0 =A0 =A0 NB> You don't need 2 LSP-Pings. F= or bidirectional co-routed LSPs, the egress SHOULD
=A0 =A0 send the pack= et over the LSP itself.

=A0 =A0 =A0 For bidirectional associated LSP, the egress again SHOULD s= end the packet over the
=A0 =A0 associated LSP itself. See Section 3.1 o= f draft-nitinb-mpls-tp-lsp-ping-extensions-00.
=A0 =A0 Even if the speci= fications in the draft above are not used, I presume there will *some*
=A0 =A0 way that one will specify the LSP "association". One coul= d use that way to ensure that
=A0 =A0 lsp-ping responses always use that= association. So additional protocol machinery is not
=A0 =A0 needed.
=A0 =A0 =A0 For uni-directional LSPs, yes you will need 2 lsp-pings. B= ut the LSP is uni-directional.....
=A0 =A0 so you are testing only the forward direction.....
=A0 =A0 there= is no concept of reverse direction for uni-directional LSPs.


Ot= her comments
--------------
The draft talks about specifying ways in = which ingress could specify how the
egress should respond. I fail to see how operators will use this *ability* = in
the field. How does the operator know which LSP should be used for re= turn-path?
If the operator knows this via config, then the same config c= ould be added at
LSP egress as well.

If the operator is just going to loop through (i= n return-path tlv) all the egress
initated LSPs hoping for at least 1 su= ccessful response, then the scheme is broken.
One should use BFD (or som= e other mechanism) to ensure that both ingress initiated
and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then th= e egress
can respond back via any UP LSP and the echo response will reac= h the ingress...since the
LSP is UP. If you want to ensure that the echo= response comes back via a LSP (and not IP),
then I guess you could add a code-point that says "reply via lsp"= or something like that.

From a practical operator persecptive, I ne= ed to understand more on how someone would
use the feature/flexibility t= hat you are proposing.

Thanks
Nitin
--000e0cd71a6a862d6f047f767f8e-- From eric.gray@ericsson.com Wed Feb 17 06:37:34 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 D75DB28C13F; Wed, 17 Feb 2010 06:37:34 -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 NhUsGcDNQjWN; Wed, 17 Feb 2010 06:37:34 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 0469328C131; Wed, 17 Feb 2010 06:37:33 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1HEes8T026658; Wed, 17 Feb 2010 08:40:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 17 Feb 2010 09:39:11 -0500 From: Eric Gray To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Wed, 17 Feb 2010 09:39:09 -0500 Thread-Topic: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpod20yImQSL5nQS6RZLzzdWw3ZAGPQWjQ Message-ID: References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@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] [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 17 Feb 2010 14:37:35 -0000 Yes -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: Tuesday, February 09, 2010 11:06 AM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /Loa --=20 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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From agmalis@gmail.com Wed Feb 17 10:46: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 103E928C19D; Wed, 17 Feb 2010 10:46:58 -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 fllzsFHnr0CU; Wed, 17 Feb 2010 10:46:57 -0800 (PST) Received: from mail-yx0-f190.google.com (mail-yx0-f190.google.com [209.85.210.190]) by core3.amsl.com (Postfix) with ESMTP id CB76A28C178; Wed, 17 Feb 2010 10:46:56 -0800 (PST) Received: by yxe28 with SMTP id 28so5086567yxe.29 for ; Wed, 17 Feb 2010 10:48:33 -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 :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=cgecIBlyxK2lSHP/Eb6FbiR9w3ePqgk4o7jN5joy6Vk=; b=p02hs25UvKZCiV6B7eBlxV2qaeWe02Ko/wRNndwCqLXncUTDQlP2u7GPmkBZnBILNC GBMKkxk0zWTwmYng5WSJ/D8XV3u2mpMByGliyHyk3Wtk4FAjm0evb+TqbM2TkzNywQgc ieo7BYTbwmFX1lVCJIxG3UwSK619cnpRe9sSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=aCoE05f1bxqYkgeqW0mRMyjlqdh7hrrt4ttR/dHiYxbuZ43UcjtZCQ+Cf+2I2hzTBp WfQkvIulZiDGmd8FQ8Ho2a6YmsyEk/B6sHKLi7fweFZ+2KFoh73pF7yWaGUygOVQWgTi 82aTSQNQeTzRwgMT5NTIGQVHTz1MNxWZiq0Ac= MIME-Version: 1.0 Received: by 10.101.184.38 with SMTP id l38mr7333291anp.81.1266432509293; Wed, 17 Feb 2010 10:48:29 -0800 (PST) In-Reply-To: References: <1265795114.4b72802ab7a84@discus.singnet.com.sg> From: "Andrew G. Malis" Date: Wed, 17 Feb 2010 13:48:09 -0500 Message-ID: <8c99930d1002171048s7ec00560we4683577e50403ba@mail.gmail.com> To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Loa@core3.amsl.com, "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "mngpl@singnet.com.sg" Subject: Re: [mpls] [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 17 Feb 2010 18:46:58 -0000 I support the draft, and also Sasha's comment below seems quite reasonable. Cheers, Andy On Wed, Feb 10, 2010 at 10:31 AM, Alexander Vainshtein wrote: > Max, > The MPLS-TP framework draft is defined as Informational while the MPLS-TP= data plane > draft is defined as Standard Track. This seems to be one good reason not = to merge them. > > On the other hand, it makes sense to me move all the data-plane issues fr= om the > Framework draft to the data plane one and just to reference in in the Fra= mework draft. > > Regards, > =A0 =A0 Sasha > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> Behalf Of mngpl@singnet.com.sg >> Sent: Wednesday, February 10, 2010 11:45 AM >> To: Loa Andersson >> Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org >> Subject: Re: [PWE3] [mpls-tp] poll on making >> draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >> >> Hi Loa and the authors, >> >> From what I read, the main key aspect of this draft defines a >> new ethernet MAC discovery through the use of multicast MAC. >> The rest of the drafts discuss about specific dataplane >> implementation that is align with >> draft-ietf-mpls-tp-framework-10, which calls it profiling. >> >> Suggestion, why not put profile details into the framework >> draft? This improves readability? Or unless there can other >> type of profiling. >> >> /Max >> --- Loa Andersson wrote: >> >> > All, >> > >> > This is to start two week poll on making >> > draft-fbb-mpls-tp-data-plane-00.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". >> > >> > Note that this ID is a starting point for what needs to >> > be documented on the MPLS data plane for the MPLS-TP >> > project. The ID is largely based on the data plane specific >> > text from the framework, together with some notes concerning >> > how the Transport Profile of MPLS might operate over Ethernet. >> > >> > >> > /Loa >> > >> > >> > -- >> > >> > >> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: >> > loa.andersson@ericsson.com >> > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >> > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13 >> > _______________________________________________ >> > mpls-tp mailing list >> > mpls-tp@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls-tp >> > >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Wed Feb 17 11:28: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 907D93A7EFC; Wed, 17 Feb 2010 11:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 oxP1Hd0QPopP; Wed, 17 Feb 2010 11:28:47 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id C029E3A75C6; Wed, 17 Feb 2010 11:28:47 -0800 (PST) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 72BB1D4052; Wed, 17 Feb 2010 20:30:25 +0100 (CET) Message-ID: <4B7C43CF.3070700@pi.nu> Date: Wed, 17 Feb 2010 20:30:23 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 17 Feb 2010 19:28:48 -0000 All, this is to start a two week working group poll on making draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt an mpls working group document. Send your response to the mpls-tp@ietf.org mailing list (only), indicating "yes/support" or "no/do not support". The poll ends eob March 5th 2001. /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 tom.nadeau@bt.com Wed Feb 17 11:51: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 5F1E328C16E; Wed, 17 Feb 2010 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 C-fnzDhmm6UE; Wed, 17 Feb 2010 11:51:04 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 6718D3A7F01; Wed, 17 Feb 2010 11:51:04 -0800 (PST) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 19:52:43 +0000 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Feb 2010 19:52:41 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 17 Feb 2010 14:52:41 -0500 From: "Thomas D. Nadeau" To: Loa Andersson , "mpls-tp@ietf.org" , , CCAMP WG , Message-ID: Thread-Topic: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt Thread-Index: AcqwCsOG/A+rfo1YNEWX0UNMcXX4Iw== In-Reply-To: <4B7C43CF.3070700@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Feb 2010 19:52:43.0102 (UTC) FILETIME=[C4C707E0:01CAB00A] Subject: Re: [mpls] [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 17 Feb 2010 19:51:05 -0000 Support. On 2/17/10 2:30 PM, "Loa Andersson" wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > /Loa From gregimirsky@gmail.com Wed Feb 17 12:14: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 C0CE528C245; Wed, 17 Feb 2010 12:14:57 -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 TPbsnnhktAoc; Wed, 17 Feb 2010 12:14:56 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id D62C628C16E; Wed, 17 Feb 2010 12:14:55 -0800 (PST) Received: by fxm7 with SMTP id 7so9212112fxm.28 for ; Wed, 17 Feb 2010 12:16:31 -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=uGLyLhOuKE0Y1673DhsQDj/0Kg4d/z5QnCbi6fClYAY=; b=MVRJxX/ljZ++E4bqE7kJqt7ZnOV69TmzMg4Egbzc2PobPQNBGfUBWsciXGir/UhG5Q 8rivg97N8G+ucGxFOZ9mSx7by/qasne6Cy01Efd+XsdlEotKfTo1KsG8dMDImrgXMD/V uXMmQ6kqqE4hD3hrLEaFQv+/3qPa/EMR91KJY= 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=jXWGVSPmFD3o38RD5U4RnunEd4Ub+oXf/rf2s/lk5qd0rQSnQfsBNJn+aV6KCGlBtb iv8oXsYUVnROcmV0H18CJLNIfdK5oSU+4w1fOXVr/oTbp01EJqwzf+CUq6ADOyvxa68l f4ykVZ3Z+gLjtRbVT6M+yKt1Yye4Hc/zx3uO0= MIME-Version: 1.0 Received: by 10.204.5.154 with SMTP id 26mr1672782bkv.62.1266437791325; Wed, 17 Feb 2010 12:16:31 -0800 (PST) In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Date: Wed, 17 Feb 2010 12:16:31 -0800 Message-ID: <787be2781002171216n19917213k5dc16b96df92bcb@mail.gmail.com> From: Greg Mirsky To: "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org Content-Type: multipart/alternative; boundary=00151758fb9eae9dc0047fd186a5 Subject: Re: [mpls] [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 17 Feb 2010 20:14:57 -0000 --00151758fb9eae9dc0047fd186a5 Content-Type: text/plain; charset=ISO-8859-1 yes/support On Wed, Feb 17, 2010 at 11:30 AM, Loa Andersson wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > /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 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --00151758fb9eae9dc0047fd186a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes/support

On Wed, Feb 17, 2010 at 11:30= AM, Loa Andersson <loa@p= i.nu> wrote:
All,


this is to start a two week working group poll on making
draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt
an mpls working group document.

Send your response to the mpls-tp@ietf.org mailing list
(only), indicating "yes/support" or "no/do not support"= .

The poll ends eob March 5th 2001.

/Loa
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--00151758fb9eae9dc0047fd186a5-- From jdrake@juniper.net Wed Feb 17 12:39:30 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 3BF7E28C16B; Wed, 17 Feb 2010 12:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 w32Vh5L7kPwT; Wed, 17 Feb 2010 12:39:29 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0E1083A7BCF; Wed, 17 Feb 2010 12:39:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS3xUX7nGgO1NqdMziz7CCW4xFmZnLixN@postini.com; Wed, 17 Feb 2010 12:41:09 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; Wed, 17 Feb 2010 12:39:54 -0800 From: John E Drake To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , CCAMP WG , "pwe3@ietf.org" Date: Wed, 17 Feb 2010 12:39:52 -0800 Thread-Topic: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt Thread-Index: AcqwB6wRWS9tbIMxQEWM+RKAL8uo7QACaovg Message-ID: <5E893DB832F57341992548CDBB33316398050D9620@EMBX01-HQ.jnpr.net> References: <4B7C43CF.3070700@pi.nu> In-Reply-To: <4B7C43CF.3070700@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] [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 17 Feb 2010 20:39:30 -0000 Yes > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Wednesday, February 17, 2010 11:30 AM > To: mpls-tp@ietf.org; mpls@ietf.org; CCAMP WG; pwe3@ietf.org > Subject: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures- > 02.txt >=20 > All, >=20 >=20 > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. >=20 > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". >=20 > The poll ends eob March 5th 2001. >=20 > /Loa > -- >=20 >=20 > 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 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From gregimirsky@gmail.com Wed Feb 17 12:57:45 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 4BCCA28C14A; Wed, 17 Feb 2010 12:57:45 -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 RFUhFB12iFgM; Wed, 17 Feb 2010 12:57:44 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 59D633A7BED; Wed, 17 Feb 2010 12:57:43 -0800 (PST) Received: by fxm7 with SMTP id 7so9269435fxm.28 for ; Wed, 17 Feb 2010 12:59:18 -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=E9KOtCUMwnU/9vt7zUvgsMGXsRkSIzTlP3tS+8QheEA=; b=fE4JgG9yduekCxrXOBI7FfderTOXaMSXrLRv6x8UsYXZrOmueiQvWShTkYE8oO2wA9 DagO1P/Qac1PjLK9YO2IiuaxchycmgXg0+16OFJR/kM5rWSbG4E30sFGc7aRQ1hLiktQ S4+eS9EemkY63hXpdHAgDTMINqlNWixYBb6eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qtkeDcURC2F9VrfYhUMutADgd5mKSEXBE6lqwDNw9Z+Xa2Wgx2zf1zsCs6CMW5PUcT JWGuzDMsZgnxmBZjztVtVc2LWDEVRMUc8Bq0MakDjqJO1K+Ca0rkphn4yx36Q9zzQ1WT tjYrKpCRcHX3ynD0jySnVVpu5KcowGkJg/Zs8= MIME-Version: 1.0 Received: by 10.204.143.130 with SMTP id v2mr5632506bku.7.1266440358309; Wed, 17 Feb 2010 12:59:18 -0800 (PST) Date: Wed, 17 Feb 2010 12:59:18 -0800 Message-ID: <787be2781002171259x1c9a3536k7dafabed3ab99f66@mail.gmail.com> From: Greg Mirsky To: Nitin Bahadur , Rahul Aggarwal , David Ward , "Thomas D. Nadeau" , mpls@ietf.org, mpls-tp@ietf.org, ccamp@ietf.org, pwe3 Content-Type: multipart/alternative; boundary=0015175caa56afb286047fd21f5b Subject: [mpls] Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02 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, 17 Feb 2010 20:57:45 -0000 --0015175caa56afb286047fd21f5b Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, below are my comments to the document: - Abstract - "widely deployed" to replace "widely deployment" - Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH TLVs might be present then ACH TLV Header must be present. The Length of ACH TLV Header may set to zero in no ACH TLVs are actually present in the given packet. Said that I turn to figure 2 that presents LSP Ping packet with ACH format. The ACH TLV Header is not presented in the format even though presence of ACH TLVs is indicated. I think that proper LSP Ping with ACH format will look as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Section 2.3 discusses optional use of Source Address TLV but the sentence "Only 1 source address TLV MUST be present in a LSP-Ping packet." may be interpreted as the Source Address TLV is mandatory. I propose to change "MUST" to "MAY" in the sentence - Figure 3 - same comments regarding ACH TLV Header in the format as for Figure 2 Regards, Greg --0015175caa56afb286047fd21f5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
below are my comments to the document:
  • = Abstract - "widely deployed" to replace "widely deployment&q= uot;
  • Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH = TLVs might be present then ACH TLV Header must be present. The Length of AC= H TLV Header may set to zero in no ACH TLVs are actually present in the giv= en packet. Said that I turn to figure 2 that presents LSP Ping packet with = ACH format. The ACH TLV Header is not presented in the format even though p= resence of ACH TLVs is indicated. I think that proper LSP Ping with ACH for= mat will look as:
       0                           1            =
                2                            3

       0 1 2 3 4 5=
 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+

       |          =
                          MPLS Label stack                                |=

       |                     =
                                                                           =
|

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                            =
  GAL                                           |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|Version|   Reserved    |     LSP-Pin=
g Channel Type     |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                   ACH TLV H=
eader                                  |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                          AC=
H TLVs                                      |

       |          =
                                                                           =
           |
<=
span style=3D"font-family: arial,helvetica,sans-serif;">       +-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |          =
                          LSP-Ping payload                               |<=
/span>
       |                        =
                                                                        |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Section 2= .3 discusses optional use of Source Address TLV but the sentence "Only= 1 source address TLV MUST be present in a LSP-Ping packet." may be in= terpreted as the Source Address TLV is mandatory. I propose to change "= ;MUST" to "MAY" in the sentence
  • Figure 3 - same comments regarding ACH TLV Header in the format as for = Figure 2
Regards,
Greg

--0015175caa56afb286047fd21f5b-- From Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Wed Feb 17 17:54: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 4AE3928C2B6 for ; Wed, 17 Feb 2010 17:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BXsMVg6+mvnW for ; Wed, 17 Feb 2010 17:54:56 -0800 (PST) Received: from mx05.melco.co.jp (mx05.melco.co.jp [192.218.140.145]) by core3.amsl.com (Postfix) with ESMTP id EC14A28C2B5 for ; Wed, 17 Feb 2010 17:54:55 -0800 (PST) Received: from mr05.melco.co.jp (mr05 [133.141.98.165]) by mx05.melco.co.jp (Postfix) with ESMTP id 3C9BD5D414 for ; Thu, 18 Feb 2010 10:56:35 +0900 (JST) Received: from mr05.melco.co.jp (localhost [127.0.0.1]) by mr05.imss (Postfix) with ESMTP id 1402BA989 for ; Thu, 18 Feb 2010 10:56:35 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr05.melco.co.jp (Postfix) with ESMTP id A8446AB5A for ; Thu, 18 Feb 2010 10:56:34 +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 7491431F3EA for ; Thu, 18 Feb 2010 10:56:34 +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 26AD822CBE8 for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: from LeakStopper186 (stopper2.isl.melco.co.jp [10.74.245.36]) by iswall2a.isl.melco.co.jp (Postfix) with SMTP id 0FFC422CBD4 for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: (qmail 25653 invoked by uid 507); 18 Feb 2010 10:56:33 +0900 Received: from unknown (HELO mob2501.isl.melco.co.jp) (133.141.13.135) by 0 with SMTP; 18 Feb 2010 10:51:35 +0900 Received: from KF5ZXSFDNOKJ9H8 (unknown [10.62.216.183]) by mob2501.isl.melco.co.jp (Postfix) with ESMTP id D2B9421D8148; Thu, 18 Feb 2010 10:51:34 +0900 (JST) From: "Shoichiro Seno" To: , , , Date: Thu, 18 Feb 2010 10:51:38 +0900 Message-ID: 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: AcqwPOiWRafWxv+2Q/6NVNU13BvRMA== Subject: [mpls] iPOP 2010 submission deadline extended to March 1 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, 18 Feb 2010 01:54:57 -0000 CCAMP, MPLS, MPLS-TP and PCE subscribers, Please find below iPOP 2010 CFP with the extended deadline. Sorry for multiple messages. Sho Seno ----------------------------------------------------------------------- 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: March 1, 2010 (extended) 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 ---------------------------------------------------------------------------- ---- From nitinb@juniper.net Wed Feb 17 23:29: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 6668028C10D; Wed, 17 Feb 2010 23:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 80FCaRE+OjGb; Wed, 17 Feb 2010 23:29:36 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id DFB363A7DD2; Wed, 17 Feb 2010 23:29:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS3zswraBGjj9lUI4zD1n49hbm1j7mmv+@postini.com; Wed, 17 Feb 2010 23:31:18 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, 17 Feb 2010 23:28:45 -0800 From: Nitin Bahadur To: Greg Mirsky , Rahul Aggarwal , David Ward , "Thomas D. Nadeau" , "mpls@ietf.org" , "mpls-tp@ietf.org" , "ccamp@ietf.org" , pwe3 Date: Wed, 17 Feb 2010 23:28:42 -0800 Thread-Topic: Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02 Thread-Index: AcqwFBO+zMuQ18V2SDiRtp4XiQfBkAAV+tHV Message-ID: In-Reply-To: <787be2781002171259x1c9a3536k7dafabed3ab99f66@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02 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, 18 Feb 2010 07:29:37 -0000 Hi Greg, Thanks for reading the draft in detail. See inline below for responses t= o your comments. On 2/17/10 12:59 PM, "Greg Mirsky" wrote: Dear Authors and All, below are my comments to the document: * Abstract - "widely deployed" to replace "widely deployment" NB> Will fix that. * Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH TLVs mig= ht be present then ACH TLV Header must be present. The Length of ACH TLV He= ader may set to zero in no ACH TLVs are actually present in the given packe= t. Said that I turn to figure 2 that presents LSP Ping packet with ACH form= at. The ACH TLV Header is not presented in the format even though presence = of ACH TLVs is indicated. I think that proper LSP Ping with ACH format will= look as: 0 1 2 = 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLVs = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NB> You are right. I will fix that. * Section 2.3 discusses optional use of Source Address TLV but the sente= nce "Only 1 source address TLV MUST be present in a LSP-Ping packet." may b= e interpreted as the Source Address TLV is mandatory. I propose to change "= MUST" to "MAY" in the sentence NB> Sure...will rephrase to avoid confusion. * Figure 3 - same comments regarding ACH TLV Header in the format as for= Figure 2 NB> Will fix. Thanks for your useful comments Greg. Nitin From Alexander.Vainshtein@ecitele.com Thu Feb 18 04:21: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 A772C3A7CA6; Thu, 18 Feb 2010 04:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 huUKnQ3TE553; Thu, 18 Feb 2010 04:21:51 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id B72983A7C8D; Thu, 18 Feb 2010 04:21:50 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-50-4b7d2fb2036b Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 8E.7C.18464.2BF2D7B4; Thu, 18 Feb 2010 14:16:50 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Feb 2010 14:23:27 +0200 From: Alexander Vainshtein To: "lberger@labn.net" , "lieven.levrau@alcatel-lucent.com" , "danfrost@cisco.com" , "stbryant@cisco.com" , "matthew.bocci@alcatel-lucent.com" Date: Thu, 18 Feb 2010 14:23:26 +0200 Thread-Topic: LC comments on sections 3.4.2 and 3.4.3 of draft-ietf-mpls-tp-framework-10 Thread-Index: AcqwlSvfo2BejOrqTGS/Hy3AV6LdfA== Message-ID: 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 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [mpls] LC comments on sections 3.4.2 and 3.4.3 of draft-ietf-mpls-tp-framework-10 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, 18 Feb 2010 12:21:52 -0000 Hi all, I have a couple of LC comments/questions on Sections 3.4.2 and 3.4.3 of the= draft. Figure 8 in Section 3.4.2 describes format of several types of MPLS-TP pack= ets: +-------------------+ /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D\ /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ | Client Layer | H OAM PDU H H OAM PDU H /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ H---------= ----------H H-------------------H H PW Encap H H GACh H H GACh H H-------------------H H-------------------H H-------------------H H PW Demux (S=3D1) H H PW Demux (S=3D1) H H GAL (S=3D1) = H H-------------------H H-------------------H H-------------------H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ \=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ \=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ | Server Layer | | Server Layer | | Server Layer | +-------------------+ +-------------------+ +-------------------+ User Traffic PW OAM LSP OAM I assume that in this diagram the "LSP demux" label is terminated by the bo= x that=20 looks at PW demux and/or GAL, i.e., its corresponding entry in the ILM is v= alid and contains the following NHLFE: - Next Hop: this box (i.e., its loopback interface) - Label stack action: Pop. This works just fine with the user traffic and PW OAM packets, because diff= erentiation Between user traffic and OAM packets is not based on any labels. However, the LSP OAM packet will be recognized as such only by looking at G= AL after=20 the LSP demux label has been popped. RFC 3031 states in Section 3.9: Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present. It is not clear to me how can an RFC 3031-compliant LSR refer an LSP OAM packet to a specific LSP without violating this rule. One way to assure it would be by encoding the LSP identifier in the body of each OAM packet; if, as I suspect, this is the only way, it should be explicitly mentioned both in this draft and in the MPLS-TP OAM framework. Similar problem exists with proposed usage of Service LSP demux labels that are introduced in Section 3.4.3 for carrying IP and its "helper" non-IP protocols (e.g., IS-IS) over MPLS-TP LSPs, see Figure 10: /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D\ H OAM PDU H +-------------------+ H-------------------H /=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ | Client Layer | H GACh H H OAM PDU H /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ H---------= ----------H H-------------------H H Encap Label H H GAL (S=3D1) H H GACh H H-------------------H H-------------------H H-------------------H H SvcLSP Demux H H SvcLSP Demux (S=3D0)H H GAL (S=3D1) = H H-------------------H H-------------------H H-------------------H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ \=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ \=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ | Server Layer | | Server Layer | | Server Layer | +-------------------+ +-------------------+ +-------------------+ User Traffic Service LSP OAM LSP OAM This situation is worse, IMHO, because the box that terminates the LSP demu= x Label should be able to treat it as a "context label" that defines a common= context for IP and its helper protocols distinguished by their appropriate service LSP dem= ux labels... The method proposed for OAM packets will not help here. One possibility to = resolve this problem would be by assigning a set of Service Demux labels in a way that p= reserves their common context regardless of being received in the same LSP (i.e., pl= ace it beyond MPLS-TP proper)... One generic way out of the problems could be by using only upstream-allocat= ed labels in MPLS-TP. Upstream-allocated labels are not subject to restriction= s defined in RFC 3031, and RFC 5331 explicitly introduces "context labels" with upstream allocatio= n (at least, in certain specific situations). However, the scale on which con= text labels=20 would be used in MPLS-TP goes far beyond what has been envisioned in RFC 53= 31.=20 It is not clear to me how well this approach scales up. Hopefully, these notes will be useful. Regards, Sasha From Martin.Vigoureux@alcatel-lucent.com Thu Feb 18 05:45: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 DF48028C209 for ; Thu, 18 Feb 2010 05:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=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 gqmkzq4IOORA for ; Thu, 18 Feb 2010 05:45:36 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CE1BB28C202 for ; Thu, 18 Feb 2010 05:45:35 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1IDkkmD032188; Thu, 18 Feb 2010 14:46:54 +0100 Received: from [172.27.213.25] ([172.27.213.25]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 14:46:48 +0100 Message-ID: <4B7D44C8.7040605@alcatel-lucent.com> Date: Thu, 18 Feb 2010 14:46:48 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2010 13:46:48.0641 (UTC) FILETIME=[D14FE310:01CAB0A0] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [mpls] Presentation slot requests for MPLS WG sessions in Anaheim (IETF 77th) 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, 18 Feb 2010 13:45:37 -0000 all, in preparation of the IETF 77th MPLS WG sessions could you please send me propositions for presentations. These cover mpls and mpls-tp. We have requested two slots (still to be confirmed) and will synchronize with PWE3 and CCAMP WGs for the mpls-tp presentations. Thank you. martin From root@core3.amsl.com Thu Feb 18 06: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 2DAA33A72CD; Thu, 18 Feb 2010 06: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: <20100218144502.2DAA33A72CD@core3.amsl.com> Date: Thu, 18 Feb 2010 06:45:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-requirements-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: Thu, 18 Feb 2010 14: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 : Requirements for OAM in MPLS Transport Networks Author(s) : M. Vigoureux, et al. Filename : draft-ietf-mpls-tp-oam-requirements-05.txt Pages : 17 Date : 2010-02-18 This document lists architectural and functional requirements for the Operations, Administration and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-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-oam-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-18063356.I-D@ietf.org> --NextPart-- From dieter.beller@alcatel-lucent.com Fri Feb 19 06:21: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 5E8F23A7F6D; Fri, 19 Feb 2010 06:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 Ue0Fs8DcXHLq; Fri, 19 Feb 2010 06:21:09 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C6D4F3A7DE7; Fri, 19 Feb 2010 06:21:08 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1JEMrEq018443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Feb 2010 15:22:53 +0100 Received: from [135.244.182.16] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 19 Feb 2010 15:22:52 +0100 Message-ID: <4B7E9EBB.5080102@alcatel-lucent.com> Date: Fri, 19 Feb 2010 15:22:51 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , ITU-T ad hoc team on MPLS-TP Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [mpls] Early version of revised ITU-T Recommendation G.7712 including 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: Fri, 19 Feb 2010 14:21:11 -0000 Dear colleagues,

Please find below  an early version of revised ITU-T Recommendation G.7712
(in “word” and “pdf”), which updates SCN and MSN aspects based on recently
published IETF RFCs for MPLS-TP and describes the associated MPLS-TP atomic
functions.

http://ifa.itu.int/t/2009/sg15/ahmpls-tp/documents/wdxx_editor_G7712-revised_v0.2.pdf

http://ifa.itu.int/t/2009/sg15/ahmpls-tp/documents/wdxx_editor_G7712-revised_v0.2.doc

The alignment is not complete yet as indicated by several editor's notes,
but the intention is that the experts can start providing comments and
discussing specific MPLS-TP related topics on the mailing lists of the two
organizations before the revised MPLS-TP sections and new MPLS-TP
related amendments will be presented and discussed at the Stockholm
interim meeting in April dedicated to MPLS-TP.


In case you do not have permissions yet to access the documents, please
go to the following web site and follow the instructions in section 6:

http://www.itu.int/ITU-T/studygroups/com15/ahmpls-tp/


Regards,
Dieter
--
From sboutros@cisco.com Fri Feb 19 11:24: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 C8FF53A7CCD; Fri, 19 Feb 2010 11:24:22 -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 CmLwQK24rPSs; Fri, 19 Feb 2010 11:24:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C884F3A72CE; Fri, 19 Feb 2010 11:24:21 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAFt0fkurR7Hu/2dsb2JhbACGJ5Ric6U1l20ChGUEgxU X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="300962444" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2010 19:26:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1JJQ9t4026134; Fri, 19 Feb 2010 19:26:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:26:09 -0800 Received: from sboutros-wxp02.ciswco.com ([10.21.95.24]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:26:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Feb 2010 11:16:50 -0800 To: Loa Andersson , "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org From: Sami Boutros In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2010 19:26:09.0075 (UTC) FILETIME=[637D5030:01CAB199] Subject: Re: [mpls] [PWE3] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 19 Feb 2010 19:24:23 -0000 yes/support. At 11:30 AM 2/17/2010, Loa Andersson wrote: >All, > > >this is to start a two week working group poll on making >draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt >an mpls working group document. > >Send your response to the mpls-tp@ietf.org mailing list >(only), indicating "yes/support" or "no/do not support". > >The poll ends eob March 5th 2001. > >/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 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From pratiravi@gmail.com Fri Feb 19 14:09:19 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 0C5A03A7B89; Fri, 19 Feb 2010 14:09:19 -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 2INItBwgAKzk; Fri, 19 Feb 2010 14:09:18 -0800 (PST) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id 13C403A7B77; Fri, 19 Feb 2010 14:09:17 -0800 (PST) Received: by qyk8 with SMTP id 8so325340qyk.14 for ; Fri, 19 Feb 2010 14:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=rpZrpEauFP3UN8PbG7StXjDj+AJAZKzjElqTrQ9DDms=; b=gUDAD1Et/yZzdKbPkWbnb5cqtGYJ/aqmukL8J0IrUfWjG7JuwmdgZi7aYMpKeL5rYo JveUgdE8gXTIfWbDYfDdV9LQ9kAVFVKfFv64gcqjIEsRWl2MX49aUS3aQx9XuyBZIYH7 /WDM3OumFWLfqPMLqxvAdT10Aym5iodUOu5YY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LX0ZnB95XDz3EzzrkXSyfT4P2+bOaCLB+YPT983E4wZW4wQdt9dlsyBa5YMSb6eySV s++hwjSBXWwOnoabzQ1UhRF6aF09AOA0QG62O1aPYAcTJUfeagfFvXkQCeuNtavTL1FQ KH4EK9Uu/r47nHrxvNNOLO8iNJ0jojB2waPRs= Received: by 10.224.95.202 with SMTP id e10mr3865909qan.171.1266617463001; Fri, 19 Feb 2010 14:11:03 -0800 (PST) Received: from ?192.168.1.106? (c-24-218-22-68.hsd1.nh.comcast.net [24.218.22.68]) by mx.google.com with ESMTPS id 5sm1806110qwg.8.2010.02.19.14.11.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 14:11:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Raveendra Torvi In-Reply-To: <4B7C43CF.3070700@pi.nu> Date: Fri, 19 Feb 2010 17:10:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D49AC93-6FD6-4E7A-BCF5-6204C60A1166@gmail.com> References: <4B7C43CF.3070700@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1077) Cc: mpls@ietf.org, CCAMP WG , pwe3@ietf.org Subject: Re: [mpls] [mpls-tp] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 19 Feb 2010 22:09:19 -0000 Could we keep P2MP ping-bfd procedures outside the scope of this = document, until the mpls-tp-p2mp-framework and mp-bfd are well defined?=20= -Ravi. On Feb 17, 2010, at 2:30 PM, Loa Andersson wrote: > All, >=20 >=20 > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. >=20 > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". >=20 > The poll ends eob March 5th 2001. >=20 > /Loa > --=20 >=20 >=20 > 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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lucyyong@huawei.com Fri Feb 19 15:31:51 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 1F5153A7BF9; Fri, 19 Feb 2010 15:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[AWL=0.008, 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 CTvy0R-ZsI7C; Fri, 19 Feb 2010 15:31:50 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 41EA33A7A59; Fri, 19 Feb 2010 15:31:50 -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 <0KY4005OR43RJB@szxga02-in.huawei.com>; Sat, 20 Feb 2010 07:33:28 +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 <0KY400KYY43RV8@szxga02-in.huawei.com>; Sat, 20 Feb 2010 07:33:27 +0800 (CST) Received: from y736742 ([10.124.12.122]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY4009RH43PUQ@szxml04-in.huawei.com>; Sat, 20 Feb 2010 07:33:27 +0800 (CST) Date: Fri, 19 Feb 2010 17:33:24 -0600 From: Yong Lucy To: pwe3@ietf.org, mpls@ietf.org Message-id: <00d101cab1bb$ef7d2fc0$7a0c7c0a@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_Hi46qKZXNIkrzYwXryxNYQ)" Thread-index: Acqxu+34QNIl0DznR5uY7kxpsq96Ew== Cc: 'Peilin Yang' Subject: [mpls] draft-yong-pwe3-enhance-ecmp-lfat-01.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, 19 Feb 2010 23:31:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Hi46qKZXNIkrzYwXryxNYQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT WG, We have published draft-ietf-pwe3-enhance-ecmp-lfat-01.txt. It proposes an enhanced ECMP method that performs differentiated treatments on small and large flows and large/small flow indication on PW flow label. The method significantly improves hash based load balance. E-mail commons are welcome prior to IETF77 meeting. Thanks, Lucy Yong --Boundary_(ID_Hi46qKZXNIkrzYwXryxNYQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

WG,

 

We have published draft-ietf-pwe3-enhance-ecmp-lfat-01.txt. It proposes an enhanced ECMP method that performs differentiated treatments on small and large flows and large/small flow indication on PW flow label. The method significantly improves hash based load balance.

 

E-mail commons are welcome prior to IETF77 meeting.

 

Thanks,

Lucy Yong

 

 

--Boundary_(ID_Hi46qKZXNIkrzYwXryxNYQ)-- From mach@huawei.com Fri Feb 19 18:47: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 8689B28C11C; Fri, 19 Feb 2010 18:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 8EhsGG5ZCa3m; Fri, 19 Feb 2010 18:47:31 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5C4BA28C0F3; Fri, 19 Feb 2010 18:47:31 -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 <0KY400J4FD5X4A@szxga02-in.huawei.com>; Sat, 20 Feb 2010 10:49:09 +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 <0KY400DO1D5WL7@szxga02-in.huawei.com>; Sat, 20 Feb 2010 10:49:09 +0800 (CST) Date: Sat, 20 Feb 2010 10:49:08 +0800 From: Mach Chen In-reply-to: To: Nitin Bahadur , Mach Chen , 'George Swallow' Message-id: <6D475EECD626479495D08B7CD1DE8384@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=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: Cc: mpls@ietf.org, So Ning , Simon.A.DeLord@team.telstra.com, mpls-tp@ietf.org Subject: Re: [mpls] Comments for 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: Sat, 20 Feb 2010 02:47:32 -0000 Hi Nitin, Thanks for your comments and sorry for the delayed response! Please see my reply inline... -------------------------------------------------- From: "Nitin Bahadur" Sent: Friday, February 12, 2010 4:29 PM To: "Mach Chen" ; "'George Swallow'" Cc: ; ; "So Ning" ; ; Subject: Re: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > Hi Mach, > > I'm splitting my replies into multiple emails to address topics > separately. > >>>> There are two issues that our draft tries to resolve: >>>> 1. Current LSP Ping mechanisms are lack of the capability of specifying >>>> the return path >>>> of an echo reply, hence some time it may bring difficuties in faults >>>> localization. >>> >>> NB> This is only a problem for uni-directional LSPs. Also, the problem >>> only exists >>> if the LSP forward path is UP and the reverse IP path is down. If the >>> forward LSP path >>> is DOWN, then lsp traceroute should help in fault localization. >> >> There are several conditions that may lead to problems, not just only the >> reverse IP path is down. The return path of the echo reply could be >> either >> IP or LSP path that depends on the local routing policy. >> >> And the LSP traceroute may not help in fault localization sometimes, take >> a >> simple topology(A--B--C--D) for example, there is an LSP from A to D and >> maybe an LSP from D to A, no matter what the failure is at the hop >> between C >> and D or at the reverse path or at D, there will no different in the >> trace >> result(A..B..C). That means the operator can not yet determine whether >> the >> forward LSP is with failure. > > Agreed that with current mechanisms you cannot figure out if a failure is > with the forward path or reverse path. That's a good problem statement to > have. Yes. > > I don't agree with the solution presented. The solution presented makes > the > ingress node have detailed knowledge of FECs originating at the egress and > creates an implicit binding betweens multiple return paths. Actually, no matter what the presented solution exists, when the LSPs established between the egress and the ingress, the ingress node will always have the detailed knowledge of the FECs originating at the egress. The RPS-Ping just uses these information to help in fault localization. > > Instead maybe you can just have a new return mode called "Reply via > alternate path" in which the egress will rely using the non-default path. "Reply via alternate path" is one of the fuctions of RPS-Ping. > If even the non-default path is broken, then you have a problem. In theory, that would happen, but mostly, this will not happen. If both the default and the non-default are broken, that exactly gives the operators more evidence to determine that the return path is broken, and the forward path is workable, more attention need to be paid to the return direction. >I'm not convinced if that problem is worth addressing.... I have met such a situation in a real network where it is desired to determine of which direction is broken, hence to help in fault localization. > > There might be other ways to address the problem statement...my main > intent > is to reduce the coupling between the ingress and egress and reduce > configuration overhead. In RPS-Ping, it does not require to do any extra permanent configuration in advance, it just give more methods to the operators in fault localization. Best regards, Mach > > I see that some operators have been cc'ed on this email. So it would be > good > to get their input on how much complex configuration they want to do on > their mpls boxes to effectively use oam. > > Thanks > Nitin > From mach@huawei.com Sat Feb 20 00:58: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 A0D143A81DD; Sat, 20 Feb 2010 00:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_82=0.6, 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 oDLZhatf56Uh; Sat, 20 Feb 2010 00:58:08 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CD26C3A81DE; Sat, 20 Feb 2010 00:58: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 <0KY400672UBNVL@szxga03-in.huawei.com>; Sat, 20 Feb 2010 16:59:47 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY400IMWUBME8@szxga03-in.huawei.com>; Sat, 20 Feb 2010 16:59:47 +0800 (CST) Date: Sat, 20 Feb 2010 16:59:49 +0800 From: Mach Chen In-reply-to: To: Nitin Bahadur , 'George Swallow' 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: Cc: mpls@ietf.org, So Ning , Simon.A.DeLord@team.telstra.com, mpls-tp@ietf.org Subject: Re: [mpls] Comments for 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: Sat, 20 Feb 2010 08:58:09 -0000 Hi Nitin, Thanks for your comments! Please see my reply inline... -------------------------------------------------- From: "Nitin Bahadur" Sent: Friday, February 12, 2010 5:13 PM To: "Mach Chen" ; "'George Swallow'" Cc: ; ; "So Ning" ; ; Subject: Re: Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > Hi Mach, > >> Since the echo reply will not carry the FEC stack information of the >> reverse >> direction, one LSP-Ping could only complete cv checking of the forward >> direction of the LSP. > > I'm not an RSVP expert, but I believe, for co-routed bi-directional LSPs, > the FEC stack for the reverse direction will be the same. So CV checking > on > the reverse path involves 2 things: > > 1) Ensuring that received echo response is for the echo request sent > 2) Ensuring that echo response is received on the reverse path of the > bi-directional LSP. > > For associated bi-directional LSPs, the ingress node already knows which > egress LSP has been associated with the ingress LSP. So the ingress node > needs to validate: > 1) Received echo response is for the echo request sent > 2) Echo response is received on the egress LSP. > > More details are not needed IMO. > > In echo request, we need the FEC stack to identify the LSP under test (to > catch a case where an OAM packet arrives at an un-intended destination). > Note that regular uni-directional LSPs use PHP and hence FEC determination > cannot be based off a label (since there will be no label received on > egress). > > In echo response, if the packet is dropped, then the receiver (ingress) > will > time out. If the packet is mis-routed, then the receiver (some random > node) > will drop it since it won't be expecting an echo response. Almost agree with your analysis, but the echo request/the echo reply MUST inlcude the FEC Stack of the LSP, hence it could perform CV validations of both directions of the LSP. > > In addition, RFC 4379 specifies, "The FEC Stack TLV from the echo request > MAY be copied to the reply." This has huge implications. This means that > for > bi-directional co-routed LSPs, one can copy the incoming FEC stack TLV (if > one wants to) and for bi-directional associated LSPs, once can insert a > new > FEC stack TLV identifying the reverse path FEC. The ingress has > information > regarding the association, so it can perform any CV validations. Although RFC 4379 has already specified that "The FEC Stack TLV from the echo request MAY be copied to the reply." IMHO, for CV validation of the reverse path, the current specification is not enough, it does not define how to process when the ingress received a echo reply with an FEC Stack TLV. And that "MAY" sometime probably means "may not"! For co-routed bidirectional LSP, since the FEC is the same, that would be OK, but at least need some carification. For associated bidirectional LSP, just copy the FEC Stack TLV from the echo reply does not work, the egress/terminator MUST add a new FEC Stack TLV of the reverse LSP when sending the echo reply. And the ingress/initiator should be able to differentiate the FEC Stack TLV is for forward or reverse LSP. This is one of purposes of the RPS-Ping draft trying to achieve. > > sniped... > >>> Other comments >>> -------------- >>> The draft talks about specifying ways in which ingress could specify how >>> the >>> egress should respond. I fail to see how operators will use this >>> *ability* >>> in >>> the field. How does the operator know which LSP should be used for >>> return-path? >>> If the operator knows this via config, then the same config could be >>> added >>> at >>> LSP egress as well. >> >> The operators could based on their experence and the on-site conditions >> to >> choose the specific LSP for return-path. > > Experience and on-site conditions => complicated NMS systems and more > maintenance windows. OAM should be simple and stupid...otherwise it will > not > be deployable. The RPS solution just adds a new reply mode(Reply via specified return path) to the LSP-Ping, hence to provide more fucntions in LSP testing and fault localization. Compare to other LSP-Ping function, according to the functions it provide, our solution will not increase extra complexity of LSP-Ping and it is deployable. > > >>> If the operator is just going to loop through (in return-path tlv) all >>> the >>> egress >>> initated LSPs hoping for at least 1 successful response, then the scheme >>> is broken. >> >> Loop through all the egress initated LSPs is the worsest situation, and >> for >> most of the time, there will not be too many LSPs. For me this is >> reasonable. Why do you think the scheme is broken? > > It's broken because now the ingress needs to know about all the "egress > initiated LSPs". It's too much coupling. As I said in my other email, all > you need is an alternate way of sending the response. Multiple alternate > ways will not provide you with too much benefit. The cost vs benefit > equation doesn't favor multiple alternate paths. In theory, RPS solution has the capability to loop through all LSPs, if the operators want, it could do that, but it does not mean it should alway be like that. Reply via an alternate is included in the RPS solution. > >>> One should use BFD (or some other mechanism) to ensure that both ingress >>> initiated >>> and egress initiated (uni-directional) LSPs are UP. If a LSP is UP, then >>> the egress >> >> IMO, it's not possible to provision BFD session for every LSP and route, >> it's not scale. > > I happily disagree with that statement. I know more than 1 vendor that has > simplified BFD provisioning for LSPs and routes. > > Scaling yes, every system will have scaling limits. Some boxes will do > better than others. > > If you don't provision BFD for every LSP, then you won't know if a > particular LSP is down and you might black-hole traffic. If you > round-robin > packets of 1 bfd session between multiple LSPs, then you are effectively > (in > forwarding plane) increasing the time interval between packets sent on a > particular LSP....which is the same as multiple BFD sessions (without > additional control plane state). > > Again, as I said, it's my opinion. > >> And if it is only for selection a proper return path to send >> the echo reply, IMHO, provision too many BFD sessions is not >> cost-effective. > >> BTW, from my understanding, normally, the echo reply is always trying to >> follow lsp(it have higher priority the IP path). > > That's your assumption...you can have a box that has different policies > for > different things. There is nothing in the echo rely that specifies that it > must go over a LSP. > >> So, in the RPS draft, we >> define a mechanism to force the echo reply follow pure IP path(at least >> the >> egress uses IP path), hence to verify whether the LSP path is OK. > > I think you just need an alternate path....there is no guarantee that your > IP path won't be the same as the LSP path...so it's no better than an > alternate path. Althouth the IP path and the LSP path may have the same path, but the forwarding process of each is different, and it is possible that IP forwarding is OK, but MPLS is not OK, and vice versa, and this has real happened in a network. sniped... Again, here is the summary of our RPS draft. 1. By extending LSP-Ping enable that the return path of echo reply could be specified/changed on-demand, hence to help in judging whether the forward or reserse LSP is broken. 2. Echo reply is extended(by including the FEC Stack TLV of the return path) to have the capability of testing the revserse path, a bidirectional path checking could finished within a single operation, hence to simplify the operation and increase the efficiency. With this capability, it could also help a lot in inter-damain/AS LSP checking scenario(no need to perform reserve LSP checking from the remote side which belongs to other SPs). Best regards, Mach > Thanks > Nitin > From abhishekv.verma@gmail.com Sun Feb 21 16:00:19 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 16E4E28C20F for ; Sun, 21 Feb 2010 16:00:19 -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 3OToSSTbVG74 for ; Sun, 21 Feb 2010 16:00:18 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1501C28C1FD for ; Sun, 21 Feb 2010 16:00:18 -0800 (PST) Received: by gwb10 with SMTP id 10so332945gwb.31 for ; Sun, 21 Feb 2010 16:02:11 -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=FH81TBt2mxds9GV8czjBE3tXpwxva0J3SNuqCiZZhR8=; b=mtupgES27MdoqnoDqqhjT3aJp3hhcUECfV5/DSXqwTJD4jh0kHId7CSkXwiSUjCgha Y5ULh6LEUGQTPb4IL9nYXBCLF4wNBb6Pf6vxNJeDId9GfIi+g5Y+Xo9XK1duohaY0aTO s3HoZAbnkS9hiq+eeCViklMTyk3gfTUeshkYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j/IYRwb+HldLIh6rcvhyay3LwmgOKglGT56V2F9QI+tDvfs/RvxsU3Uav43DfQYQG1 m5jq44SdggycSdyjbRwLQDn0BZY59yuUlkovNLeSvNw/xagK6kyV/043AWPIKhvSmBdX HCbX7A5QBlMMvqXOGt33HuWDFabWO9RWZZkLk= MIME-Version: 1.0 Received: by 10.100.235.4 with SMTP id i4mr6181762anh.19.1266796930889; Sun, 21 Feb 2010 16:02:10 -0800 (PST) Date: Mon, 22 Feb 2010 05:32:10 +0530 Message-ID: From: Abhishek Verma To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] Question on Link Level LDP 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, 22 Feb 2010 00:00:19 -0000 Hi Experts, I have the following topology: A -- B -- C I am running link level LDP between A, B and C and the session is established. Now, when A wants to communicate with C (say ping), should it send labelled packets or native IPv4? When the box A is IXIA i see that all packets emanating from A towards C are labelled packets. Is this correct? Thanks, Abhishek From lufang@cisco.com Sun Feb 21 19:40: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 2112828C20E; Sun, 21 Feb 2010 19:40:20 -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 dU57PfzmJ4hs; Sun, 21 Feb 2010 19:40:19 -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 99C1928C129; Sun, 21 Feb 2010 19:40:18 -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: AvsEABOMgUtAZnwM/2dsb2JhbACbBHOjcpc2AoRpBIMV X-IronPort-AV: E=Sophos;i="4.49,515,1262563200"; d="scan'208";a="87851430" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2010 03:42:15 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1M3gElQ024909; Mon, 22 Feb 2010 03:42:15 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); Sun, 21 Feb 2010 21:42:14 -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: Sun, 21 Feb 2010 21:42:13 -0600 Message-ID: <238542D917511A45B6B8AA806E875E259FBEAA@XMB-RCD-201.cisco.com> In-Reply-To: <4B7187EE.30404@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqpodIlZoRhCNeZSgSodpS2IOgCRgJzpEXQ References: <4B7187EE.30404@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , , "Adrian Farrel" X-OriginalArrivalTime: 22 Feb 2010 03:42:14.0736 (UTC) FILETIME=[06083D00:01CAB371] Subject: Re: [mpls] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Mon, 22 Feb 2010 03:40:20 -0000 yes/support. Thanks, Luyuan=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 09 February 2010 11:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian Farrel Subject: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /Loa --=20 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From prabhu.ashwin@gmail.com Mon Feb 22 01:20: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 C401528C0E6; Mon, 22 Feb 2010 01:20:44 -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 uRZYLEmMTiVV; Mon, 22 Feb 2010 01:20:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6E9DA28C13D; Mon, 22 Feb 2010 01:20:43 -0800 (PST) Received: by vws20 with SMTP id 20so684206vws.31 for ; Mon, 22 Feb 2010 01:22:38 -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=pYfDIP8MdxXVmaJXr6CopepFyFUO26CcKKi3INKy3Fo=; b=vo8sUcltqBvF1sS79KK81UaWItM4RyMAXDJNL0GqrZtz1pDlj8G4B3S+qnzJQBMsJ/ VqKT9fEmGXgaRpHVnoBW3/W7vOrL30ANuZdmlclIAfEHKCpXFYpo7E08nK9nCubvA6JS p/ZNqu3yv0nJla0eHzC5r/SGMUjY/oQUXmxAE= 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=qKqvfAgxYgwpBubDayftIlm+y9yY3Xz425wUCfmuWWdHVTj0617w7GoNHoE8do3aR7 eTDJlGtufrA3AyT9sMHiA1sAoZEYzrIaGQ4M8N/exkJqB+Jq0yAfW2dvp02ABvstqyxV sisqYD0T5ZuSkGE9tcTRRvN3gbeSO9KCmUJvc= MIME-Version: 1.0 Received: by 10.220.124.24 with SMTP id s24mr7384643vcr.62.1266830557973; Mon, 22 Feb 2010 01:22:37 -0800 (PST) In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Date: Mon, 22 Feb 2010 14:52:37 +0530 Message-ID: <3c33c551002220122u6380c42ep54d26cef9ee5a6a6@mail.gmail.com> From: "Ashwin C. Prabhu" To: Loa Andersson Content-Type: multipart/alternative; boundary=001636ed62f0660bea04802cf98f Cc: mpls@ietf.org, CCAMP WG , pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.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, 22 Feb 2010 09:20:44 -0000 --001636ed62f0660bea04802cf98f Content-Type: text/plain; charset=ISO-8859-1 yes/support On Thu, Feb 18, 2010 at 1:00 AM, Loa Andersson wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001636ed62f0660bea04802cf98f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
yes/support


=A0
On Thu, Feb 18, 2010 at 1:00 AM, Loa Andersson <= span dir=3D"ltr"><loa@pi.nu> = wrote:
All,


this is to start= a two week working group poll on making
draft-nitinb-mpls-tp-lsp-ping-b= fd-procedures-02.txt=20

an mpls working group document.

Send you= r response to the mpl= s-tp@ietf.org mailing list
(only), indicating "yes/support"= ; or "no/do not support".

The poll ends eob March 5th 2001.=20


/Loa
--


Loa Andersson =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strate= gy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
__________________________= _____________________

--001636ed62f0660bea04802cf98f-- From cjeker@diehard.n-r-g.com Mon Feb 22 01:39: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 1B0ED3A82C4 for ; Mon, 22 Feb 2010 01:39:40 -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 bksQTW--vpsm for ; Mon, 22 Feb 2010 01:39:39 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 2ABA73A82C2 for ; Mon, 22 Feb 2010 01:39:38 -0800 (PST) Received: (qmail 25645 invoked by uid 1001); 22 Feb 2010 09:41:35 -0000 Date: Mon, 22 Feb 2010 10:41:35 +0100 From: Claudio Jeker To: mpls@ietf.org Message-ID: <20100222094135.GH7288@diehard.n-r-g.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [mpls] Question on Link Level LDP 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, 22 Feb 2010 09:39:40 -0000 On Mon, Feb 22, 2010 at 05:32:10AM +0530, Abhishek Verma wrote: > Hi Experts, > > I have the following topology: > > A -- B -- C > > I am running link level LDP between A, B and C and the session is > established. Now, when A wants to communicate with C (say ping), > should it send labelled packets or native IPv4? When the box A is IXIA > i see that all packets emanating from A towards C are labelled > packets. Is this correct? > Yes. Even though unlabled traffic would work packets are labelled as soon as there is an LSP available. -- :wq Claudio From bedard.phil@gmail.com Mon Feb 22 08:00: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 0E38128C317 for ; Mon, 22 Feb 2010 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 kgov8Ydz0I8t for ; Mon, 22 Feb 2010 08:00:27 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id C3FEF3A7F6A for ; Mon, 22 Feb 2010 08:00:26 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so623327qwb.31 for ; Mon, 22 Feb 2010 08:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=FZlLIB/vptDhkHG9DFAG21bA5Jrk+vUvLi1j/bbXbSU=; b=KXKnXCwfZejIv9Gr3cd5Hs0NwtAbW8kkZ1/n44cPwzFApYGMq0LYn5xMueYeyQSZZB 0B+22rGwaGwsk5bM6QsVlSH4HK4JLNyAaFkCuCe+SfkTL1SbSgsePTSYEnH8TrfjJtNG 0DznOJS3Ot5QBC87EvCMse3qFH+9ymZ0bm3tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=mA0Zq7Bh2I0tcesGnkBEg0pG2uniEX/X9wQ4+6rIQkWd2Oxag9ddWB3EVdeOtcEe36 HMJknVWANl6t/D29k8EB0O/cOD0MINCab0rq7pOMTxniwGxqJv/eGyYhKrP57Ck01lCY zE18RwUbgSs3+Kdx6WRLkVG5l94VM1QVjizPo= Received: by 10.224.52.88 with SMTP id h24mr561226qag.315.1266854542225; Mon, 22 Feb 2010 08:02:22 -0800 (PST) Received: from ?10.64.30.41? (gw1.cox.com [24.248.74.254]) by mx.google.com with ESMTPS id 5sm5565583qwg.48.2010.02.22.08.02.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 08:02:19 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Phil Bedard Date: Mon, 22 Feb 2010 11:02:17 -0500 To: Abhishek Verma X-Mailer: Apple Mail (2.1077) Cc: mpls@ietf.org Subject: Re: [mpls] Question on Link Level LDP 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, 22 Feb 2010 16:00:29 -0000 It depends on the platform you are using and its configuration. Some = platforms will use an LDP LSP as soon as its available, others by = default prefer native IP paths until you turn on a knob to say use an = MPLS path instead (IGP/BGP shortcuts). =20 Phil=20 On Feb 21, 2010, at 7:02 PM, Abhishek Verma wrote: > Hi Experts, >=20 > I have the following topology: >=20 > A -- B -- C >=20 > I am running link level LDP between A, B and C and the session is > established. Now, when A wants to communicate with C (say ping), > should it send labelled packets or native IPv4? When the box A is IXIA > i see that all packets emanating from A towards C are labelled > packets. Is this correct? >=20 > Thanks, > Abhishek > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From benjamin.niven-jenkins@bt.com Mon Feb 22 08:25: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 A81103A81FC; Mon, 22 Feb 2010 08:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJrsjlljakYR; Mon, 22 Feb 2010 08:25:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id A735E3A7C92; Mon, 22 Feb 2010 08:25:48 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 22 Feb 2010 16:27:47 +0000 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.9]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 22 Feb 2010 16:27:47 +0000 From: To: , Date: Mon, 22 Feb 2010 16:27:44 +0000 Thread-Topic: [mpls-tp] [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acqra3U/jbz8EGtcQKK9K8wU9xlWpQIcIDBW Message-ID: In-Reply-To: <787be2781002111441u2d4ed86bic1af17ca1caf18d@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB 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] Comments for 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: Mon, 22 Feb 2010 16:25:49 -0000 On 11/02/2010 22:41, "Greg Mirsky" wrote: > Dear Nitin, > I agree on your perspective regarding co-routed bi-directional LSP. As it= was > intentionally built with fate sharing between ingress/egress directions I > don't see why operator will need to specify return path other than opposi= te > direction of LSP under examination. > Troubleshooting bi-directional associated connection might have different > requirements. (Wish we have someone from operators community to speak her= e). > As directions, in general case, are diversly routed, so I see value in > specifying return path. It is logical to name opposite direction of assoc= iated > connection as default return path but explicit, one-time overwrite seems = to > have value. IMO the opposite direction of the associated bidirectional LSP should be used by default. I can't think of an application for overwriting it off the top of my head, but that's not to say one doesn't exist. Ben From tnadeau@lucidvision.com Mon Feb 22 09:16:35 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 CD42B28C335; Mon, 22 Feb 2010 09:16:35 -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 v2-QvgLYCk1R; Mon, 22 Feb 2010 09:16:34 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 4005528C170; Mon, 22 Feb 2010 09:16:34 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 0884B43C2901; Mon, 22 Feb 2010 12:18:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Mon, 22 Feb 2010 12:18:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <35FEA04E-49A5-4940-8886-9B4DF468BBF6@lucidvision.com> References: To: X-Mailer: Apple Mail (2.1077) Cc: mpls-tp@ietf.org, mpls@ietf.org Subject: Re: [mpls] [mpls-tp] Comments for 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: Mon, 22 Feb 2010 17:16:36 -0000 Without specifying, you cannot tell if the forward or reverse = LSP is broken. These are specified in RFC4378 already: [RFC4379] states that the third mode may be used when the IP return path is deemed unreliable. This mode of operation requires that all intermediate nodes must support the Router Alert option and must understand and know how to forward MPLS echo replies. The thing that puzzles me about this draft is that seems to be = finding "more reliable" return paths than even "unreliable" ones: And in any case, the use modes 2 or 3 cannot guarantee the delivery of echo responses through an IP network that is fundamentally unreliable. The failure to deliver echo response messages can lead to false negatives making it appear that the LSP has failed. --Tom > On 11/02/2010 22:41, "Greg Mirsky" wrote: >=20 >> Dear Nitin, >> I agree on your perspective regarding co-routed bi-directional LSP. = As it was >> intentionally built with fate sharing between ingress/egress = directions I >> don't see why operator will need to specify return path other than = opposite >> direction of LSP under examination. >> Troubleshooting bi-directional associated connection might have = different >> requirements. (Wish we have someone from operators community to speak = here). >> As directions, in general case, are diversly routed, so I see value = in >> specifying return path. It is logical to name opposite direction of = associated >> connection as default return path but explicit, one-time overwrite = seems to >> have value. >=20 > IMO the opposite direction of the associated bidirectional LSP should = be > used by default. >=20 > I can't think of an application for overwriting it off the top of my = head, > but that's not to say one doesn't exist. >=20 > Ben >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From vishwas.ietf@gmail.com Mon Feb 22 09:31: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 7F0CB28C181; Mon, 22 Feb 2010 09:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.164, 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 JUmeGgNduzOQ; Mon, 22 Feb 2010 09:31:49 -0800 (PST) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id A9F6F28C180; Mon, 22 Feb 2010 09:31:48 -0800 (PST) Received: by gxk9 with SMTP id 9so3347908gxk.8 for ; Mon, 22 Feb 2010 09:33:43 -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=fMzC4QhfErRkIh+HZYd3L6OMPcdmXjIa49Y3ROsVF/4=; b=abLV0/kp1WpYIc1MaTtd6VF50EMjAsLAvpiaLA5CZaRv3+WkJUC3kZdsch5utjFHBf OMsO2xUpl8UU07efWEyPASYCOUDYe/hbCN2toc9nO1y9aZA1rpM6YQJVeWEq+P76KE4Z 6w9HQEuMbq1Lj3QuDjCy39BqPttyjTjt1PP80= 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=jPk8gYZAvfFf7/RMZrJti5UPlJ9et4PElMzplwyHRVxgDNyoc3hLhEGUGuXjzWb54p aaKaZ5U93mcbbZazKcadw9HFmbfo/D6FRiVuRg1vKH17Mt19oGiYm6tiM3emcZ73kVLv La0LHU6LoFP4uSgSRknBP/5wSi8uZtIKAHGgU= MIME-Version: 1.0 Received: by 10.150.213.11 with SMTP id l11mr3201836ybg.324.1266860023628; Mon, 22 Feb 2010 09:33:43 -0800 (PST) In-Reply-To: <35FEA04E-49A5-4940-8886-9B4DF468BBF6@lucidvision.com> References: <35FEA04E-49A5-4940-8886-9B4DF468BBF6@lucidvision.com> Date: Mon, 22 Feb 2010 09:33:43 -0800 Message-ID: <77ead0ec1002220933p466f1c5cie9a11f9669d1aa35@mail.gmail.com> From: Vishwas Manral To: Thomas Nadeau Content-Type: multipart/alternative; boundary=000e0cd37a54b044fe048033d51a Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Comments for 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: Mon, 22 Feb 2010 17:31:50 -0000 --000e0cd37a54b044fe048033d51a Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Maybe the word "more reliable" is a misnomer. It should probably be alternate paths. Thanks, Vishwas On Mon, Feb 22, 2010 at 9:18 AM, Thomas Nadeau wrote: > > Without specifying, you cannot tell if the forward or reverse LSP is > broken. These are specified in RFC4378 already: > > [RFC4379] states that the third mode may be used when the IP return > path is deemed unreliable. This mode of operation requires that all > intermediate nodes must support the Router Alert option and must > understand and know how to forward MPLS echo replies. > > The thing that puzzles me about this draft is that seems to be > finding "more reliable" return paths than even "unreliable" ones: > > And in any case, the use modes 2 or 3 cannot guarantee the delivery > of echo responses through an IP network that is fundamentally > unreliable. The failure to deliver echo response messages can lead > to false negatives making it appear that the LSP has failed. > > --Tom > > > > On 11/02/2010 22:41, "Greg Mirsky" wrote: > > > >> Dear Nitin, > >> I agree on your perspective regarding co-routed bi-directional LSP. As > it was > >> intentionally built with fate sharing between ingress/egress directions > I > >> don't see why operator will need to specify return path other than > opposite > >> direction of LSP under examination. > >> Troubleshooting bi-directional associated connection might have > different > >> requirements. (Wish we have someone from operators community to speak > here). > >> As directions, in general case, are diversly routed, so I see value in > >> specifying return path. It is logical to name opposite direction of > associated > >> connection as default return path but explicit, one-time overwrite seems > to > >> have value. > > > > IMO the opposite direction of the associated bidirectional LSP should be > > used by default. > > > > I can't think of an application for overwriting it off the top of my > head, > > but that's not to say one doesn't exist. > > > > Ben > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --000e0cd37a54b044fe048033d51a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,
=A0
Maybe the word "more reliable" is a misnomer. It should prob= ably be alternate paths.
=A0
Thanks,
Vishwas
On Mon, Feb 22, 2010 at 9:18 AM, Thomas Nadeau <= span dir=3D"ltr"><tnadeau@luc= idvision.com> wrote:

=A0 =A0 =A0 =A0Without speci= fying, you cannot tell if the forward or reverse LSP is broken. =A0These ar= e specified in =A0RFC4378 already:

=A0 [RFC4379] states that the third mode may be used when the IP return=
=A0 path is deemed unreliable. This mode of operation requires that all=
=A0 intermediate nodes must support the Router Alert option and must=A0 understand and know how to forward MPLS echo replies.

=A0 =A0 =A0 =A0The thing that puzzles me about this draft is that seems= to be finding "more reliable" return paths than even "unrel= iable" ones:

=A0 And in any case, the use modes 2 or 3 cannot g= uarantee the delivery
=A0 of echo responses through an IP network that is fundamentally
=A0 un= reliable. The failure to deliver echo response messages can lead
=A0 to = false negatives making it appear that the LSP has failed.

=A0 =A0 = =A0 =A0--Tom


> On 11/02/2010 22:41, "Greg Mirsky"= <gregimirsky@gmail.com>= wrote:
>
>> Dear Nitin,
>> I agree on your perspec= tive regarding co-routed bi-directional LSP. As it was
>> intentionally built with fate sharing between ingress/egress direc= tions I
>> don't see why operator will need to specify return = path other than opposite
>> direction of LSP under examination. >> Troubleshooting bi-directional associated connection might have di= fferent
>> requirements. (Wish we have someone from operators comm= unity to speak here).
>> As directions, in general case, are diver= sly routed, so I see value in
>> specifying return path. It is logical to name opposite direction o= f associated
>> connection as default return path but explicit, on= e-time overwrite seems to
>> have value.
>
> IMO the o= pposite direction of the associated bidirectional LSP should be
> used by default.
>
> I can't think of an application f= or overwriting it off the top of my head,
> but that's not to say= one doesn't exist.
>
> Ben
>
> _______________= ________________________________
> mpls mailing list
> mpls@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/mpls
>

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

--000e0cd37a54b044fe048033d51a-- From root@core3.amsl.com Mon Feb 22 10: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 E896628C2E8; Mon, 22 Feb 2010 10: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: <20100222183001.E896628C2E8@core3.amsl.com> Date: Mon, 22 Feb 2010 10:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-framework-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, 22 Feb 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 : MPLS-TP Network Management Framework Author(s) : S. Mansfield, et al. Filename : draft-ietf-mpls-tp-nm-framework-05.txt Pages : 19 Date : 2010-02-22 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.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-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-nm-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-22102306.I-D@ietf.org> --NextPart-- From loa@pi.nu Mon Feb 22 11:25: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 AD16A3A7D1B; Mon, 22 Feb 2010 11:25:56 -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 jQynRSejkYCI; Mon, 22 Feb 2010 11:25:56 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DFC183A832B; Mon, 22 Feb 2010 11:25:55 -0800 (PST) Received: from [109.58.58.181] (109.58.58.181.bredband.tre.se [109.58.58.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 85815D4052; Mon, 22 Feb 2010 20:27:51 +0100 (CET) Message-ID: <4B82DABF.1070504@pi.nu> Date: Mon, 22 Feb 2010 20:27:59 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] clarification on poll to accept lsp-ping/bfd draft(s) as working group document(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, 22 Feb 2010 19:25:56 -0000 Working Group(s) Two drafts are being progressed in the MPLS Working Group now: draft-nitinb-mpls-tp-lsp-ping-bfd-procedures and draft-asm-mpls-tp-bfd-cc-cv This note is intended to clarify the relationship between these drafts. Draft-nintinb addresses the problem of running BFD as it is currently defined for MPLS, this obviously has aspects that are relevant to packet transport networks. Draft-asm is intended to meet all the requirements in the MPLS-TP OAM Requirements. It turns out that the two drafts are closer than we earlier anticipated and there is a bit of overlap. This will not stop us from progressing both drafts, but it introduces a new need for coordination between the two author teams. /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 mach@huawei.com Wed Feb 24 01:17:07 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 AA5633A7D94; Wed, 24 Feb 2010 01:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.083, 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 waYpLsTunaph; Wed, 24 Feb 2010 01:17:06 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4DC833A7FB0; Wed, 24 Feb 2010 01:17:06 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYC0039O9U4VJ@szxga01-in.huawei.com>; Wed, 24 Feb 2010 17:18:05 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYC002I59U2OB@szxga01-in.huawei.com>; Wed, 24 Feb 2010 17:18:04 +0800 (CST) Date: Wed, 24 Feb 2010 17:18:02 +0800 From: Mach Chen In-reply-to: To: benjamin.niven-jenkins@bt.com, gregimirsky@gmail.com, nitinb@juniper.net 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: Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Comments for 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: Wed, 24 Feb 2010 09:17:07 -0000 Hi Ben, -------------------------------------------------- From: Sent: Tuesday, February 23, 2010 12:27 AM To: ; Cc: ; Subject: Re: [mpls-tp] [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > On 11/02/2010 22:41, "Greg Mirsky" wrote: > >> Dear Nitin, >> I agree on your perspective regarding co-routed bi-directional LSP. As it >> was >> intentionally built with fate sharing between ingress/egress directions I >> don't see why operator will need to specify return path other than >> opposite >> direction of LSP under examination. >> Troubleshooting bi-directional associated connection might have different >> requirements. (Wish we have someone from operators community to speak >> here). >> As directions, in general case, are diversly routed, so I see value in >> specifying return path. It is logical to name opposite direction of >> associated >> connection as default return path but explicit, one-time overwrite seems >> to >> have value. > > IMO the opposite direction of the associated bidirectional LSP should be > used by default. > > I can't think of an application for overwriting it off the top of my head, > but that's not to say one doesn't exist. How about when the default return path is suspected broken, overwriting may help in judging whether the return path is borken or not. By the way, with this return path specified capability, it may be used to setup an associated bidirectional LSP. > > Ben > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From mach@huawei.com Wed Feb 24 01:53: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 5B3CE3A7B89; Wed, 24 Feb 2010 01:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.074, 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 sM-FrgNHTb9S; Wed, 24 Feb 2010 01:53:21 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4E5673A70E2; Wed, 24 Feb 2010 01:53:21 -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 <0KYC008MDBGYJX@szxga04-in.huawei.com>; Wed, 24 Feb 2010 17:53:23 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYC00DRZBGUAD@szxga04-in.huawei.com>; Wed, 24 Feb 2010 17:53:21 +0800 (CST) Date: Wed, 24 Feb 2010 17:53:17 +0800 From: Mach Chen In-reply-to: <35FEA04E-49A5-4940-8886-9B4DF468BBF6@lucidvision.com> To: Thomas Nadeau , benjamin.niven-jenkins@bt.com Message-id: <3EC9A0F02A604A2EB1BC066993AFB7BC@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=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <35FEA04E-49A5-4940-8886-9B4DF468BBF6@lucidvision.com> Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Comments fordraft-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: Wed, 24 Feb 2010 09:53:22 -0000 Hi Ben, Thanks for your comments! -------------------------------------------------- From: "Thomas Nadeau" Sent: Tuesday, February 23, 2010 1:18 AM To: Cc: ; Subject: Re: [mpls-tp] [mpls] Comments fordraft-chen-mpls-return-path-specified-lsp-ping-01 > > Without specifying, you cannot tell if the forward or reverse LSP is > broken. These are specified in RFC4378 already: Yes, agree, thanks for pointing out the RFC. > > [RFC4379] states that the third mode may be used when the IP return > path is deemed unreliable. This mode of operation requires that all > intermediate nodes must support the Router Alert option and must > understand and know how to forward MPLS echo replies. > > The thing that puzzles me about this draft is that seems to be finding > "more reliable" return paths than even "unreliable" ones: Sorry for the puzzle! As Vishwas said, the draft is trying to help in fault localization (e.g., tell whether the forward or reverse LSP is broken) by specifying alternate paths. Best regards, Mach > > And in any case, the use modes 2 or 3 cannot guarantee the delivery > of echo responses through an IP network that is fundamentally > unreliable. The failure to deliver echo response messages can lead > to false negatives making it appear that the LSP has failed. > > --Tom > > >> On 11/02/2010 22:41, "Greg Mirsky" wrote: >> >>> Dear Nitin, >>> I agree on your perspective regarding co-routed bi-directional LSP. As >>> it was >>> intentionally built with fate sharing between ingress/egress directions >>> I >>> don't see why operator will need to specify return path other than >>> opposite >>> direction of LSP under examination. >>> Troubleshooting bi-directional associated connection might have >>> different >>> requirements. (Wish we have someone from operators community to speak >>> here). >>> As directions, in general case, are diversly routed, so I see value in >>> specifying return path. It is logical to name opposite direction of >>> associated >>> connection as default return path but explicit, one-time overwrite seems >>> to >>> have value. >> >> IMO the opposite direction of the associated bidirectional LSP should be >> used by default. >> >> I can't think of an application for overwriting it off the top of my >> head, >> but that's not to say one doesn't exist. >> >> Ben >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From loa@pi.nu Wed Feb 24 02:51: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 99C443A843C; Wed, 24 Feb 2010 02:51:25 -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 JdnkbBmOA1bU; Wed, 24 Feb 2010 02:51:24 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id B1E573A8430; Wed, 24 Feb 2010 02:51:24 -0800 (PST) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 76BA8D4052; Wed, 24 Feb 2010 11:53:27 +0100 (CET) Received: from 194.237.142.17 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Wed, 24 Feb 2010 11:53:28 +0100 Message-ID: In-Reply-To: <4B7187EE.30404@pi.nu> References: <4B7187EE.30404@pi.nu> Date: Wed, 24 Feb 2010 11:53:28 +0100 From: "Loa Andersson" To: "Loa Andersson" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 24 Feb 2010 10:51:25 -0000 All, this poll has ended. We have accepted draft-fbb-mpls-tp-data-plane as an MPLS wroking group document. Could the authors please re-publish the document (without any othr changes than name and date) as draft-ietf-mpls-tp-data-plane-00.txt. And in the -01 version address both the comments that we recieved before the poll started and the commetns we received as response to the poll. /Loa > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu From Alexander.Vainshtein@ecitele.com Wed Feb 24 03:46: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 4477D28C11F; Wed, 24 Feb 2010 03:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 yBayMp4b6S3K; Wed, 24 Feb 2010 03:46:48 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 2E7483A8489; Wed, 24 Feb 2010 03:46:44 -0800 (PST) X-AuditID: 93eaf2e7-b7bafae000003e7b-bc-4b851071b074 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 09.5D.15995.170158B4; Wed, 24 Feb 2010 13:41:37 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 24 Feb 2010 13:48:45 +0200 From: Alexander Vainshtein To: Loa Andersson Date: Wed, 24 Feb 2010 13:48:42 +0200 Thread-Topic: [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acq1P6J8iltoMu6oRcekljq8bYpafwABhqTg Message-ID: References: <4B7187EE.30404@pi.nu> 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 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [PWE3] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 24 Feb 2010 11:46:49 -0000 Loa, One of my early comments on the data plane draft proposed moving all data p= lane-related issues=20 from the MPLS-TP Framework draft to this one. To the best of my recollectio= n, several people =20 have supported this proposal during the poll. When you ask the authors to address "both the comments that we received bef= ore the poll started and the comments we received as response to the poll" = in the -01 version, do you include this comment as well? I am asking because the LC on draft-ietf-mpls-tp-framework-10 was expected = to end on February 19. Regards, Sasha -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, February 24, 2010 12:53 PM To: Loa Andersson Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org Subject: Re: [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.t= xt a mpls working group document All, this poll has ended. We have accepted draft-fbb-mpls-tp-data-plane as an MPLS wroking group document. Could the authors please re-publish the document (without any othr changes than name and date) as draft-ietf-mpls-tp-data-plane-00.txt. And in the -01 version address both the comments that we recieved before the poll started and the commetns we received as response to the poll. /Loa > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From root@core3.amsl.com Wed Feb 24 05: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 6BB6F28C161; Wed, 24 Feb 2010 05: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: <20100224133001.6BB6F28C161@core3.amsl.com> Date: Wed, 24 Feb 2010 05:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-data-plane-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, 24 Feb 2010 13: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 : MPLS Transport Profile Data Plane Architecture Author(s) : D. Frost, et al. Filename : draft-ietf-mpls-tp-data-plane-00.txt Pages : 12 Date : 2010-02-24 The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network. 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-data-plane-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-data-plane-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24052123.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 24 09: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 F378128C1ED; Wed, 24 Feb 2010 09: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: <20100224173001.F378128C1ED@core3.amsl.com> Date: Wed, 24 Feb 2010 09:30:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-06.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, 24 Feb 2010 17: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 : LDP Typed Wildcard FEC Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-typed-wildcard-06.txt Pages : 11 Date : 2010-02-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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24092211.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Feb 25 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 2393328C176; Thu, 25 Feb 2010 15: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: <20100225231502.2393328C176@core3.amsl.com> Date: Thu, 25 Feb 2010 15:15:02 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-upstream-06.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, 25 Feb 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-06.txt Pages : 11 Date : 2010-02-25 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-25150557.I-D@ietf.org> --NextPart-- From lizhong.jin@zte.com.cn Thu Feb 25 18:38: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 AAE1728C4CB for ; Thu, 25 Feb 2010 18:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pgyLB3ypI3eT for ; Thu, 25 Feb 2010 18:38:40 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 23C9628C4CA for ; Thu, 25 Feb 2010 18:38:39 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164806486374; Fri, 26 Feb 2010 10:03:28 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.3442771177; Fri, 26 Feb 2010 10:39:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o1Q2ejkA023709; Fri, 26 Feb 2010 10:40:45 +0800 (CST) (envelope-from lizhong.jin@zte.com.cn) To: ina@juniper.net, rajiva@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 26 Feb 2010 10:40:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-02-26 10:40:41, Serialize complete at 2010-02-26 10:40:41 Content-Type: multipart/alternative; boundary="=_alternative 000EB454482576D6_=" X-MAIL: mse2.zte.com.cn o1Q2ejkA023709 Cc: mpls@ietf.org Subject: [mpls] Small comments for draft-ietf-mpls-ldp-typed-wildcard 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, 26 Feb 2010 02:38:41 -0000 This is a multipart message in MIME format. --=_alternative 000EB454482576D6_= Content-Type: text/plain; charset="US-ASCII" Hi Ina: I find there is a small mistake in the draft as follows. Section 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements. It is said "In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be 0x01." I think the sentence should be "In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be 0x01 or 0x03." Best Regards Lizhong Jin -------------------------------------------------------- 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. --=_alternative 000EB454482576D6_= Content-Type: text/html; charset="US-ASCII"
Hi Ina:
I find there is a small mistake in the draft as follows.
Section 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements. It is said "In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be 0x01."
I think the sentence should be "In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be 0x01 or 0x03."

Best Regards
Lizhong Jin
 
--------------------------------------------------------
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.
--=_alternative 000EB454482576D6_=-- From root@core3.amsl.com Fri Feb 26 08:00: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 6FDF328C0D8; Fri, 26 Feb 2010 08:00: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: <20100226160001.6FDF328C0D8@core3.amsl.com> Date: Fri, 26 Feb 2010 08:00:01 -0800 (PST) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mldp-in-band-signaling-01.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, 26 Feb 2010 16:00: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-01.txt Pages : 13 Date : 2010-02-26 Suppose an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages are received at the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-in-band-signaling-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-26075633.I-D@ietf.org> --NextPart-- From Martin.Vigoureux@alcatel-lucent.com Fri Feb 26 09: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 7674228C0EA for ; Fri, 26 Feb 2010 09:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HELO_EQ_FR=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 INj2tsnkxOLR for ; Fri, 26 Feb 2010 09:44:02 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 6269B3A881E for ; Fri, 26 Feb 2010 09:44:01 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1QHkDD8031330 for ; Fri, 26 Feb 2010 18:46:13 +0100 Received: from [172.27.205.119] ([172.27.205.119]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 18:46:13 +0100 Message-ID: <4B8808E4.1000601@alcatel-lucent.com> Date: Fri, 26 Feb 2010 18:46:12 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "mpls@ietf.org" References: <4B7D44C8.7040605@alcatel-lucent.com> In-Reply-To: <4B7D44C8.7040605@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Feb 2010 17:46:13.0274 (UTC) FILETIME=[969AEFA0:01CAB70B] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] Presentation slot requests for MPLS WG sessions in Anaheim (IETF 77th) 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, 26 Feb 2010 17:44:03 -0000 all, the final agenda is available here: https://datatracker.ietf.org/meeting/77/agenda.html Please send me propositions for presentations slots including time desired. regards, martin Martin Vigoureux a écrit : > all, > > in preparation of the IETF 77th MPLS WG sessions could you please > send me propositions for presentations. > These cover mpls and mpls-tp. > We have requested two slots (still to be confirmed) and will synchronize > with PWE3 and CCAMP WGs for the mpls-tp presentations. > > Thank you. > > > martin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From db3546@att.com Fri Feb 26 13:50: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 D98F73A885B; Fri, 26 Feb 2010 13:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 RnAwzDbNe5Fm; Fri, 26 Feb 2010 13:50:55 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 7FF523A870D; Fri, 26 Feb 2010 13:50:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1267221190!23979943!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12125 invoked from network); 26 Feb 2010 21:53:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 21:53:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QLr1Fb030582; Fri, 26 Feb 2010 16:53:01 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QLr0jH030557; Fri, 26 Feb 2010 16:53:00 -0500 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: Fri, 26 Feb 2010 16:53:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll on draft-abfb-mpls-tp-control-plane-framework Thread-Index: Acq3LhTmuSG/kxGCTt+1iMNqBtXcyg== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: [mpls] poll on draft-abfb-mpls-tp-control-plane-framework 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, 26 Feb 2010 21:50:57 -0000 All, This is to start a two week working group poll on making draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working group document. This poll is being initiated at this time as this document is part of the MPLS-TP work and it is needed to progress the work. Send your response to the ccamp@ietf.org mailing list (only), indicating "yes/support" or "no/do not support". This poll ends March 12th. Deborah From loa@pi.nu Sat Feb 27 03:59: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 7E9F33A8764; Sat, 27 Feb 2010 03:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 T+GUoByijLFo; Sat, 27 Feb 2010 03:59:53 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 7F6E13A8760; Sat, 27 Feb 2010 03:59:53 -0800 (PST) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B9AF9D4052; Sat, 27 Feb 2010 13:02:09 +0100 (CET) Message-ID: <4B8909D8.9020208@pi.nu> Date: Sat, 27 Feb 2010 13:02:32 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, pwe3@ietf.org, CCAMP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll to make draft-nitinb-mpls-tp-lsp-ping-extensions an mpls working 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, 27 Feb 2010 11:59:54 -0000 All, this is to start a poll on accepting draft-nitinb-mpls-tp-lsp-ping-extensions-01 as an mpls working group document. Please respond to the mpls-tp mailing list *only*! Indicating "yes/support" or "no/do not support". Technical comments, which are very welcome, should be sent to the same list, but with a differnt subject line. The poll ends eob March 12th 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 loa@pi.nu Sat Feb 27 04:07: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 4714D28C1A5 for ; Sat, 27 Feb 2010 04:07:33 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): Subject: ...n draft-ietf-mpls-ldp-igp-sync-bcast-00.txt\n \n X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 EQTtM81slRsQ for ; Sat, 27 Feb 2010 04:07:32 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 74C9928C182 for ; Sat, 27 Feb 2010 04:07:32 -0800 (PST) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 600BBD4052 for ; Sat, 27 Feb 2010 13:09:49 +0100 (CET) Message-ID: <4B890BA3.8010306@pi.nu> Date: Sat, 27 Feb 2010 13:10:11 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-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: Sat, 27 Feb 2010 12:07:33 -0000 All, this is to start a mpls working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Please sen your comments to the mpls working group mailing list (mpls@ietf.org). The working group last call end eob March 12. /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 loa@pi.nu Sat Feb 27 10:59: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 A062128C2C4 for ; Sat, 27 Feb 2010 10:59:58 -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.201, 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 wPhuTl0hs0wl for ; Sat, 27 Feb 2010 10:59:58 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id AE3E928C2C3 for ; Sat, 27 Feb 2010 10:59:57 -0800 (PST) Received: from [192.168.0.101] (h133n2fls33o883.telia.com [217.208.62.133]) (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 09C55D4052 for ; Sat, 27 Feb 2010 20:02:14 +0100 (CET) Message-ID: <4B896C37.1050809@pi.nu> Date: Sat, 27 Feb 2010 20:02:15 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] RSVP mini-BoF in Annaheim 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, 27 Feb 2010 18:59:58 -0000 Working Group, a mini-BoF is planned to take place at the TSV Area meeting in Annaheim. The topic is RSVP, since this is of interest for the MPLS wg I'd like to encourage that wg memebers participate in the TSV Area meeting. Here are the details: The RSVP mini-BoF is (~) 45min during the TSVAREA meeting, which is Wed 1300-1500 local time, in room California C. /Loa From ssaxena@cisco.com Sat Feb 27 15:31: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 42E8F3A8A10; Sat, 27 Feb 2010 15:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 HCKQlDsBZ6XE; Sat, 27 Feb 2010 15:31:40 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6DE6F3A8A0B; Sat, 27 Feb 2010 15:31:40 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD46iUutJV2Y/2dsb2JhbACbHnOgbpd/AoR5BIMX X-IronPort-AV: E=Sophos;i="4.49,552,1262563200"; d="scan'208";a="242990969" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2010 23:31:39 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o1RNVc9U018672; Sat, 27 Feb 2010 23:31:38 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Feb 2010 17:31:38 -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: Sat, 27 Feb 2010 17:31:36 -0600 Message-ID: In-Reply-To: <4B8909D8.9020208@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll to make draft-nitinb-mpls-tp-lsp-ping-extensions an mpls working document Thread-Index: Acq3pNhcUaGGr4lqRn2OuzjT8CR3bgAYCDyg References: <4B8909D8.9020208@pi.nu> From: "Shaleen Saxena (ssaxena)" To: "Loa Andersson" , , , , "CCAMP WG" X-OriginalArrivalTime: 27 Feb 2010 23:31:38.0834 (UTC) FILETIME=[026A2B20:01CAB805] Subject: Re: [mpls] poll to make draft-nitinb-mpls-tp-lsp-ping-extensions an mpls working 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, 27 Feb 2010 23:31:41 -0000 Yes/support Shaleen > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, February 27, 2010 7:03 AM > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP WG > Subject: [mpls] poll to make draft-nitinb-mpls-tp-lsp-ping-extensions > an mpls working document >=20 > All, >=20 > this is to start a poll on accepting > draft-nitinb-mpls-tp-lsp-ping-extensions-01 > as an mpls working group document. >=20 > Please respond to the mpls-tp mailing list *only*! > Indicating "yes/support" or "no/do not support". >=20 > Technical comments, which are very welcome, should be > sent to the same list, but with a differnt subject line. >=20 > The poll ends eob March 12th 2010. >=20 > /Loa >=20 >=20 > -- >=20 >=20 > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From benjamin.niven-jenkins@bt.com Sun Feb 28 10: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 7282928C130 for ; Sun, 28 Feb 2010 10:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L+ZpYXJOt64 for ; Sun, 28 Feb 2010 10:37:30 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 5EFD128C0DB for ; Sun, 28 Feb 2010 10:37:29 -0800 (PST) Received: from RDW083A009HT61.domain1.systemhost.net (10.187.59.12) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 28 Feb 2010 18:37:28 +0000 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.9]) by RDW083A009HT61.domain1.systemhost.net ([10.187.59.12]) with mapi; Sun, 28 Feb 2010 18:37:28 +0000 From: To: , Date: Sun, 28 Feb 2010 18:37:23 +0000 Thread-Topic: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Thread-Index: Acq3pcjJWaohYvI1SCKbeLRL9Vp0/AA/0haC Message-ID: In-Reply-To: <4B890BA3.8010306@pi.nu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-ietf-mpls-ldp-igp-sync-bcast@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-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: Sun, 28 Feb 2010 18:37:31 -0000 Loa, authors, See below for my comments following a review of draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Major: 1) Run the draft through the idnits tool (http://tools.ietf.org/tools/idnits/) and correct the 5 errors & 3 warnings it produces. 2) Page 4, final paragraph of Section 1. In the second interpretation of of [LDP-IGP-SYNC] it is not clear to me why A would have B as the nexthop for PE2, as A has advertised a maximum cost for that link, effectively costing it out of the SPF calculation. 3) If you are going to define a new term "cut-edge" then it needs a clearer definition of what circumstances lead to an interface being defined as a "cut-edge" interface. E.g. expand the text in the paragraph on page 4 that starts "In another alternative interpretation..." to describe what constitutes a "cut-edge" interface. Minor: 4) Expand acronyms on first usage through the document. Nits: 5) Abstract: s/when IGP is operational/when an IGP is operational 6) Introduction, first paragraph, first sentence: s/link, IGP advertises the link/link, the IGP advertises the link 7) Introduction, sencond paragraph, first sentence: s/On broadcast links, IGP advertises/On broadcast links, the IGP advertises= / 8) Introduction, third paragraph s/Till LDP becomes operational/Until LDP becomes operational/ Ben On 27/02/2010 12:10, "Loa Andersson" wrote: > All, >=20 >=20 > this is to start a mpls working group last call on > draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >=20 > Please sen your comments to the mpls working group mailing > list (mpls@ietf.org). >=20 > The working group last call end eob March 12. >=20 > /Loa From benjamin.niven-jenkins@bt.com Sun Feb 28 11:01:45 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 CA79328C0DB; Sun, 28 Feb 2010 11:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPnqUkKbFfhM; Sun, 28 Feb 2010 11:01:45 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id BD7913A6920; Sun, 28 Feb 2010 11:01:44 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 28 Feb 2010 19:01:44 +0000 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.9]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Sun, 28 Feb 2010 19:01:43 +0000 From: To: , , Date: Sun, 28 Feb 2010 19:01:37 +0000 Thread-Topic: [mpls-tp] [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 Thread-Index: Acq1MmfhyLtrKm6vQfqdEPCTFlbXlADdgvkz Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB 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] Comments for 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: Sun, 28 Feb 2010 19:01:45 -0000 Mach, On 24/02/2010 09:18, "Mach Chen" wrote: >> IMO the opposite direction of the associated bidirectional LSP should be >> used by default. >>=20 >> I can't think of an application for overwriting it off the top of my hea= d, >> but that's not to say one doesn't exist. >=20 > How about when the default return path is suspected broken, overwriting m= ay > help in judging whether the return path is borken or not. If the default return path is broken and the default return path is the opposite direction of an associated bidirectional LSP then the entire associated bidirectional LSP is essentially broken. This then implies that use of draft-chen-mpls-return-path-specified-lsp-pin= g is for troubleshooting and diagnostic purposes following the failure of an LSP? What advantage does draft-chen-mpls-return-path-specified-lsp-ping provide to troubleshoot the location in the network where the LSP is broken over sa= y LSP traceroute? Thanks Ben From sriganesh.kini@ericsson.com Sun Feb 28 11:45: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 D6FDB28C1A6 for ; Sun, 28 Feb 2010 11:45:47 -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 BEoibPcg0XWg for ; Sun, 28 Feb 2010 11:45:47 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E855E28C198 for ; Sun, 28 Feb 2010 11:45:46 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o1SJm1YQ026057; Sun, 28 Feb 2010 13:48:02 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 28 Feb 2010 14:45:42 -0500 From: Sriganesh Kini To: "benjamin.niven-jenkins@bt.com" , "loa@pi.nu" , "mpls@ietf.org" Date: Sun, 28 Feb 2010 14:41:23 -0500 Thread-Topic: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt Thread-Index: Acq3pcjJWaohYvI1SCKbeLRL9Vp0/AA/0haCAAFhjBA= Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F52E44D2AAC@EUSAACMS0703.eamcs.ericsson.se> References: <4B890BA3.8010306@pi.nu> 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: "draft-ietf-mpls-ldp-igp-sync-bcast@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-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: Sun, 28 Feb 2010 19:45:47 -0000 Ben, Thanks for the review and comments. Pls see inline @ [Sri]. Will update nex= t rev with all 'Accepted' comments. - Sri -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ben= jamin.niven-jenkins@bt.com Sent: Sunday, February 28, 2010 10:37 AM To: loa@pi.nu; mpls@ietf.org Cc: draft-ietf-mpls-ldp-igp-sync-bcast@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync= -bcast-00.txt Loa, authors, See below for my comments following a review of draft-ietf-mpls-ldp-igp-syn= c-bcast-00.txt Major: 1) Run the draft through the idnits tool (http://tools.ietf.org/tools/idnits/) and correct the 5 errors & 3 warnings= it produces. [Sri] Accepted. 2) Page 4, final paragraph of Section 1. In the second interpretation of of [LDP-IGP-SYNC] it is not clear to me why= A would have B as the nexthop for PE2, as A has advertised a maximum cost = for that link, effectively costing it out of the SPF calculation. [Sri] Only B advertises the maximum cost. See first two sentences of final = paragraph of section 1. When A runs SPF, its cost to B will not be the maxi= mum cost, hence the nexthop to PE2 will be through B. 3) If you are going to define a new term "cut-edge" then it needs a clearer= definition of what circumstances lead to an interface being defined as a "= cut-edge" interface. E.g. expand the text in the paragraph on page 4 that starts "In another alt= ernative interpretation..." to describe what constitutes a "cut-edge" interface. [Sri] Page 4, third paragraph of section 3 defines a 'cut-edge' interface. = It is fairly standard terminology in graph-theory to describe a link. Howev= er we can add an extra sentence in section 3 to further clarify. Accepted. Minor: 4) Expand acronyms on first usage through the document. [Sri] Accepted. Nits: 5) Abstract: s/when IGP is operational/when an IGP is operational [Sri] Accepted 6) Introduction, first paragraph, first sentence: s/link, IGP advertises the link/link, the IGP advertises the link [Sri] Accepted 7) Introduction, sencond paragraph, first sentence: s/On broadcast links, IGP advertises/On broadcast links, the IGP advertises= / [Sri] Accepted 8) Introduction, third paragraph s/Till LDP becomes operational/Until LDP becomes operational/ [Sri] Accepted Ben On 27/02/2010 12:10, "Loa Andersson" wrote: > All, >=20 >=20 > this is to start a mpls working group last call on=20 > draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >=20 > Please sen your comments to the mpls working group mailing list=20 > (mpls@ietf.org). >=20 > The working group last call end eob March 12. >=20 > /Loa _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From tm-otani@kddi.com Sun Feb 28 15:28: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 EC17E3A89CC; Sun, 28 Feb 2010 15:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.018 X-Spam-Level: * X-Spam-Status: No, score=1.018 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_40=-0.185] 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 u-DJvYla0Lxy; Sun, 28 Feb 2010 15:28:41 -0800 (PST) Received: from UTMC1103.kddi.com (athena.kddi.com [210.141.112.39]) by core3.amsl.com (Postfix) with ESMTP id 300433A8886; Sun, 28 Feb 2010 15:28:40 -0800 (PST) Received: from UTMC1132 (unknown [10.5.16.195]) by UTMC1103.kddi.com (Postfix) with SMTP id E1C101D95; Mon, 1 Mar 2010 08:28:40 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D26D21A41; Mon, 1 Mar 2010 08:28:37 +0900 (JST) Received: from UTMC1113.kddi.com (unknown [10.5.16.13]) by UTMC1123.kddi.com (Postfix) with ESMTP id C299119FC; Mon, 1 Mar 2010 08:28:37 +0900 (JST) Received: from KDDI-0805PC0145 ([10.211.58.104] [10.211.58.104]) by post-ims.kddi.com with ESMTPA; Mon, 1 Mar 2010 08:28:37 +0900 To: db3546@att.com, ccamp@ietf.org From: Tomohiro Otani References: In-Reply-To: Message-Id: <201003010828.CIJ90157.OPUBUJtN@kddi.com> X-Mailer: Winbiff [Version 2.51 PL3] X-Accept-Language: ja,en,zh Date: Mon, 1 Mar 2010 08:28:38 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-WAuditID: 1003010828370000201171 Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [CCAMP] poll on draft-abfb-mpls-tp-control-plane-framework 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, 28 Feb 2010 23:28:42 -0000 Hi all, Yes/Support. This is a good draft for starting to formalize application of GMPLS. # I have been re-subscribing a couple of lists. Regards, Tomo $B$N!"(B "[CCAMP] poll on draft-abfb-mpls-tp-control-plane-framework" $B$K$*$$$F!"(B ""BRUNGARD, DEBORAH A (ATTLABS)" "$B$5$s$O=q$-$^$7$?!'(B >All, > >This is to start a two week working group poll on making >draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working >group document. This poll is being initiated at this time as this >document is part of the MPLS-TP work and it is needed to progress the >work. > >Send your response to the ccamp@ietf.org mailing list (only), indicating >"yes/support" or "no/do not support". > >This poll ends March 12th. > >Deborah >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp > From mach@huawei.com Sun Feb 28 18:39: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 29BD33A8A2F; Sun, 28 Feb 2010 18:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, 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 JZWgjCKMswei; Sun, 28 Feb 2010 18:39:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 070423A88AE; Sun, 28 Feb 2010 18:39:04 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYL00FMI0OTZX@szxga01-in.huawei.com>; Mon, 01 Mar 2010 10:38:53 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYL00EXD0OSO7@szxga01-in.huawei.com>; Mon, 01 Mar 2010 10:38:53 +0800 (CST) Date: Mon, 01 Mar 2010 10:38:52 +0800 From: Mach Chen In-reply-to: To: benjamin.niven-jenkins@bt.com, gregimirsky@gmail.com, nitinb@juniper.net 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: Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Comments for 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: Mon, 01 Mar 2010 02:39:05 -0000 Hi Ben, Thanks for your reply! -------------------------------------------------- From: Sent: Monday, March 01, 2010 3:01 AM To: ; ; Cc: ; Subject: Re: [mpls-tp] [mpls] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01 > Mach, > > On 24/02/2010 09:18, "Mach Chen" wrote: >>> IMO the opposite direction of the associated bidirectional LSP should be >>> used by default. >>> >>> I can't think of an application for overwriting it off the top of my >>> head, >>> but that's not to say one doesn't exist. >> >> How about when the default return path is suspected broken, overwriting >> may >> help in judging whether the return path is borken or not. > > If the default return path is broken and the default return path is the > opposite direction of an associated bidirectional LSP then the entire > associated bidirectional LSP is essentially broken. Yes, it should be. And presumably the normal logic is that when failures occur, and then try to find which direction is broken and then re-construct a new associated bidirectional LSP. > > This then implies that use of > draft-chen-mpls-return-path-specified-lsp-ping > is for troubleshooting and diagnostic purposes following the failure of an > LSP? This is one of the purposes of draft-chen-mpls-return-path-specified-lsp-ping(by specifying alternate return paths). By the way, since the draft extends the fucntion of echo reply(by including the FEC stack info of the return path) to enable that echo reply could be used to test the reverse direction the bidirectional LSP as well. It give the capabiltiy to perform LSP checking from whatever which side of the LSP. Hence, a bidirectional LSP could be tested within one operation. And in inter-AS/domain scenario, since the operator from one side has no right to log on to the remote side to perform any operation, with this extension, the operators could check the reverse direation of an inter-AS/domain associated bidirectional LSP from their own side. > > What advantage does draft-chen-mpls-return-path-specified-lsp-ping provide > to troubleshoot the location in the network where the LSP is broken over > say > LSP traceroute? In some scenarios, even with LSP traceroute, it could not locate the failure point. Take the following simple topology as an example: A--B----C--D \ / E---F There is an LSP(A-B-C-D) from A to D and two LSPs from D to A (D-C-B-A and D-F-E-B-A). LSP(A-B-C-D) and LSP(D-C-B-A) are binded to an associated bidirectional LSP, say LSP-a. No matter what the failure is at the hop between C and D of LSP(A-B-C-D) or at the reverse direction of LSP-a or at D, there will no different in the trace result(A..B..C). With draft-chen, if the reverse direction of LSP-a is suspected broken, then the operator could initiante another LSP ping by specifying LSP(D-F-E-B-A) as the return path and then if it works, it could judge that LSP(D-C-B-A) is with failures. Best regards, Mach > > Thanks > Ben >