6. If it is Asymmetric, if one direction of the MPLS-TP lsp goes down,= do we need to make other direction of the paired LSP to =A0make it down.?<= /div>

Many thanks in advance.

=A0

Regards

Velan.S

--001636831e765f05bd049bbbe0b0-- From ice@cisco.com Tue Feb 8 00:12:15 2011 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 5D7763A6CBA for ; Tue, 8 Feb 2011 00:12: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 J23i-trkkrYH for ; Tue, 8 Feb 2011 00:12:14 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 00B473A6CB0 for ; Tue, 8 Feb 2011 00:12:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1888Yne000098; Tue, 8 Feb 2011 09:08:34 +0100 (CET) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1888XcV009515; Tue, 8 Feb 2011 09:08:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <5FADE6EC-11E3-4646-A2DD-97DD56E569F9@niven-jenkins.co.uk> Date: Tue, 8 Feb 2011 09:08:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5337CA29-27C6-4915-9C8F-B10A4548609E@cisco.com> References: <4CD8FD3E.4090507@pi.nu> <5FADE6EC-11E3-4646-A2DD-97DD56E569F9@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1081) Cc: "mpls@ietf.org" , Stewart Bryant Subject: Re: [mpls] LC Comments on draft-ietf-mpls-ldp-p2mp-11 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, 08 Feb 2011 08:12:15 -0000 Hi Ben, Thanks for the comments. > Non-editorial: >=20 > 1) Section 2.1 - the "divider" between the "P2MP Capability" field and = the Length field is not on a bit boundary making it unclear whether the = P2MP Capability field is 14 bits or 15 bits (I assume it is meant to be = 14 bits). I fixed it to be 14. > 2) Section 2.1 - "If the peer has not advertised the corresponding = capability, then no label messages using the P2MP FEC Element should be = sent to the peer." >=20 > Is this really lowercase should or is it really a "SHOULD NOT be sent = to" Changed to "SHOULD NOT" > 3) Section 3, last paragraph=20 > "Another consideration is the various techniques that can be used to = splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will be = described in a later revision." >=20 > As this is in WG LC I suggest rewording to something like > "Another consideration is the technique to use to splice unicast LDP = MP2P LSPs to the LDP P2MP LSP; this document does not mandate a specific = technique, leaving it to each application to specify an appropriate = technique to use." >=20 > or just leave it out of scope: >=20 > "Another consideration is the technique to use to splice unicast LDP = MP2P LSPs to the LDP P2MP LSP; the specific technique to use is outside = the scope of this document." Section 3 is underdeveloped and either needs to be modified or removed. = This section is not mLDP specific and applies equally to RSVP-TE P2MP = LSPs, so I think it does not really belong in this draft. I raised it = with Rahul Aggarwal last IETF and I'm waiting for him to come back to me = with a proposal. > 4) Section 4.1 (Same comment as for section 2.1, i.e) - "If the peer = has not advertised the corresponding capability, then no label messages = using the P2MP FEC Element should be sent to the peer." >=20 > Is this really lowercase should or is it really a "SHOULD NOT be sent = to" Changed to "SHOULD NOT". > 5) Section 12 - IANA Considerations: > The ocument creates 3 new name spaces to be managed by IANA but does = not specify any guidelines for managing the number ranges and does not = specify an allocation policy (or policies) to be used. Got it, will add it, Thx, Ice. From ice@cisco.com Tue Feb 8 00:46:30 2011 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 32B6C3A7058 for ; Tue, 8 Feb 2011 00:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 R1QtM3RhAafi for ; Tue, 8 Feb 2011 00:46:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 105BE3A7019 for ; Tue, 8 Feb 2011 00:46:28 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p188kYfd003285; Tue, 8 Feb 2011 09:46:34 +0100 (CET) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p188kXSc001183; Tue, 8 Feb 2011 09:46:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <19338ACC-82B8-475B-94EE-6BB629F2674E@niven-jenkins.co.uk> Date: Tue, 8 Feb 2011 09:46:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15BD76E2-8C44-486D-932D-5E7FB81417C7@cisco.com> References: <4CD8FD3E.4090507@pi.nu> <19338ACC-82B8-475B-94EE-6BB629F2674E@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1081) Cc: Ross Callon , mpls@ietf.org, Stewart Bryant Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11 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, 08 Feb 2011 08:46:30 -0000 Hi Ben, Thanks for the detailed comments below. See inline. > Below are my editorial comments on draft-ietf-mpls-ldp-p2mp-11: >=20 > 1) Abstract: >=20 > "These extensions are also referred to as mLDP Multicast LDP" >=20 > Should that be "These extensions are also referred Multicast LDP = (mLDP)"? Changed it to "These extensions are also referred to as Multicast LDP = (mLDP)" > 2) Section 1 - Introduction: >=20 > Seems to mix root/leaf & ingress/egress. Should probably try and be = consistent and pick on set of terms? It looks correct to me. The term 'leaf' can be seen as a more generic = way to describe a leg of a MP-LSP, since when it comes to MP2MP a leaf = can be both ingress and egress. Also, root and ingress don't have to be = the same when it comes to MP2MP LSPs. > 3) Section 1 - Introduction: >=20 > The last sentence seems a little strangely worded. Maybe something = like " > [I-D.ietf-mpls-mp-ldp-reqs], [I-D.ietf-l3vpn-2547bis-mcast] and = [RFC4875]. >=20 > [Note: I reordered the references as I think the reqs & l3vpn = documents are more relevant to this document than P2MP RSVP-TE] Sounds good. > 4) 2.4.1.1, para 2 s/amoung/among/ Done. > 5) 2.4.2 s/The following lists/The following sections list/ Done. > 6) Section 4.3, bullet 6, 2nd sentence s/Label L MUST/Label Lu MUST/ Done. > 7) Section 4.3.1.3 bullet 1 s/bases/basis/ Done. > 8) Section 4.3.1.3 bullet 2 s/build/built/ Done. > 9) Section 4.4.2 s/The following lists/The following sections list/ Done. > 10) Section 5 use LFT but it is not expanded anywhere. Done. > 11) Section 6.2.1 s/and an additional information/and any additional = information/ Done. > 12) Section 7.1.1 s/LSP label is send to the upstream LSR/LSP label is = sent to the upstream LSR/ Done. > 13) Section 7.1.1 s/installed the context/installed in the context/ Done. > 14) Section 9.4.3 s/that an other/that another/ Done. > 15) Section 9.4.4 s/is send to/is sent to/ Done. > 16) Section 9.4.5 s/are send to/are sent to/ Done. > 17) Section 15.1 >=20 > draft-ietf-mpls-upstream-label-05 is now RFC5331 >=20 > draft-ietf-mpls-ldp-upstream-02 is now draft-ietf-mpls-ldp-upstream-08 >=20 > draft-ietf-mpls-ldp-capabilities-02 is now RFC5561 >=20 > draft-ietf-mpls-ldp-typed-wildcard-07 is now RFC5918 Fixed. >=20 >=20 > 18) Section 15.2 >=20 > draft-ietf-mpls-mp-ldp-reqs-04 has expired Has been updated now. >=20 > draft-ietf-l3vpn-2547bis-mcast-06 is now = draft-ietf-l3vpn-2547bis-mcast-10 >=20 > draft-ietf-mpls-multicast-encaps-09 is now RFC 5332 Fixed. Thx, Ice. > On 9 Nov 2010, at 07:50, Loa Andersson wrote: >=20 >> Working Group, >>=20 >>=20 >> this is to start a 2 week+ working group last call on >> draft-ietf-mpls-ldp-p2mp-11. >>=20 >> Please review the document and send comments to the >> mpls@ietf.org mailing lsit. >>=20 >> The working group last call ends November 26 - 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From saalvare@cisco.com Tue Feb 8 01:29:05 2011 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 B80483A6CF5; Tue, 8 Feb 2011 01:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeDYe+0SccRg; Tue, 8 Feb 2011 01:29:01 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ABC0B3A6CC4; Tue, 8 Feb 2011 01:29:00 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgBAKqbUE2rR7Hu/2dsb2JhbACCSZQGjltzoBabMIVaBIR7iiM Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 09:29:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p189T7WK024894; Tue, 8 Feb 2011 09:29:07 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 01:29:07 -0800 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_01CBC772.A1E81601" Date: Tue, 8 Feb 2011 01:29:05 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0DBEABC4@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Questions of MPLS-TP LSP labeling Thread-Index: AcvHNbbFLBK5SaGtRX+0KpC6Khzo7gAPFLMA References: From: "Santiago Alvarez (saalvare)" To: "Velan S" , , X-OriginalArrivalTime: 08 Feb 2011 09:29:07.0099 (UTC) FILETIME=[A2290EB0:01CBC772] Cc: "Santiago Alvarez $saalvare$" Subject: Re: [mpls] Questions of MPLS-TP LSP labeling 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, 08 Feb 2011 09:29:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC772.A1E81601 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You may want to read RFC 5586, RFC 5654, RFC 5860, RFC 5921. Hope that helps. Cheers. =20 SA -- =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Velan S Sent: Monday, February 07, 2011 6:12 PM To: mpls-tp@ietf.org; mpls@ietf.org Subject: [mpls] Questions of MPLS-TP LSP labeling =20 Hi Experts, =20 I have few questions and clarifications on MPLS-TP LSP labeling before I speed up into MPLS-TP world. =20 1. Is MPLS-TP LSP uses special label value allocated static/dynamically. ? =20 2. why MPLS-TP LSP needs to be bidirectional and does each LSR/LER need to bind the bi-directional LSP's association.? =20 3. My assumption is that MPLS-TP lsp is nothing but normal LSP created statically/dynamically used to carry data and in-band channel information over it.? =20 4. My assumption is that each Pseudowire data circuit will have 1:1 MPLS-TP Pseudowire for in-band channel communication to operate OAM function on Pseudowire.? =20 5. Is bi-directional LSP symmeric or not? =20 6. If it is Asymmetric, if one direction of the MPLS-TP lsp goes down, do we need to make other direction of the paired LSP to make it down.? =20 Please clarify my question. =20 Many thanks in advance. =20 Regards Velan.S ------_=_NextPart_001_01CBC772.A1E81601 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You may want to read RFC 5586, RFC 5654, RFC 5860, RFC 5921. Hope = that helps.

Cheers.

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Velan S
Sent: Monday, February 07, 2011 6:12 = PM
To: mpls-tp@ietf.org; mpls@ietf.org
Subject: = [mpls] Questions of MPLS-TP LSP = labeling

Hi = Experts,

I = have few questions and clarifications on MPLS-TP LSP labeling = before I speed up into MPLS-TP world.

1. Is MPLS-TP LSP uses special label value = allocated static/dynamically. ?

2. why MPLS-TP LSP needs to be bidirectional and = does each LSR/LER need to bind the bi-directional LSP's = association.?

3. My assumption is that MPLS-TP lsp is nothing = but normal LSP created statically/dynamically used to carry data and = in-band channel information over it.?

4. My assumption is that = each Pseudowire data circuit will have 1:1 = MPLS-TP Pseudowire for in-band channel communication to operate OAM = function on Pseudowire.?

5. Is bi-directional LSP symmeric or = not?

6. If it is Asymmetric, if one direction of the = MPLS-TP lsp goes down, do we need to make other direction of the paired = LSP to make it down.?

Please clarify my = question.

Many thanks in advance.

Regards

Velan.S

------_=_NextPart_001_01CBC772.A1E81601-- From ben@niven-jenkins.co.uk Tue Feb 8 03:19:01 2011 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 D56983A710E for ; Tue, 8 Feb 2011 03:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 WXLrVhNbHS0b for ; Tue, 8 Feb 2011 03:19:01 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 28AD83A6D95 for ; Tue, 8 Feb 2011 03:19:01 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-144-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pmlb9-0007OG-1O; Tue, 08 Feb 2011 11:19:07 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <15BD76E2-8C44-486D-932D-5E7FB81417C7@cisco.com> Date: Tue, 8 Feb 2011 11:19:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD8FD3E.4090507@pi.nu> <19338ACC-82B8-475B-94EE-6BB629F2674E@niven-jenkins.co.uk> <15BD76E2-8C44-486D-932D-5E7FB81417C7@cisco.com> To: IJsbrand Wijnands X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Ross Callon , mpls@ietf.org, Stewart Bryant Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11 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, 08 Feb 2011 11:19:01 -0000 Ice, On 8 Feb 2011, at 08:46, IJsbrand Wijnands wrote: >> 2) Section 1 - Introduction: >>=20 >> Seems to mix root/leaf & ingress/egress. Should probably try and be = consistent and pick on set of terms? >=20 > It looks correct to me. The term 'leaf' can be seen as a more generic = way to describe a leg of a MP-LSP, since when it comes to MP2MP a leaf = can be both ingress and egress. Also, root and ingress don't have to be = the same when it comes to MP2MP LSPs. Good point. I'm happy for you to ignore my previous comment. Ben From Internet-Drafts@ietf.org Tue Feb 8 05:30:03 2011 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 094733A7011; Tue, 8 Feb 2011 05:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, 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 HGEldnnRf9XP; Tue, 8 Feb 2011 05:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47E63A6C8A; Tue, 8 Feb 2011 05:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208133001.32546.96918.idtracker@localhost> Date: Tue, 08 Feb 2011 05:30:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mldp-in-band-signaling-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:30:03 -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-03.txt Pages : 13 Date : 2011-02-08 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-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-mldp-in-band-signaling-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08052058.I-D@ietf.org> --NextPart-- From linda.dunbar@huawei.com Tue Feb 8 13:57:44 2011 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 7B6473A6870; Tue, 8 Feb 2011 13:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QnHKoCdjz6j; Tue, 8 Feb 2011 13:57:43 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3BF113A686A; Tue, 8 Feb 2011 13:57:43 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGB00IHYJOE3R@usaga04-in.huawei.com>; Tue, 08 Feb 2011 15:57:50 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGB00JH4JODLT@usaga04-in.huawei.com>; Tue, 08 Feb 2011 15:57:50 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Feb 2011 13:57:45 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 08 Feb 2011 13:57:33 -0800 Date: Tue, 08 Feb 2011 21:57:32 +0000 From: Linda Dunbar In-reply-to: X-Originating-IP: [10.124.12.77] To: Ross Callon , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6A81B8F@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ffl+4YF35ie4P24LY6xPfQ)" Content-language: en-US Accept-Language: en-US Thread-topic: MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Thread-index: AQHLx9sw7YZ5M3jNY0iGGGg2vMPKUA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 08 Feb 2011 21:57:44 -0000 --Boundary_(ID_Ffl+4YF35ie4P24LY6xPfQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I have some issues with this draft: There had been a lot of discussions on email list on what should Initiator (querier) do when not receiving a response from far end. Ben Jenkins suggested the following text (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html) which is not incorporated to this new draft yet. When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. The querier should abort the measurement after not receiving any positive feedback when a specified timer expires. Section 3.5.3: It stated: When a query is received with a Session Query Interval that is too low for the receiver to support, the receiver SHOULD include this object when it generates an error response. Question: Which error code should be used? Is it 0x18:Error - Unsupported Query Interval? If Yes, should add this to the sentence. What if the Querier indicates "0x2: No Response Requested"? Section 4.1.5: * Should allow the Loss measurement to be calculated somewhere else, in case the initiator (querier) doesn't have the capacity to do the calculation. * Should add a description that measurement is to be stopped when far end not respond anymore. Linda Dunbar -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Sunday, February 06, 2011 9:33 PM To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Subject: [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01 Working Group, This is to start a four week working group last call on " Packet Loss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay-01). Please send comments to the mpls at ietf.org mailing list. Also, please note that the related document " draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in parallel on the mpls-tp email list (mpls-tp at ietf.org). This working group last call ends on Monday March 7, 2011. Ross, Loa, and George MPLS WG co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --Boundary_(ID_Ffl+4YF35ie4P24LY6xPfQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I have some issues with this draft:

There had been a lot of discussions on email list on what should Initiator (querier) do when not receiving a response from far end.

Ben Jenkins suggested the following text (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html) which is not incorporated to this new draft yet.

When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. The querier should abort the measurement after not receiving any positive feedback when a specified timer expires.

Section 3.5.3: It stated:

When a query is received with a Session Query Interval that is too low for the receiver to support, the receiver SHOULD include this object when it generates an error response.

Question:

Which error code should be used? Is it 0x18:Error - Unsupported Query Interval? If Yes, should add this to the sentence.

What if the Querier indicates "0x2: No Response Requested"?

Section 4.1.5:

Should allow the Loss measurement to be calculated somewhere else, in case the initiator (querier) doesn't have the capacity to do the calculation.
Should add a description that measurement is to be stopped when far end not respond anymore.

Linda Dunbar

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Sunday, February 06, 2011 9:33 PM
To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01

Working Group,

This is to start a four week working group last call on

" Packet Loss and Delay Measurement for MPLS Networks"

(draft-ietf-mpls-loss-delay-01).

Please send comments to the mpls at ietf.org mailing list.

Also, please note that the related document

" draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in

parallel on the mpls-tp email list (mpls-tp at ietf.org).

This working group last call ends on Monday March 7, 2011.

Ross, Loa, and George

MPLS WG co-chairs

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls

--Boundary_(ID_Ffl+4YF35ie4P24LY6xPfQ)-- From loa@pi.nu Tue Feb 8 15:40:33 2011 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 DCBF73A68D1; Tue, 8 Feb 2011 15:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 z9IyiHEbZes6; Tue, 8 Feb 2011 15:40:33 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id F212D3A6866; Tue, 8 Feb 2011 15:40:32 -0800 (PST) Received: from [10.104.72.179] (62-50-197-30.client.stsn.net [62.50.197.30]) (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 3075B2A8001; Wed, 9 Feb 2011 00:40:38 +0100 (CET) Message-ID: <4D51D472.5070607@pi.nu> Date: Wed, 09 Feb 2011 00:40:34 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls-tp@ietf.org" References: <4D3B30A3.1030607@pi.nu> In-Reply-To: <4D3B30A3.1030607@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , MPLS-TP ad hoc team , draft-fang-mpls-tp-security-framework@tools.ietf.org Subject: [mpls] Poll has ended - Re: poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:40:34 -0000 All, this poll has ended. We have accepted a new working group document. Could the authors please publish the document as: draft-ietf-mpls-tp-security-framework-00 without any other changes than date, file name and version number. Loa, George and Ross mpls wg co-chairs On 2011-01-22 20:31, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-fang-mpls-tp-security-framework-04 > > an MPLS working group document! > > Please send your responses to the mpls-tp@ietf.org mailing list. > > The poll ends Feb 6, 2011. > > Loa, George and Ross > 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 takeda.tomonori@lab.ntt.co.jp Wed Feb 9 07:02:41 2011 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 70A483A69A8; Wed, 9 Feb 2011 07:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 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, 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 oNDqTJqwJklB; Wed, 9 Feb 2011 07:02:40 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 1425E3A6767; Wed, 9 Feb 2011 07:02:39 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p19F2m2H028639; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 70A486D3D; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4AD2E6D39; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id p19F2mPp015543; Thu, 10 Feb 2011 00:02:48 +0900 Message-Id: <201102091502.p19F2mPp015543@imail2.m.ecl.ntt.co.jp> To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org From: Tomonori TAKEDA Date: Thu, 10 Feb 2011 00:02:48 +0900 X-Mailer: WebMail V3.7 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Cc: iPOP2011-tpc-sec@pilab.jp Subject: [mpls] iPOP2011 Call for Presentation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:02:41 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, iPOP2011 Call for Presentation is now open as follows. The deadline for submitting presentation proposal is February 25th. Best Regards, Tomonori Takeda ------------------------------------------------------------------------ Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2010 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 25, 2010 Notification of acceptance: April 4, 2010 Submission deadline of final presentation slides: April 22, 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$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Wed Feb 9 11:30:03 2011 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 274593A6833; Wed, 9 Feb 2011 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 QGY13zOL1rhu; Wed, 9 Feb 2011 11:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56083A69ED; Wed, 9 Feb 2011 11:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209193001.19667.86167.idtracker@localhost> Date: Wed, 09 Feb 2011 11:30:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-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, 09 Feb 2011 19:30:03 -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 On-demand Connectivity Verification and Route Tracing Author(s) : N. Bahadur, et al. Filename : draft-ietf-mpls-tp-on-demand-cv-02.txt Pages : 17 Date : 2011-02-09 LSP-Ping is an existing and widely deployed OAM mechanism for MPLS LSPs. This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS-TP LSPs. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-02.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-on-demand-cv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-09112733.I-D@ietf.org> --NextPart-- From gregimirsky@gmail.com Wed Feb 9 16:51:13 2011 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 A356E3A672F; Wed, 9 Feb 2011 16:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 RRL-0kS24T0i; Wed, 9 Feb 2011 16:51:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9358D3A67FA; Wed, 9 Feb 2011 16:51:12 -0800 (PST) Received: by vxi40 with SMTP id 40so418649vxi.31 for ; Wed, 09 Feb 2011 16:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=tUqJXPz2GD7xvMYG+mU49GaszlbMbASjF6rh0h6kV6o=; b=ptoBztQnUajvfmGh6JfO5z3zYF3JumxabTr2Urn2EAOoPmsknVTDPuicguyD66Vvli xSfZjx7EWcCOqWGk04tYPIpsKrk0VF9l3chnk8wYG9zTLDN3sBuOp/NAexYL6DutnNyi O3QvdcqFXuErq5Uh0mDnFMcXqnQBHXliCXbNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DFDGJxPPhf2lzeAQpBZh2iGPYPResOgVniZj4p8qe0yoTKiUiMGRQ1Z5H+fCtmHVO4 3HUsy86WPF0o23z6Fpexz2z/ALOSRuJvWGRFz6LyQfWV3joDcHWKsXhNxAyhmAf5vQ19 GrcrpoEQp7fP9i5E8GnDXGS6pw10rabU5aoxk= MIME-Version: 1.0 Received: by 10.220.181.9 with SMTP id bw9mr177252vcb.13.1297299083130; Wed, 09 Feb 2011 16:51:23 -0800 (PST) Received: by 10.220.103.4 with HTTP; Wed, 9 Feb 2011 16:51:23 -0800 (PST) Date: Wed, 9 Feb 2011 16:51:23 -0800 Message-ID: From: Greg Mirsky To: swallow@cisco.com, martin.vigoureux@alcatel-lucent.com, Sami Boutros , David Ward , mpls@ietf.org, mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=90e6ba53a90c0478c9049be2fb97 Subject: [mpls] Question to draft-ietf-mpls-tp-fault-03 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, 10 Feb 2011 00:51:13 -0000 --90e6ba53a90c0478c9049be2fb97 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, section 6 lists mandatory and optional implementation requirements. In bullet 1 setting of R-flag to non-zero value (clearing of previously reported FM condition) listed as optional - "... setting the R bit to value other than zero need not be supported." But setting the R-flag is not listed as optional functionality. Only "support of receiving the R flag" is listed as optional item #2. Adding "sending" and " or "setting R-flag to non-zero value" to this "Support of receiving the R flag" might clear the issue. Regards, Greg --90e6ba53a90c0478c9049be2fb97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
section 6 lists mandatory and optional implementation requ= irements. In bullet 1 setting of R-flag to non-zero value (clearing of prev= iously reported FM condition) listed as optional - "... setting the R = bit to value other than zero need not be supported."
But setting the R-flag is not listed as optional functionality. Only "= support of receiving the R flag" is listed as optional item #2. Adding= "sending" and " or "setting R-flag to non-zero value&q= uot; to this=A0 "Support of receiving the R flag" might clear the= issue.

Regards,
Greg
--90e6ba53a90c0478c9049be2fb97-- From mach@huawei.com Wed Feb 9 19:46:05 2011 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 76C343A684D; Wed, 9 Feb 2011 19:46:05 -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 1ZCLo3qFLs7M; Wed, 9 Feb 2011 19:46:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 280F73A684B; Wed, 9 Feb 2011 19:46:04 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGD00FYNUEH60@szxga05-in.huawei.com>; Thu, 10 Feb 2011 11:44:41 +0800 (CST) Received: from C55527A ([10.110.98.33]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGD00MPYUEBW4@szxga05-in.huawei.com>; Thu, 10 Feb 2011 11:44:41 +0800 (CST) Date: Thu, 10 Feb 2011 11:44:35 +0800 From: Mach Chen In-reply-to: <4D4AB81D.3080907@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org, ahmpls-tp@lists.itu.int Message-id: <06c901cbc8d4$d682a820$8387f860$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQ References: <4D4AB81D.3080907@pi.nu> Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 10 Feb 2011 03:46:05 -0000 Dear authors, I read the draft, here are some comments, please consider: 1.Section 3.5, last sentence of first paragraph "Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD." There is a "be" lost between "can" and "only". 2.Section 3.5.2 "1. BFD control packets are received with an unexpected encapsulation (mis-connectivity defect), these include: - a PW receiving a packet with a GAL", Since GAL can be used for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), this should not be a defect. Suggest to remove it. 3 Section 3.5.2 " 4. Receipt of an expected session discriminator with an unexpected label (mis-connectivity defect).", For a receiver, how does it know that the session discriminator is valid but the label is invalid? IMHO, this defect is just another description of defect 3 . Suggest to remove it. 4.Section 3.5.4.2 " Exit from a misconfiguration defect occurs when two consecutive CC or CV frames have been received with the expected M bit setting." IMHO, this sentence is little bit vague, and since this draft only defines for P2P LSP, why not just say "...with M bit clear." 5. Section 3.5.4.3 "Exit from a mis-connectivity defect state occurs when no CV messages have been received with an incorrect source MEP-ID for a period of 3.5 seconds.", since there are several defects listed in Section 3.5.2 and this is only one condition for exiting from a mis-connectivity defect state. How about "Exit from a mis-connectivity defect state occurs when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds " 6. Section 3.5.5 In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state. Best regards, Mach > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Thursday, February 03, 2011 10:14 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 > > Working Group, > > this is to start a four week working group last call on > "Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile" > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > Please send comments to the mpls-tp@ietf.org mailing list. > > This working group last call ends on February 28, 2011. > > > Loa, George and Ross > > 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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From Internet-Drafts@ietf.org Wed Feb 9 22:45:10 2011 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 A3CCD3A68C5; Wed, 9 Feb 2011 22:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 EYneQUVzjNjy; Wed, 9 Feb 2011 22:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4593A68B6; Wed, 9 Feb 2011 22:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110210064502.2182.85531.idtracker@localhost> Date: Wed, 09 Feb 2011 22:45:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-csf-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, 10 Feb 2011 06:45:10 -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 : Indication of Client Failure in MPLS-TP Author(s) : H. Jia, et al. Filename : draft-ietf-mpls-tp-csf-00.txt Pages : 11 Date : 2011-02-09 This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) tool to propagate a client failure indication across an MPLS-TP network in case the propagation of failure status in the client layer is not supported as required in [RFC5860]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-csf-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-csf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-09223042.I-D@ietf.org> --NextPart-- From guoxinchun@huawei.com Thu Feb 10 01:51:45 2011 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 8F00B3A693C; Thu, 10 Feb 2011 01:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 XJPSMaK0xY3p; Thu, 10 Feb 2011 01:51:44 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D6C173A6929; Thu, 10 Feb 2011 01:51:43 -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 <0LGE004EUBE985@szxga04-in.huawei.com>; Thu, 10 Feb 2011 17:51:45 +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 <0LGE009XEBE930@szxga04-in.huawei.com>; Thu, 10 Feb 2011 17:51:45 +0800 (CST) Received: from g67564e ([10.110.98.42]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGE003E3BE4B5@szxml04-in.huawei.com>; Thu, 10 Feb 2011 17:51:45 +0800 (CST) Date: Thu, 10 Feb 2011 17:51:40 +0800 From: g67564 In-reply-to: <4D4A934F.5020206@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org Message-id: <01b501cbc908$1dbba830$5932f890$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: TEXT/PLAIN Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDlrY6pzaQPGLDTRSwwtw9z+OhdgFcUP8g References: <4D4A934F.5020206@pi.nu> Cc: 'Ross Callon' , ahmpls-tp@lists.itu.int Subject: Re: [mpls] wg last call on draft-ietf-mpls-tp-fault-03 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, 10 Feb 2011 09:51:45 -0000 Dear authors After read the document, I have a question about the FM massage procedure. In the section 5.1, the third paragraph, it said "The message is then sent. The message MUST be refreshed two more times at an interval of one second. Further refreshes are sent according to the value of the refresh timer." I don't know why the refreshing massage must be first sent two more times in one second and then sent as the refresh timer interval. Is it ok if the refreshing massage is sent only according to the value of the refresh timer? If it is not, what problem may be introduced? Hope authors could explain it for me. In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format " other than" MPLS-TP OAM Message Format " is more suitable. Best Regards Xinchun -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 7:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: Ross Callon; ahmpls-tp@lists.itu.int Subject: [mpls] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Thu Feb 10 03:08:36 2011 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 8389E3A6955; Thu, 10 Feb 2011 03:08:36 -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 RHrhnwiGs62l; Thu, 10 Feb 2011 03:08:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 36EAD3A6970; Thu, 10 Feb 2011 03:08:34 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1ABqmBC012803; Thu, 10 Feb 2011 05:52:49 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 10 Feb 2011 06:08:35 -0500 From: David Allan I To: Mach Chen , "'Loa Andersson'" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Thu, 10 Feb 2011 06:08:35 -0500 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@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 Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 10 Feb 2011 11:08:36 -0000 =20 Hi Mach:=20 Thanks for the review >I read the draft, here are some comments, please consider: >1.Section 3.5, last sentence of first paragraph >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.= " >There is a "be" lost between "can" and "only". Good catch, will fix. >2.Section 3.5.2 >"1. BFD control packets are received with an unexpected encapsulation (mis= -connectivity defect), these include:=20 > - a PW receiving a packet with a GAL", Since GAL can be used=20 >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), t= his should not be a defect. Suggest to remove it. We'll review and edit accordingly. >3 Section 3.5.2 >" 4. Receipt of an expected session discriminator with an unexpected label= (mis-connectivity defect).", For a receiver, how does it know that the ses= sion >discriminator is valid but the label is invalid? IMHO, this defect is= just another description of defect 3 . Suggest to remove it. If the session discriminator exists in the BFD database, it is superficiall= y a valid descriminator but the label of arrival can be incorrect. This may= indicate an implementation problem at the source MEP. What we were referri= ng to in '3' was a session discriminator that did not exist in the local da= tabase, BFD had never handed it out hence it could not be found. >4.Section 3.5.4.2 >" Exit from a misconfiguration defect occurs when two consecutive CC or=20 >CV frames have been received with the expected M bit setting." IMHO, this = sentence is little bit vague, and since this draft only defines for P2P LSP= , why not just say "...with M bit clear." OK >5. Section 3.5.4.3 >"Exit from a mis-connectivity defect state occurs when no CV messages=20 >have been received with an incorrect source MEP-ID for a period of 3.5 sec= onds.", since there are several defects listed in Section 3.5.2 and this is= only one condition for exiting from a mis-connectivity defect state. How a= bout "Exit >from a mis-connectivity defect state occurs when no CV messages= with mis-connectivity defects have been received for a period of 3.5 secon= ds " That seems to be more accurate, I'd replace "with...." with "indicating an = on-going mis-connectivity defect has been....". Simply wordsmithing. >6. Section 3.5.5 >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state= . Good catch. Will fix Cheers Dave > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, February 03, 2011 10:14 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 >=20 > Working Group, >=20 > this is to start a four week working group last call on "Proactive=20 > Connectivity Verification, Continuity Check and Remote Defect=20 > indication for MPLS Transport Profile" > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs > -- >=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=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Thu Feb 10 03:36:26 2011 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 8F9A63A698F; Thu, 10 Feb 2011 03:36:26 -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 NjzuCnORzw0m; Thu, 10 Feb 2011 03:36:25 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 6B1EC3A697B; Thu, 10 Feb 2011 03:36:24 -0800 (PST) X-AuditID: 93eaf2e7-b7b47ae000005f02-3d-4d53cdc5b6dc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id AD.C1.24322.5CDC35D4; Thu, 10 Feb 2011 13:36:38 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 10 Feb 2011 13:36:35 +0200 From: Alexander Vainshtein To: David Allan I Date: Thu, 10 Feb 2011 13:36:25 +0200 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4A Message-ID: References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , Robert Rennison Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 10 Feb 2011 11:36:26 -0000 Dave and all, I'd like to remind you that Rob and I have already questioned the decision = to change the BFD state machine by disabling in some case the Poll/Final se= quence. The situation as presented in the draft seems to introduce even more proble= ms.=20 E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but f= ollows the procedures specified in RFC 5880 and 5881 which, to the best of = my understanding, include usage of Poll/Final sequence. It is my understanding that BFD for an MPLS-TP LSP would look exactly as BF= D in VCCV (including the same code point). If this is correct, how should the implementation distinguish between "PWE3= mode" (where poll/final are used) and "MPLS-TP mode where they seem to be = prohibited? Regards, Sasha -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Thursday, February 10, 2011 1:09 PM To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@= lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 =20 Hi Mach:=20 Thanks for the review >I read the draft, here are some comments, please consider: >1.Section 3.5, last sentence of first paragraph >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.= " >There is a "be" lost between "can" and "only". Good catch, will fix. >2.Section 3.5.2 >"1. BFD control packets are received with an unexpected encapsulation (mis= -connectivity defect), these include:=20 > - a PW receiving a packet with a GAL", Since GAL can be used=20 >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), t= his should not be a defect. Suggest to remove it. We'll review and edit accordingly. >3 Section 3.5.2 >" 4. Receipt of an expected session discriminator with an unexpected label= (mis-connectivity defect).", For a receiver, how does it know that the ses= sion >discriminator is valid but the label is invalid? IMHO, this defect is= just another description of defect 3 . Suggest to remove it. If the session discriminator exists in the BFD database, it is superficiall= y a valid descriminator but the label of arrival can be incorrect. This may= indicate an implementation problem at the source MEP. What we were referri= ng to in '3' was a session discriminator that did not exist in the local da= tabase, BFD had never handed it out hence it could not be found. >4.Section 3.5.4.2 >" Exit from a misconfiguration defect occurs when two consecutive CC or=20 >CV frames have been received with the expected M bit setting." IMHO, this = sentence is little bit vague, and since this draft only defines for P2P LSP= , why not just say "...with M bit clear." OK >5. Section 3.5.4.3 >"Exit from a mis-connectivity defect state occurs when no CV messages=20 >have been received with an incorrect source MEP-ID for a period of 3.5 sec= onds.", since there are several defects listed in Section 3.5.2 and this is= only one condition for exiting from a mis-connectivity defect state. How a= bout "Exit >from a mis-connectivity defect state occurs when no CV messages= with mis-connectivity defects have been received for a period of 3.5 secon= ds " That seems to be more accurate, I'd replace "with...." with "indicating an = on-going mis-connectivity defect has been....". Simply wordsmithing. >6. Section 3.5.5 >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state= . Good catch. Will fix Cheers Dave > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, February 03, 2011 10:14 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 >=20 > Working Group, >=20 > this is to start a four week working group last call on "Proactive=20 > Connectivity Verification, Continuity Check and Remote Defect=20 > indication for MPLS Transport Profile" > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs > -- >=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=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Thu Feb 10 06:38:14 2011 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 1CA8C3A69C9; Thu, 10 Feb 2011 06:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0qSXzqbMoJG; Thu, 10 Feb 2011 06:38:13 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 275E23A69C6; Thu, 10 Feb 2011 06:38:11 -0800 (PST) X-AuditID: 93eaf2e7-b7b47ae000005f02-46-4d53f86198c5 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 31.69.24322.168F35D4; Thu, 10 Feb 2011 16:38:26 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 10 Feb 2011 16:38:21 +0200 From: Alexander Vainshtein To: David Allan I Date: Thu, 10 Feb 2011 16:38:20 +0200 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBA= Message-ID: References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , Robert Rennison Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 10 Feb 2011 14:38:14 -0000 Dave, and all, To avoid any misinterpretation, please consider the original email as my LC= comment. Regards, Sasha -----Original Message----- From: Alexander Vainshtein=20 Sent: Thursday, February 10, 2011 1:36 PM To: 'David Allan I' Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; Robert Ren= nison Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Dave and all, I'd like to remind you that Rob and I have already questioned the decision = to change the BFD state machine by disabling in some case the Poll/Final se= quence. The situation as presented in the draft seems to introduce even more proble= ms.=20 E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but f= ollows the procedures specified in RFC 5880 and 5881 which, to the best of = my understanding, include usage of Poll/Final sequence. It is my understanding that BFD for an MPLS-TP LSP would look exactly as BF= D in VCCV (including the same code point). If this is correct, how should the implementation distinguish between "PWE3= mode" (where poll/final are used) and "MPLS-TP mode where they seem to be = prohibited? Regards, Sasha -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Thursday, February 10, 2011 1:09 PM To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@= lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 =20 Hi Mach:=20 Thanks for the review >I read the draft, here are some comments, please consider: >1.Section 3.5, last sentence of first paragraph >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.= " >There is a "be" lost between "can" and "only". Good catch, will fix. >2.Section 3.5.2 >"1. BFD control packets are received with an unexpected encapsulation (mis= -connectivity defect), these include:=20 > - a PW receiving a packet with a GAL", Since GAL can be used=20 >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), t= his should not be a defect. Suggest to remove it. We'll review and edit accordingly. >3 Section 3.5.2 >" 4. Receipt of an expected session discriminator with an unexpected label= (mis-connectivity defect).", For a receiver, how does it know that the ses= sion >discriminator is valid but the label is invalid? IMHO, this defect is= just another description of defect 3 . Suggest to remove it. If the session discriminator exists in the BFD database, it is superficiall= y a valid descriminator but the label of arrival can be incorrect. This may= indicate an implementation problem at the source MEP. What we were referri= ng to in '3' was a session discriminator that did not exist in the local da= tabase, BFD had never handed it out hence it could not be found. >4.Section 3.5.4.2 >" Exit from a misconfiguration defect occurs when two consecutive CC or=20 >CV frames have been received with the expected M bit setting." IMHO, this = sentence is little bit vague, and since this draft only defines for P2P LSP= , why not just say "...with M bit clear." OK >5. Section 3.5.4.3 >"Exit from a mis-connectivity defect state occurs when no CV messages=20 >have been received with an incorrect source MEP-ID for a period of 3.5 sec= onds.", since there are several defects listed in Section 3.5.2 and this is= only one condition for exiting from a mis-connectivity defect state. How a= bout "Exit >from a mis-connectivity defect state occurs when no CV messages= with mis-connectivity defects have been received for a period of 3.5 secon= ds " That seems to be more accurate, I'd replace "with...." with "indicating an = on-going mis-connectivity defect has been....". Simply wordsmithing. >6. Section 3.5.5 >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state= . Good catch. Will fix Cheers Dave > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, February 03, 2011 10:14 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 >=20 > Working Group, >=20 > this is to start a four week working group last call on "Proactive=20 > Connectivity Verification, Continuity Check and Remote Defect=20 > indication for MPLS Transport Profile" > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs > -- >=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=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Thu Feb 10 07:58:52 2011 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 CAD073A69C8; Thu, 10 Feb 2011 07:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dqD33fM00oAp; Thu, 10 Feb 2011 07:58:51 -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 DDC593A67B1; Thu, 10 Feb 2011 07:58:50 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="214115459" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2011 15:59:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1AFx1qi001535; Thu, 10 Feb 2011 15:59:01 GMT Received: from dhcp-gpk02-vlan300-64-103-65-98.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p1AFwu806238; Thu, 10 Feb 2011 15:58:56 GMT Message-ID: <4D540B40.4020501@cisco.com> Date: Thu, 10 Feb 2011 15:58:56 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Huub Van Helvoort , Ghani Abbas , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "Lam, Hing-Kam $Kam$" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant Subject: [mpls] Response to Draft revised Recommendation G.8110.1 [Ref#044.03] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:58:52 -0000 Title: Response to Draft revised Recommendation G.8110.1 [Ref#044.03] Submission Date: 10th February 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Thank you for your liaison statement "LS236 - Draft revised Recommendation G.8110.1 [Ref#044.01]" *Summary and General Comments* In general the document should be progressed pending satisfactory resolution of the comments below. We therefore request that the changes and comments identified below are addressed and that we are given a further opportunity to review this draft recommendation before the document is advanced through the ITU-T publications process. The document eliminates Penultimate Hop Popping in several places while saying it is an option in Annex A. I believe Penultimate Hop Popping is allowed, although as Annex A points out, it is not the preferred mode of operation. Given this the text must not mandate that it cannot be used. It would be helpful to the reader if its use was addressed in the modeling. *Major Comments* - Summary, Paragraph 2, 2nd sentence - "In the event of a difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence." The RFCs should take precedence in all cases. Change the text to read: "In the event of a difference between this ITU-T Recommendation and any of the referenced IETF RFCs, the RFCs take precedence." - Section 10 MPLS-TP DiffServ Architecture, paragraph 3 states: "The setting of the traffic class (TC) field is as defined in [IETF RFC 3270] and [IETF RFC 5462] for the short-pipe and uniform models with no Penultimate Hop Popping (PHP)." However Annex A allows PHP. Please change the text to "The setting of the traffic class (TC) field is as defined in [IETF RFC 3270] and [IETF RFC 5462] for the short-pipe and uniform models." - Section 10 MPLS-TP DiffServ Architecture, paragraph 5 states: "In order to support short-pipe and uniform tunnelling modes, as defined in [IETF RFC 3270], the Server/MT_A_So function is configured, on individual MT_CP basis, to encode the TC field based on one of the following QoS Encoding Modes: - QoS Encoding Mode A where the TC field is encoded according to the outgoing PHB information; - QoS Encoding Mode B where the TC field is encoded with any value (representing non-meaningful Diff-Serv information)." The TC field must never be used for any purposed other than encoding traffic class information. Please remove Mode B and add the following text "The TC field is encoded and used for QoS indications or, if not used, is silently ignored." - Section 10.1.1 Short Pipe Model, 1st sentence: "The transport processing functions and processes for the short-pipe model (without penultimate hop popping) are described in Figure 10-1. Remove "(without penultimate hop popping)" from the sentence per the inconsistency with Annex A highlighted in the comment above. Please add a second figure showing the PHP case for consistency with Annex A. - Section 10.1.2 Uniform Model, 1st sentence: "The transport processing functions and processes for the Uniform model (without penultimate hop popping) are described in Figure 10-2. Remove "(without penultimate hop popping)" from the sentence per the inconsistency with Annex A highlighted in the comment above. Please add a second figure showing the PHP case for consistency with Annex A. *Minor Comments* - Section 1 Scope, paragraph 6 - "MPLS-TP is a connection-oriented packet-switched transport layer network technology that uses MPLS-TP LSPs and PWs" Should read "MPLS-TP is a connection-oriented packet-switched transport layer network technology that uses PWs and MPLS-TP LSPs per the definition in section 1.3.4 of RFC 5921]" There is no definition of an MPLS-TP PW, and the text should be clear on the definition of an MPLS-TP LSP. - Section 1 Scope, paragraph 6 - "... allows consistent operations with other transport technologies" should be "... allows operation consistent with other transport technologies." - Section 2 References - What is the reason for moving the Survivability framework draft reference (top of page 8) to the Bibliography (bottom of page 46)? It is still listed in the "Scope" clause (1), Functional architecture clause (6), MPLS-TP MEG clause (8.1.3), MPLS-TP survivability techniques clause (9) and Security aspects clause (12). Since the referenced document has now been approved for publication as an RFC, it would make sense to move this reference back to the References section from the Bibliography. - Section 6.1 MPLS-TP Network Layered Structure - No definition of "the MPLS-TP network architecture". Please provide a reference to the definition of the architecture. Reference section 1.3 of RFC 5921. - Section 6.1 MPLS-TP Network Layered Structure - "PWs in MPLS-TP can only be carried over MPLS-TP LSPs." should be "While PWs can only be carried over MPLS LSPs, this document only addresses the case where PWs are carried over MPLS-TP LSPs." The structure as defined is overly restrictive. - Section 6.1 MPLS-TP Network Layered Structure - "The MPLS architecture does not have a minimum packet length. When MPLS packets are transmitted over a non-MPLS-TP server layer with a minimum frame size, the Server/MPLS-TP adaptation function will pad these packets to the minimum frame size of that non-MPLS-TP server layer. This padding is removed at the adaptation sink of the non-MPLS client. The mechanisms for mapping clients over MPLS-TP provide appropriate information (e.g. the length field in the Control Word) to remove the padding at that MPLS-TP/Client adaptation sink function." This paragraph discusses MPLS client adaptation to non-MPLS-TP server layers. Please explain the relevance to MPLS-TP Network Layered Structure. - Figure 6-5 see comment on Section 1 Scope paragraph 6. - Section 6.1.2/6.2.3.1 MPLS Trail Termination section 6.1.2 states "the assignment of the S and TTL fields in the LSP or PW Label Stack Entry (LSE) of a G-ACh packet is defined in the MPLS-TP Trail Termination (MT_TT) function" however, nothing is mentioned about the S bit in section 6.2.3.1. - Section 6.1.2 MPLS-TP Characteristic Information - States "The MT_CI traffic units (MT_CI_D) are accompanied by the MT_CI_iPHB, MT_CI_oPHB, MT_CI_SSF and optional MT_CI_APS signals." There is no definition of MT_CI_APS that I can find in G.8110 or other ITU-T documents. Please add specific normative references to the definition of MT_CI_APS. - Section 6.4 MPLS-TP Network Topology Last sentence before section 6.4.1 "The control plane aspects are out of the scope of this Recommendation." should read "The control plane aspects are not prohibited, but are outside the scope of this Recommendation." Control plane function is part of the MPLS-TP requirements. - Section 6.4.1 Unidirectional and bidirectional connections and trails - Need to clarify this text. It sounds like unidirectional connections in the server layer cannot be combined to carry bidirectional MPLS-TP connections. If this is the intention of the text, it should be brought out more strongly. However, it seems like an unnecessary restriction. - Figure 6-9 - Point to multipoint MPLS-TP subnetwork connection - The previous paragraph states the traffic is broadcast from the root to the leaves. Yet in this figure there are some leaves not receiving the broadcast. Is the traffic multicast instead of broadcast and if so what is the criteria of the multicast? Also if the traffic is sent from root to leaf, what are the horizontal inter leaf communications in the figure? The horizontal lines are labeled "MPLS-TP LC" which may indicate to the reader the exit from the subnetwork, however it is unclear whether they indicate this or communication paths. - Section 6.5 MPLS-TP Label Behavior, 1st sentence - It would be good to provide some specifics here. This sentence references hundreds of pages of documentation not all of which is relevant to label allocation and behavior. - Section 6.5.2 last paragraph before 6.5.3 states "When a request is made to a label manager, a particular label value can be suggested. However there is no guarantee that the suggested label value would be allocated." How is a particular label suggested? If done via management this function is outside the scope of the recommendation. If done via the control plane, this is also outside the scope of the recommendation. In either case, this is an internal function and should be removed from the text. - Section 7 Server/Client Associations states "- MT/client adaptation, where the client is not MPLS-TP. - MT/MT adaptation, for supporting hierarchical MPLS-TP LSPs." - See comment on section 1 regarding "MPLS-TP LSPs". It is not clear whether MPLS is included or excluded as a client in the context of MPLS-TP LSPs. Please clarify. - Section 7.1.1 MT/ETH adaptation, 3rd paragraph, 1st bullet - The text says "Insert the CW word..." Insert between what? It isn't clear what the starting data is for these steps. - Section 7.1.1 MT/ETH adaptation, 3rd paragraph, after 1st bullet - Add "If required, the CW is inserted between and . The sequence number processing may be performed." Without this text it is inconsistent with the 4th paragraph last bullet. and should indicate the points of insertion that will be clarified by the comment above. - Section 7.2 MT/MT adaptation, 3rd paragraph, 3rd bullet - What protocol is the CI_APS based? Please provide a specific normative reference for the definition and details of CI_APS. - Section 7.3 Server/MT adaptation states: "Further definition of the processes to adapt MPLS-TP to server layers is outside the scope of this Recommendation and will be described in [b-ITU-T G.8121]." Shouldn't this say "is described in [b-ITU-T G.8121]"? - Section 8 MPLS-TP OAM Architecture - States "The MPLS-TP OAM mechanisms and implementation are outside the scope of this Recommendation." Change this text to "The MPLS-TP OAM mechanisms are defined in the IETF RFCs and are outside the scope of this Recommendation." *Editorial Comments* - Section 6.2.1.3 MPLS-TP Link uses the access group term before it is defined in 6.2.1.4. It is recommended to swap these sections in the document order. - Figure 6-8 - The arrow should point to MT LC vs. TM LC. - Section 10.1 seems to be missing. The text jumps from section 10 to 10.1.1. From stbryant@cisco.com Thu Feb 10 08:17:00 2011 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 731153A69C5; Thu, 10 Feb 2011 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kJ--37fM4aF1; Thu, 10 Feb 2011 08:16:59 -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 3724B3A67B1; Thu, 10 Feb 2011 08:16:59 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="214122342" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2011 16:17:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AGH9xZ010389; Thu, 10 Feb 2011 16:17:09 GMT Received: from dhcp-gpk02-vlan300-64-103-65-98.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p1AGH5808335; Thu, 10 Feb 2011 16:17:06 GMT Message-ID: <4D540F81.50306@cisco.com> Date: Thu, 10 Feb 2011 16:17:05 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg , Hiroshi Ota , IAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , Greg , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "ITU-T SG15 TSB"@cisco.com, "Lam, Hing-Kam $Kam$" , =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant , Huub Van Helvoort , Ghani Abbas Subject: [mpls] Response to Updated draft Recommendation G.8121 [Ref 042.03] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:17:00 -0000 Title: Response to Updated draft Recommendation G.8121 [Ref 042.03] Submission Date: 10th February 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int iab@ietf.org CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Deadline: 15th March 2011 Thank you for your updated liaison statement "LS232 - Updated draft Recommendation G.8121 [Ref 042.01]" attaching WD19r2. Please may I refer you to our earlier response of 15th January 2011 entitled "Response to Updated draft Recommendation G.8121 [Ref 042.02]" Additionally, since the text of draft Recommendation for G.8121 is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in "Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012)" (Geneva, 1 � 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en. As a consequence the MPLS WG has not been asked to review this Draft Recommendation by the IETF management. When the ITU-T SG15 liaises a draft Recommendation written in accordance with the above agreement, IETF management will ask the MPLS WG to perform an in depth review. We look forward to receiving your next draft. Please can we take this opportunity state that the IETF is committed to developing the MPLS-TP solution as described in the Joint Working Team Recommendations and meeting the jointly agreed MPLS-TP requirements documented in RFC5654. From guoxinchun@huawei.com Thu Feb 10 17:39:30 2011 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 1F3F13A6971; Thu, 10 Feb 2011 17:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 3sgTbNIW8I1m; Thu, 10 Feb 2011 17:39:29 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 237123A67D2; Thu, 10 Feb 2011 17:39:29 -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 <0LGF005H2J9RIJ@szxga04-in.huawei.com>; Fri, 11 Feb 2011 09:39:27 +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 <0LGF00GM4J9R7J@szxga04-in.huawei.com>; Fri, 11 Feb 2011 09:39:27 +0800 (CST) Received: from g67564e ([10.110.98.42]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGF00AESJ9MX5@szxml04-in.huawei.com>; Fri, 11 Feb 2011 09:39:27 +0800 (CST) Date: Fri, 11 Feb 2011 09:39:22 +0800 From: Xinchun Guo In-reply-to: <4D4A934F.5020206@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org Message-id: <020201cbc98c$8269d750$873d85f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: TEXT/PLAIN Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDlq57z2Yieu+sT1qv11A4xrFRrgF9U4SA References: <4D4A934F.5020206@pi.nu> Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 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, 11 Feb 2011 01:39:30 -0000 Dear authors After read the document, I have a question about the FM massage procedure. In the section 5.1, the third paragraph, it said "The message is then sent. The message MUST be refreshed two more times at an interval of one second. Further refreshes are sent according to the value of the refresh timer." I don't know why the refreshing massage must be first sent two more times in one second and then sent as the refresh timer interval. Is it ok if the refreshing massage is sent only according to the value of the refresh timer? If it is not, what problem may be introduced? Hope authors could explain it for me. In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format " other than" MPLS-TP OAM Message Format " is more suitable. Best Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 7:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From mach@huawei.com Fri Feb 11 00:14:14 2011 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 751883A68BB; Fri, 11 Feb 2011 00:14:14 -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 VzN7SgovTT80; Fri, 11 Feb 2011 00:14:13 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DA38C3A681D; Fri, 11 Feb 2011 00:14:12 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGG001OM1G1V1@szxga05-in.huawei.com>; Fri, 11 Feb 2011 16:12:01 +0800 (CST) Received: from C55527A ([10.110.98.33]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGG00MMG1FWCS@szxga05-in.huawei.com>; Fri, 11 Feb 2011 16:12:01 +0800 (CST) Date: Fri, 11 Feb 2011 16:11:56 +0800 From: Mach Chen In-reply-to: <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> To: 'David Allan I' , 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org, ahmpls-tp@lists.itu.int Message-id: <075b01cbc9c3$5a4ca810$0ee5f830$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oA References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 11 Feb 2011 08:14:14 -0000 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. > > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may indicate an > implementation problem at the source MEP. What we were referring to in '3' > was a session discriminator that did not exist in the local database, BFD had > never handed it out hence it could not be found. > OK, but more clarification text would be helpful. Best regards, Mach From dongjie_dj@huawei.com Fri Feb 11 00:44:10 2011 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 A469A3A6A43; Fri, 11 Feb 2011 00:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 FuvzyIzK9DyT; Fri, 11 Feb 2011 00:44:09 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 970973A69DD; Fri, 11 Feb 2011 00:44:09 -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 <0LGG00GC62XNVI@szxga04-in.huawei.com>; Fri, 11 Feb 2011 16:44:11 +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 <0LGG00KIK2XNJT@szxga04-in.huawei.com>; Fri, 11 Feb 2011 16:44:11 +0800 (CST) Received: from D65110A ([10.110.98.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGG004V72XITN@szxml04-in.huawei.com>; Fri, 11 Feb 2011 16:44:11 +0800 (CST) Date: Fri, 11 Feb 2011 16:44:06 +0800 From: Jie Dong In-reply-to: <4D4A9478.7050704@pi.nu> To: mpls-tp@ietf.org, mpls@ietf.org Message-id: <021101cbc9c7$d7c8b140$875a13c0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: TEXT/PLAIN Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1g References: <4D4A9478.7050704@pi.nu> Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-linear-protection-04 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, 11 Feb 2011 08:44:10 -0000 Dear authors, Here are some comments on linear protection draft. 1. In section 1.2, it says: " The basic protocol is designed for use in conjunction with the 1:1 protection architecture (for both unidirectional and bidirectional protection) and for 1+1 protection of a bidirectional path (for both unidirectional and bidirectional protection switching). " Would you please explain why coordination is needed for unidirectional protection switching in 1+1 protection of a bidirectional path? Because section 4.7.2 of tp-survive-fwk says: "In 1+1 unidirectional protection switching there is no need to coordinate the protection state between the protection controllers at both ends of the protection domain." I guess you mean 1+1 protection may need coordination to keep traffic on co-routed paths, but that would be bidirectional protection switching. Hope this could be made clearer in this draft. 2. Section 2.1, Acronyms The full name of "LER" should be "Label Edge Router" "PST" is an old term replaced by SPME (Sub-Path Maintenance Entity), but neither is used in the following sections, so it may be removed from acronyms. 3. In Section 3, there is only one level-2 subsection (3.1), so what about promote the level-3 subtitles (3.1.1, 3.1.2, ...) to level-2, and level-4 (3.1.6.1) to level-3? 4. Section 4, 3rd paragraph, s/single-phase/single-phased, to be consistent with 2nd paragraph. 5. Section 4.1, 4th paragraph, " In the event a signal fail condition is detected on the protection path, the received PSC specific information should be evaluated." The statement is vague. What would be the state and action when a signal fail is detected on the protection path? Would you please elaborate on this point? 6. Section 4.2.2, 4th paragraph, " The Fpath field SHALL identify the path that is reporting the failure condition (i.e. if protection path then Fpath is set to 0...". Since PSC message are only transmitted on protection path, if protection path has signal fail, the PSC message may not be able to be sent out to far-end. 7. Section 4.3.2, there is signal degrade on working path as input, but no signal degrade on protection path. 8. Section 4.3.3, I go through this part fast, a general question is: are the PSC operations for 4 different protection types identical ? In this section there is no description about operation of each specific protection type, but to my understanding, there may be different operations, e.g., for bidirectional 1:1 protection, the end point may need to switch the sink selector and transmitting bridge simultaneously according to some input, but for unidirectional 1:1 the end point may only need to switch the transmitting bridge OR the sink selector. And the PSC message sent may also be different for different protection types. (Please correct me if there is anything wrong with this thought). Best Regards, Jie > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Thursday, February 03, 2011 7:42 PM > To: mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-linear-protection-04 > > Working Group, > > this is to start a four week working group last call on > "MPLS-TP Linear Protection" (draft-ietf-mpls-tp-linear-protection-04). > > Please send comments to the mpls-tp@ietf.org mailing list. > > This working group last call ends on February 28, 2011. > > > > Loa, George and Ross > > 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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From guoxinchun@huawei.com Fri Feb 11 01:53:32 2011 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 24A933A688F; Fri, 11 Feb 2011 01:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 u35drlYcj7MU; Fri, 11 Feb 2011 01:53:31 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 27ADF3A685A; Fri, 11 Feb 2011 01:53:31 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGG002P563246@szxga05-in.huawei.com>; Fri, 11 Feb 2011 17:52:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGG00ELT631LS@szxga05-in.huawei.com>; Fri, 11 Feb 2011 17:52:13 +0800 (CST) Received: from g67564e ([10.110.98.42]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGG00B0Z62WFI@szxml04-in.huawei.com>; Fri, 11 Feb 2011 17:52:13 +0800 (CST) Date: Fri, 11 Feb 2011 17:52:08 +0800 From: Xinchun Guo In-reply-to: <020201cbc98c$8269d750$873d85f0$@com> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org Message-id: <020701cbc9d1$594011b0$0bc03510$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: TEXT/PLAIN Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDlq57z2Yieu+sT1qv11A4xrFRrgF9U4SAAAVBXrA= References: <4D4A934F.5020206@pi.nu> <020201cbc98c$8269d750$873d85f0$@com> Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 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, 11 Feb 2011 09:53:32 -0000 Other 3 edit comments, see below. 1.section 2.2, there is overlapping between the last sentence of the first paragraph and the first sentence of the second paragraph about " The purpose of the LKR message is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs" . Simplify it will be more smart. 2.section 4.1.2, the first sentence" This TLV carries the Interface Identifier as defined ......", "the Interface Identifier" should be "the Global Identifier". right? 3. section 5.3, there are two "that" in the first sentence, one is redundancy. Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Xinchun Guo Sent: Friday, February 11, 2011 9:39 AM To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Dear authors After read the document, I have a question about the FM massage procedure. In the section 5.1, the third paragraph, it said "The message is then sent. The message MUST be refreshed two more times at an interval of one second. Further refreshes are sent according to the value of the refresh timer." I don't know why the refreshing massage must be first sent two more times in one second and then sent as the refresh timer interval. Is it ok if the refreshing massage is sent only according to the value of the refresh timer? If it is not, what problem may be introduced? Hope authors could explain it for me. In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format " other than" MPLS-TP OAM Message Format " is more suitable. Best Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 7:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross 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 _______________________________________________ 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 Internet-Drafts@ietf.org Fri Feb 11 02:00:02 2011 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 85E3F3A69DD; Fri, 11 Feb 2011 02:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 5WbnphkFrE3b; Fri, 11 Feb 2011 02:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8783A6860; Fri, 11 Feb 2011 02:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110211100001.6688.55753.idtracker@localhost> Date: Fri, 11 Feb 2011 02:00:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-framework-11.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, 11 Feb 2011 10:00: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 : Operations, Administration and Maintenance Framework for MPLS-based Transport Networks Author(s) : D. Allan, et al. Filename : draft-ietf-mpls-tp-oam-framework-11.txt Pages : 65 Date : 2011-02-11 The Transport Profile of Multi-Protocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications 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 as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-11.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-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-11014539.I-D@ietf.org> --NextPart-- From david.i.allan@ericsson.com Fri Feb 11 02:11:40 2011 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 B23F23A6A70; Fri, 11 Feb 2011 02:11: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOTNO63niOl7; Fri, 11 Feb 2011 02:11:39 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id ACEFF3A6A6D; Fri, 11 Feb 2011 02:11:39 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p1BABp9r018454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Feb 2011 04:11:51 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 11 Feb 2011 05:11:50 -0500 From: David Allan I To: Mach Chen , "'Loa Andersson'" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Fri, 11 Feb 2011 05:11:40 -0500 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oAAA0+koA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <075b01cbc9c3$5a4ca810$0ee5f830$@com> In-Reply-To: <075b01cbc9c3$5a4ca810$0ee5f830$@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 Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 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, 11 Feb 2011 10:11:40 -0000 OK, will do... Dave=20 -----Original Message----- From: Mach Chen [mailto:mach@huawei.com]=20 Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls= -tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the=20 > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. >=20 > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may=20 > indicate an > implementation problem at the source MEP. What we were referring to in '3= ' > was a session discriminator that did not exist in the local database,=20 > BFD had > never handed it out hence it could not be found. >=20 OK, but more clarification text would be helpful. Best regards, Mach From wwwrun@core3.amsl.com Thu Feb 10 23:39:51 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 55BE63A6B11; Thu, 10 Feb 2011 23:39:51 -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: <20110211073951.55BE63A6B11@core3.amsl.com> Date: Thu, 10 Feb 2011 23:39:51 -0800 (PST) X-Mailman-Approved-At: Fri, 11 Feb 2011 06:15:47 -0800 Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, mpls-tp@ietf.org, Matthew.Bocci@alcatel-lucent.com, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, andrew.g.malis@verizon.com, hhelvoort@huawei.com, elisa.bellagamba@ericsson.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Status of the IETF MPLS-TP project documents 2011-02-11 (ref #052.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: Fri, 11 Feb 2011 07:39:51 -0000 Title: Status of the IETF MPLS-TP project documents 2011-02-11 (ref #052.01) Submission Date: 2011-02-10 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1013 From: Loa Andersson(IETF MPLS WG) To: SG15, Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com rcallon@juniper.net db3546@att.com lberger@labn.net andrew.g.malis@verizon.com Matthew.Bocci@alcatel-lucent.com Purpose: For information Body: The chairs of the MPLS, PWE3, and CCAMP working group would like to inform you of the status of the MPLS-TP project within the IETF. The attached document shows the many MPLS-TP documents that have been worked on within the IETF, and shows what formal input has been provided by SG15 of the ITU-T. We would like to take this opportunity to thank the many experts from SG15 who have contributed to this work by participating through the normal IETF process. Loa Andersson (MPLS WG Co-chair) Lou Berger (CCAMP WG Co-chair) Matthew Bocci (PWE3 WG Co-chair) Deborah Brungard (CCAMP WG Co-chair) Ross Callon (MPLS WG Co-chair) Andrew Malis (PWE3 WG Co-chair) George Swallow (MPLS WG Co-chair) Attachment(s): Status of MPLS-TP Documents Under Development in the IETF � February 10, 2011 (https://datatracker.ietf.org/documents/LIAISON/file1186.doc) From stbryant@cisco.com Fri Feb 11 08:38:37 2011 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 C50413A68C0; Fri, 11 Feb 2011 08:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dcKgE58Hw+Rn; Fri, 11 Feb 2011 08:38:36 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8FF773A6405; Fri, 11 Feb 2011 08:38:36 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="214320922" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Feb 2011 16:38:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1BGcnJf018618; Fri, 11 Feb 2011 16:38:49 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p1BGce805694; Fri, 11 Feb 2011 16:38:41 GMT Message-ID: <4D556610.1010204@cisco.com> Date: Fri, 11 Feb 2011 16:38:40 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Huub Van Helvoort , Ghani Abbas , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "Lam, Hing-Kam $Kam$" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant Subject: [mpls] Response to Updated draft Recommendation G.8151 [Ref 045.03] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:38:38 -0000 Title: Response to Updated draft Recommendation G.8151 [Ref 045.03] Submission Date: 11th February 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Thank you for your liaison statement "LS237 - Updated draft Recommendation G.8151 [Ref 045.01]" The IETF Routing Area Directorate have performed an initial review of the liaised text of draft Recommendation G.8151. We are concerned that this draft recommendation has been aligned with draft-bhh-mpls-tp-oam-y1731-06, since this is not an MPLS OAM protocol deigned within the IETF Standards Process. In particular we note that document only specifies the ICC-based MEG_ID and is therefore missing the IP based identifiers specified in draft-ietf-mpls-tp-identifiers-03. The MEP_ID is also not aligned with the MEP_ID defined in the above IETF draft. We are also concerned that this document defines an MPLS-TP MEL since a MEL is not a construct supported in MPLS-TP. We look forward to receiving a revised version of the draft Recommendation that is aligned with the jointly agreed MPLS-TP design. Please can we take this opportunity state that the IETF is committed to developing the MPLS-TP solution as described in the Joint Working Team Recommendations and meeting the jointly agreed MPLS-TP requirements documented in RFC5654. From ice@cisco.com Fri Feb 11 11:47:49 2011 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 0C88C3A6A3E for ; Fri, 11 Feb 2011 11:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 rqzQyKuZ2csv for ; Fri, 11 Feb 2011 11:47:47 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5EAC73A6A01 for ; Fri, 11 Feb 2011 11:47:47 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1BJVOjD000704; Fri, 11 Feb 2011 20:31:24 +0100 (CET) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1BJVN3G001447; Fri, 11 Feb 2011 20:31:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <29649.1289925038@erosen-linux> Date: Fri, 11 Feb 2011 20:31:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3724E3BF-B704-4F8C-995D-7A4278081BD7@cisco.com> References: <29649.1289925038@erosen-linux> To: erosen@cisco.com X-Mailer: Apple Mail (2.1081) Cc: "mpls@ietf.org" , Stewart Bryant Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11 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, 11 Feb 2011 19:47:49 -0000 Hi Eric, Thanks for the comments, I've incorporated all of them. I will also remove section 3 in the next revision if I don't get further = comments from the list. Thx, Ice. On 16 Nov 2010, at 17:30, Eric Rosen wrote: >=20 > I am delighted to see this draft moving forward, but there are a few = minor > things I think need to be fixed first. >=20 > 1. Section 3 >=20 > I suggest removing this entire section, as it has no relevant = content. >=20 > All it says is that it is possible to send a packet to the root of = an > P2MP LSP and then for the root to distribute the packet down the = LSP. > While this is perfectly true, nothing is said about how to make this > happen. Apparently this section is really a placeholder for = something > that was supposed to be "described in a later revision". Since that > material was never provided, this section doesn't really say = anything > useful. >=20 > The last two paragraphs of this section make unsubstantiated claims = about > the value or lack thereof of using a P2MP LSP in this manner. The > advantages of using one or another technique for some application = depends > on the application and is outside the scope of this document. >=20 > 2. IANA Considerations: LDP MP Opaque Value Element >=20 > The draft calls for IANA to create a new registry for "LDP MP Opaque > Value Element types". However, it fails to specify the allocation > policy. Also, the size of the field, as specified in section 2.3, = is > only one octet. The use of a non-extensible one-octet type field = is, I > think, a bad practice. I've made this mistake often, and have = always > ended up regretting it. >=20 > I would suggest that we define a particular value of the octet, say = 255, > to mean that the next two bytes contain an "extended type code". = Let's > ask IANA to create two registries: >=20 > a. LDP MP Opaque Value Element Basic type >=20 > The range will be 0-255, with the following values defined in = this > document: >=20 > 1: Generic LSP identifier > 255: Extended Type field is present in the following two bytes >=20 > I propose that the allocation policy for this field should be > "Standards Action with Early Allocation". >=20 > b. LDP MP Opaque Value Element Extended type: >=20 > The range will be 0-65335, with the following allocation = policies: >=20 > 0-32767: Standards Action with Early Allocation > 32768-65535: First Come, First Served >=20 > I would propose modifying section 2.3 to include a second diagram, = i.e.: >=20 > The LDP MP Opaque Value Element is encoded as follows: >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type < 255 | Length | Value ... = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | > ~ = ~ > | = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > or >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 255 | Extended Type | Length = (high) | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | Length (low) | Value = | > +-+-+-+-+-+-+-+-+ > ~ = ~ > | = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > BTW the existing picture in the draft needs to have the two rows = of bit > numbers shifted one to the right, as done above. >=20 > Also BTW, the IANA Considerations first paragraph and last = paragraph > seem to call for the creation of the same registry. >=20 > The draft also calls for a second registry to be created by IANA = for > LDP MP Status Value Element type. The same considerations may = apply. >=20 > 3. The acronym "mLDP". >=20 > This acronym is defined only in the abstract, and then is used in > sections 5 and 10. I think it needs to be defined in section 1.2 > (terminology). Even so, the RFC Editor is bound to ask why "LDP" is = used > in some places and "mLDP" in others; we might want to make this more > uniform. >=20 > 4. Section 2.1 diagram: >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| P2MP Capability (TBD IANA)| Length (=3D 1) = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Reserved | > +-+-+-+-+-+-+-+-+ >=20 > I believe the above is a corrected rendition. >=20 > 5. Section 4.1 diagram: >=20 > The diagram in the draft is: >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| MP2MP Capability (TBD IANA) | Length (=3D 1) = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Reserved | > +-+-+-+-+-+-+-+-+ >=20 > This shows 2 flags, a 15-bit capability value, and a 15-bit length = field. >=20 > Is that the intention? >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lizhong.jin@zte.com.cn Fri Feb 11 17:55:19 2011 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 19F203A6A72 for ; Fri, 11 Feb 2011 17:55:19 -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 y5r8tNh3giGg for ; Fri, 11 Feb 2011 17:55:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A04AC3A6A50 for ; Fri, 11 Feb 2011 17:55:17 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510806486374; Sat, 12 Feb 2011 09:53:25 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.4940600559; Sat, 12 Feb 2011 09:55:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1C1tLlG033774; Sat, 12 Feb 2011 09:55:21 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: "Ice " MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Sat, 12 Feb 2011 09:54:49 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-02-12 09:55:22, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-02-12 09:55:22, Serialize complete at 2011-02-12 09:55:22, S/MIME Sign failed at 2011-02-12 09:55:22: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-12 09:55:21, Serialize complete at 2011-02-12 09:55:21 Content-Type: multipart/alternative; boundary="=_alternative 000A900448257835_=" X-MAIL: mse01.zte.com.cn p1C1tLlG033774 Cc: duan.hongfang@zte.com.cn, eckert@cisco.com, mnapierala@att.com, mpls@ietf.org Subject: [mpls] PHP of draft-ietf-mpls-mldp-in-band-signaling-03 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, 12 Feb 2011 01:55:19 -0000 This is a multipart message in MIME format. --=_alternative 000A900448257835_= Content-Type: text/plain; charset="US-ASCII" Hi Ice, >From the technical point of view, the leaf node (will never be Bud node, if ensure) can enable PHP if LSP carries IP multicast traffic (application described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud node should always disable the PHP. But the problem is that one leaf node may become a bud node in future. Then what is the PHP behavior for draft-ietf-mpls-mldp-in-band-signaling-03? draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior for node, does that mean the application binding P2MP/MP2MP LSP should address the PHP behavior? Thanks Lizhong -------------------------------------------------------- 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 000A900448257835_= Content-Type: text/html; charset="US-ASCII"
Hi Ice,
From the technical point of view, the leaf node (will never be Bud node, if ensure) can enable PHP if LSP carries IP multicast traffic (application described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud node should always disable the PHP. But the problem is that one leaf node may become a bud node in future. Then what is the PHP behavior for draft-ietf-mpls-mldp-in-band-signaling-03?
draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior for node, does that mean the application binding P2MP/MP2MP LSP should address the PHP behavior?

Thanks
Lizhong
-------------------------------------------------------- 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 000A900448257835_=-- From eckert@cisco.com Sat Feb 12 01:27:51 2011 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 A36E03A6AB9 for ; Sat, 12 Feb 2011 01:27:51 -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 KfV6KBxlP3Br for ; Sat, 12 Feb 2011 01:27:50 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8F7A93A6AAF for ; Sat, 12 Feb 2011 01:27:50 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,461,1291593600"; d="scan'208";a="261857610" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2011 09:28:07 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1C9S78J024654; Sat, 12 Feb 2011 09:28:07 GMT Received: from mcast-linux1.cisco.com (mdt-linux4 [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id p1C9S7Ie018200; Sat, 12 Feb 2011 01:28:07 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p1C9S5qF018198; Sat, 12 Feb 2011 01:28:05 -0800 Date: Sat, 12 Feb 2011 01:28:05 -0800 From: Toerless Eckert To: lizhong.jin@zte.com.cn Message-ID: <20110212092805.GU22898@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: mnapierala@att.com, mpls@ietf.org, Ice , duan.hongfang@zte.com.cn Subject: Re: [mpls] PHP of draft-ietf-mpls-mldp-in-band-signaling-03 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, 12 Feb 2011 09:27:51 -0000 Why do we want to bother about PHP with mLDP. inv(Nike): Just don't do it. I've still not seen an mentioning of benefits, eg: performance downside is IMHO a historical argument. With inband signaling, i also have the most simple example of why it can break things. If the downstream PE wants to fail over for the same (S,G) between two headend PE, then it is that last-hop label that provides the ability to drop the currently unwanted version of the (S,G) flow during switchover. The same would be true for any other switchover cases on the tailend PE between different LSPs. Or just the generic considerations: I only want labelled multicast packet on my core, that way i can much better distinguish them from my native multicast packets on the CE side. I want mLDP to stay simple, and consistently doing label binding all the way from headend LSR to tailend LSR makes the last hop not a special case where i need to spend always level of design considerations. On Sat, Feb 12, 2011 at 09:54:49AM +0800, lizhong.jin@zte.com.cn wrote: > Hi Ice, > From the technical point of view, the leaf node (will never be Bud node, > if ensure) can enable PHP if LSP carries IP multicast traffic (application > described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud > node should always disable the PHP. But the problem is that one leaf node > may become a bud node in future. Then what is the PHP behavior for > draft-ietf-mpls-mldp-in-band-signaling-03? > draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior for node, does > that mean the application binding P2MP/MP2MP LSP should address the PHP > behavior? > > Thanks > Lizhong > > -------------------------------------------------------- > 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. -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture Network Agnostic: Applications that work best on cheap, stupid networks. Suicide: Devaluating the intelligent network with network agnostic apps. From lizhong.jin@zte.com.cn Sat Feb 12 06:44:19 2011 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 5D5723A697D for ; Sat, 12 Feb 2011 06:44:19 -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 lyVGh3Y9G5Wd for ; Sat, 12 Feb 2011 06:44:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7648F3A6964 for ; Sat, 12 Feb 2011 06:44:17 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510806486374; Sat, 12 Feb 2011 22:42:27 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16200.4940600559; Sat, 12 Feb 2011 22:36:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1CEiQBt053586; Sat, 12 Feb 2011 22:44:26 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <20110212092805.GU22898@cisco.com> To: Toerless Eckert MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Sat, 12 Feb 2011 22:43:53 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-02-12 22:44:28, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-02-12 22:44:28, Serialize complete at 2011-02-12 22:44:28, S/MIME Sign failed at 2011-02-12 22:44:28: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-12 22:44:28 Content-Type: multipart/alternative; boundary="=_alternative 0050F9B248257835_=" X-MAIL: mse01.zte.com.cn p1CEiQBt053586 Cc: duan.hongfang@zte.com.cn, mnapierala@att.com, Ice , mpls@ietf.org Subject: Re: [mpls] PHP of draft-ietf-mpls-mldp-in-band-signaling-03 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, 12 Feb 2011 14:44:19 -0000 This is a multipart message in MIME format. --=_alternative 0050F9B248257835_= Content-Type: text/plain; charset="US-ASCII" Hi Toerless, It is not my intention to allow PHP for mLDP, and I agree with you to disable PHP for mLDP. Since PHP is the default function in many current MPLS implementations, it is necessary for the mLDP in-band signaling draft to explicitly describe whether PHP should be always disabled or enabled, so as to avoid misunderstanding. Lizhong Toerless Eckert wrote on 2011-02-12 17:28:05: > Why do we want to bother about PHP with mLDP. > > inv(Nike): Just don't do it. > > I've still not seen an mentioning of benefits, eg: > performance downside is IMHO a historical argument. > > With inband signaling, i also have the most simple example of > why it can break things. > If the downstream PE wants to fail over for the same (S,G) > between two headend PE, then it is that last-hop label that > provides the ability to drop the currently unwanted version of the > (S,G) flow during switchover. The same would be true for any other > switchover cases on the tailend PE between different LSPs. > > Or just the generic considerations: > > I only want labelled multicast packet on my core, that way i can much better > distinguish them from my native multicast packets on the CE side. > > I want mLDP to stay simple, and consistently doing label > binding all the way from headend LSR to tailend LSR makes the > last hop not a special case where i need to spend always level of > design considerations. > > > On Sat, Feb 12, 2011 at 09:54:49AM +0800, lizhong.jin@zte.com.cn wrote: > > Hi Ice, > > From the technical point of view, the leaf node (will never be Bud node, > > if ensure) can enable PHP if LSP carries IP multicast traffic > (application > > described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud > > node should always disable the PHP. But the problem is that oneleaf node > > may become a bud node in future. Then what is the PHP behavior for > > draft-ietf-mpls-mldp-in-band-signaling-03? > > draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior fornode, does > > that mean the application binding P2MP/MP2MP LSP should address the PHP > > behavior? > > > > Thanks > > Lizhong > > > > -------------------------------------------------------- > > 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. > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > Network Agnostic: Applications that work best on cheap, stupid networks. > Suicide: Devaluating the intelligent network with network agnostic apps. > > -------------------------------------------------------- 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 0050F9B248257835_= Content-Type: text/html; charset="US-ASCII"
Hi Toerless,
It is not my intention to allow PHP for mLDP, and I agree with you to disable PHP for mLDP. Since PHP is the default function in many current MPLS implementations, it is necessary for the mLDP in-band signaling draft to explicitly describe whether PHP should be always disabled or enabled, so as to avoid misunderstanding.

Lizhong

Toerless Eckert <eckert@cisco.com> wrote on 2011-02-12 17:28:05: > Why do we want to bother about PHP with mLDP. > > inv(Nike): Just don't do it. > > I've still not seen an mentioning of benefits, eg: > performance downside is IMHO a historical argument. > > With inband signaling, i also have the most simple example of > why it can break things. > If the downstream PE wants to fail over for the same (S,G) > between two headend PE, then it is that last-hop label that > provides the ability to drop the currently unwanted version of the > (S,G) flow during switchover. The same would be true for any other > switchover cases on the tailend PE between different LSPs. > > Or just the generic considerations: > > I only want labelled multicast packet on my core, that way i can much better > distinguish them from my native multicast packets on the CE side. > > I want mLDP to stay simple, and consistently doing label > binding all the way from headend LSR to tailend LSR makes the > last hop not a special case where i need to spend always level of > design considerations. > > > On Sat, Feb 12, 2011 at 09:54:49AM +0800, lizhong.jin@zte.com.cn wrote: > > Hi Ice, > > From the technical point of view, the leaf node (will never be Bud node, > > if ensure) can enable PHP if LSP carries IP multicast traffic > (application > > described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud > > node should always disable the PHP. But the problem is that oneleaf node > > may become a bud node in future. Then what is the PHP behavior for > > draft-ietf-mpls-mldp-in-band-signaling-03? > > draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior fornode, does > > that mean the application binding P2MP/MP2MP LSP should address the PHP > > behavior? > > > > Thanks > > Lizhong > > > > -------------------------------------------------------- > > 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. > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > Network Agnostic: Applications that work best on cheap, stupid networks. > Suicide: Devaluating the intelligent network with network agnostic apps. > >
-------------------------------------------------------- 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 0050F9B248257835_=-- From ben.mackcrane@huawei.com Sun Feb 13 15:11:38 2011 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 1D75A3A6C38 for ; Sun, 13 Feb 2011 15:11:38 -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 lFouWxoM+TxR for ; Sun, 13 Feb 2011 15:11:37 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DAAB23A6C35 for ; Sun, 13 Feb 2011 15:11:36 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGK00KXJWFWYJ@usaga04-in.huawei.com> for mpls@ietf.org; Sun, 13 Feb 2011 17:11:57 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGK009UFWFW0G@usaga04-in.huawei.com> for mpls@ietf.org; Sun, 13 Feb 2011 17:11:56 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 13 Feb 2011 15:11:56 -0800 Received: from BMCRANEIL1 (10.200.218.74) by DFWEML401-HUB.china.huawei.com (10.193.5.101) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 13 Feb 2011 15:11:54 -0800 Date: Mon, 14 Feb 2011 00:12:06 +0100 From: ben mackcrane In-reply-to: X-Originating-IP: [10.200.218.74] To: mpls@ietf.org Message-id: <00b901cbcbd3$71ca4350$555ec9f0$%mackcrane@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcvGd7puTQVnojA3ThmPPWkMXUN/MgFFEtMA References: Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 13 Feb 2011 23:17:57 -0000 Hello, I have reviewed draft-ietf-mpls-loss-delay-01 and have the following comments/questions: 1) The final loss, throughput, or delay calculations may be performed = either by the querier or by another post-processing system (e.g., a network management server). For unidirectional measurements this can be accomplished simply by sending the out-of-band response to the post-processing system identified by the return address TLV. For bidirectional measurements the querier can forward the final measurement message using the same out-of-band mechanism used by the responder to = the address of the desired post-processing system. Some port-processing systems may have the ability to store measurement data for an extended measurement period and produce a variety of useful statistics from the measurement data. Use of an off-line post-processing system also allows = the measurement function at the querier to be completely stateless. The = option to support off-line post-processing should be included (and should = require only a small amount of additional text to describe). 2) In section 1 the work =93packet=94 should be deleted from the bullet = =93The LM protocol supports both 32-bit and 64-bit packet counters.=94 since octet counters are also supported. 3) In section 2.1 the received packet count is described as not = including the LM packet itself. Unless the LM messages are excluded from the = counting altogether, it may be easier to include the LM packet in the count as it must be received (and likely would be counted) before it is recognized = as andLM packet and further processing occurs. It may be easier to add one = to the count when the LM message is sent than to subtract one when the LM message is received. It could also be specified that the sending count = does not include the LM packet and the receiving count does and the = correction can be handled I the post-processing calculations (keeping the LM query/response functions as simple as possible). 4) In 2.2 the phrase "measurement of the throughput sustained over the channel during the interval" would be better without "sustained" which = tends to suggest a constant rate. 5) In 2.2 the statement "This metric can be called the delivered throughput." should be expanded since the values recorded allow = calculation of both offered throughput and delivered throughput. 6) In 2.2 the phrase "As for loss measurement," should be deleted since = this section is about throughput measurement (and the particular sentence = appears to be as well). 7) It is noted that due to the TC of the measurement messages they may = be reordered with respect to other packets. It should be further noted somewhere that, while this can affect individual measurements in the = direct measurement method, the packet loss rate (derivative of packet loss measurement) can still be accurately determined over time. Some places where this might be noted are in 2.7.2, 2.7.3, and/or 2.7.6. 8) Presumably the editor's note in 2.7.5 is no longer needed. 9) In 3.1 there should be a notification value (0x5?) for the case that = the egress measurement resource is preempted or released by an administrator (indicating the measurement session should end). 10) In 3.1 the case of "Unsupported Version" is indicated as an error. = It may be better to make this a notification so that the querier can decide whether or not the earlier version responder can nevertheless provide = useful data. There may be cases in which the responder does not have to be upgraded to make beneficial use of additional information (e.g. in TLVs) sent by the querier and returned (without being understood) in the = response message. If this is desirable, then 4.1.4 should indicate that optional TLVs are copied in the response if they are not understood. 11) In 3.1 the control code 0x15 mentions "Destination Node Identifier" = -- is this the Destination Address (TLV 129)? If not, to what does it = refer? 12) In 3.1 to what does the "channel identifier supplied in the query" = refer in the description of control code 0x16? 13) In 3.2 the description of the Flags field is a bit confused. It = refers to similarity with 3.1 and the X flag (which is in the DFlags field, not = in the Flags field). 14) In 3.5.3, since it is likely that the minimum supported LM interval = will vary for different endpoints and that useful measurements are not necessarily dependent on the interval chosen, it would be more useful = for the suggested process to be the following: The querier need not send a Session Query Interval TLV in the initial LM query, the responder SHOULD send a Session Query Interval in the initial responses (indicating the minimum supported interval), the querier SHOULD send a Session Query Interval TLV in subsequent LM queries indicating the interval chosen (greater than or equal to the minimum supported by the responder). On seeing the TLV from the querier the responder may cease including the = TLV, and on seeing the TLV not included in the response the querier may cease sending the TLV. This has the advantage of quickly finding an agreeable rate and always initiating a measurement without requiring the = administrator or querier to know the capabilities of the responder a priori. 15) In 4.1.1 it is noted that data from multiple intervals can be accumulated to provide a total loss measure. It should also be noted = that this data can be used to calculate a loss rate. 16) In 4.1.2 the querier sets counter 1 to the count of packets sent = before the LM query message. It could also indicate that this value may be set = to zero until the counting resources have been engaged (e.g., if waiting = for a favorable response from the responder before beginning the measurement process). 17) 4.1.5 should state that it is also possible to forward the final LM message (containing all counts) to another location for post-processing. Regards, Ben Mack-Crane From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon Sent: Monday, February 07, 2011 4:33 AM To: mpls@ietf.org Subject: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Working Group, =A0 This is to start a four week working group last call on " Packet Loss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay-01). =A0 Please send comments to the mpls@ietf.org mailing list. =A0 Also, please note that the related document=20 " draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in=20 parallel on the mpls-tp email list (mpls-tp@ietf.org).=20 =A0 This working group last call ends on Monday March 7, 2011. =A0 Ross, Loa, and George =A0 MPLS WG co-chairs =A0 =A0 From guoxinchun@huawei.com Sun Feb 13 19:09:52 2011 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 57D5D3A6A6F; Sun, 13 Feb 2011 19:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 c5Mz+Y0HOmWX; Sun, 13 Feb 2011 19:09:51 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0D6133A6839; Sun, 13 Feb 2011 19:09:51 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGL00J367GQP3@szxga05-in.huawei.com>; Mon, 14 Feb 2011 11:10:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGL00CFS7GPKM@szxga05-in.huawei.com>; Mon, 14 Feb 2011 11:10:01 +0800 (CST) Received: from g67564e ([10.110.98.42]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGL00FUU7GL2F@szxml04-in.huawei.com>; Mon, 14 Feb 2011 11:10:01 +0800 (CST) Date: Mon, 14 Feb 2011 11:09:56 +0800 From: Xinchun Guo In-reply-to: <020701cbc9d1$594011b0$0bc03510$@com> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org Message-id: <000001cbcbf4$a8cd32b0$fa679810$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: TEXT/PLAIN Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvDlq57z2Yieu+sT1qv11A4xrFRrgF9U4SAAAVBXrAAk0N8oA== References: <4D4A934F.5020206@pi.nu> <020201cbc98c$8269d750$873d85f0$@com> <020701cbc9d1$594011b0$0bc03510$@com> Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 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, 14 Feb 2011 03:09:52 -0000 Hi authors and all About this document, I have another question expect to be clarification. I am not very clear about the specific application of Fault management message. In section 2 of this document, it said " Fault OAM messages are generated by intermediate nodes where an LSP is switched". Does it mean that the fault message can only be used for alarm suppress of LSP layer? Could not this fault management function be used for PW layer, especially for the MS-PW conditions. Take the following hiberarchy scenario for example, PW1 and PW2 are two segments of the MS-PW which is client of the LSP layer. if the server layer of LSP fails, such as Link1, node2 will initiate AIS message and sent it to LSP1 end point node3. As MS-PW is client of LSP1, for this condition, whether Node3 will further initiate Fault management message to MS-PW end point Node4 to notify the failure of LSP1 to suppress alarm of the end to end pw service. IMO, Fault management function should cover these PW conditions. - MS-PW - - +---------AIS/LKR-------------->>- -<-----------------PW1-------------------->|-----------------PW2------------ >- - +----AIS/LKR---->> - -<-------LSP1---------+-------------------><--------------LSP2-------------- ->- - |AIS/LKR - -<--- Link1---------->|<--- Link2------><--------Link3--------------------->- Node1 Node2 Node3 Node4 Hope authors could clarify this point and detail the Fault function process about PW scenarios in this document. Best Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Xinchun Guo Sent: Friday, February 11, 2011 5:52 PM To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Other 3 edit comments, see below. 1.section 2.2, there is overlapping between the last sentence of the first paragraph and the first sentence of the second paragraph about " The purpose of the LKR message is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs" . Simplify it will be more smart. 2.section 4.1.2, the first sentence" This TLV carries the Interface Identifier as defined ......", "the Interface Identifier" should be "the Global Identifier". right? 3. section 5.3, there are two "that" in the first sentence, one is redundancy. Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Xinchun Guo Sent: Friday, February 11, 2011 9:39 AM To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Dear authors After read the document, I have a question about the FM massage procedure. In the section 5.1, the third paragraph, it said "The message is then sent. The message MUST be refreshed two more times at an interval of one second. Further refreshes are sent according to the value of the refresh timer." I don't know why the refreshing massage must be first sent two more times in one second and then sent as the refresh timer interval. Is it ok if the refreshing massage is sent only according to the value of the refresh timer? If it is not, what problem may be introduced? Hope authors could explain it for me. In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format " other than" MPLS-TP OAM Message Format " is more suitable. Best Regards Xinchun -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, February 03, 2011 7:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross 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 _______________________________________________ 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 nick.delregno@verizon.com Mon Feb 14 07:40:11 2011 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 474653A6D6E; Mon, 14 Feb 2011 07:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNCgWhrVkdRd; Mon, 14 Feb 2011 07:40:06 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id EB0483A6D45; Mon, 14 Feb 2011 07:40:05 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGM003LU67G7A70@firewall.verizonbusiness.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGM00BA067GEC00@pdcismtp03.vzbi.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGM00B0L67GGO00@pdcismtp03.vzbi.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 15:40:28 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBCC5D.80927EF2" Date: Mon, 14 Feb 2011 15:40:25 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600069340AD@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: PW/VCCV Survey Ending Soon! Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzACX6Nw8A== X-Priority: 1 Priority: Urgent Importance: high References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 14 Feb 2011 15:40:28.0007 (UTC) FILETIME=[81184F70:01CBCC5D] Subject: [mpls] PW/VCCV Survey Ending Soon! 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, 14 Feb 2011 15:40:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCC5D.80927EF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We now have 9 valid responses to the VCCV User Survey. Time is running out. The deadline for submissions is February 25th. So we have 11 days and counting. =20 It is important that we get as many participants as possible to ensure fair representation in any future PW Control Word and VCCV related work in the PWE3 working group. =20 I will be presenting the results of the PW/VCCV survey in the form of a draft for IETF 80 in Prague. =20 Thanks, Nick =20 =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 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBCC5D.80927EF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We now have 9 valid responses to the VCCV = User Survey. Time is running out. The deadline for = submissions is February 25^th. So we have 11 days and = counting.

It is = important that we get as many participants as possible to ensure fair = representation in any future PW Control Word and VCCV related work in = the PWE3 working group.

I will be presenting the = results of the PW/VCCV survey in the form of a draft for IETF 80 in = Prague.

Thanks,
Nick

=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

All:

Per the = direction of the PWE3 working group, beginning in IETF77 and reinforced = in IETF78, the PWE3 working group is conducting a Service Provider = implementation survey related to:

-          = Pseudowire Encapsulations
-          = Control Word Support
-          = Control Word Use
-          = VCCV Control Channel Support
-          = VCCV Control Channel Use

http://www.surveymonkey.com/s= /pwe3

This is a short survey directed toward Service = Providers who currently operate networks using any of the defined PWE3 = encapsulations. The results of this survey will be used to = determine the direction of the Control Word support in current and = future encapsulations as well as solutions to VCCV interoperability = challenges.

We sincerely urge all service providers to = participate. We ask that all equipment providers encourage = participation by their Service Provider customers. The more = feedback we receive, the better view of the existing network we can have = on which to base going-forward direction.

If you have = any questions, regarding the survey, especially of a technical nature, = please contact me. If you have non-technical questions, feel free = to reach out to the PWE3 WG chairs and myself.

The results = of the survey will be aggregated and shared at a high level. No = low-level details of network implementations will be shared. All = participant’s responses will remain private, if not = anonymous.

All responses will require a valid email address to = help ensure the survey’s validity.

Thanks,
Nick

Christopher N. “Nick” DelRegno, = PMTS
CNT, Ethernet Network Architecture & = Design
400 International Pkwy
Richardson, TX = 75081
Tel: 972-729-3411
Email: = Nick.DelRegno@verizon.com

------_=_NextPart_001_01CBCC5D.80927EF2-- From iesg-secretary@ietf.org Mon Feb 14 11:46:56 2011 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 9B5333A67DF; Mon, 14 Feb 2011 11:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 geYS2goNMzZx; Mon, 14 Feb 2011 11:46:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604463A6AB9; Mon, 14 Feb 2011 11:46:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110214194655.10345.51750.idtracker@localhost> Date: Mon, 14 Feb 2011 11:46:55 -0800 Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Document Action: 'Operations, Administration and Maintenance Framework for MPLS-based Transport Networks' to Informational RFC (draft-ietf-mpls-tp-oam-framework-11.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, 14 Feb 2011 19:46:56 -0000 The IESG has approved the following document: - 'Operations, Administration and Maintenance Framework for MPLS-based Transport Networks' (draft-ietf-mpls-tp-oam-framework-11.txt) as an Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-framework/ Technical Summary This MPLS-TP OAM Framework defines the mechanisms and procedures for alarm, fault, performance and protection-switching management for an MPLS based packet transport applications. Care has been taken to make sure the OAM for MPLS based packet transport networks is backwards compatible with existing MPLS OAM tools, New OAM mechanisms have only been defined when existing mechanisms are not sufficient to meet the MPLS-TP requirements. This document includes a comprehensive set of OAM procedures that satisfy the requirements mentioned above. The docement defines a set of functions that has great affinity with comparable functions in existing transport networks, e.g. SONET/SDH and OTN. The MPLS-TP OAM framework discusses mechanisms that are applicable to LSPs and/or (MS-)PWs. Co-routed and associated bidirectional p2p transport paths as well as unidirectional p2p and p2mp transport paths are within scope of the document. Working Group Summary Since the document is an output from the MPLS-TP project it is the joint output of several IETF working groups and Qustion 9, 10, 12 and 14 of ITU-T SG15. Document Quality The document is well reviewed in all the groups mentioned above Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd Adrian Farrel (adrian.farrel@huawei.com) is the responsible AD From xiao.min2@zte.com.cn Mon Feb 14 19:15:37 2011 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 8B2D03A6E27; Mon, 14 Feb 2011 19:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1HyAVENPHgh; Mon, 14 Feb 2011 19:15:36 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C30B13A6E23; Mon, 14 Feb 2011 19:15:35 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951784411434; Tue, 15 Feb 2011 11:11:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.1937000543; Tue, 15 Feb 2011 11:15:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1F3FhMg079055; Tue, 15 Feb 2011 11:15:45 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Tue, 15 Feb 2011 11:15:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-15 11:15:45, Serialize complete at 2011-02-15 11:15:45 Content-Type: multipart/alternative; boundary="=_alternative 0011E78948257838_=" X-MAIL: mse01.zte.com.cn p1F3FhMg079055 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 15 Feb 2011 03:15:37 -0000 This is a multipart message in MIME format. --=_alternative 0011E78948257838_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KSSBoYXZlIGEgY29tbWVudCBvbiBsb3NzIG1lYXN1cmVtZW50IGluIHRo aXMgZHJhZnQuDQoNCkFmdGVyIHJlY2VpdmluZyBMTSBRdWVyeSBtZXNzYWdlLCB0aGUgcmVzcG9u ZGVyIHdvdWxkIHJlcGx5IExNIFJlc3BvbnNlIA0KbWVzc2FnZSB3aGljaCBzaG91bGQgdGFrZSBz b21lIGNvdW50ZXJzLiBCdXQgSSBjYW4ndCBmaW5kIHRleHQgaW4gdGhpcyANCmRyYWZ0IHRvIGRl c2NyaWJlIGhvdyB0aGUgY291bnRpbmcgZnVuY3Rpb24gYXQgdGhlIHJlc3BvbmRlciBpcyBzd2l0 Y2hlZCANCm9uLiBJTUhPIG9uZSBtb3JlIGJpdC9mbGFnIHNob3VsZCBiZSBkZWZpbmVkICBpbiB0 aGUgTE0gUXVlcnkgbWVzc2FnZSB0byANCmFjdGl2YXRlIG9yIGRlYWN0aXZhdGUgdGhlIGNvdW50 aW5nIGZ1bmN0aW9uIGF0IHRoZSByZXNwb25kZXIuDQpEaWQgSSBtaXNzIHNvbWV0aGluZz8NCg0K QmVzdCBSZWdhcmRzLA0KWGlhbyBNaW4NCg0KDQoNCg0KUm9zcyBDYWxsb24gPHJjYWxsb25AanVu aXBlci5uZXQ+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLzAyLzA3IDEx OjMzDQoNCsrVvP7Iyw0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0KDQrW 98ziDQpbbXBsc10gTVBMUyBXRyBMYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVs YXktMDENCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQogDQpUaGlzIGlzIHRvIHN0YXJ0IGEg Zm91ciB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQoiIFBhY2tldCBMb3NzIGFuZCBE ZWxheSBNZWFzdXJlbWVudCBmb3IgTVBMUyBOZXR3b3JrcyINCihkcmFmdC1pZXRmLW1wbHMtbG9z cy1kZWxheS0wMSkuDQogDQpQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbXBsc0BpZXRmLm9y ZyBtYWlsaW5nIGxpc3QuDQogDQpBbHNvLCBwbGVhc2Ugbm90ZSB0aGF0IHRoZSByZWxhdGVkIGRv Y3VtZW50IA0KIiBkcmFmdC1pZXRmLW1wbHMtdHAtbG9zcy1kZWxheS1wcm9maWxlLTAyLnR4dCIg aXMgYmVpbmcgbGFzdCBjYWxsZWQgaW4gDQpwYXJhbGxlbCBvbiB0aGUgbXBscy10cCBlbWFpbCBs aXN0IChtcGxzLXRwQGlldGYub3JnKS4gDQogDQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IGVuZHMgb24gTW9uZGF5IE1hcmNoIDcsIDIwMTEuDQogDQpSb3NzLCBMb2EsIGFuZCBHZW9yZ2UN CiANCk1QTFMgV0cgY28tY2hhaXJzDQogDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQo= --=_alternative 0011E78948257838_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEF1dGhvcnMsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhdmUgYSBjb21tZW50 IG9uIGxvc3MgbWVhc3VyZW1lbnQNCmluIHRoaXMgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BZnRlciByZWNlaXZpbmcgTE0gUXVlcnkgbWVz c2FnZSwgdGhlDQpyZXNwb25kZXIgd291bGQgcmVwbHkgTE0gUmVzcG9uc2UgbWVzc2FnZSB3aGlj aCBzaG91bGQgdGFrZSBzb21lIGNvdW50ZXJzLg0KQnV0IEkgY2FuJ3QgZmluZCB0ZXh0IGluIHRo aXMgZHJhZnQgdG8gZGVzY3JpYmUgaG93IHRoZSBjb3VudGluZyBmdW5jdGlvbg0KYXQgdGhlIHJl c3BvbmRlciBpcyBzd2l0Y2hlZCBvbi4gSU1ITyBvbmUgbW9yZSBiaXQvZmxhZyBzaG91bGQgYmUg ZGVmaW5lZA0KJm5ic3A7aW4gdGhlIExNIFF1ZXJ5IG1lc3NhZ2UgdG8gYWN0aXZhdGUgb3IgZGVh Y3RpdmF0ZSB0aGUgY291bnRpbmcgZnVuY3Rpb24NCmF0IHRoZSByZXNwb25kZXIuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5EaWQgSSBtaXNzIHNvbWV0aGluZz88 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVn YXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlhpYW8gTWlu PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjxiPlJvc3MgQ2FsbG9uICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMS8wMi8wNyAxMTozMzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+W21wbHNdIE1QTFMgV0cgTGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1sb3Nz LWRlbGF5LTAxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPldvcmtpbmcgR3JvdXAsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPlRoaXMgaXMgdG8gc3RhcnQgYSBmb3VyIHdlZWsgd29ya2luZyBncm91cA0KbGFz dCBjYWxsIG9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mcXVvdDsg UGFja2V0IExvc3MgYW5kIERlbGF5IE1lYXN1cmVtZW50DQpmb3IgTVBMUyBOZXR3b3JrcyZxdW90 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+KGRyYWZ0LWlldGYtbXBs cy1sb3NzLWRlbGF5LTAxKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UGxlYXNlIHNl bmQgY29tbWVudHMgdG8gdGhlIG1wbHNAaWV0Zi5vcmcNCm1haWxpbmcgbGlzdC48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+QWxzbywgcGxlYXNlIG5vdGUgdGhhdCB0aGUgcmVsYXRlZCBk b2N1bWVudA0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mcXVvdDsg ZHJhZnQtaWV0Zi1tcGxzLXRwLWxvc3MtZGVsYXktcHJvZmlsZS0wMi50eHQmcXVvdDsNCmlzIGJl aW5nIGxhc3QgY2FsbGVkIGluIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+cGFyYWxsZWwgb24gdGhlIG1wbHMtdHAgZW1haWwgbGlzdCAobXBscy10cEBpZXRmLm9yZyku DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBlbmRzIG9uIE1vbmRheQ0KTWFyY2ggNywgMjAxMS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+Um9zcywgTG9hLCBhbmQgR2VvcmdlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPk1QTFMgV0cgY28tY2hhaXJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3Jn PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPC90 dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0011E78948257838_=-- From danfrost@cisco.com Tue Feb 15 06:14:56 2011 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 560D73A6C94; Tue, 15 Feb 2011 06:14:56 -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 z7Gn5q8nyG37; Tue, 15 Feb 2011 06:14:55 -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 442D23A6A6C; Tue, 15 Feb 2011 06:14:55 -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: AvsEAPYYWk1AZnwM/2dsb2JhbAClV3OgGptlhV4EjAI X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="215825315" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2011 14:15:20 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1FEFKPx025208; Tue, 15 Feb 2011 14:15:20 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p1FEFKqC022897; Tue, 15 Feb 2011 09:15:20 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p1FEFJo6022896; Tue, 15 Feb 2011 14:15:19 GMT X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: Linda Dunbar In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6A81B8F@DFWEML501-MBX.china.huawei.com> (Linda Dunbar's message of "Tue, 08 Feb 2011 21:57:32 +0000") References: <4A95BA014132FF49AE685FAB4B9F17F6A81B8F@DFWEML501-MBX.china.huawei.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Tue, 15 Feb 2011 14:15:19 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 15 Feb 2011 14:14:56 -0000 Hi Linda, Linda Dunbar writes: > I have some issues with this draft: > There had been a lot of discussions on email list on what should > Initiator (querier) do when not receiving a response from far end. > > Ben Jenkins suggested the following text > (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html) > which is not incorporated to this new draft yet. > > When initiating an LM operation, the far end may require a > period of time to become ready for the requested measurement > operation or the far end may not be able to support the > requested measurement. Under those circumstances, LM queries MAY > simply be discarded, and the querier expecting a response SHOULD > be prepared for this situation. Alternatively, the receiver MAY > respond, possibly in a rate-limited manner, to queries received > during this period with an appropriate notification code. The > querier should abort the measurement after not receiving any > positive feedback when a specified timer expires. With one exception, this text looks substantially the same to me as the last paragraph of Section 4.1.1. The exception is your addition of 'or the far end may not be able to support the requested measurement' to the first sentence, but that case is not what this text is meant to cover: if the far end doesn't support the requested measurement, the right thing to do is to reply with an appropriate error code so the querier knows what went wrong. > Section 3.5.3: It stated: > When a query is received with a Session Query Interval that is > too low for the receiver to support, the receiver SHOULD > include this object when it generates an error response. > > Question: > Which error code should be used? Is it 0x18:Error - Unsupported > Query Interval? If Yes, should add this to the sentence. Yes, that's the purpose of this error code. We can be explicit here. > What if the Querier indicates "0x2: No Response Requested"? In general, a no-response-requested measurement means that the querier can't receive any direct feedback; the assumption of this measurement mode is that control is achieved through some external means, e.g. an NMS that ensures consistent operation among the nodes involved. > Section 4.1.5: > * Should allow the Loss measurement to be calculated somewhere else, > in case the initiator (querier) doesn't have the capacity to do the > calculation. Ben Mack-Crane has made comprehensive comments on this topic, so we'll address it in that context. > * Should add a description that measurement is to be stopped when far > end not respond anymore. OK. Thanks for your comments! -d > Linda Dunbar From wwwrun@core3.amsl.com Tue Feb 15 07:39:41 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EE5143A6AB2; Tue, 15 Feb 2011 07:39:40 -0800 (PST) To: mach@huawei.com, frederic.jounay@orange-ftgroup.com, guoxinchun@huawei.com, ning.so@verizonbusiness.com, simon.a.delord@team.telstra.com, caoweigne@huawei.com From: IETF Secretariat Message-Id: <20110215153940.EE5143A6AB2@core3.amsl.com> Date: Tue, 15 Feb 2011 07:39:40 -0800 (PST) Cc: mpls@ietf.org, housley@vigilsec.com, adrian.farrel@huawei.com, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-return-path-specified-lsp-ping-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: Tue, 15 Feb 2011 15:39:41 -0000 Dear Mach Chen, Frederic JOUNAY, Xinchun Guo, So Ning, Simon Delord, Wei Cao: An IPR disclosure that pertains to your Internet-Draft entitled "Return Path Specified LSP Ping" (draft-ietf-mpls-return-path-specified-lsp-ping) was submitted to the IETF Secretariat on 2011-02-14 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1491/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-return-path-specified-lsp-ping-02." The IETF Secretariat From danfrost@cisco.com Tue Feb 15 08:06:17 2011 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 4F4413A6B60 for ; Tue, 15 Feb 2011 08:06:17 -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 TrOPCe8kNBy2 for ; Tue, 15 Feb 2011 08:06:16 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D193C3A6BCD for ; Tue, 15 Feb 2011 08:06:15 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOozWk1AZnwN/2dsb2JhbACEHaE8c6A8inGQdoEng0F2BIwC X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="215633900" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Feb 2011 16:06:37 +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 p1FG6bcF013745; Tue, 15 Feb 2011 16:06:37 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p1FG6bi3023881; Tue, 15 Feb 2011 11:06:37 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p1FG6bVf023880; Tue, 15 Feb 2011 16:06:37 GMT X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: ben mackcrane In-Reply-To: <00b901cbcbd3$71ca4350$555ec9f0$%mackcrane@huawei.com> (ben mackcrane's message of "Mon, 14 Feb 2011 00:12:06 +0100") References: <00b901cbcbd3$71ca4350$555ec9f0$%mackcrane@huawei.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Tue, 15 Feb 2011 16:06:37 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 15 Feb 2011 16:06:17 -0000 Hi Ben, ben mackcrane writes: > Hello, > > I have reviewed draft-ietf-mpls-loss-delay-01 and have the following > comments/questions: Thanks a lot for your detailed review and comments! > 1) The final loss, throughput, or delay calculations may be performed > either by the querier or by another post-processing system (e.g., a > network management server). For unidirectional measurements this can > be accomplished simply by sending the out-of-band response to the > post-processing system identified by the return address TLV. For > bidirectional measurements the querier can forward the final > measurement message using the same out-of-band mechanism used by the > responder to the address of the desired post-processing system. Some > port-processing systems may have the ability to store measurement data > for an extended measurement period and produce a variety of useful > statistics from the measurement data. Use of an off-line > post-processing system also allows the measurement function at the > querier to be completely stateless. The option to support off-line > post-processing should be included (and should require only a small > amount of additional text to describe). Agree that this is a useful option and also that it shouldn't require much in the way of new text. We'll take this up. > 2) In section 1 the work =E2=80=9Cpacket=E2=80=9D should be deleted from = the bullet > =E2=80=9CThe LM protocol supports both 32-bit and 64-bit packet counters.= =E2=80=9D > since octet counters are also supported. Sure. > 3) In section 2.1 the received packet count is described as not > including the LM packet itself. Unless the LM messages are excluded > from the counting altogether, it may be easier to include the LM > packet in the count as it must be received (and likely would be > counted) before it is recognized as andLM packet and further > processing occurs. It may be easier to add one to the count when the > LM message is sent than to subtract one when the LM message is > received. It could also be specified that the sending count does not > include the LM packet and the receiving count does and the correction > can be handled I the post-processing calculations (keeping the LM > query/response functions as simple as possible). The practical side of this is currently covered by Section 4.1.8 which states that all G-ACh packets are excluded from the count by default. A key reason for this is the possibility of intermediate nodes injecting traffic into the G-ACh. > 4) In 2.2 the phrase "measurement of the throughput sustained over the > channel during the interval" would be better without "sustained" which > tends to suggest a constant rate. OK. > 5) In 2.2 the statement "This metric can be called the delivered > throughput." should be expanded since the values recorded allow > calculation of both offered throughput and delivered throughput. OK. > 6) In 2.2 the phrase "As for loss measurement," should be deleted > since this section is about throughput measurement (and the particular > sentence appears to be as well). Ah, the intended meaning was "Just as with loss measurement..." Will rephrase. > 7) It is noted that due to the TC of the measurement messages they may > be reordered with respect to other packets. It should be further noted > somewhere that, while this can affect individual measurements in the > direct measurement method, the packet loss rate (derivative of packet > loss measurement) can still be accurately determined over time. Some > places where this might be noted are in 2.7.2, 2.7.3, and/or 2.7.6. Good point; thanks. > 8) Presumably the editor's note in 2.7.5 is no longer needed. Right. > 9) In 3.1 there should be a notification value (0x5?) for the case > that the egress measurement resource is preempted or released by an > administrator (indicating the measurement session should end). OK. > 10) In 3.1 the case of "Unsupported Version" is indicated as an error. > It may be better to make this a notification so that the querier can > decide whether or not the earlier version responder can nevertheless > provide useful data. There may be cases in which the responder does > not have to be upgraded to make beneficial use of additional > information (e.g. in TLVs) sent by the querier and returned (without > being understood) in the response message. If this is desirable, then > 4.1.4 should indicate that optional TLVs are copied in the response if > they are not understood. Regarding the version, it would seem to make the most sense for the querier to adapt to a lower-version responder by retrying the measurement operation with a lower version. Regarding TLV-copying, this could be useful, but it would have to use some other mechanism, as requiring that all unknown optional TLVs be copied wouldn't make sense for any of the currently-defined optional TLVs, for example! If there's a need for a querier to attach opaque data that just gets copied by the responder, defining a single TLV for that purpose might be enough. > 11) In 3.1 the control code 0x15 mentions "Destination Node > Identifier" -- is this the Destination Address (TLV 129)? If not, to > what does it refer? > > 12) In 3.1 to what does the "channel identifier supplied in the query" > refer in the description of control code 0x16? These exist to support MPLS-TP-style identifiers (draft-ietf-mpls-tp-identifiers), although TLVs for them haven't been defined yet. > 13) In 3.2 the description of the Flags field is a bit confused. It > refers to similarity with 3.1 and the X flag (which is in the DFlags > field, not in the Flags field). Oops! It should say "As specified in Section 3.1. The T flag in a DM message is set to 1." Will fix that, thanks. > 14) In 3.5.3, since it is likely that the minimum supported LM > interval will vary for different endpoints and that useful > measurements are not necessarily dependent on the interval chosen, it > would be more useful for the suggested process to be the following: > The querier need not send a Session Query Interval TLV in the initial > LM query, the responder SHOULD send a Session Query Interval in the > initial responses (indicating the minimum supported interval), the > querier SHOULD send a Session Query Interval TLV in subsequent LM > queries indicating the interval chosen (greater than or equal to the > minimum supported by the responder). On seeing the TLV from the > querier the responder may cease including the TLV, and on seeing the > TLV not included in the response the querier may cease sending the > TLV. This has the advantage of quickly finding an agreeable rate and > always initiating a measurement without requiring the administrator or > querier to know the capabilities of the responder a priori. This sounds reasonable; we'll consider the options here. > 15) In 4.1.1 it is noted that data from multiple intervals can be > accumulated to provide a total loss measure. It should also be noted > that this data can be used to calculate a loss rate. OK. > 16) In 4.1.2 the querier sets counter 1 to the count of packets sent > before the LM query message. It could also indicate that this value > may be set to zero until the counting resources have been engaged > (e.g., if waiting for a favorable response from the responder before > beginning the measurement process). OK. > 17) 4.1.5 should state that it is also possible to forward the final > LM message (containing all counts) to another location for > post-processing. OK. Thanks again! -d > Regards, > Ben Mack-Crane From linda.dunbar@huawei.com Tue Feb 15 08:06:51 2011 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 0D9173A6C38; Tue, 15 Feb 2011 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=1.218, 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 po7EqR+xrJzS; Tue, 15 Feb 2011 08:06:49 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BF9903A6B60; Tue, 15 Feb 2011 08:06:49 -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 <0LGO004T5242U9@usaga02-in.huawei.com>; Tue, 15 Feb 2011 08:07:15 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGO00CIE24275@usaga02-in.huawei.com>; Tue, 15 Feb 2011 08:07:14 -0800 (PST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Feb 2011 08:07:11 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 15 Feb 2011 08:07:14 -0800 Date: Tue, 15 Feb 2011 16:07:12 +0000 From: Linda Dunbar In-reply-to: X-Originating-IP: [10.124.12.77] To: Dan Frost Message-id: <4A95BA014132FF49AE685FAB4B9F17F6A83645@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NyZlYbtxfvUUJtZRdhAsxw)" Content-language: en-US Accept-Language: en-US Thread-topic: [mpls-tp] [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Thread-index: AQHLzRr0ixNfwYWA20Cm8N6c/tU+FpQCtduw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6A81B8F@DFWEML501-MBX.china.huawei.com> Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 15 Feb 2011 16:06:51 -0000 --Boundary_(ID_NyZlYbtxfvUUJtZRdhAsxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dan: You said: "if the far end doesn't support the requested measurement, the right thing to do is to reply with an appropriate error code so the querier knows what went wrong." What if the reply message got lost? Then you have to add the mechanism to make far-end sending multiple messages with the correct Error Code. So the simplest thing is for the Querier to stop the measurement either upon receiving a reply with Error Code or not receiving any reply for a while. Linda Dunbar -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Dan Frost Sent: Tuesday, February 15, 2011 8:15 AM To: Linda Dunbar Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Hi Linda, Linda Dunbar writes: > I have some issues with this draft: > There had been a lot of discussions on email list on what should > Initiator (querier) do when not receiving a response from far end. > > Ben Jenkins suggested the following text > (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html) > which is not incorporated to this new draft yet. > > When initiating an LM operation, the far end may require a > period of time to become ready for the requested measurement > operation or the far end may not be able to support the > requested measurement. Under those circumstances, LM queries MAY > simply be discarded, and the querier expecting a response SHOULD > be prepared for this situation. Alternatively, the receiver MAY > respond, possibly in a rate-limited manner, to queries received > during this period with an appropriate notification code. The > querier should abort the measurement after not receiving any > positive feedback when a specified timer expires. With one exception, this text looks substantially the same to me as the last paragraph of Section 4.1.1. The exception is your addition of 'or the far end may not be able to support the requested measurement' to the first sentence, but that case is not what this text is meant to cover: if the far end doesn't support the requested measurement, the right thing to do is to reply with an appropriate error code so the querier knows what went wrong. > Section 3.5.3: It stated: > When a query is received with a Session Query Interval that is > too low for the receiver to support, the receiver SHOULD > include this object when it generates an error response. > > Question: > Which error code should be used? Is it 0x18:Error - Unsupported > Query Interval? If Yes, should add this to the sentence. Yes, that's the purpose of this error code. We can be explicit here. > What if the Querier indicates "0x2: No Response Requested"? In general, a no-response-requested measurement means that the querier can't receive any direct feedback; the assumption of this measurement mode is that control is achieved through some external means, e.g. an NMS that ensures consistent operation among the nodes involved. > Section 4.1.5: > * Should allow the Loss measurement to be calculated somewhere else, > in case the initiator (querier) doesn't have the capacity to do the > calculation. Ben Mack-Crane has made comprehensive comments on this topic, so we'll address it in that context. > * Should add a description that measurement is to be stopped when far > end not respond anymore. OK. Thanks for your comments! -d > Linda Dunbar _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_NyZlYbtxfvUUJtZRdhAsxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Dan:

You said:

"if the far end doesn't support the requested measurement, the right thing to do is to reply with an appropriate error code so the querier knows what went wrong."

What if the reply message got lost? Then you have to add the mechanism to make far-end sending multiple messages with the correct Error Code.

So the simplest thing is for the Querier to stop the measurement either upon receiving a reply with Error Code or not receiving any reply for a while.

Linda Dunbar

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Dan Frost
Sent: Tuesday, February 15, 2011 8:15 AM
To: Linda Dunbar
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Hi Linda,

Linda Dunbar <linda.dunbar@huawei.com> writes:

> I have some issues with this draft:

> There had been a lot of discussions on email list on what should

> Initiator (querier) do when not receiving a response from far end.

>

> Ben Jenkins suggested the following text

> (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html)

> which is not incorporated to this new draft yet.

>

>       When initiating an LM operation, the far end may require a

>       period of time to become ready for the requested measurement

>       operation or the far end may not be able to support the

>       requested measurement. Under those circumstances, LM queries MAY

>       simply be discarded, and the querier expecting a response SHOULD

>       be prepared for this situation. Alternatively, the receiver MAY

>       respond, possibly in a rate-limited manner, to queries received

>       during this period with an appropriate notification code. The

>       querier should abort the measurement after not receiving any

>       positive feedback when a specified timer expires.

With one exception, this text looks substantially the same to me as the

last paragraph of Section 4.1.1. The exception is your addition of 'or

the far end may not be able to support the requested measurement' to the

first sentence, but that case is not what this text is meant to cover:

if the far end doesn't support the requested measurement, the right

thing to do is to reply with an appropriate error code so the querier

knows what went wrong.

> Section 3.5.3: It stated:

>        When a query is received with a Session Query Interval that is

>        too low for the receiver to support, the receiver SHOULD

>        include this object when it generates an error response.

>

> Question:

>       Which error code should be used? Is it 0x18:Error - Unsupported

>       Query Interval? If Yes, should add this to the sentence.

Yes, that's the purpose of this error code. We can be explicit here.

>       What if the Querier indicates "0x2: No Response Requested"?

In general, a no-response-requested measurement means that the querier

can't receive any direct feedback; the assumption of this measurement

mode is that control is achieved through some external means, e.g. an

NMS that ensures consistent operation among the nodes involved.

> Section 4.1.5:

> * Should allow the Loss measurement to be calculated somewhere else,

> in case the initiator (querier) doesn't have the capacity to do the

> calculation.

Ben Mack-Crane has made comprehensive comments on this topic, so we'll

address it in that context.

> * Should add a description that measurement is to be stopped when far

> end not respond anymore.

OK.

Thanks for your comments!

-d

> Linda Dunbar

_______________________________________________

mpls-tp mailing list

mpls-tp@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-tp

--Boundary_(ID_NyZlYbtxfvUUJtZRdhAsxw)-- From danfrost@cisco.com Wed Feb 16 03:02:20 2011 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 935843A6A91 for ; Wed, 16 Feb 2011 03:02: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 8niEz+irQlRS for ; Wed, 16 Feb 2011 03:02: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 B35C83A6DD9 for ; Wed, 16 Feb 2011 03:02:19 -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: AksHAO89W01AZnwM/2dsb2JhbACXVo4Ic6Bpm1OFXgSMCg X-IronPort-AV: E=Sophos;i="4.60,479,1291593600"; d="scan'208";a="216217341" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2011 11:02:47 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1GB2ltZ006410; Wed, 16 Feb 2011 11:02:47 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p1GB2l7k004498; Wed, 16 Feb 2011 06:02:47 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p1GB2kLj004497; Wed, 16 Feb 2011 11:02:46 GMT Date: Wed, 16 Feb 2011 11:02:46 +0000 From: Dan Frost To: xiao.min2@zte.com.cn Message-ID: <20110216110246.GA2602@cisco.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) Cc: mpls@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 16 Feb 2011 11:02:20 -0000 Hi Xiao Min, On Tue, Feb 15, 2011 at 11:15:37AM +0800, xiao.min2@zte.com.cn wrote: > Hi Authors, > > I have a comment on loss measurement in this draft. > > After receiving LM Query message, the responder would reply LM > Response message which should take some counters. But I can't find > text in this draft to describe how the counting function at the > responder is switched on. IMHO one more bit/flag should be defined in > the LM Query message to activate or deactivate the counting function > at the responder. Did I miss something? There should be no need for a separate activation flag or message. The last paragraph of Section 4.1.1 explains what the responder can do if it is not yet ready to provide counter data. It can simply not respond until it is ready, or it can respond with an appropriate notification code in the meantime (the appropriate code in this case would be Notification - Initialization In Progress, described in Section 3.1). Cheers, -d > Best Regards, Xiao Min From danfrost@cisco.com Wed Feb 16 03:22:20 2011 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 268513A6D3C; Wed, 16 Feb 2011 03:22: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 C2BvrmTZj8BA; Wed, 16 Feb 2011 03:22:18 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4A7463A6D3A; Wed, 16 Feb 2011 03:22:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGNCW01AZnwN/2dsb2JhbAClXnOgcptOhV4EjAo X-IronPort-AV: E=Sophos;i="4.60,479,1291593600"; d="scan'208";a="215981752" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Feb 2011 11:22:46 +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 p1GBMk8Z001819; Wed, 16 Feb 2011 11:22:46 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p1GBMjc2004729; Wed, 16 Feb 2011 06:22:45 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p1GBMj8P004728; Wed, 16 Feb 2011 11:22:45 GMT Date: Wed, 16 Feb 2011 11:22:45 +0000 From: Dan Frost To: Linda Dunbar Message-ID: <20110216112245.GB2602@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F6A81B8F@DFWEML501-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F6A83645@DFWEML501-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6A83645@DFWEML501-MBX.china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 16 Feb 2011 11:22:20 -0000 Hi Linda, On Tue, Feb 15, 2011 at 04:07:12PM +0000, Linda Dunbar wrote: > You said: > "if the far end doesn't support the requested measurement, > the right thing to do is to reply with an appropriate > error code so the querier knows what went wrong." > > What if the reply message got lost? Then you have to add the mechanism > to make far-end sending multiple messages with the correct Error Code. There's no extra mechanism needed; this is the normal operation of the protocol. A lost response just means another query/response will happen. > So the simplest thing is for the Querier to stop the measurement > either upon receiving a reply with Error Code or not receiving any > reply for a while. Sure. In essence, upon receiving a query requesting an unsupported operation, the responder SHOULD respond with an appropriate error code, and in general, the querier SHOULD time out any measurement attempt that's been outstanding for too long. We'll clarify this in the text. Cheers, -d > Linda Dunbar From yaacov.weingarten@nsn.com Wed Feb 16 06:08:39 2011 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 633453A6CCD; Wed, 16 Feb 2011 06:08:39 -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 A8gU2ts+MrzR; Wed, 16 Feb 2011 06:08:38 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8E56B3A6CA7; Wed, 16 Feb 2011 06:08:33 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1GE8sWC006843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 15:08:54 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1GE8rEU011815; Wed, 16 Feb 2011 15:08:54 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 15:08:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 15:08:46 +0100 Message-ID: In-Reply-To: <021101cbc9c7$d7c8b140$875a13c0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 Thread-Index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1gATjyzUA= References: <4D4A9478.7050704@pi.nu> <021101cbc9c7$d7c8b140$875a13c0$@com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Jie Dong" , , X-OriginalArrivalTime: 16 Feb 2011 14:08:51.0980 (UTC) FILETIME=[0A08A4C0:01CBCDE3] Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 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, 16 Feb 2011 14:08:39 -0000 Jie, hi Thank you for your very detailed comments, see replies in-line BR, yaacov >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of ext Jie Dong >> Sent: Friday, February 11, 2011 10:44 AM >> To: mpls-tp@ietf.org; mpls@ietf.org >> Subject: Re: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear- >> protection-04 >>=20 >> Dear authors, >>=20 >> Here are some comments on linear protection draft. >>=20 >> 1. In section 1.2, it says: >> " The basic protocol is designed for use in conjunction with the 1:1 >> protection architecture (for both unidirectional and bidirectional >> protection) and for 1+1 protection of a bidirectional path (for both >> unidirectional and bidirectional protection switching). " >>=20 >> Would you please explain why coordination is needed for unidirectional >> protection switching in 1+1 protection of a bidirectional path? >> Because >> section 4.7.2 of tp-survive-fwk says: >> "In 1+1 unidirectional protection switching there is no need to >> coordinate >> the protection state between the protection controllers at both ends >> of the >> protection domain." yw> Yes, you are correct that there is no need for coordination for unidirectional protection however this protocol could be used by the endpoints to coordinate information regarding the state of the network.=20 >>=20 >> I guess you mean 1+1 protection may need coordination to keep traffic >> on >> co-routed paths, but that would be bidirectional protection switching. >> Hope this could be made clearer in this draft. yw> we will try to clarify this better in the next version. >>=20 >> 2. Section 2.1, Acronyms >> The full name of "LER" should be "Label Edge Router" >> "PST" is an old term replaced by SPME (Sub-Path Maintenance Entity), >> but >> neither is used in the following sections, so it may be removed from >> acronyms. Yw> You are correct and this will be corrected as suggested. >>=20 >> 3. In Section 3, there is only one level-2 subsection (3.1), so what >> about >> promote the level-3 subtitles (3.1.1, 3.1.2, ...) to level-2, and >> level-4 >> (3.1.6.1) to level-3? yw> Thank you for pointing this out! >>=20 >> 4. Section 4, 3rd paragraph, s/single-phase/single-phased, to be >> consistent >> with 2nd paragraph. yw> Thank you >>=20 >> 5. Section 4.1, 4th paragraph, >> " In the event a signal fail condition is detected on the protection >> path, >> the received PSC specific information should be evaluated." >> The statement is vague. What would be the state and action when a >> signal >> fail is detected on the protection path? Would you please elaborate on >> this >> point? yw> will try to clarify in the next version. >>=20 >> 6. Section 4.2.2, 4th paragraph, >> " The Fpath field SHALL identify the path that is reporting the >> failure >> condition (i.e. if protection path then Fpath is set to 0...". >> Since PSC message are only transmitted on protection path, if >> protection >> path has signal fail, the PSC message may not be able to be sent out >> to >> far-end. yw> Actually, if there is a signal failure on the protection path, there is a possibility that the messages may not be received by the far-end, however, it is advisable that the source end-point continue to transmit these messages. >>=20 >> 7. Section 4.3.2, there is signal degrade on working path as input, >> but no >> signal degrade on protection path. yw> Currently, the signal degrade input in this list is a place holder - the issue of how to deal with SD in general is for further study as stated in section 4.2.2. Note - there have been lengthy discussions at several IETF meetings on how to deal with SD without any conclusions. >>=20 >> 8. Section 4.3.3, I go through this part fast, a general question is: >> are >> the PSC operations for 4 different protection types identical ? In >> this >> section there is no description about operation of each specific >> protection >> type, but to my understanding, there may be different operations, >> e.g., for >> bidirectional 1:1 protection, the end point may need to switch the >> sink >> selector and transmitting bridge simultaneously according to some >> input, but >> for unidirectional 1:1 the end point may only need to switch the >> transmitting bridge OR the sink selector. And the PSC message sent may >> also >> be different for different protection types. (Please correct me if >> there is >> anything wrong with this thought). yw> Can you clarify for which scenario you believe that the messages generated should be different dependent upon the protection type (aside from the value of the protection type field)? The exact actions of the selector and transmitting bridges are not fully described in the document aside from the note at the end of section 4.3.1. In addition, in the introductory text of each state description in section 4.3.3.3.x describe how the user data is being transmitted. Is there a feeling that we need to describe this separately for each scenario? >>=20 >>=20 >> Best Regards, >> Jie >>=20 >> > -----Original Message----- >> > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> > Behalf Of Loa Andersson >> > Sent: Thursday, February 03, 2011 7:42 PM >> > To: mpls-tp@ietf.org; mpls@ietf.org >> > Cc: ahmpls-tp@lists.itu.int >> > Subject: [mpls-tp] mpls wg last call on >> draft-ietf-mpls-tp-linear-protection-04 >> > >> > Working Group, >> > >> > this is to start a four week working group last call on >> > "MPLS-TP Linear Protection" (draft-ietf-mpls-tp-linear-protection- >> 04). >> > >> > Please send comments to the mpls-tp@ietf.org mailing list. >> > >> > This working group last call ends on February 28, 2011. >> > >> > >> > >> > Loa, George and Ross >> > >> > 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 >> > _______________________________________________ >> > mpls-tp mailing list >> > mpls-tp@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp From Feng.f.Huang@alcatel-sbell.com.cn Wed Feb 16 08:43:01 2011 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 3B34D3A6E8B; Wed, 16 Feb 2011 08:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlylfp7sTrqO; Wed, 16 Feb 2011 08:43:00 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id C5F243A6E80; Wed, 16 Feb 2011 08:42:59 -0800 (PST) X-AuditID: ac189297-b7c82ae0000013a2-b2-4d5bfeae8e47 Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id AE.D8.05026.EAEFB5D4; Thu, 17 Feb 2011 00:43:26 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 00:42:53 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 00:42:50 +0800 Message-ID: In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oAAA0+koABCO/PQA== References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com><60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se><075b01cbc9c3$5a4ca810$0ee5f830$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> From: "HUANG Feng F" To: "David Allan I" , , , X-OriginalArrivalTime: 16 Feb 2011 16:42:53.0555 (UTC) FILETIME=[8E711430:01CBCDF8] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 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, 16 Feb 2011 16:43:01 -0000 Dear Dave, In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is = defined without MEG, how to detect Mismerge? And BFD protocol is enabled for period negotiation, when period is = different, lower one is used, then how to detection Uexpect period? B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = David Allan I Sent: 2011=C4=EA2=D4=C211=C8=D5 18:12 To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last callon = draft-ietf-mpls-tp-cc-cv-rdi-03 OK, will do... Dave=20 -----Original Message----- From: Mach Chen [mailto:mach@huawei.com] Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on = draft-ietf-mpls-tp-cc-cv-rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the = > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. >=20 > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may=20 > indicate an > implementation problem at the source MEP. What we were referring to in = '3' > was a session discriminator that did not exist in the local database,=20 > BFD had > never handed it out hence it could not be found. >=20 OK, but more clarification text would be helpful. Best regards, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Wed Feb 16 08:50:18 2011 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 B4FC33A6E84; Wed, 16 Feb 2011 08:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 F1JLXrYZ5XIr; Wed, 16 Feb 2011 08:50:15 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 4F6B63A6B7C; Wed, 16 Feb 2011 08:50:14 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1GHa9Ph003156; Wed, 16 Feb 2011 11:36:12 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 16 Feb 2011 11:50:38 -0500 From: David Allan I To: HUANG Feng F , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Wed, 16 Feb 2011 11:50:37 -0500 Thread-Topic: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oAAA0+koABCO/PQAAAVVfQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CDFCE2D0@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com><60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se><075b01cbc9c3$5a4ca810$0ee5f830$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> 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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 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, 16 Feb 2011 16:50:18 -0000 HI Feng: See section 7.1 of http://tools.ietf.org/html/draft-ietf-mpls-tp-identifier= s-03 . IMO it is simply a terminology issue as to whether a MEG is encoded = in the LSP and PW formats or not. Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation is = not used. So unexpected period occurs when one end unpexpectedly changes th= e period advertised. I hope this helps Dave=20 -----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 Sent: Wednesday, February 16, 2011 5:43 PM To: David Allan I; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-= rdi-03 Dear Dave, In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is defined= without MEG, how to detect Mismerge? And BFD protocol is enabled for period negotiation, when period is dif= ferent, lower one is used, then how to detection Uexpect period? B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: 2011=1B$BG/=1B(B2=1B$B7n=1B(B11=1B$BF|=1B(B 18:12 To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@= lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-= rdi-03 OK, will do... Dave=20 -----Original Message----- From: Mach Chen [mailto:mach@huawei.com] Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls= -tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the=20 > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. >=20 > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may=20 > indicate an > implementation problem at the source MEP. What we were referring to in '3= ' > was a session discriminator that did not exist in the local database,=20 > BFD had > never handed it out hence it could not be found. >=20 OK, but more clarification text would be helpful. Best regards, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eosborne@cisco.com Wed Feb 16 09:57:43 2011 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 CDA4E3A6EDE; Wed, 16 Feb 2011 09:57:43 -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 q-oIHFdoz14i; Wed, 16 Feb 2011 09:57:43 -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 C20053A6D27; Wed, 16 Feb 2011 09:57:42 -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: AiABADKfW02tJV2a/2dsb2JhbACXI45Ic6Bqm1UCgnuCYQSFCIVxhE8 X-IronPort-AV: E=Sophos;i="4.60,480,1291593600"; d="scan'208";a="216386923" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2011 17:58:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1GHwALI001388; Wed, 16 Feb 2011 17:58:10 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 11:58:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 11:58:09 -0600 Message-ID: In-Reply-To: <021101cbc9c7$d7c8b140$875a13c0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 Thread-Index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1gAUNLvlA= References: <4D4A9478.7050704@pi.nu> <021101cbc9c7$d7c8b140$875a13c0$@com> From: "Eric Osborne (eosborne)" To: "Jie Dong" , , X-OriginalArrivalTime: 16 Feb 2011 17:58:10.0887 (UTC) FILETIME=[12FB3D70:01CBCE03] Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 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, 16 Feb 2011 17:57:43 -0000 Hi Jie- Yaacov has replied to most of your comments, but let me add two things: >=20 > 6. Section 4.2.2, 4th paragraph, > " The Fpath field SHALL identify the path that is reporting the failure > condition (i.e. if protection path then Fpath is set to 0...". > Since PSC message are only transmitted on protection path, if protection > path has signal fail, the PSC message may not be able to be sent out to > far-end. As Yaacov has mentioned, we would like the PSC to send messages anyways in the chance that they may get through. This is explicitly noted in section 4.3.3.2: --- "When the domain is in unavailable state the PSC messages may not get through and therefore the protection is more dependent on the local inputs rather than the remote messages (that may not be received)." ---- Is that sufficient, or do you think we need additional text to reinforce this point? > 8. Section 4.3.3, I go through this part fast, a general question is: are > the PSC operations for 4 different protection types identical ? In this > section there is no description about operation of each specific > protection type, but to my understanding, there may be different > operations, e.g., for bidirectional 1:1 protection, the end point may need > to switch the sink selector and transmitting bridge simultaneously > according to some input, but for unidirectional 1:1 the end point may only > need to switch the transmitting bridge OR the sink selector. And the PSC > message sent may also be different for different protection types. (Please > correct me if there is anything wrong with this thought). PSC is not, in my view, tightly coupled to the four protection types. That is to say, PSC is a tool that allows the device vendor and network operator to build protection in an MPLS-TP network. This protection can be one of the four protection types you describe, but PSC is merely a protocol to accomplish the end goal. It may, for example, be possible in the future to use PSC to build one or more types of 1:n protection; when and if this is done, the message types would likely remain the same as they are now. eric >=20 >=20 > Best Regards, > Jie >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Loa Andersson > > Sent: Thursday, February 03, 2011 7:42 PM > > To: mpls-tp@ietf.org; mpls@ietf.org > > Cc: ahmpls-tp@lists.itu.int > > Subject: [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-linear-protection-04 > > > > Working Group, > > > > this is to start a four week working group last call on "MPLS-TP > > Linear Protection" (draft-ietf-mpls-tp-linear-protection-04). > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > This working group last call ends on February 28, 2011. > > > > > > > > Loa, George and Ross > > > > 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 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From xiao.min2@zte.com.cn Wed Feb 16 17:31:50 2011 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 0E3483A6F03 for ; Wed, 16 Feb 2011 17:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAFckM77RcOz for ; Wed, 16 Feb 2011 17:31:49 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7DBBF3A6F02 for ; Wed, 16 Feb 2011 17:31:48 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510806486374; Thu, 17 Feb 2011 09:30:08 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.2789515077; Thu, 17 Feb 2011 09:32:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1H1WAZv062999; Thu, 17 Feb 2011 09:32:10 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: <20110216110246.GA2602@cisco.com> To: Dan Frost MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Thu, 17 Feb 2011 09:31:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-17 09:32:10, Serialize complete at 2011-02-17 09:32:10 Content-Type: multipart/alternative; boundary="=_alternative 00086B3B4825783A_=" X-MAIL: mse01.zte.com.cn p1H1WAZv062999 Cc: mpls@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 17 Feb 2011 01:31:50 -0000 This is a multipart message in MIME format. --=_alternative 00086B3B4825783A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGFuLA0KDQpUbyBteSB1bmRlcnN0YW5kaW5nLCB0aGUgdGV4dHMgeW91IHJlZmVycmVkIGV4 cGxhaW4gd2hhdCB0aGUgUXVlcmllciBhbmQgDQp0aGUgUmVzcG9uZGVyIHNob3VsZCBkbyBpZiB0 aGUgY291bnRpbmcgZnVuY3Rpb24gYXQgdGhlIFJlc3BvbmRlciBpcyBub3QgDQpyZWFkeSwgYnV0 IHRoZXJlIGlzIG5vIHRleHQgYWJvdXQgaG93IHRvIHN3aXRjaCBvbi9vZmYgdGhpcyBjb3VudGlu ZyANCmZ1bmN0aW9uIGF0IHRoZSBSZXNwb25kZXIuIEFGQUlLIGNvdW50aW5nIGF0IHRoZSBSZXNw b25kZXIgd29uJ3QgYmUgDQpzd2l0Y2hlZCBvbiBhdXRvbWF0aWNhbGx5IGFmdGVyIHBvd2VyIHVw LCBhbmQgc29tZSBvcGVyYXRpb24gaXMgbmVlZGVkIHRvIA0KbWFrZSBjb3VudGluZyBiZWdpbi4g SSB0aGluayB0aGlzIHBvaW50IGlzIGFsc28gbmVjZXNzYXJ5IHRvIGJlIGV4cGxpY2l0bHkgDQpk ZWZpbmVkLg0KDQpCZXN0IFJlZ2FyZHMsDQpYaWFvIE1pbg0KDQoNCg0KDQpEYW4gRnJvc3QgPGRh bmZyb3N0QGNpc2NvLmNvbT4gDQoyMDExLzAyLzE2IDE5OjAyDQoNCsrVvP7Iyw0KeGlhby5taW4y QHp0ZS5jb20uY24NCrOty80NCm1wbHNAaWV0Zi5vcmcNCtb3zOINClJlOiBbbXBsc10gTVBMUyBX RyBMYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVsYXktMDENCg0KDQoNCg0KDQoN CkhpIFhpYW8gTWluLA0KDQpPbiBUdWUsIEZlYiAxNSwgMjAxMSBhdCAxMToxNTozN0FNICswODAw LCB4aWFvLm1pbjJAenRlLmNvbS5jbiB3cm90ZToNCj4gSGkgQXV0aG9ycywNCj4gDQo+IEkgaGF2 ZSBhIGNvbW1lbnQgb24gbG9zcyBtZWFzdXJlbWVudCBpbiB0aGlzIGRyYWZ0Lg0KPiANCj4gQWZ0 ZXIgcmVjZWl2aW5nIExNIFF1ZXJ5IG1lc3NhZ2UsIHRoZSByZXNwb25kZXIgd291bGQgcmVwbHkg TE0NCj4gUmVzcG9uc2UgbWVzc2FnZSB3aGljaCBzaG91bGQgdGFrZSBzb21lIGNvdW50ZXJzLiBC dXQgSSBjYW4ndCBmaW5kDQo+IHRleHQgaW4gdGhpcyBkcmFmdCB0byBkZXNjcmliZSBob3cgdGhl IGNvdW50aW5nIGZ1bmN0aW9uIGF0IHRoZQ0KPiByZXNwb25kZXIgaXMgc3dpdGNoZWQgb24uIElN SE8gb25lIG1vcmUgYml0L2ZsYWcgc2hvdWxkIGJlIGRlZmluZWQgIGluDQo+IHRoZSBMTSBRdWVy eSBtZXNzYWdlIHRvIGFjdGl2YXRlIG9yIGRlYWN0aXZhdGUgdGhlIGNvdW50aW5nIGZ1bmN0aW9u DQo+IGF0IHRoZSByZXNwb25kZXIuICBEaWQgSSBtaXNzIHNvbWV0aGluZz8NCg0KVGhlcmUgc2hv dWxkIGJlIG5vIG5lZWQgZm9yIGEgc2VwYXJhdGUgYWN0aXZhdGlvbiBmbGFnIG9yIG1lc3NhZ2Uu ICBUaGUNCmxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xLjEgZXhwbGFpbnMgd2hhdCB0aGUg cmVzcG9uZGVyIGNhbiBkbyBpZiBpdA0KaXMgbm90IHlldCByZWFkeSB0byBwcm92aWRlIGNvdW50 ZXIgZGF0YS4gIEl0IGNhbiBzaW1wbHkgbm90IHJlc3BvbmQNCnVudGlsIGl0IGlzIHJlYWR5LCBv ciBpdCBjYW4gcmVzcG9uZCB3aXRoIGFuIGFwcHJvcHJpYXRlIG5vdGlmaWNhdGlvbg0KY29kZSBp biB0aGUgbWVhbnRpbWUgKHRoZSBhcHByb3ByaWF0ZSBjb2RlIGluIHRoaXMgY2FzZSB3b3VsZCBi ZQ0KTm90aWZpY2F0aW9uIC0gSW5pdGlhbGl6YXRpb24gSW4gUHJvZ3Jlc3MsIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMuMSkuDQoNCkNoZWVycywNCg0KLWQNCg0KPiBCZXN0IFJlZ2FyZHMsIFhpYW8g TWluDQoNCg0KDQo= --=_alternative 00086B3B4825783A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhbiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRvIG15IHVuZGVyc3RhbmRpbmcs IHRoZSB0ZXh0cyB5b3UgcmVmZXJyZWQNCmV4cGxhaW4gd2hhdCB0aGUgUXVlcmllciBhbmQgdGhl IFJlc3BvbmRlciBzaG91bGQgZG8gaWYgdGhlIGNvdW50aW5nIGZ1bmN0aW9uDQphdCB0aGUgUmVz cG9uZGVyIGlzIG5vdCByZWFkeSwgYnV0IHRoZXJlIGlzIG5vIHRleHQgYWJvdXQgaG93IHRvIHN3 aXRjaA0Kb24vb2ZmIHRoaXMgY291bnRpbmcgZnVuY3Rpb24gYXQgdGhlIFJlc3BvbmRlci4gQUZB SUsgY291bnRpbmcgYXQgdGhlIFJlc3BvbmRlcg0Kd29uJ3QgYmUgc3dpdGNoZWQgb24gYXV0b21h dGljYWxseSBhZnRlciBwb3dlciB1cCwgYW5kIHNvbWUgb3BlcmF0aW9uIGlzDQpuZWVkZWQgdG8g bWFrZSBjb3VudGluZyBiZWdpbi4gSSB0aGluayB0aGlzIHBvaW50IGlzIGFsc28gbmVjZXNzYXJ5 IHRvDQpiZSBleHBsaWNpdGx5IGRlZmluZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5YaWFvIE1pbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5EYW4gRnJvc3QgJmx0O2RhbmZyb3N0QGNp c2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMS8wMi8xNiAxOTowMjwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj54aWFvLm1pbjJAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+bXBsc0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzXSBNUExTIFdHIExh c3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheS0wMTwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgWGlhbyBNaW4sPGJy Pg0KPGJyPg0KT24gVHVlLCBGZWIgMTUsIDIwMTEgYXQgMTE6MTU6MzdBTSArMDgwMCwgeGlhby5t aW4yQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyBIaSBBdXRob3JzLDxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIGhhdmUgYSBjb21tZW50IG9uIGxvc3MgbWVhc3VyZW1lbnQgaW4gdGhpcyBkcmFm dC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQWZ0ZXIgcmVjZWl2aW5nIExNIFF1ZXJ5IG1lc3NhZ2Us IHRoZSByZXNwb25kZXIgd291bGQgcmVwbHkgTE08YnI+DQomZ3Q7IFJlc3BvbnNlIG1lc3NhZ2Ug d2hpY2ggc2hvdWxkIHRha2Ugc29tZSBjb3VudGVycy4gQnV0IEkgY2FuJ3QgZmluZDxicj4NCiZn dDsgdGV4dCBpbiB0aGlzIGRyYWZ0IHRvIGRlc2NyaWJlIGhvdyB0aGUgY291bnRpbmcgZnVuY3Rp b24gYXQgdGhlPGJyPg0KJmd0OyByZXNwb25kZXIgaXMgc3dpdGNoZWQgb24uIElNSE8gb25lIG1v cmUgYml0L2ZsYWcgc2hvdWxkIGJlIGRlZmluZWQNCiZuYnNwO2luPGJyPg0KJmd0OyB0aGUgTE0g UXVlcnkgbWVzc2FnZSB0byBhY3RpdmF0ZSBvciBkZWFjdGl2YXRlIHRoZSBjb3VudGluZyBmdW5j dGlvbjxicj4NCiZndDsgYXQgdGhlIHJlc3BvbmRlci4gJm5ic3A7RGlkIEkgbWlzcyBzb21ldGhp bmc/PGJyPg0KPGJyPg0KVGhlcmUgc2hvdWxkIGJlIG5vIG5lZWQgZm9yIGEgc2VwYXJhdGUgYWN0 aXZhdGlvbiBmbGFnIG9yIG1lc3NhZ2UuICZuYnNwO1RoZTxicj4NCmxhc3QgcGFyYWdyYXBoIG9m IFNlY3Rpb24gNC4xLjEgZXhwbGFpbnMgd2hhdCB0aGUgcmVzcG9uZGVyIGNhbiBkbyBpZiBpdDxi cj4NCmlzIG5vdCB5ZXQgcmVhZHkgdG8gcHJvdmlkZSBjb3VudGVyIGRhdGEuICZuYnNwO0l0IGNh biBzaW1wbHkgbm90IHJlc3BvbmQ8YnI+DQp1bnRpbCBpdCBpcyByZWFkeSwgb3IgaXQgY2FuIHJl c3BvbmQgd2l0aCBhbiBhcHByb3ByaWF0ZSBub3RpZmljYXRpb248YnI+DQpjb2RlIGluIHRoZSBt ZWFudGltZSAodGhlIGFwcHJvcHJpYXRlIGNvZGUgaW4gdGhpcyBjYXNlIHdvdWxkIGJlPGJyPg0K Tm90aWZpY2F0aW9uIC0gSW5pdGlhbGl6YXRpb24gSW4gUHJvZ3Jlc3MsIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuMSkuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCi1kPGJyPg0KPGJyPg0K Jmd0OyBCZXN0IFJlZ2FyZHMsIFhpYW8gTWluPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+ DQo= --=_alternative 00086B3B4825783A_=-- From dai.xuehui@zte.com.cn Wed Feb 16 18:55:14 2011 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 82A343A6C31; Wed, 16 Feb 2011 18:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.776 X-Spam-Level: X-Spam-Status: No, score=-95.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5VKTkrMQu4b; Wed, 16 Feb 2011 18:55:13 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4127E3A6CE5; Wed, 16 Feb 2011 18:55:12 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951911657480; Thu, 17 Feb 2011 10:50:38 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.3038837400; Thu, 17 Feb 2011 10:55:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1H2tStJ072957; Thu, 17 Feb 2011 10:55:28 +0800 (GMT-8) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: <4D4A9478.7050704@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-KeepSent: A15D6179:FFA847CB-4825783A:000F9AEF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: dai.xuehui@zte.com.cn Date: Thu, 17 Feb 2011 10:55:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-17 10:55:28, Serialize complete at 2011-02-17 10:55:28 Content-Type: multipart/alternative; boundary="=_alternative 001011BB4825783A_=" X-MAIL: mse02.zte.com.cn p1H2tStJ072957 Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int, mpls-tp-bounces@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-linear-protection-04 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, 17 Feb 2011 02:55:14 -0000 This is a multipart message in MIME format. --=_alternative 001011BB4825783A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhdXRob3Jzo6wNCg0KQmVsb3cgYXJlIHR3byBjb21tZW50czoNCg0KMS4gaW4gc2VjdGlv biAzLjEuNi4gIFBTQyBDb250cm9sIFN0YXRlcw0KdGhlIGRlZmluaXRpb24gb2YgdW5hdmFpbGFi bGUgc3RhdGUgaXMgOg0KIlVuYXZhaWxhYmxlIHN0YXRlIC0gVGhlIHByb3RlY3Rpb24gcGF0aCBp cyB1bmF2YWlsYWJsZSAtIGVpdGhlciBhcyBhIA0KcmVzdWx0IG9mIGFuIG9wZXJhdG9yIExvY2tv dXQgY29tbWFuZCBvciBhIGZhaWx1cmUvZGVncmFkZSBjb25kaXRpb24gDQpkZXRlY3RlZCBvbiB0 aGUgcHJvdGVjdGlvbiBwYXRoLiINCmJ1dCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rp b24gNC4zLjMuMi4sICB0aGUgY2F1c2Ugb2YgdW5hdmFpbGFibGUgDQpzdGF0ZSBkb2VzIG5vdCBp bmNsdWRlICB0aGlzIGRlZ3JhZGUgY29uZGl0aW9uIGRldGVjdGVkIG9uIHRoZSBwcm90ZWN0aW9u IA0KcGF0aC4NCg0KdGhlc2UgdHdvIGRlc2NyaXB0aW9ucyBhcmUgbm90IGNvbnNpc3RlbnQuDQoN CjIuIHR5cG8gDQp0aGUgZmlyc3QgcGFyYWdyYWdoICBpbiBzZWN0aW9uIDQuMy4zLjQuLCAicmVt b3RlIFNGIFBDUyBtZXNzYWdlIiBzaGFsbCBiZSANCmNoYW5nZWQgdG8gInJlbW90ZSBTRiBQU0Mg IG1lc3NhZ2UiIA0KDQpCZXN0IFJlZ2FyZHMsDQp4dWVodWkNCg0KDQoNCg0KTG9hIEFuZGVyc3Nv biA8bG9hQHBpLm51PiANCreivP7IyzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0w Mi0wMyAxOTo0MQ0KDQrK1bz+yMsNCm1wbHMtdHBAaWV0Zi5vcmcsIG1wbHNAaWV0Zi5vcmcNCrOt y80NCmFobXBscy10cEBsaXN0cy5pdHUuaW50DQrW98ziDQpbbXBscy10cF0gbXBscyB3ZyBsYXN0 IGNhbGwgb24gIGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbi0wNA0KDQoNCg0K DQoNCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0byBzdGFydCBhIGZvdXIgd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KIk1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24iIChkcmFm dC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tMDQpLg0KDQpQbGVhc2Ugc2VuZCBjb21t ZW50cyB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QuDQoNClRoaXMgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBGZWJydWFyeSAyOCwgMjAxMS4NCg0KDQoNCkxvYSwg R2VvcmdlIGFuZCBSb3NzDQoNCk1QTFMgd2cgY28tY2hhaXJzDQoNCg0KDQotLSANCg0KDQpMb2Eg QW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVy aWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAg bG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiAr NDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg== --=_alternative 001011BB4825783A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgYXV0aG9yc6OsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZWxvdyBhcmUgdHdv IGNvbW1lbnRzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+MS4gaW4gc2VjdGlvbiAzLjEuNi4gJm5ic3A7UFNDIENvbnRyb2wNClN0YXRlczwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGRlZmluaXRpb24gb2YgdW5h dmFpbGFibGUgc3RhdGUNCmlzIDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZxdW90O1VuYXZhaWxhYmxlIHN0YXRlIC0gVGhlIHByb3RlY3Rpb24NCnBhdGggaXMg dW5hdmFpbGFibGUgLSBlaXRoZXIgYXMgYSByZXN1bHQgb2YgYW4gb3BlcmF0b3IgTG9ja291dCBj b21tYW5kDQpvciBhIGZhaWx1cmUvZGVncmFkZSBjb25kaXRpb24gZGV0ZWN0ZWQgb24gdGhlIHBy b3RlY3Rpb24gcGF0aC4mcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPmJ1dCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24NCjQuMy4zLjIuLCAm bmJzcDt0aGUgY2F1c2Ugb2YgdW5hdmFpbGFibGUgc3RhdGUgZG9lcyBub3QgaW5jbHVkZSAmbmJz cDt0aGlzDQpkZWdyYWRlIGNvbmRpdGlvbiBkZXRlY3RlZCBvbiB0aGUgcHJvdGVjdGlvbiBwYXRo LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlc2Ug dHdvIGRlc2NyaXB0aW9ucyBhcmUgbm90IGNvbnNpc3RlbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiB0eXBvIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGZpcnN0IHBhcmFncmFnaCAmbmJzcDtpbiBzZWN0 aW9uDQo0LjMuMy40LiwgJnF1b3Q7cmVtb3RlIFNGIFBDUyBtZXNzYWdlJnF1b3Q7IHNoYWxsIGJl IGNoYW5nZWQgdG8gJnF1b3Q7cmVtb3RlDQpTRiBQU0MgJm5ic3A7bWVzc2FnZSZxdW90OyA8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVnYXJk cyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnh1ZWh1aTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5M b2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtdHAtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAyLTAz IDE5OjQxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPm1wbHMtdHBAaWV0Zi5vcmcsIG1wbHNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PmFobXBscy10cEBsaXN0cy5pdHUuaW50PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBscy10cF0gbXBs cyB3ZyBsYXN0IGNhbGwgb24gJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYt bXBscy10cC1saW5lYXItcHJvdGVjdGlvbi0wNDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+V29ya2luZyBHcm91cCw8YnI+DQo8YnI+DQp0 aGlzIGlzIHRvIHN0YXJ0IGEgZm91ciB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJy Pg0KJnF1b3Q7TVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiZxdW90OyAoZHJhZnQtaWV0Zi1tcGxz LXRwLWxpbmVhci1wcm90ZWN0aW9uLTA0KS48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCBjb21tZW50 cyB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QuPGJyPg0KPGJyPg0KVGhpcyB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEZlYnJ1YXJ5IDI4LCAyMDExLjxicj4NCjxi cj4NCjxicj4NCjxicj4NCkxvYSwgR2VvcmdlIGFuZCBSb3NzPGJyPg0KPGJyPg0KTVBMUyB3ZyBj by1jaGFpcnM8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmlj c3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAg NzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10 cEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cy10cDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 001011BB4825783A_=-- From Feng.f.Huang@alcatel-sbell.com.cn Wed Feb 16 22:27:33 2011 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 6C5FD3A6D7B; Wed, 16 Feb 2011 22:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+0PcCC6XG-p; Wed, 16 Feb 2011 22:27:24 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id D6A043A6D6A; Wed, 16 Feb 2011 22:27:20 -0800 (PST) X-AuditID: ac189297-b7c82ae0000013a2-31-4d5cbfe5a0c5 Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 7F.69.05026.5EFBC5D4; Thu, 17 Feb 2011 14:27:49 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 14:27:16 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 14:27:12 +0800 Message-ID: In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51CDFCE2D0@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oAAA0+koABCO/PQAAAVVfQAABHbLA= References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com><60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se><075b01cbc9c3$5a4ca810$0ee5f830$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51CDFCE2D0@EUSAACMS0703.eamcs.ericsson.se> From: "HUANG Feng F" To: "David Allan I" , , , X-OriginalArrivalTime: 17 Feb 2011 06:27:16.0410 (UTC) FILETIME=[B899C9A0:01CBCE6B] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 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, 17 Feb 2011 06:27:33 -0000 Hi,Dave, Thanks, LSP MEP ID in draft-ietf-mpls-tp-identifiers-03 is: = Node_ID::Tunnel_Num::LSP_Num, =20 and for LSP MEG ID: (7.1.2.1.) Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs for MPLS-TP LSPs are simply the corresponding LSP_IDs. We note that while the two identifiers are syntactically identical, they have different semantics. This semantic difference needs to be made clear. For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs are to be encoded in TLVs different types need to be assigned for these two identifiers. =20 you can only detect wrong MEP ID, that's Unexpected MEP, it is not = Mis-merge. =20 If period negotiation is not used, how to insure interoperability with = BFD used in IP/MPLS asked always by providers? B.R. Feng =20 -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: 2011=C4=EA2=D4=C217=C8=D5 0:51 To: HUANG Feng F; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last = callondraft-ietf-mpls-tp-cc-cv-rdi-03 HI Feng: See section 7.1 of = http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-03 . IMO it is = simply a terminology issue as to whether a MEG is encoded in the LSP and = PW formats or not. Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation = is not used. So unexpected period occurs when one end unpexpectedly = changes the period advertised. I hope this helps Dave=20 -----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Wednesday, February 16, 2011 5:43 PM To: David Allan I; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callon = draft-ietf-mpls-tp-cc-cv-rdi-03 Dear Dave, In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is = defined without MEG, how to detect Mismerge? And BFD protocol is enabled for period negotiation, when period is = different, lower one is used, then how to detection Uexpect period? B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = David Allan I Sent: 2011=C4=EA2=D4=C211=C8=D5 18:12 To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last callon = draft-ietf-mpls-tp-cc-cv-rdi-03 OK, will do... Dave=20 -----Original Message----- From: Mach Chen [mailto:mach@huawei.com] Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on = draft-ietf-mpls-tp-cc-cv-rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the = > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. >=20 > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may=20 > indicate an > implementation problem at the source MEP. What we were referring to in = '3' > was a session discriminator that did not exist in the local database,=20 > BFD had > never handed it out hence it could not be found. >=20 OK, but more clarification text would be helpful. Best regards, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Thu Feb 17 00:01:35 2011 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 DD7583A6D84; Thu, 17 Feb 2011 00:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 CmuaEbvQfXwH; Thu, 17 Feb 2011 00:01:34 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id AC02B3A6D48; Thu, 17 Feb 2011 00:01:34 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p1H821OF032709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Feb 2011 02:02:01 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 17 Feb 2011 03:02:01 -0500 From: David Allan I To: HUANG Feng F , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Thu, 17 Feb 2011 03:01:34 -0500 Thread-Topic: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAAlE/oAAA0+koABCO/PQAAAVVfQAABHbLAAH2laQA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CDFCE7FC@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com><60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se><075b01cbc9c3$5a4ca810$0ee5f830$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3FEBE@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD51CDFCE2D0@EUSAACMS0703.eamcs.ericsson.se> 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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 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, 17 Feb 2011 08:01:36 -0000 Hi Feng: I'm not sure how unexpected MEP is not indicative of a mismerge. Either the= source MEP ID has been misconfigured, or you are receiving a message from = a MEP due to LIB corruption or similar defect somewhere in the network.=20 As for your second point, it is not that negotiation is not used, there is = simply no give and take allowed, so the procedures are simply modified slig= htly in the TP case . If the far end refuses to support the requested perio= dicity for whatever reason, you do not progress beyond the INIT state and p= resumably send some indication to management that the session could not com= e "UP". You have that option whether you are conformant to CC-CV-RDI draft = or simply RFC 5884. So as far as I can tell interoperability options exist,= they were always there in the protocol, we are simply providing implementa= tion guidelines for the TP application... I hope this helps Dave -----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 Sent: Thursday, February 17, 2011 7:27 AM To: David Allan I; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-r= di-03 Hi,Dave, Thanks, LSP MEP ID in draft-ietf-mpls-tp-identifiers-03 is: Node_ID::T= unnel_Num::LSP_Num, =20 and for LSP MEG ID: (7.1.2.1.) Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs for MPLS-TP LSPs are simply the corresponding LSP_IDs. We note that while the two identifiers are syntactically identical, they have different semantics. This semantic difference needs to be made clear. For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs are to be encoded in TLVs different types need to be assigned for these two identifiers. =20 you can only detect wrong MEP ID, that's Unexpected MEP, it is not Mis-merg= e. =20 If period negotiation is not used, how to insure interoperability with BFD = used in IP/MPLS asked always by providers? B.R. Feng =20 -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 2011=1B$BG/=1B(B2=1B$B7n=1B(B17=1B$BF|=1B(B 0:51 To: HUANG Feng F; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-r= di-03 HI Feng: See section 7.1 of http://tools.ietf.org/html/draft-ietf-mpls-tp-identifier= s-03 . IMO it is simply a terminology issue as to whether a MEG is encoded = in the LSP and PW formats or not. Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation is = not used. So unexpected period occurs when one end unpexpectedly changes th= e period advertised. I hope this helps Dave=20 -----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Wednesday, February 16, 2011 5:43 PM To: David Allan I; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-= rdi-03 Dear Dave, In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is defined= without MEG, how to detect Mismerge? And BFD protocol is enabled for period negotiation, when period is dif= ferent, lower one is used, then how to detection Uexpect period? B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: 2011=1B$BG/=1B(B2=1B$B7n=1B(B11=1B$BF|=1B(B 18:12 To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@= lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-= rdi-03 OK, will do... Dave=20 -----Original Message----- From: Mach Chen [mailto:mach@huawei.com] Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls= -tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the=20 > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. >=20 > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may=20 > indicate an > implementation problem at the source MEP. What we were referring to in '3= ' > was a session discriminator that did not exist in the local database,=20 > BFD had > never handed it out hence it could not be found. >=20 OK, but more clarification text would be helpful. Best regards, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From matthew.bocci@alcatel-lucent.com Thu Feb 17 05:34:11 2011 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 29ED63A6CCA; Thu, 17 Feb 2011 05:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 7UWl1YKipeAQ; Thu, 17 Feb 2011 05:34:09 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 292023A6CAE; Thu, 17 Feb 2011 05:34:08 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1HDXfjc008936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Feb 2011 14:34:38 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 17 Feb 2011 14:34:35 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 17 Feb 2011 14:34:34 +0100 Thread-Topic: PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Thread-Index: AcvOp2qo3CL3sSTlSLeLd/7Gd8zznQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-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: Thu, 17 Feb 2011 13:34:11 -0000 This email begins a working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. This is a very short draft but since there are other MPLS-TP-related last calls going on concurrently, this will be a three-week last call. This WG LC will end of 11th March 2011. Please respond with any comments to the PWE3 mailing list. Regards, Matthew and Andy =20 From venkatflex@gmail.com Thu Feb 17 07:41:55 2011 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 AE5853A6F2F; Thu, 17 Feb 2011 07:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmUCO9cLchvs; Thu, 17 Feb 2011 07:41:53 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4D2573A6DFE; Thu, 17 Feb 2011 07:41:53 -0800 (PST) Received: by qwi2 with SMTP id 2so2716485qwi.31 for ; Thu, 17 Feb 2011 07:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=IyelI0DjS865cW3cXKFj4Vt8S7MgxcJx915NZy95aCU=; b=fC3Qb902mUBJ7B02RMba4g/LskUtmNWWgwY4iSJEED2i8mRhuXGypgWXXbi5XLGvI3 jdGBFgQ2MZv8NgCUp54CDsU2h8EP2exy6XNsOLguFd9ALBAOGoHVVMsNCmUKd5sPxLFT ixAmQxGuVdjkNWog6MoVvl/t8+SqQNUcpDoT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZcHxJIjB4AvnhNUaMsCLDwHBjIgb41Ef11aDeQfJdoP1JCTTXzHxLbI1dl1dgs/XpC NoKbOcQYNIwJDK/xneTRWjugsv01H+an/ZpKzDbT9IDG3tVN3IPU7lykrCUg5UNw9eHv Ljem30yeC0NPRpvrjXYMSHLnLWkpkqGg89a0s= MIME-Version: 1.0 Received: by 10.224.37.140 with SMTP id x12mr2709784qad.158.1297957343414; Thu, 17 Feb 2011 07:42:23 -0800 (PST) Received: by 10.224.20.71 with HTTP; Thu, 17 Feb 2011 07:42:23 -0800 (PST) Date: Thu, 17 Feb 2011 10:42:23 -0500 Message-ID: From: venkatesan mahalingam To: mpls-tp@ietf.org, mpls , david.i.allan@ericsson.com Content-Type: multipart/alternative; boundary=0015175ce016634902049c7c3ecf Subject: Re: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 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, 17 Feb 2011 15:41:55 -0000 --0015175ce016634902049c7c3ecf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, W.r.t ITU standard, Mismerge and Unexpected MEP are identified as follows, If a CCM frame with same MEG Level but with a MEG ID different than the receiving MEP=E2=80=99s own MEG ID is received, *Mismerge* is detected. =E2=80=A2 If a CCM frame with the same MEG Level and a correct MEG ID but w= ith an incorrect MEP ID, including receiving MEP=E2=80=99s own MEP ID, is received, *Unexpected MEP* is detect= ed. I think, the authors should clearly differentiate the unexpected MEP and Mismerge defects in the MPLS-TP OAM? --=20 BR, Venkat. Hi Feng: I'm not sure how unexpected MEP is not indicative of a mismerge. Either the source MEP ID has been misconfigured, or you are receiving a message from a MEP due to LIB corruption or similar defect somewhere in the network. As for your second point, it is not that negotiation is not used, there is simply no give and take allowed, so the procedures are simply modified slightly in the TP case . If the far end refuses to support the requested periodicity for whatever reason, you do not progress beyond the INIT state and presumably send some indication to management that the session could not come "UP". You have that option whether you are conformant to CC-CV-RDI draft or simply RFC 5884. So as far as I can tell interoperability options exist, they were always there in the protocol, we are simply providing implementation guidelines for the TP application... I hope this helps Dave ----- Original Message ----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn ] Sent: Thursday, February 17, 2011 11:57 AM To: David Allan I ; MPLS TP; mpls@ietf.org < mpls@ietf.org>; ahmpls-tp@lists.itu.int Subject: Re: [mpls-tp] [mpls] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 Hi,Dave, Thanks, LSP MEP ID in draft-ietf-mpls-tp-identifiers-03 is: Node_ID::Tunnel_Num::LSP_Num, and for LSP MEG ID: (7.1.2.1.) Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs for MPLS-TP LSPs are simply the corresponding LSP_IDs. We note that while the two identifiers are syntactically identical, they have different semantics. This semantic difference needs to be made clear. For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs are to be encoded in TLVs different types need to be assigned for these two identifiers. you can only detect wrong MEP ID, that's Unexpected MEP, it is not Mis-merge. If period negotiation is not used, how to insure interoperability with BFD used in IP/MPLS asked always by providers? B.R. Feng -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com ] Sent: 2011=E5=B9=B42=E6=9C=8817=E6=97=A5 0:51 To: HUANG Feng F; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03 HI Feng: See section 7.1 of http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-03 . IMO it is simply a terminology issue as to whether a MEG is encoded in the LSP and PW formats or not. Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation is not used. So unexpected period occurs when one end unpexpectedly changes th= e period advertised. I hope this helps Dave -----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn ] Sent: Wednesday, February 16, 2011 5:43 PM To: David Allan I; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Cc: Loa Andersson Subject: RE: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 Dear Dave, In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is defined without MEG, how to detect Mismerge? And BFD protocol is enabled for period negotiation, when period is different, lower one is used, then how to detection Uexpect period? B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I Sent: 2011=E5=B9=B42=E6=9C=8811=E6=97=A5 18:12 To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-cc-cv-rdi-03 OK, will do... Dave -----Original Message----- From: Mach Chen [mailto:mach@huawei.com ] Sent: Friday, February 11, 2011 12:12 AM To: David Allan I; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Hi Dave, Thanks for your prompt response! > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the > session >discriminator is valid but the label is invalid? IMHO, this defect is just > another description of defect 3 . Suggest to remove it. > > If the session discriminator exists in the BFD database, it is superficially a valid > descriminator but the label of arrival can be incorrect. This may > indicate an > implementation problem at the source MEP. What we were referring to in '3= ' > was a session discriminator that did not exist in the local database, > BFD had > never handed it out hence it could not be found. > OK, but more clarification text would be helpful. Best regards, Mach --0015175ce016634902049c7c3ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

W.r.t ITU standard, Mismerge and Unexpect= ed MEP are identified as follows,

If a CCM frame w= ith same MEG Level but with a MEG ID different than the receiving MEP=E2=80= =99s own MEG ID is=C2=A0

received, Mismerge is detected.

=E2=80= =A2 If a CCM frame with the same MEG Level and a correct MEG ID but with an= incorrect MEP ID, including=C2=A0
receiving MEP=E2=80=99s own ME= P ID, is received, Unexpected MEP is detected.

I think, the authors should clearly=C2=A0differentiate=C2=A0= the unexpected MEP and Mismerge defects in the MPLS-TP OAM?

-- =
BR,
Venkat.

Hi Feng: I'm not sure how unexpected MEP is not indicative of a mismerge. Either= the source MEP ID has been misconfigured, or you are receiving a message f= rom a MEP due to LIB corruption or similar defect somewhere in the network.= =20 As for your second point, it is not that negotiation is not used, there is = simply no give and take allowed, so the procedures are simply modified slig= htly in the TP case . If the far end refuses to support the requested perio= dicity for whatever reason, you do not progress beyond the INIT state and p= resumably send some indication to management that the session could not com= e "UP". You have that option whether you are conformant to CC-CV-= RDI draft or simply RFC 5884. So as far as I can tell interoperability opti= ons exist, they were always there in the protocol, we are simply providing = implementation guidelines for the TP application... I hope this helps Dave
----- Original Message -----
From: HUANG Feng= F [mailto:Feng.f.Huang@alcatel-sbell.com= .cn]
Sent: Thursday, February 17, 2011 11= :57 AM
To: David Allan I <david.i.allan@ericsson.com>; MPLS TP= ; mpls@ietf.org <mpls@ietf.org>; ahmpls-tp@lists.itu.int <ahmpls-tp@lists.itu.int>
Subject: Re: [mpls-tp] [mpls] mpls w= g last=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 callondraft-ietf-mpls-tp-cc-cv-rdi-03<= /span>

Hi,Dave,
=C2=A0=C2=A0=C2=A0=C2=A0 Thanks, LSP= MEP ID in draft-ietf-mpls-tp-identifiers-03 is: Node_ID::Tunnel_Num::LSP_N= um,=C2=A0=C2=A0

and for LSP MEG ID: (7.1.2.1.)
=C2=A0=C2=A0=C2=A0 Since a MEG perta= ins to a single MPLS-TP LSP, IP compatible MEG_IDs
=C2=A0=C2=A0 for MPLS-TP LSPs are si= mply the corresponding LSP_IDs.=C2=A0 We note that
=C2=A0=C2=A0 while the two identifie= rs are syntactically identical, they have
=C2=A0=C2=A0 different semantics.=C2= =A0 This semantic difference needs to be made
=C2=A0=C2=A0 clear.=C2=A0 For instan= ce if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs
=C2=A0=C2=A0 are to be encoded in TL= Vs different types need to be assigned for
=C2=A0=C2=A0 these two identifiers.<= /span>
=C2=A0
you can only detect wrong MEP ID, th= at's Unexpected MEP, it is not Mis-merge.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
If period negotiation is not used, h= ow to insure interoperability with BFD used in IP/MPLS asked always by prov= iders?

B.R.
Feng
=C2=A0

-----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=C2=A0
Sent: 2011=E5=B9=B42=E6=9C=8817=E6= =97=A5 0:51
To: HUANG Feng F; mpls-tp@ietf.org; mp= ls@ietf.org; ahmpls-tp@lists= .itu.int
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls w= g last callondraft-ietf-mpls-tp-cc-cv-rdi-03

HI Feng:

See section 7.1 of=C2=A0ht= tp://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-03=C2=A0. IM= O it is simply a terminology issue as to whether a MEG is encoded in the LS= P and PW formats or not.

Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiat= ion is not used. So unexpected period occurs when one end unpexpectedly cha= nges the period advertised.

I hope this helps
Dave=C2=A0

-----Original Message----- From: HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]
Sent: Wednesday, February 16, 2011 5= :43 PM
To: David Allan I; mpls-tp@ietf.org; m= pls@ietf.org; ahmpls-tp@list= s.itu.int
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls w= g last callon draft-ietf-mpls-tp-cc-cv-rdi-03

=C2=A0Dear Dave,
=C2=A0=C2=A0=C2=A0=C2=A0 In 3.3. MPL= S BFD proactive CV Message format, LSP/PW MEP ID is defined without MEG, ho= w to detect Mismerge?
=C2=A0=C2=A0=C2=A0=C2=A0 And BFD pro= tocol is enabled for period negotiation, when period is different, lower on= e is used, then how to detection Uexpect period?
B.R.
Feng

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of Davi= d Allan I
Sent: 2011=E5=B9=B42=E6=9C=8811=E6= =97=A5 18:12
To: Mach Chen; 'Loa Andersson= 9;; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls w= g last callon draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave=C2=A0

-----Original Message----- From: Mach Chen [m= ailto:mach@huawei.com]
Sent: Friday, February 11, 2011 12:1= 2 AM
To: David Allan I; 'Loa Andersso= n'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int
Subject: RE: [mpls] [mpls-tp] mpls w= g last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

Thanks for your prompt response!
> >3 Section 3.5.2
> >" 4. Receipt of an exp= ected session discriminator with an unexpected
label
> (mis-connectivity defect)."= ;, For a receiver, how does it know that the=C2=A0
> session >discriminator is va= lid but the label is invalid? IMHO, this
defect is just
> another description of defect 3= . Suggest to remove it.
>=C2=A0
> If the session discriminator ex= ists in the BFD database, it is
superficially a valid
> descriminator but the label of = arrival can be incorrect. This may= =C2=A0
> indicate
an
> implementation problem at the s= ource MEP. What we were referring to in '3'
> was a session discriminator tha= t did not exist in the local database,
> BFD
had
> never handed it out hence it co= uld not be found.
>=C2=A0

OK, but more clarification text would be helpful.

Best regards,
Mach

--0015175ce016634902049c7c3ecf-- From wwwrun@core3.amsl.com Thu Feb 17 14:04:47 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 468723A6D31; Thu, 17 Feb 2011 14:04:47 -0800 (PST) From: Stephanie McCammon(IETF PWE3 WG) To: Greg Jones Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110217220447.468723A6D31@core3.amsl.com> Date: Thu, 17 Feb 2011 14:04:47 -0800 (PST) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, mpls-tp@ietf.or, malcolm.betts@zte.com.cn, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, pwe3@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, andrew.g.malis@verizon.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Matthew Bocci List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 22:04:47 -0000 Title: IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Submission Date: 2011-02-17 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1017 Please reply by 2011-03-11 From: Stephanie McCammon(IETF PWE3 WG) To: ITU-T SG15, Q9, Q10, Q12 and Q14(Greg Jones ) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com stbryant@cisco.com pwe3@ietf.org mpls@ietf.org mpls-tp@ietf.or Reponse Contact: matthew.bocci@alcatel-lucent.com andrew.g.malis@verizon.com Technical Contact: andrew.g.malis@verizon.com Purpose: For action Body: The PWE3 working group would like to inform you that we have started a working group last call on "Using the Generic Associated Channel Label for Pseudowire in MPLS-TP" (draft-ietf-pwe3-mpls-tp-gal-in-pw-00). This is a very short draft but since there are other MPLS-TP-related last calls going on concurrently, this will be a three-week last call. Since we intend to work the comments received through this working group last call into the documents that will be discussed at the IETF meeting in Prague, we would like to receive comments from the ITU-T by March 11, 2011. Matthew Bocci Andrew Malis IETF PWE3 Working Group Chairs Attachment(s): No document has been attached From Internet-Drafts@ietf.org Thu Feb 17 14:45:02 2011 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 3C0F13A6D89; Thu, 17 Feb 2011 14:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 wRQxATv3NfZC; Thu, 17 Feb 2011 14:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5513A6D31; Thu, 17 Feb 2011 14:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110217224501.7853.26849.idtracker@localhost> Date: Thu, 17 Feb 2011 14:45:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-security-framework-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, 17 Feb 2011 22: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 Security Framework Author(s) : N. Bitar, L. Fang, B. Niven-Jenkins, R. Zhang, S. Mansfield, M. Daikoku, L. Wang Filename : draft-ietf-mpls-tp-security-framework-00.txt Pages : 25 Date : 2011-2-16 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, transport oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP; potential securities threats and migration procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS networks. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-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-security-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-2-17143019.I-D@ietf.org> --NextPart-- From gregimirsky@gmail.com Thu Feb 17 22:46:36 2011 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 A11863A6D72; Thu, 17 Feb 2011 22:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvZvAAJlzCXY; Thu, 17 Feb 2011 22:46:34 -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 137123A6D6D; Thu, 17 Feb 2011 22:46:32 -0800 (PST) Received: by vws7 with SMTP id 7so1857315vws.31 for ; Thu, 17 Feb 2011 22:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=xYg5vczfCME4GJsR8FblCbXMVCVcfzDurewQ8UrgMaE=; b=xExpT6gzSVSLXwmnCoukrkVsTDHI/sWu6W3TYtXC12AFj3QAUVBw/j2idBOPuHjmly b4gh6VAKhetN/a9aXP7CVaVXNvXy2JU3yJrRHFcQ7PygxRacnDyt/O/+fS6pM2cX7XkS +jEQtm73fjaWyn+cC6W5WqYwsf0RYzgVypVyQ= 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=PpRD0yF7OSDzdI3kcYo9ItTIKzLUxbBqpkq+Q+v2F4iQHo5Bl91HDzBF9XBm8Q9mHd EqP9RKHiA7Fe53hXyAIGKlqJd7L6QC682vu7LXr8kmlbQ6xskmq9sK3iP2e3FvizIONI e/3YcjViVxfdhLmCpqPvwka1P+9M0pvtuxktw= MIME-Version: 1.0 Received: by 10.52.157.65 with SMTP id wk1mr556497vdb.125.1298011624253; Thu, 17 Feb 2011 22:47:04 -0800 (PST) Received: by 10.52.165.9 with HTTP; Thu, 17 Feb 2011 22:47:04 -0800 (PST) Date: Thu, 17 Feb 2011 22:47:04 -0800 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec53f931fc72a77049c88e1ce Cc: mpls@ietf.org, mpls-tp@ietf.org, lihan@chinamobile.com, pwe3 , HUANG Feng F Subject: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:46:36 -0000 --bcaec53f931fc72a77049c88e1ce Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG document Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in the minutes. I think that this issue should be specified, explained. In my view, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini wrote: > Greg, > > You are correct , the proposed update does not propose any changes to VCCV. > However the problem with vccv is not as simple as to ask for a new code > point from IANA. > Given the good amount of discussion on this point, we should probably have > a discussion in Beijing. > > Luca > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > Dear Authors, > I think that proposed update of the Section 4.2. RFC 5586 makes it possible > to use GAL on MPLS-TP PW that uses Control Word. I consider it to be > conflict between PW VCCV CC types because use of GAL is not negotiated > through PW VCCV negotiation. To avoid such situation I propose: > > - in Section 5 request IANA to assign new CC Type "MPLS Generic > Associated Channel Label" > - assign precedence to new CC Type that affects Section 7 RFC 5085 > > Regards, > Greg > > > > _______________________________________________ > mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls > > > --bcaec53f931fc72a77049c88e1ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
prior to the meeting in Bejing and acceptance of t= his proposal as WG document Luca and I agreed that use of GAL with PW VCCV = presents a problem.
I was not attending the IETF-79, nor I found discuss= ion of this issue in the minutes. I think that this issue should be specifi= ed, explained. In my view, this document updates not only RFC 5586
but RFC 5085 too.

Regards,
Greg

Comment to draft-lm-pwe3-m= pls-tp-gal-in-pw-00.txt

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

=20 =20 =20 =20
Greg,

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

Luca

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

Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg

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

--bcaec53f931fc72a77049c88e1ce-- From Alexander.Vainshtein@ecitele.com Thu Feb 17 23:07:36 2011 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 A03EB3A68DD; Thu, 17 Feb 2011 23:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 GdrWklM+u8kJ; Thu, 17 Feb 2011 23:07:34 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 247803A6A84; Thu, 17 Feb 2011 23:07:32 -0800 (PST) X-AuditID: 93eaf2e7-b7b9cae000002a0e-67-4d5e1ad78877 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 58.04.10766.7DA1E5D4; Fri, 18 Feb 2011 09:08:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 18 Feb 2011 09:08:04 +0200 From: Alexander Vainshtein To: Greg Mirsky Date: Fri, 18 Feb 2011 09:05:19 +0200 Thread-Topic: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFM 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_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAARci5Uo= Cc: Robert Rennison , "mpls@ietf.org" , "mpls-tp@ietf.org" , Mishael Wexler , "lihan@chinamobile.com" , pwe3 , Rotem, HUANG, Feng F , Cohen Subject: Re: [mpls] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 07:07:36 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, and all, I concur with Greg. Using GAL with PWs is highly problematic, and all the related issues (raise= d during the poll on accepting this draft as a WG item) have not, AFAIK, be= en resolved. Regards, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 18, 2011 8:47 AM To: Luca Martini Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Fen= g F Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: Greg, You are correct , the proposed update does not propose any changes to VCCV. However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA. Given the good amount of discussion on this point, we should probably have = a discussion in Beijing. Luca On 10/29/2010 05:07 PM, Greg Mirsky wrote: Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Greg, and all,

I concur with Greg.

Using GAL with PWs is highly problemati= c, and all the related issues (raised during the poll on accepting this dra= ft as a WG item) have not, AFAIK, been resolved.

Regards,

     Sasha

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

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

Regards,
Greg

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

On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini <= span dir=3D"ltr"> <lmartini@cisco.com>= wrote:

Greg,

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

Luca

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

Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg

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

--_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_-- From jie.dong@huawei.com Fri Feb 18 00:57:49 2011 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 1166D3A6E0C; Fri, 18 Feb 2011 00:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBFDlL+KYYS8; Fri, 18 Feb 2011 00:57:48 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id AA0043A6EAE; Fri, 18 Feb 2011 00:57:47 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGT006TP26N5T@szxga05-in.huawei.com>; Fri, 18 Feb 2011 16:56:47 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGT003MH26MXV@szxga05-in.huawei.com>; Fri, 18 Feb 2011 16:56:46 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 18 Feb 2011 16:55:33 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 16:56:45 +0800 Date: Fri, 18 Feb 2011 08:56:45 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.31] To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , "mpls-tp@ietf.org" , "mpls@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AADC7B@szxeml508-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 Thread-index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1gATjyzUAAWWFeIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D4A9478.7050704@pi.nu> <021101cbc9c7$d7c8b140$875a13c0$@com> Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 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, 18 Feb 2011 08:57:49 -0000 Hi Yaacov, Thanks for your reply, and please see in-line with [Jie]: > >> 6. Section 4.2.2, 4th paragraph, > >> " The Fpath field SHALL identify the path that is reporting the > >> failure > >> condition (i.e. if protection path then Fpath is set to 0...". > >> Since PSC message are only transmitted on protection path, if > >> protection > >> path has signal fail, the PSC message may not be able to be sent out > >> to > >> far-end. > > yw> Actually, if there is a signal failure on the protection path, > there is a possibility that the messages may not be received by the > far-end, however, it is advisable that the source end-point continue to > transmit these messages. [Jie] Actually this comment is also about the first sentence in 4.1: "The PSC control packets SHALL be transmitted over the protection path only" IMO, If the transmitting end knows (either through remote PSC message or local information) the transmitting direction of the protection path is in fault, it may use working path to send PSC message. This way the PSC message would always be sent on only one path, and the remote end could still receive this message in protection path failure scenarios. > >> 7. Section 4.3.2, there is signal degrade on working path as input, > >> but no > >> signal degrade on protection path. > > yw> Currently, the signal degrade input in this list is a place holder - > the issue of how to deal with SD in general is for further study as > stated in section 4.2.2. Note - there have been lengthy discussions at > several IETF meetings on how to deal with SD without any conclusions. [Jie] OK. So will the SD part be added to this draft later, or it will be specified in a separate document? > >> 8. Section 4.3.3, I go through this part fast, a general question is: > >> are > >> the PSC operations for 4 different protection types identical ? In > >> this > >> section there is no description about operation of each specific > >> protection > >> type, but to my understanding, there may be different operations, > >> e.g., for > >> bidirectional 1:1 protection, the end point may need to switch the > >> sink > >> selector and transmitting bridge simultaneously according to some > >> input, but > >> for unidirectional 1:1 the end point may only need to switch the > >> transmitting bridge OR the sink selector. And the PSC message sent > may > >> also > >> be different for different protection types. (Please correct me if > >> there is > >> anything wrong with this thought). > > yw> Can you clarify for which scenario you believe that the messages > generated should be different dependent upon the protection type (aside > from the value of the protection type field)? The exact actions of the > selector and transmitting bridges are not fully described in the > document aside from the note at the end of section 4.3.1. In addition, > in the introductory text of each state description in section 4.3.3.3.x > describe how the user data is being transmitted. Is there a feeling > that we need to describe this separately for each scenario? [Jie] As draft-sur-fwk specified, "For bidirectional P2P paths, both unidirectional and bidirectional protection switching are supported." So an example is one end of the bidirectional path receives local signal fail on working path. This would normally be a failure in receiving direction on working path. For 1:1 unidirectional protection, the protection actions in each direction are independent, then maybe one direction has switched to the protection path, while in the opposite direction the traffic is still on the working path. In this case the output PSC message should indicate the remote end to switch the transmitting bridge to protection path and keep the remote selector bridge unchanged. For this the "Path" Field may need to be extended to TxPath and RxPath, and the PSC message with the format REQ(Fpath, TxPath, RxPath) would be SF(1,0,1). If later a remote signal fail on working path is received, then the output message would be changed to SF(1,1,1). For 1+1 bidirectional protection, the output PSC message should indicate the remote end to switch both the transmitting bridge and the selector bridge to protection path. Thus the output message would be SF(1,1,1). Thus IMO for unidirectional and bidirectional protection the action would be different, and the messages may need be different to convey clear information. Best regards, Jie > >> > -----Original Message----- > >> > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > >> > Behalf Of Loa Andersson > >> > Sent: Thursday, February 03, 2011 7:42 PM > >> > To: mpls-tp@ietf.org; mpls@ietf.org > >> > Cc: ahmpls-tp@lists.itu.int > >> > Subject: [mpls-tp] mpls wg last call on > >> draft-ietf-mpls-tp-linear-protection-04 > >> > > >> > Working Group, > >> > > >> > this is to start a four week working group last call on > >> > "MPLS-TP Linear Protection" (draft-ietf-mpls-tp-linear-protection- > >> 04). > >> > > >> > Please send comments to the mpls-tp@ietf.org mailing list. > >> > > >> > This working group last call ends on February 28, 2011. > >> > > >> > > >> > > >> > Loa, George and Ross > >> > > >> > 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 > >> > _______________________________________________ > >> > 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 jie.dong@huawei.com Fri Feb 18 01:15:13 2011 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 096BD3A6E88; Fri, 18 Feb 2011 01:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Up9FCBfkQh+l; Fri, 18 Feb 2011 01:15:12 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BFE3B3A6E81; Fri, 18 Feb 2011 01:15:11 -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 <0LGT000L730DRY@szxga03-in.huawei.com>; Fri, 18 Feb 2011 17:14:37 +0800 (CST) Received: from szxeml201-edg.china.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 <0LGT004JO30B2Q@szxga03-in.huawei.com>; Fri, 18 Feb 2011 17:14:37 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 18 Feb 2011 17:14:32 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 17:14:34 +0800 Date: Fri, 18 Feb 2011 09:14:33 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.31] To: "Eric Osborne (eosborne)" , "mpls-tp@ietf.org" , "mpls@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AADCA1@szxeml508-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 Thread-index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1gAUNLvlAAUdyZIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D4A9478.7050704@pi.nu> <021101cbc9c7$d7c8b140$875a13c0$@com> Subject: Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04 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, 18 Feb 2011 09:15:13 -0000 Hi Eric, Thanks for your reply, and please see in-line with [Jie]: > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, February 17, 2011 1:58 AM > To: Jie Dong; mpls-tp@ietf.org; mpls@ietf.org > Subject: RE: [mpls-tp] mpls wg last callon > draft-ietf-mpls-tp-linear-protection-04 > > Hi Jie- > > Yaacov has replied to most of your comments, but let me add two > things: > > > > > > 6. Section 4.2.2, 4th paragraph, > > " The Fpath field SHALL identify the path that is reporting the > failure > > condition (i.e. if protection path then Fpath is set to 0...". > > Since PSC message are only transmitted on protection path, if > protection > > path has signal fail, the PSC message may not be able to be sent out > to > > far-end. > > > As Yaacov has mentioned, we would like the PSC to send messages anyways > in the chance that they may get through. This is explicitly noted in > section 4.3.3.2: > --- > "When the domain is in unavailable state the PSC messages may not get > through and therefore the protection is more dependent on the local > inputs rather than the remote messages (that may not be received)." > ---- > > Is that sufficient, or do you think we need additional text to reinforce > this point? [Jie] I acknowledge this purpose, and my further comment would be the same as to Yaacov: what about sending this message through working path if it is known the transmitting direction of the protection path is in failure? In this way the message is still sent on only one path. > > 8. Section 4.3.3, I go through this part fast, a general question is: > are > > the PSC operations for 4 different protection types identical ? In > this > > section there is no description about operation of each specific > > protection type, but to my understanding, there may be different > > operations, e.g., for bidirectional 1:1 protection, the end point may > need > > to switch the sink selector and transmitting bridge simultaneously > > according to some input, but for unidirectional 1:1 the end point may > only > > need to switch the transmitting bridge OR the sink selector. And the > PSC > > message sent may also be different for different protection types. > (Please > > correct me if there is anything wrong with this thought). > > > PSC is not, in my view, tightly coupled to the four protection types. > That is to say, PSC is a tool that allows the device vendor and network > operator to build protection in an MPLS-TP network. This protection can > be one of the four protection types you describe, but PSC is merely a > protocol to accomplish the end goal. It may, for example, be possible > in the future to use PSC to build one or more types of 1:n protection; > when and if this is done, the message types would likely remain the same > as they are now. > I agree that PSC protocol can be used for all these protection types, and may also be applicable to 1:n protection, but for each protection type the state machine may be slightly different. The draft-tp-cc-cv-rdi also works in this way. The message types are likely the same, but some fields in the message may be different. Best regards, Jie > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of Loa Andersson > > > Sent: Thursday, February 03, 2011 7:42 PM > > > To: mpls-tp@ietf.org; mpls@ietf.org > > > Cc: ahmpls-tp@lists.itu.int > > > Subject: [mpls-tp] mpls wg last call on > > draft-ietf-mpls-tp-linear-protection-04 > > > > > > Working Group, > > > > > > this is to start a four week working group last call on "MPLS-TP > > > Linear Protection" (draft-ietf-mpls-tp-linear-protection-04). > > > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > > > This working group last call ends on February 28, 2011. > > > > > > > > > > > > Loa, George and Ross > > > > > > 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 > > > _______________________________________________ > > > 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 Fri Feb 18 01:17:28 2011 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 DCA853A6E81; Fri, 18 Feb 2011 01:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMwjF7K2DcqV; Fri, 18 Feb 2011 01:17:27 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id B9C183A6E0C; Fri, 18 Feb 2011 01:17:26 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 18 Feb 2011 09:17:58 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.15]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 18 Feb 2011 09:17:58 +0000 From: To: , Date: Fri, 18 Feb 2011 09:17:54 +0000 Thread-Topic: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFMAAQ7z9A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440145CA70F@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, HUANG@core3.amsl.com, Rotem@core3.amsl.com, mpls-tp@ietf.org, Mishael.Wexler@ecitele.com, lihan@chinamobile.com, pwe3@ietf.org, Feng.f.Huang@alcatel-sbell.com.cn, Robert.Rennison@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [mpls] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:17:29 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha/Greg, I would certainly agree that the use of the GAL with PWs is wrong....but th= e reason for that is simply that PWs per se violate the whole purpose of MP= LS-TP as a *transparent* transport network, noting that a true transport ne= twork must treat all client symbols equally...that is just a fact. However, given PWs are being carried forward into MPLS-TP then we also have= to deal with the issue that CP/MP of a transport network needs to logicall= y OOB wrt to the DP traffic. The GAL provides this function for the MPLS-T= P layer network itself (though it also gets this a wee bit wrong by asking = it to play a DP OAM role too,) but what about the PW layer network? MS PWs for sure are their own/different layer network....so they will need = their own access point addressing, OAM, routing, signalling, etc. I asked = some time ago why we were not using RSVP signalling here but T-LDP instead.= ..and I was told that RSVP cannot handle the PW signalling messages (nor th= e access addressing formats I assume...and we will of course need a new ins= tance of routing that will). So how is T-LDP being taken OOB wrt to the PW DP? regards, Neil Neil Harrison BT Design Tel: +44 (0) 1 803 812 545 Email: neil.2.harrison@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 18 February 2011 07:05 To: Greg Mirsky Cc: Robert Rennison; mpls@ietf.org; Luca Martini; mpls-tp@ietf.org; Mishael= Wexler; lihan@chinamobile.com; pwe3; Rotem@core3.amsl.com; HUANG@core3.ams= l.com; Feng F; Cohen Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Greg, and all, I concur with Greg. Using GAL with PWs is highly problematic, and all the related issues (raise= d during the poll on accepting this draft as a WG item) have not, AFAIK, be= en resolved. Regards, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 18, 2011 8:47 AM To: Luca Martini Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Fen= g F Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: Greg, You are correct , the proposed update does not propose any changes to VCCV. However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA. Given the good amount of discussion on this point, we should probably have = a discussion in Beijing. Luca On 10/29/2010 05:07 PM, Greg Mirsky wrote: Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha/Greg,

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

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

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

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

regards, Neil

Neil Harrison
BT Design

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

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

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

Greg, and all,<= /span>

I concur with Greg.

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

Regards,=

     S= asha

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

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

Regards,
Greg

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

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

Greg,

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

Luca

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

Dear Authors,
=
I think that proposed update of the Section 4.2. RFC = 5586 makes it possible
to use GAL on MPLS-TP PW that uses Control Word. I co= nsider it to be
conflict between PW VCCV CC types because use of GAL = is not negotiated
through PW VCCV negotiation. To avoid such situation = I propose:

   - in Section 5 request IANA to assign new CC Type &q= uot;MPLS Generic
   Associated Channel Label"
   - assign precedence to new CC Type that = affects Section 7 RFC 5085

Regards,
Greg

_______________________________________________<= /o:p>
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=

--_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_-- From danfrost@cisco.com Fri Feb 18 04:14:09 2011 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 2F6BA3A6C82 for ; Fri, 18 Feb 2011 04:14:09 -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 4ca1Y4m-8noq for ; Fri, 18 Feb 2011 04:14:08 -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 391CE3A6D63 for ; Fri, 18 Feb 2011 04:14:08 -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: AocGAFbxXU1AZnwM/2dsb2JhbACEH5N3jgpzoHKKe5A5gSeDQXYEjBE X-IronPort-AV: E=Sophos;i="4.62,186,1297036800"; d="scan'208";a="217173028" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 12:14:41 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1ICEfBO016943; Fri, 18 Feb 2011 12:14:41 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p1ICEe9Q009550; Fri, 18 Feb 2011 07:14:40 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p1ICEdi1009549; Fri, 18 Feb 2011 12:14:39 GMT Date: Fri, 18 Feb 2011 12:14:39 +0000 From: Dan Frost To: xiao.min2@zte.com.cn Message-ID: <20110218121439.GB8070@cisco.com> References: <20110216110246.GA2602@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 18 Feb 2011 12:14:09 -0000 Hi Xiao Min, On Thu, Feb 17, 2011 at 09:31:56AM +0800, xiao.min2@zte.com.cn wrote: > Hi Dan, > > To my understanding, the texts you referred explain what the Querier > and the Responder should do if the counting function at the Responder > is not ready, but there is no text about how to switch on/off this > counting function at the Responder. AFAIK counting at the Responder > won't be switched on automatically after power up, and some operation > is needed to make counting begin. I think this point is also necessary > to be explicitly defined. To put it another way, the initial query message is itself the signal to the responder to take whatever initialization actions are required for it to begin generating useful responses. Such actions may include "switching on the counting function" or anything else, and are implementation-dependent. -d > Best Regards, > Xiao Min > > > Dan Frost > 2011/02/16 19:02 > > 收件人 > xiao.min2@zte.com.cn > 抄送 > mpls@ietf.org > 主题 > Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 > > > Hi Xiao Min, > > On Tue, Feb 15, 2011 at 11:15:37AM +0800, xiao.min2@zte.com.cn wrote: > > Hi Authors, > > > > I have a comment on loss measurement in this draft. > > > > After receiving LM Query message, the responder would reply LM > > Response message which should take some counters. But I can't find > > text in this draft to describe how the counting function at the > > responder is switched on. IMHO one more bit/flag should be defined in > > the LM Query message to activate or deactivate the counting function > > at the responder. Did I miss something? > > There should be no need for a separate activation flag or message. The > last paragraph of Section 4.1.1 explains what the responder can do if it > is not yet ready to provide counter data. It can simply not respond > until it is ready, or it can respond with an appropriate notification > code in the meantime (the appropriate code in this case would be > Notification - Initialization In Progress, described in Section 3.1). > > Cheers, > > -d > > > Best Regards, Xiao Min From martin.vigoureux@alcatel-lucent.com Fri Feb 18 05:26:09 2011 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 52A5F3A6EF9; Fri, 18 Feb 2011 05:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6HuQ+IrA0d44; Fri, 18 Feb 2011 05:26:08 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 430873A6C80; Fri, 18 Feb 2011 05:26:07 -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 p1IDQeVJ009599 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 18 Feb 2011 14:26:40 +0100 Received: from [135.244.197.111] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 18 Feb 2011 14:26:40 +0100 Message-ID: <4D5E7389.7040604@alcatel-lucent.com> Date: Fri, 18 Feb 2011 14:26:33 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls-tp@ietf.org" Subject: [mpls] Slots requests for IETF 80 - Prague 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, 18 Feb 2011 13:26:09 -0000 All, it is time we start building the agenda for Prague. Please send me your requests for a presentation slot indicating: draft name, speaker and duration Please be aware that we might not be able to satisfy all requests. Thank you. regards, martin From Internet-Drafts@ietf.org Fri Feb 18 07:15:02 2011 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 E61CF3A6F97; Fri, 18 Feb 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 Ua382Bl1IeOr; Fri, 18 Feb 2011 07:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B423A6E67; Fri, 18 Feb 2011 07:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218151502.14793.72031.idtracker@localhost> Date: Fri, 18 Feb 2011 07:15:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-p2mp-12.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, 18 Feb 2011 15:15:03 -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 : Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-p2mp-12.txt Pages : 39 Date : 2011-02-18 This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as Multicast LDP (mLDP). mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/ MP2MP LSPs is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-12.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-p2mp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-18070830.I-D@ietf.org> --NextPart-- From ice@cisco.com Fri Feb 18 07:22:26 2011 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 1A52D3A6E1E for ; Fri, 18 Feb 2011 07:22:26 -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 waS44nL3r2Yw for ; Fri, 18 Feb 2011 07:22:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 097EF3A6D27 for ; Fri, 18 Feb 2011 07:22:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1IFJD3g002038 for ; Fri, 18 Feb 2011 16:19:13 +0100 (CET) Received: from dhcp-171-70-245-233.cisco.com (dhcp-171-70-245-233.cisco.com [171.70.245.233]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1IFJCGk011031 for ; Fri, 18 Feb 2011 16:19:12 +0100 (CET) From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 07:19:11 -0800 Message-Id: <7AB9E8C4-9B17-4BA3-A9CD-E2DC87EB7B6F@cisco.com> To: mpls@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [mpls] New version draft-ietf-mpls-ldp-p2mp-12 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, 18 Feb 2011 15:22:26 -0000 Dear WG, Thanks all who have provided comments on draft-ietf-mpls-ldp-p2mp-12. = I've just posted a new version of the draft that incorporates the = comments made on the list. Please review and let me know if you have = other comments or suggestions.=20 Thx, Ice. From lmartini@cisco.com Fri Feb 18 07:45:50 2011 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 B20B93A6F0A; Fri, 18 Feb 2011 07:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nEUV7B-PuYx; Fri, 18 Feb 2011 07:45:49 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 96D6A3A6D47; Fri, 18 Feb 2011 07:45:49 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p1IFkAcH000113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 08:46:11 -0700 (MST) Message-ID: <4D5E9442.3030101@cisco.com> Date: Fri, 18 Feb 2011 08:46:10 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: Greg Mirsky References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 15:45:50 -0000 Greg, Sorry, but I do not remember the point you mention. Can you explain again here ? Thanks. Luca On 02/17/11 23:47, Greg Mirsky wrote: > Dear Authors and All, > prior to the meeting in Bejing and acceptance of this proposal as WG > document Luca and I agreed that use of GAL with PW VCCV presents a > problem. > I was not attending the IETF-79, nor I found discussion of this issue > in the minutes. I think that this issue should be specified, > explained. In my view, this document updates not only RFC 5586 > but RFC 5085 too. > > Regards, > Greg > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: > > Greg, > > You are correct , the proposed update does not propose any changes > to VCCV. > However the problem with vccv is not as simple as to ask for a new > code point from IANA. > Given the good amount of discussion on this point, we should > probably have a discussion in Beijing. > > Luca > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: >> Dear Authors, >> I think that proposed update of the Section 4.2. RFC 5586 makes it possible >> to use GAL on MPLS-TP PW that uses Control Word. I consider it to be >> conflict between PW VCCV CC types because use of GAL is not negotiated >> through PW VCCV negotiation. To avoid such situation I propose: >> >> - in Section 5 request IANA to assign new CC Type "MPLS Generic >> Associated Channel Label" >> - assign precedence to new CC Type that affects Section 7 RFC 5085 >> >> Regards, >> Greg >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From manavbhatia@gmail.com Fri Feb 18 08:36:09 2011 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 0F3683A6C8D for ; Fri, 18 Feb 2011 08:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 xo97vcLRusg0 for ; Fri, 18 Feb 2011 08:36:08 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 091BC3A6AA7 for ; Fri, 18 Feb 2011 08:36:07 -0800 (PST) Received: by wwa36 with SMTP id 36so4030149wwa.13 for ; Fri, 18 Feb 2011 08:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=UB6+CITRw5FSUb3UOWoB9rN/rYrwoDx4wAoBeglU58M=; b=x+8uTbrygMkM3JLKMA44Di0zApkUKrJxiyXQukZH6EugnvETK1xnND+vNHCaLfl6Ik 3kbxf/glLF/w5FCXwZRY3ChqQNxyzoMhJcZsjW3yDeOyB+gn10btP6cxRloeM5vdBaFG wr2iDtRhrn7vT43qX2EnmA+lMEfC8QbDIPVTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GQoHdBVdUEhzZYa053VotT4QPUdJx2fNN4GtDU5P1PWXrxr6FbhkJQr5ZAuUPBV7n0 AFHeWte6yo/oZQoUaJ3+f1Od2qo62JdXSNepcPaKnRniqoCzk03Dwbk75BcWOgLdB/pP sTZmur1uX/AO5TginsdHpZC8mZMcqwnbUEoWE= MIME-Version: 1.0 Received: by 10.227.72.129 with SMTP id m1mr843846wbj.47.1298047001462; Fri, 18 Feb 2011 08:36:41 -0800 (PST) Received: by 10.227.157.139 with HTTP; Fri, 18 Feb 2011 08:36:41 -0800 (PST) Date: Fri, 18 Feb 2011 22:06:41 +0530 Message-ID: From: Manav Bhatia To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] Hub and Spoke Multipoint LSPs 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, 18 Feb 2011 16:36:09 -0000 Hi, Lizhong, Fred and I have written a small draft that describes a technique targetting one-to-many applications that require reverse one-to-one traffic flow (thus many one-to-one in the reverse direction). Would love to hear comments and feedback from the WG. The draft is available here: http://www.ietf.org/id/draft-jjb-mpls-rsvp-te-hsmp-lsp-00.txt Abstract In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) environment, the RSVP-TE based Point-to-Multipoint (P2MP) LSP allows traffic to transmit from root to leaf node, but there is no co-routed reverse path for traffic from leaf to root node. This draft introduces a Hub and Spoke Multipoint (HSMP) LSP, which allows traffic from both the root to the leaves through a P2MP LSP and also the leaves to the root along a co-routed reverse path. Cheers, Manav From davari@broadcom.com Fri Feb 18 09:15:40 2011 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 A8AF83A6D56; Fri, 18 Feb 2011 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] 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 yWTUe9upzuNI; Fri, 18 Feb 2011 09:15:39 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 56EE03A6CC7; Fri, 18 Feb 2011 09:15:39 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 18 Feb 2011 09:17:34 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 18 Feb 2011 09:15:37 -0800 From: "Shahram Davari" To: "'Alexander.Vainshtein@ecitele.com'" , "'gregimirsky@gmail.com'" Date: Fri, 18 Feb 2011 09:15:36 -0800 Thread-Topic: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFMABVQVLE= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD69419A002F9@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 614076275OK8247826-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Cc: "'mpls@ietf.org'" , "'HUANG@core3.amsl.com'" , "'Rotem@core3.amsl.com'" , "'mpls-tp@ietf.org'" , "'Mishael.Wexler@ecitele.com'" , "'lihan@chinamobile.com'" , "'pwe3@ietf.org'" , "'Feng.f.Huang@alcatel-sbell.com.cn'" , "'Robert.Rennison@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" Subject: Re: [mpls] [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:15:40 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHdpdGggU2FzaGEuIENyZWF0aW5nIGEgVkNDViB0eXBlIDQgaXMgcHJvYmxl bWF0aWMsIGFsbW9zdCBubyBoYXJkd2FyZSBleGlzdCBmb3IgaXQgYW5kIGNhdXNlcyBpbnRlcndv cmtpbmcgaXNzdWVzLiBTaWduYWxpbmcgVkNDViBuZWVkcyB0byBjaGFuZ2UgYXMgd2VsbC4NCg0K VGh4DQpTaGFocmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBw d2UzLWJvdW5jZXNAaWV0Zi5vcmcgPHB3ZTMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBHcmVnIE1p cnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KQ2M6IFJvYmVydCBSZW5uaXNvbiA8Um9iZXJ0 LlJlbm5pc29uQGVjaXRlbGUuY29tPjsgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz47IEx1 Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tPjsgbXBscy10cEBpZXRmLm9yZyA8bXBscy10 cEBpZXRmLm9yZz47IE1pc2hhZWwgV2V4bGVyIDxNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47 IGxpaGFuQGNoaW5hbW9iaWxlLmNvbSA8bGloYW5AY2hpbmFtb2JpbGUuY29tPjsgcHdlMyA8cHdl M0BpZXRmLm9yZz47IFJvdGVtQGNvcmUzLmFtc2wuY29tIDxSb3RlbUBjb3JlMy5hbXNsLmNvbT47 IEhVQU5HQGNvcmUzLmFtc2wuY29tIDxIVUFOR0Bjb3JlMy5hbXNsLmNvbT47IEZlbmcgRiA8RmVu Zy5mLkh1YW5nQGFsY2F0ZWwtc2JlbGwuY29tLmNuPjsgQ29oZW4gPFJvdGVtLkNvaGVuQGVjaXRl bGUuY29tPg0KU2VudDogVGh1IEZlYiAxNyAyMzowNToxOSAyMDExDQpTdWJqZWN0OiBSZTogW1BX RTNdIFttcGxzLXRwXSBXRyBMQyBkcmFmdC1sbS1wd2UzLW1wbHMtdHAtZ2FsLWluLXB3LTAwLnR4 dA0KDQpHcmVnLCBhbmQgYWxsLA0KSSBjb25jdXIgd2l0aCBHcmVnLg0KVXNpbmcgR0FMIHdpdGgg UFdzIGlzIGhpZ2hseSBwcm9ibGVtYXRpYywgYW5kIGFsbCB0aGUgcmVsYXRlZCBpc3N1ZXMgKHJh aXNlZCBkdXJpbmcgdGhlIHBvbGwgb24gYWNjZXB0aW5nIHRoaXMgZHJhZnQgYXMgYSBXRyBpdGVt KSBoYXZlIG5vdCwgQUZBSUssIGJlZW4gcmVzb2x2ZWQuDQoNClJlZ2FyZHMsDQogICAgIFNhc2hh DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcg TWlyc2t5IFtncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE4 LCAyMDExIDg6NDcgQU0NClRvOiBMdWNhIE1hcnRpbmkNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxz LXRwQGlldGYub3JnOyBsaWhhbkBjaGluYW1vYmlsZS5jb207IHB3ZTM7IEhVQU5HIEZlbmcgRg0K U3ViamVjdDogW21wbHMtdHBdIFdHIExDIGRyYWZ0LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHct MDAudHh0DQoNCkRlYXIgQXV0aG9ycyBhbmQgQWxsLA0KcHJpb3IgdG8gdGhlIG1lZXRpbmcgaW4g QmVqaW5nIGFuZCBhY2NlcHRhbmNlIG9mIHRoaXMgcHJvcG9zYWwgYXMgV0cgZG9jdW1lbnQgTHVj YSBhbmQgSSBhZ3JlZWQgdGhhdCB1c2Ugb2YgR0FMIHdpdGggUFcgVkNDViBwcmVzZW50cyBhIHBy b2JsZW0uDQpJIHdhcyBub3QgYXR0ZW5kaW5nIHRoZSBJRVRGLTc5LCBub3IgSSBmb3VuZCBkaXNj dXNzaW9uIG9mIHRoaXMgaXNzdWUgaW4gdGhlIG1pbnV0ZXMuIEkgdGhpbmsgdGhhdCB0aGlzIGlz c3VlIHNob3VsZCBiZSBzcGVjaWZpZWQsIGV4cGxhaW5lZC4gSW4gbXkgdmlldywgdGhpcyBkb2N1 bWVudCB1cGRhdGVzIG5vdCBvbmx5IFJGQyA1NTg2DQpidXQgUkZDIDUwODUgdG9vLg0KDQpSZWdh cmRzLA0KR3JlZw0KDQpDb21tZW50IHRvIGRyYWZ0LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHct MDAudHh0DQoNCk9uIFNhdCwgT2N0IDMwLCAyMDEwIGF0IDEwOjE0IEFNLCBMdWNhIE1hcnRpbmkg PGxtYXJ0aW5pQGNpc2NvLmNvbTxtYWlsdG86bG1hcnRpbmlAY2lzY28uY29tPj4gd3JvdGU6DQpH cmVnLA0KDQpZb3UgYXJlIGNvcnJlY3QgLCB0aGUgcHJvcG9zZWQgdXBkYXRlIGRvZXMgbm90IHBy b3Bvc2UgYW55IGNoYW5nZXMgdG8gVkNDVi4NCkhvd2V2ZXIgdGhlIHByb2JsZW0gd2l0aCB2Y2N2 IGlzIG5vdCBhcyBzaW1wbGUgYXMgdG8gYXNrIGZvciBhIG5ldyBjb2RlIHBvaW50IGZyb20gSUFO QS4NCkdpdmVuIHRoZSBnb29kIGFtb3VudCBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgcG9pbnQsIHdl IHNob3VsZCBwcm9iYWJseSBoYXZlIGEgZGlzY3Vzc2lvbiBpbiBCZWlqaW5nLg0KDQpMdWNhDQoN Cg0KDQpPbiAxMC8yOS8yMDEwIDA1OjA3IFBNLCBHcmVnIE1pcnNreSB3cm90ZToNCg0KRGVhciBB dXRob3JzLA0KSSB0aGluayB0aGF0IHByb3Bvc2VkIHVwZGF0ZSBvZiB0aGUgU2VjdGlvbiA0LjIu IFJGQyA1NTg2IG1ha2VzIGl0IHBvc3NpYmxlDQp0byB1c2UgR0FMIG9uIE1QTFMtVFAgUFcgdGhh dCB1c2VzIENvbnRyb2wgV29yZC4gSSBjb25zaWRlciBpdCB0byBiZQ0KY29uZmxpY3QgYmV0d2Vl biBQVyBWQ0NWIENDIHR5cGVzIGJlY2F1c2UgdXNlIG9mIEdBTCBpcyBub3QgbmVnb3RpYXRlZA0K dGhyb3VnaCBQVyBWQ0NWIG5lZ290aWF0aW9uLiBUbyBhdm9pZCBzdWNoIHNpdHVhdGlvbiBJIHBy b3Bvc2U6DQoNCiAgIC0gaW4gU2VjdGlvbiA1IHJlcXVlc3QgSUFOQSB0byBhc3NpZ24gbmV3IEND IFR5cGUgIk1QTFMgR2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFubmVsIExhYmVsIg0KICAgLSBh c3NpZ24gcHJlY2VkZW5jZSB0byBuZXcgQ0MgVHlwZSB0aGF0IGFmZmVjdHMgU2VjdGlvbiA3IFJG QyA1MDg1DQoNClJlZ2FyZHMsDQpHcmVnDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KDQoNCg0K --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8bWV0YSBjb250ZW50PSJN U0hUTUwgNi4wMC42MDAwLjE3MDYzIiBuYW1lPSJHRU5FUkFUT1IiPg0KPHN0eWxlIGlkPSJvd2FU ZW1wRWRpdFN0eWxlIj48L3N0eWxlPjxzdHlsZSB0aXRsZT0ib3dhUGFyYVN0eWxlIj48IS0tUCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBvY3NpPSJ4Ij48ZGl2Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9 QXJpYWw+DQpJIGFsc28gYWdyZWUgd2l0aCBTYXNoYS4gQ3JlYXRpbmcgYSBWQ0NWIHR5cGUgNCBp cyBwcm9ibGVtYXRpYywgYWxtb3N0IG5vIGhhcmR3YXJlIGV4aXN0IGZvciBpdCBhbmQgY2F1c2Vz IGludGVyd29ya2luZyBpc3N1ZXMuIFNpZ25hbGluZyBWQ0NWIG5lZWRzIHRvIGNoYW5nZSBhcyB3 ZWxsLjxicj48YnI+VGh4PGJyPlNoYWhyYW0gPC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhyIHNp emU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFjZT1U YWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyAmbHQ7cHdl My1ib3VuY2VzQGlldGYub3JnJmd0Ow08YnI+PGI+VG88L2I+OiBHcmVnIE1pcnNreSAmbHQ7Z3Jl Z2ltaXJza3lAZ21haWwuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBSb2JlcnQgUmVubmlzb24gJmx0 O1JvYmVydC5SZW5uaXNvbkBlY2l0ZWxlLmNvbSZndDs7IG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNA aWV0Zi5vcmcmZ3Q7OyBMdWNhIE1hcnRpbmkgJmx0O2xtYXJ0aW5pQGNpc2NvLmNvbSZndDs7IG1w bHMtdHBAaWV0Zi5vcmcgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7OyBNaXNoYWVsIFdleGxlciAm bHQ7TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20mZ3Q7OyBsaWhhbkBjaGluYW1vYmlsZS5jb20g Jmx0O2xpaGFuQGNoaW5hbW9iaWxlLmNvbSZndDs7IHB3ZTMgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7 OyBSb3RlbUBjb3JlMy5hbXNsLmNvbSAmbHQ7Um90ZW1AY29yZTMuYW1zbC5jb20mZ3Q7OyBIVUFO R0Bjb3JlMy5hbXNsLmNvbSAmbHQ7SFVBTkdAY29yZTMuYW1zbC5jb20mZ3Q7OyBGZW5nIEYgJmx0 O0ZlbmcuZi5IdWFuZ0BhbGNhdGVsLXNiZWxsLmNvbS5jbiZndDs7IENvaGVuICZsdDtSb3RlbS5D b2hlbkBlY2l0ZWxlLmNvbSZndDsNPGJyPjxiPlNlbnQ8L2I+OiBUaHUgRmViIDE3IDIzOjA1OjE5 IDIwMTE8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbUFdFM10gW21wbHMtdHBdIFdHIExDIGRyYWZ0 LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHctMDAudHh0DTxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0K DQo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDE2cHg7IENPTE9SOiAjMDAwMDAwOyBESVJFQ1RJT046 IGx0cjsgRk9OVC1GQU1JTFk6IFRpbWVzIE5ldyBSb21hbiI+DQo8ZGl2PkdyZWcsIGFuZCBhbGws PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+SSBjb25jdXIgd2l0aCBH cmVnLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0idGltZXMgbmV3IHJvbWFuIj5Vc2lu ZyBHQUwgd2l0aCBQV3MgaXMgaGlnaGx5IHByb2JsZW1hdGljLCBhbmQgYWxsIHRoZSByZWxhdGVk IGlzc3VlcyAocmFpc2VkIGR1cmluZyB0aGUgcG9sbCBvbiBhY2NlcHRpbmcgdGhpcyBkcmFmdCBh cyBhIFdHIGl0ZW0pIGhhdmUgbm90LCBBRkFJSywgYmVlbiByZXNvbHZlZC48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+PC9mb250PiZuYnNwOzwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPlJlZ2FyZHMsPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTYXNoYTwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxk aXYgaWQ9ImRpdlJwRjYyODA5NSIgc3R5bGU9IkRJUkVDVElPTjogbHRyIj4NCjxociB0YWJpbmRl eD0iLTEiPg0KPGZvbnQgZmFjZT0iVGFob21hIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMiI+PGI+ RnJvbTo8L2I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kgW2dyZWdpbWlyc2t5QGdtYWlsLmNvbV08YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxOCwgMjAxMSA4OjQ3IEFNPGJyPg0KPGI+ VG86PC9iPiBMdWNhIE1hcnRpbmk8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IG1wbHMt dHBAaWV0Zi5vcmc7IGxpaGFuQGNoaW5hbW9iaWxlLmNvbTsgcHdlMzsgSFVBTkcgRmVuZyBGPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFttcGxzLXRwXSBXRyBMQyBkcmFmdC1sbS1wd2UzLW1wbHMtdHAt Z2FsLWluLXB3LTAwLnR4dDxicj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8 ZGl2PkRlYXIgQXV0aG9ycyBhbmQgQWxsLDxicj4NCnByaW9yIHRvIHRoZSBtZWV0aW5nIGluIEJl amluZyBhbmQgYWNjZXB0YW5jZSBvZiB0aGlzIHByb3Bvc2FsIGFzIFdHIGRvY3VtZW50IEx1Y2Eg YW5kIEkgYWdyZWVkIHRoYXQgdXNlIG9mIEdBTCB3aXRoIFBXIFZDQ1YgcHJlc2VudHMgYSBwcm9i bGVtLjxicj4NCkkgd2FzIG5vdCBhdHRlbmRpbmcgdGhlIElFVEYtNzksIG5vciBJIGZvdW5kIGRp c2N1c3Npb24gb2YgdGhpcyBpc3N1ZSBpbiB0aGUgbWludXRlcy4gSSB0aGluayB0aGF0IHRoaXMg aXNzdWUgc2hvdWxkIGJlIHNwZWNpZmllZCwgZXhwbGFpbmVkLiBJbiBteSB2aWV3LCB0aGlzIGRv Y3VtZW50IHVwZGF0ZXMgbm90IG9ubHkgUkZDIDU1ODY8YnI+DQpidXQgUkZDIDUwODUgdG9vLjxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KR3JlZzxicj4NCjxicj4NCkNvbW1lbnQgdG8gZHJhZnQt bG0tcHdlMy1tcGxzLXRwLWdhbC1pbi1wdy0wMC50eHQ8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gU2F0LCBPY3QgMzAsIDIwMTAgYXQgMTA6MTQgQU0sIEx1Y2EgTWFydGlu aSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmxtYXJ0aW5pQGNpc2NvLmNv bSI+bG1hcnRpbmlAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46 IDBwdCAwcHQgMHB0IDAuOGV4OyBCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29s aWQiPg0KPGRpdiBiZ2NvbG9yPSIjZmZmZmZmIj5HcmVnLDxicj4NCjxicj4NCllvdSBhcmUgY29y cmVjdCAsIHRoZSBwcm9wb3NlZCB1cGRhdGUgZG9lcyBub3QgcHJvcG9zZSBhbnkgY2hhbmdlcyB0 byBWQ0NWLjxicj4NCkhvd2V2ZXIgdGhlIHByb2JsZW0gd2l0aCB2Y2N2IGlzIG5vdCBhcyBzaW1w bGUgYXMgdG8gYXNrIGZvciBhIG5ldyBjb2RlIHBvaW50IGZyb20gSUFOQS48YnI+DQpHaXZlbiB0 aGUgZ29vZCBhbW91bnQgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHBvaW50LCB3ZSBzaG91bGQgcHJv YmFibHkgaGF2ZSBhIGRpc2N1c3Npb24gaW4gQmVpamluZy48YnI+DQo8YnI+DQpMdWNhDQo8ZGl2 Pg0KPGRpdj48L2Rpdj4NCjxkaXYgY2xhc3M9Img1Ij48YnI+DQo8YnI+DQo8YnI+DQpPbiAxMC8y OS8yMDEwIDA1OjA3IFBNLCBHcmVnIE1pcnNreSB3cm90ZTogPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2IGNsYXNzPSJoNSI+ DQo8cHJlPkRlYXIgQXV0aG9ycywNCkkgdGhpbmsgdGhhdCBwcm9wb3NlZCB1cGRhdGUgb2YgdGhl IFNlY3Rpb24gNC4yLiBSRkMgNTU4NiBtYWtlcyBpdCBwb3NzaWJsZQ0KdG8gdXNlIEdBTCBvbiBN UExTLVRQIFBXIHRoYXQgdXNlcyBDb250cm9sIFdvcmQuIEkgY29uc2lkZXIgaXQgdG8gYmUNCmNv bmZsaWN0IGJldHdlZW4gUFcgVkNDViBDQyB0eXBlcyBiZWNhdXNlIHVzZSBvZiBHQUwgaXMgbm90 IG5lZ290aWF0ZWQNCnRocm91Z2ggUFcgVkNDViBuZWdvdGlhdGlvbi4gVG8gYXZvaWQgc3VjaCBz aXR1YXRpb24gSSBwcm9wb3NlOg0KDQogICAtIGluIFNlY3Rpb24gNSByZXF1ZXN0IElBTkEgdG8g YXNzaWduIG5ldyBDQyBUeXBlICZxdW90O01QTFMgR2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFu bmVsIExhYmVsJnF1b3Q7DQogICAtIGFzc2lnbiBwcmVjZWRlbmNlIHRvIG5ldyBDQyBUeXBlIHRo YXQgYWZmZWN0cyBTZWN0aW9uIDcgUkZDIDUwODUNCg0KUmVnYXJkcywNCkdyZWcNCg0KPC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48ZmllbGRzZXQ+PC9maWVsZHNldD4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+DQo8L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_-- From gregimirsky@gmail.com Fri Feb 18 10:14:55 2011 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 247FB3A6D6A; Fri, 18 Feb 2011 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Jk3U5VHbczmr; Fri, 18 Feb 2011 10:14:54 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9D8E33A6D48; Fri, 18 Feb 2011 10:14:53 -0800 (PST) Received: by vxi40 with SMTP id 40so2334276vxi.31 for ; Fri, 18 Feb 2011 10:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eFhbxbVkVd9RRDxruN1eHxWuzfkY9LqBZ17udURWnxI=; b=Eyw3njNi9WkoxdXq6rv6DfBqfhylFf3/LoS1KEOtAqtvDV3cdcJgDr78E5VlUpM2P1 Ylbd7TKcDv9u49VmyNRq3zkMppKwXJMvuDcdzEdE5foR04unDz+8uOzPCgWTGZAS0Hqq 1Km/WT6PytuY2a1FiaKrBTZrp2ugj2QmeOniM= 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=C8KfCMqjLbrj7/7LT+ldM0AolurQ3cZ8lRDVT08f8H962E9+r3oXco5QaMOeU+QzDr HMsTbIy+Nw/96Lz8lElBzultAuw9qltnHYe8oyzo+N31KBtGH4+OT6cKJl2lBPgrReMK FMZdb8V/POafL1EFBx6cwms/89yqOSaVHgecI= MIME-Version: 1.0 Received: by 10.52.164.166 with SMTP id yr6mr1831510vdb.245.1298052926692; Fri, 18 Feb 2011 10:15:26 -0800 (PST) Received: by 10.52.165.9 with HTTP; Fri, 18 Feb 2011 10:15:26 -0800 (PST) In-Reply-To: <4D5E9442.3030101@cisco.com> References: <4D5E9442.3030101@cisco.com> Date: Fri, 18 Feb 2011 10:15:26 -0800 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec53f9359985e7f049c927f19 Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:14:55 -0000 --bcaec53f9359985e7f049c927f19 Content-Type: text/plain; charset=ISO-8859-1 Dear Luca, I see at least two issues: - use of GAL for PW, in my view, is another VCCV CC type that has to be negotiated as described in RFC 5085. - use of GAL creates ambiguous situation when PW CW is used. The benefit from extending GAL in PW, as I see, is for PWs that are not required to use PW CW. That might be a good enough reason to update RFC 5586 as proposed in the document but we must address use cases of GAL in PWs that require presence PW CW. If we prohibit or even discourage use of GAL for these PWs that have PW VCCV as native Associated Channel, then architecture of ACh for MPLS-TP PW not simplified as result of adopting the proposal. Regards, Greg On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini wrote: > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as WG > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 makes it > possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose: > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section 7 RFC > 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec53f9359985e7f049c927f19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Luca,
I see at least two issues:
use of GAL for PW, in m= y view, is another VCCV CC type that has to be negotiated as described in R= FC 5085.
use of GAL creates ambiguous situation when PW CW is used.= The benefit from extending GAL in PW, as I see, is for PWs that are not re= quired to use PW CW. That might be a good enough reason to update RFC 5586 = as proposed in the document but we must address use cases of GAL in PWs tha= t require presence PW CW. If we prohibit or even discourage use of GAL for = these PWs that have PW VCCV as native Associated Channel, then architecture= of ACh for MPLS-TP PW not simplified as result of adopting the proposal.
Regards,
Greg

On Fri, Feb 18, 201= 1 at 7:46 AM, Luca Martini <lmartini@cisco.com> wrote:
Greg,

Sorry, but I do not remember the point you mention.
Can you explain again here ?
Thanks.
Luca

On 02/17/11 23:47, Greg Mirsky wrote:
> Dear Authors and All,
> prior to the meeting in Bejing and acceptance of this proposal as WG > document Luca and I agreed that use of GAL with PW VCCV presents a
> problem.
> I was not attending the IETF-79, nor I found discussion of this issue<= br> > in the minutes. I think that this issue should be specified,
> explained. In my view, this document updates not only RFC 5586
> but RFC 5085 too.
>
> Regards,
> Greg
>
> Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>
> On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini <lmartini@cisco.com

> <mailto:lmartini@cisco.com>> wrote:
>
> =A0 =A0 Greg,
>
> =A0 =A0 You are correct , the proposed update does not propose any cha= nges
> =A0 =A0 to VCCV.
> =A0 =A0 However the problem with vccv is not as simple as to ask for a= new
> =A0 =A0 code point from IANA.
> =A0 =A0 Given the good amount of discussion on this point, we should > =A0 =A0 probably have a discussion in Beijing.
>
> =A0 =A0 Luca
>
>
>
> =A0 =A0 On 10/29/2010 05:07 PM, Greg Mirsky wrote:
>> =A0 =A0 Dear Authors,
>> =A0 =A0 I think that proposed update of the Section 4.2. RFC 5586 = makes it possible
>> =A0 =A0 to use GAL on MPLS-TP PW that uses Control Word. I conside= r it to be
>> =A0 =A0 conflict between PW VCCV CC types because use of GAL is no= t negotiated
>> =A0 =A0 through PW VCCV negotiation. To avoid such situation I pro= pose:
>>
>> =A0 =A0 =A0 =A0- in Section 5 request IANA to assign new CC Type &= quot;MPLS Generic
>> =A0 =A0 =A0 =A0Associated Channel Label"
>> =A0 =A0 =A0 =A0- assign precedence to new CC Type that affects Sec= tion 7 RFC 5085
>>
>> =A0 =A0 Regards,
>> =A0 =A0 Greg
>>
>>
>>
>> =A0 =A0 _______________________________________________
>> =A0 =A0 mpls mailing list

>> =A0 =A0 mpls@ietf.org &= lt;mailto:mpls@ietf.org>

>> =A0 =A0 https://www.ietf.org/mailm= an/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

--bcaec53f9359985e7f049c927f19-- From xiao.min2@zte.com.cn Sun Feb 20 17:23:24 2011 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 7797C3A6D4D for ; Sun, 20 Feb 2011 17:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.335 X-Spam-Level: X-Spam-Status: No, score=-96.335 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Lg2ZRKnVK3R for ; Sun, 20 Feb 2011 17:23:23 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E00323A6CC3 for ; Sun, 20 Feb 2011 17:23:22 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595806486374; Mon, 21 Feb 2011 09:18:47 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 50584.2789515077; Mon, 21 Feb 2011 09:15:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1L1Np86050683; Mon, 21 Feb 2011 09:23:51 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: <20110218121439.GB8070@cisco.com> To: Dan Frost MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Mon, 21 Feb 2011 09:23:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-21 09:23:50, Serialize complete at 2011-02-21 09:23:50 Content-Type: multipart/alternative; boundary="=_alternative 0007A6F04825783E_=" X-MAIL: mse01.zte.com.cn p1L1Np86050683 Cc: mpls@ietf.org Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 21 Feb 2011 01:23:24 -0000 This is a multipart message in MIME format. --=_alternative 0007A6F04825783E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGFuLA0KDQpJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIGluaXRpYWwgTE0gcXVlcnkgbWVzc2Fn ZSBtYXkgYmUgdHJlYXRlZCBhcyANCmNvdW50aW5nIA0KYWN0aXZhdGlvbiBtZXNzYWdlLCBidXQg dGhhdCByZXF1aXJlcyB0aGUgcmVzcG9uZGVyIHRvIGRpZmZlcmVudGlhdGUgdGhlIA0KZmlyc3Qg DQpMTSBxdWVyeSBhbmQgb3RoZXIgTE0gcXVlcmllcywgYW5kIGl0J3Mgc3RpbGwgbm90IHN1cmUg aG93IHRvIHN3aXRjaCBvZmYgDQp0aGUgDQpjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUgcmVzcG9u ZGVyIHdoZW4gdGhlIExNIGZ1bmN0aW9uIGZpbmlzaGVkLg0KDQpCUnMsDQpYaWFvIE1pbg0KDQoN Cg0KDQpEYW4gRnJvc3QgPGRhbmZyb3N0QGNpc2NvLmNvbT4gDQoyMDExLzAyLzE4IDIwOjE0DQoN CsrVvP7Iyw0KeGlhby5taW4yQHp0ZS5jb20uY24NCrOty80NCm1wbHNAaWV0Zi5vcmcNCtb3zOIN ClJlOiBbbXBsc10gTVBMUyBXRyBMYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVs YXktMDENCg0KDQoNCg0KDQoNCkhpIFhpYW8gTWluLA0KDQpPbiBUaHUsIEZlYiAxNywgMjAxMSBh dCAwOTozMTo1NkFNICswODAwLCB4aWFvLm1pbjJAenRlLmNvbS5jbiB3cm90ZToNCj4gSGkgRGFu LA0KPiANCj4gVG8gbXkgdW5kZXJzdGFuZGluZywgdGhlIHRleHRzIHlvdSByZWZlcnJlZCBleHBs YWluIHdoYXQgdGhlIFF1ZXJpZXINCj4gYW5kIHRoZSBSZXNwb25kZXIgc2hvdWxkIGRvIGlmIHRo ZSBjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUgUmVzcG9uZGVyDQo+IGlzIG5vdCByZWFkeSwgYnV0 IHRoZXJlIGlzIG5vIHRleHQgYWJvdXQgaG93IHRvIHN3aXRjaCBvbi9vZmYgdGhpcw0KPiBjb3Vu dGluZyBmdW5jdGlvbiBhdCB0aGUgUmVzcG9uZGVyLiBBRkFJSyBjb3VudGluZyBhdCB0aGUgUmVz cG9uZGVyDQo+IHdvbid0IGJlIHN3aXRjaGVkIG9uIGF1dG9tYXRpY2FsbHkgYWZ0ZXIgcG93ZXIg dXAsIGFuZCBzb21lIG9wZXJhdGlvbg0KPiBpcyBuZWVkZWQgdG8gbWFrZSBjb3VudGluZyBiZWdp bi4gSSB0aGluayB0aGlzIHBvaW50IGlzIGFsc28gbmVjZXNzYXJ5DQo+IHRvIGJlIGV4cGxpY2l0 bHkgZGVmaW5lZC4NCg0KVG8gcHV0IGl0IGFub3RoZXIgd2F5LCB0aGUgaW5pdGlhbCBxdWVyeSBt ZXNzYWdlIGlzIGl0c2VsZiB0aGUgc2lnbmFsIHRvDQp0aGUgcmVzcG9uZGVyIHRvIHRha2Ugd2hh dGV2ZXIgaW5pdGlhbGl6YXRpb24gYWN0aW9ucyBhcmUgcmVxdWlyZWQgZm9yDQppdCB0byBiZWdp biBnZW5lcmF0aW5nIHVzZWZ1bCByZXNwb25zZXMuICBTdWNoIGFjdGlvbnMgbWF5IGluY2x1ZGUN CiJzd2l0Y2hpbmcgb24gdGhlIGNvdW50aW5nIGZ1bmN0aW9uIiBvciBhbnl0aGluZyBlbHNlLCBh bmQgYXJlDQppbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQoNCi1kDQoNCj4gQmVzdCBSZWdhcmRz LA0KPiBYaWFvIE1pbg0KPiANCj4gDQo+IERhbiBGcm9zdCA8ZGFuZnJvc3RAY2lzY28uY29tPiAN Cj4gMjAxMS8wMi8xNiAxOTowMg0KPiANCj4gytW8/sjLDQo+IHhpYW8ubWluMkB6dGUuY29tLmNu DQo+ILOty80NCj4gbXBsc0BpZXRmLm9yZw0KPiDW98ziDQo+IFJlOiBbbXBsc10gTVBMUyBXRyBM YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVsYXktMDENCj4gDQo+IA0KPiBIaSBY aWFvIE1pbiwNCj4gDQo+IE9uIFR1ZSwgRmViIDE1LCAyMDExIGF0IDExOjE1OjM3QU0gKzA4MDAs IHhpYW8ubWluMkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+IEhpIEF1dGhvcnMsDQo+ID4gDQo+ID4g SSBoYXZlIGEgY29tbWVudCBvbiBsb3NzIG1lYXN1cmVtZW50IGluIHRoaXMgZHJhZnQuDQo+ID4g DQo+ID4gQWZ0ZXIgcmVjZWl2aW5nIExNIFF1ZXJ5IG1lc3NhZ2UsIHRoZSByZXNwb25kZXIgd291 bGQgcmVwbHkgTE0NCj4gPiBSZXNwb25zZSBtZXNzYWdlIHdoaWNoIHNob3VsZCB0YWtlIHNvbWUg Y291bnRlcnMuIEJ1dCBJIGNhbid0IGZpbmQNCj4gPiB0ZXh0IGluIHRoaXMgZHJhZnQgdG8gZGVz Y3JpYmUgaG93IHRoZSBjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUNCj4gPiByZXNwb25kZXIgaXMg c3dpdGNoZWQgb24uIElNSE8gb25lIG1vcmUgYml0L2ZsYWcgc2hvdWxkIGJlIGRlZmluZWQgIGlu DQo+ID4gdGhlIExNIFF1ZXJ5IG1lc3NhZ2UgdG8gYWN0aXZhdGUgb3IgZGVhY3RpdmF0ZSB0aGUg Y291bnRpbmcgZnVuY3Rpb24NCj4gPiBhdCB0aGUgcmVzcG9uZGVyLiAgRGlkIEkgbWlzcyBzb21l dGhpbmc/DQo+IA0KPiBUaGVyZSBzaG91bGQgYmUgbm8gbmVlZCBmb3IgYSBzZXBhcmF0ZSBhY3Rp dmF0aW9uIGZsYWcgb3IgbWVzc2FnZS4gIFRoZQ0KPiBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9u IDQuMS4xIGV4cGxhaW5zIHdoYXQgdGhlIHJlc3BvbmRlciBjYW4gZG8gaWYgaXQNCj4gaXMgbm90 IHlldCByZWFkeSB0byBwcm92aWRlIGNvdW50ZXIgZGF0YS4gIEl0IGNhbiBzaW1wbHkgbm90IHJl c3BvbmQNCj4gdW50aWwgaXQgaXMgcmVhZHksIG9yIGl0IGNhbiByZXNwb25kIHdpdGggYW4gYXBw cm9wcmlhdGUgbm90aWZpY2F0aW9uDQo+IGNvZGUgaW4gdGhlIG1lYW50aW1lICh0aGUgYXBwcm9w cmlhdGUgY29kZSBpbiB0aGlzIGNhc2Ugd291bGQgYmUNCj4gTm90aWZpY2F0aW9uIC0gSW5pdGlh bGl6YXRpb24gSW4gUHJvZ3Jlc3MsIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMSkuDQo+IA0KPiBD aGVlcnMsDQo+IA0KPiAtZA0KPiANCj4gPiBCZXN0IFJlZ2FyZHMsIFhpYW8gTWluDQoNCg0KDQo= --=_alternative 0007A6F04825783E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRhbiw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0 aGUgaW5pdGlhbCBMTQ0KcXVlcnkgbWVzc2FnZSBtYXkgYmUgdHJlYXRlZCBhcyBjb3VudGluZyA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFjdGl2YXRpb24gbWVz c2FnZSwgYnV0IHRoYXQgcmVxdWlyZXMNCnRoZSByZXNwb25kZXIgdG8gZGlmZmVyZW50aWF0ZSB0 aGUgZmlyc3QgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MTSBx dWVyeSBhbmQgb3RoZXIgTE0gcXVlcmllcywgYW5kIGl0J3MNCnN0aWxsIG5vdCBzdXJlIGhvdyB0 byBzd2l0Y2ggb2ZmIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmNvdW50aW5nIGZ1bmN0aW9uIGF0IHRoZSByZXNwb25kZXIgd2hlbg0KdGhlIExNIGZ1bmN0 aW9uIGZpbmlzaGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QlJzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WGlh byBNaW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+RGFuIEZyb3N0ICZsdDtkYW5mcm9zdEBjaXNjby5jb20mZ3Q7PC9iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMDIvMTggMjA6MTQ8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+eGlh by5taW4yQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlJlOiBbbXBsc10gTVBMUyBXRyBMYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1t cGxzLWxvc3MtZGVsYXktMDE8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48Zm9udCBzaXplPTI+PHR0PkhpIFhpYW8gTWluLDxicj4NCjxicj4NCk9uIFRodSwgRmViIDE3 LCAyMDExIGF0IDA5OjMxOjU2QU0gKzA4MDAsIHhpYW8ubWluMkB6dGUuY29tLmNuIHdyb3RlOjxi cj4NCiZndDsgSGkgRGFuLDxicj4NCiZndDsgPGJyPg0KJmd0OyBUbyBteSB1bmRlcnN0YW5kaW5n LCB0aGUgdGV4dHMgeW91IHJlZmVycmVkIGV4cGxhaW4gd2hhdCB0aGUgUXVlcmllcjxicj4NCiZn dDsgYW5kIHRoZSBSZXNwb25kZXIgc2hvdWxkIGRvIGlmIHRoZSBjb3VudGluZyBmdW5jdGlvbiBh dCB0aGUgUmVzcG9uZGVyPGJyPg0KJmd0OyBpcyBub3QgcmVhZHksIGJ1dCB0aGVyZSBpcyBubyB0 ZXh0IGFib3V0IGhvdyB0byBzd2l0Y2ggb24vb2ZmIHRoaXM8YnI+DQomZ3Q7IGNvdW50aW5nIGZ1 bmN0aW9uIGF0IHRoZSBSZXNwb25kZXIuIEFGQUlLIGNvdW50aW5nIGF0IHRoZSBSZXNwb25kZXI8 YnI+DQomZ3Q7IHdvbid0IGJlIHN3aXRjaGVkIG9uIGF1dG9tYXRpY2FsbHkgYWZ0ZXIgcG93ZXIg dXAsIGFuZCBzb21lIG9wZXJhdGlvbjxicj4NCiZndDsgaXMgbmVlZGVkIHRvIG1ha2UgY291bnRp bmcgYmVnaW4uIEkgdGhpbmsgdGhpcyBwb2ludCBpcyBhbHNvIG5lY2Vzc2FyeTxicj4NCiZndDsg dG8gYmUgZXhwbGljaXRseSBkZWZpbmVkLjxicj4NCjxicj4NClRvIHB1dCBpdCBhbm90aGVyIHdh eSwgdGhlIGluaXRpYWwgcXVlcnkgbWVzc2FnZSBpcyBpdHNlbGYgdGhlIHNpZ25hbCB0bzxicj4N CnRoZSByZXNwb25kZXIgdG8gdGFrZSB3aGF0ZXZlciBpbml0aWFsaXphdGlvbiBhY3Rpb25zIGFy ZSByZXF1aXJlZCBmb3I8YnI+DQppdCB0byBiZWdpbiBnZW5lcmF0aW5nIHVzZWZ1bCByZXNwb25z ZXMuICZuYnNwO1N1Y2ggYWN0aW9ucyBtYXkgaW5jbHVkZTxicj4NCiZxdW90O3N3aXRjaGluZyBv biB0aGUgY291bnRpbmcgZnVuY3Rpb24mcXVvdDsgb3IgYW55dGhpbmcgZWxzZSwgYW5kIGFyZTxi cj4NCmltcGxlbWVudGF0aW9uLWRlcGVuZGVudC48YnI+DQo8YnI+DQotZDxicj4NCjxicj4NCiZn dDsgQmVzdCBSZWdhcmRzLDxicj4NCiZndDsgWGlhbyBNaW48YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBEYW4gRnJvc3QgJmx0O2RhbmZyb3N0QGNpc2NvLmNvbSZndDsgPGJyPg0KJmd0 OyAyMDExLzAyLzE2IDE5OjAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsg eGlhby5taW4yQHp0ZS5jb20uY248YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7IG1wbHNAaWV0Zi5v cmc8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7IFJlOiBbbXBsc10gTVBMUyBXRyBMYXN0IGNhbGwg b24gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVsYXktMDE8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBIaSBYaWFvIE1pbiw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVHVlLCBGZWIgMTUs IDIwMTEgYXQgMTE6MTU6MzdBTSArMDgwMCwgeGlhby5taW4yQHp0ZS5jb20uY24gd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7IEhpIEF1dGhvcnMsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJ IGhhdmUgYSBjb21tZW50IG9uIGxvc3MgbWVhc3VyZW1lbnQgaW4gdGhpcyBkcmFmdC48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFmdGVyIHJlY2VpdmluZyBMTSBRdWVyeSBtZXNzYWdl LCB0aGUgcmVzcG9uZGVyIHdvdWxkIHJlcGx5IExNPGJyPg0KJmd0OyAmZ3Q7IFJlc3BvbnNlIG1l c3NhZ2Ugd2hpY2ggc2hvdWxkIHRha2Ugc29tZSBjb3VudGVycy4gQnV0IEkgY2FuJ3QNCmZpbmQ8 YnI+DQomZ3Q7ICZndDsgdGV4dCBpbiB0aGlzIGRyYWZ0IHRvIGRlc2NyaWJlIGhvdyB0aGUgY291 bnRpbmcgZnVuY3Rpb24gYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7IHJlc3BvbmRlciBpcyBzd2l0Y2hl ZCBvbi4gSU1ITyBvbmUgbW9yZSBiaXQvZmxhZyBzaG91bGQgYmUgZGVmaW5lZA0KJm5ic3A7aW48 YnI+DQomZ3Q7ICZndDsgdGhlIExNIFF1ZXJ5IG1lc3NhZ2UgdG8gYWN0aXZhdGUgb3IgZGVhY3Rp dmF0ZSB0aGUgY291bnRpbmcgZnVuY3Rpb248YnI+DQomZ3Q7ICZndDsgYXQgdGhlIHJlc3BvbmRl ci4gJm5ic3A7RGlkIEkgbWlzcyBzb21ldGhpbmc/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJl IHNob3VsZCBiZSBubyBuZWVkIGZvciBhIHNlcGFyYXRlIGFjdGl2YXRpb24gZmxhZyBvciBtZXNz YWdlLg0KJm5ic3A7VGhlPGJyPg0KJmd0OyBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMS4x IGV4cGxhaW5zIHdoYXQgdGhlIHJlc3BvbmRlciBjYW4gZG8NCmlmIGl0PGJyPg0KJmd0OyBpcyBu b3QgeWV0IHJlYWR5IHRvIHByb3ZpZGUgY291bnRlciBkYXRhLiAmbmJzcDtJdCBjYW4gc2ltcGx5 IG5vdA0KcmVzcG9uZDxicj4NCiZndDsgdW50aWwgaXQgaXMgcmVhZHksIG9yIGl0IGNhbiByZXNw b25kIHdpdGggYW4gYXBwcm9wcmlhdGUgbm90aWZpY2F0aW9uPGJyPg0KJmd0OyBjb2RlIGluIHRo ZSBtZWFudGltZSAodGhlIGFwcHJvcHJpYXRlIGNvZGUgaW4gdGhpcyBjYXNlIHdvdWxkIGJlPGJy Pg0KJmd0OyBOb3RpZmljYXRpb24gLSBJbml0aWFsaXphdGlvbiBJbiBQcm9ncmVzcywgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4xKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZn dDsgPGJyPg0KJmd0OyAtZDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJlc3QgUmVnYXJkcywg WGlhbyBNaW48YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 0007A6F04825783E_=-- From takeda.tomonori@lab.ntt.co.jp Sun Feb 20 22:53:04 2011 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 B1F7F3A6F96; Sun, 20 Feb 2011 22:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 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, 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 jUz2ls4kJ2uo; Sun, 20 Feb 2011 22:53:02 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id ADCAA3A6F93; Sun, 20 Feb 2011 22:53:02 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p1L6rgkq019415; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 289E665F1; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1003A65EB; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p1L6reHU009271; Mon, 21 Feb 2011 15:53:42 +0900 Message-ID: <4D620BDD.7000504@lab.ntt.co.jp> Date: Mon, 21 Feb 2011 15:53:17 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: iPOP2011-tpc-sec@pilab.jp Subject: [mpls] iPOP2011 Call for Presentation (corrected version) 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, 21 Feb 2011 06:53:05 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, The email sent on Feb. 10th titled "iPOP2011 Call for Presentation" states wrong dates. It should be year "2011", not "2010". Please find the corrected CFP as follows. Sorry for your inconvenience. Tomonori Takeda ------------------------------------------------------------------- Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2011 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 25, 2011 Notification of acceptance: April 4, 2011 Submission deadline of final presentation slides: April 22, 2011 The Technical Program Committee for iPOP 2011 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$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ----------------------------------------------------------------------- From linda.dunbar@huawei.com Mon Feb 21 06:23:12 2011 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 914303A6FD5 for ; Mon, 21 Feb 2011 06:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 vDMXCTBW4PS8 for ; Mon, 21 Feb 2011 06:23:11 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3C7AA3A6F84 for ; Mon, 21 Feb 2011 06:23:11 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGZ002OJ1BRZL@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 21 Feb 2011 08:23:52 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LGZ00BP01BOHQ@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 21 Feb 2011 08:23:51 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Feb 2011 06:23:51 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 06:23:50 -0800 Date: Mon, 21 Feb 2011 14:23:50 +0000 From: Linda Dunbar In-reply-to: X-Originating-IP: [10.47.154.230] To: "xiao.min2@zte.com.cn" , Dan Frost Message-id: <4A95BA014132FF49AE685FAB4B9F17F6A8A9BB@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/d2KwLbdKB3ZSdtpYO0WJg)" Content-language: en-US Accept-Language: en-US Thread-topic: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Thread-index: AQHLzL6dTQVnojA3ThmPPWkMXUN/MpQEfrQAgADy1wCAAkXogIAEASQAgABTonA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110218121439.GB8070@cisco.com> Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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, 21 Feb 2011 14:23:12 -0000 --Boundary_(ID_/d2KwLbdKB3ZSdtpYO0WJg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 UmVzcG9uZGVyIGNhbiBzd2l0Y2ggb2ZmIHRoZSBjb3VudGluZyBpZiBub3QgcmVjZWl2aW5nIHRo ZSBMTSBtZXNzYWdlIGZvciBjZXJ0YWluIHRpbWUuDQoNCkxpbmRhIER1bmJhcg0KDQpGcm9tOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiB4aWFvLm1pbjJAenRlLmNvbS5jbg0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAyMCwg MjAxMSA3OjI0IFBNDQpUbzogRGFuIEZyb3N0DQpDYzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFttcGxzXSBNUExTIFdHIExhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxh eS0wMQ0KDQoNCkRhbiwNCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBpbml0aWFsIExNIHF1 ZXJ5IG1lc3NhZ2UgbWF5IGJlIHRyZWF0ZWQgYXMgY291bnRpbmcNCmFjdGl2YXRpb24gbWVzc2Fn ZSwgYnV0IHRoYXQgcmVxdWlyZXMgdGhlIHJlc3BvbmRlciB0byBkaWZmZXJlbnRpYXRlIHRoZSBm aXJzdA0KTE0gcXVlcnkgYW5kIG90aGVyIExNIHF1ZXJpZXMsIGFuZCBpdCdzIHN0aWxsIG5vdCBz dXJlIGhvdyB0byBzd2l0Y2ggb2ZmIHRoZQ0KY291bnRpbmcgZnVuY3Rpb24gYXQgdGhlIHJlc3Bv bmRlciB3aGVuIHRoZSBMTSBmdW5jdGlvbiBmaW5pc2hlZC4NCg0KQlJzLA0KWGlhbyBNaW4NCg0K DQpEYW4gRnJvc3QgPGRhbmZyb3N0QGNpc2NvLmNvbT4NCg0KMjAxMS8wMi8xOCAyMDoxNA0KDQrK 1bz+yMsNCg0KeGlhby5taW4yQHp0ZS5jb20uY24NCg0Ks63LzQ0KDQptcGxzQGlldGYub3JnDQoN Ctb3zOINCg0KUmU6IFttcGxzXSBNUExTIFdHIExhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMt bG9zcy1kZWxheS0wMQ0KDQoNCg0KDQoNCg0KDQpIaSBYaWFvIE1pbiwNCg0KT24gVGh1LCBGZWIg MTcsIDIwMTEgYXQgMDk6MzE6NTZBTSArMDgwMCwgeGlhby5taW4yQHp0ZS5jb20uY24gd3JvdGU6 DQo+IEhpIERhbiwNCj4NCj4gVG8gbXkgdW5kZXJzdGFuZGluZywgdGhlIHRleHRzIHlvdSByZWZl cnJlZCBleHBsYWluIHdoYXQgdGhlIFF1ZXJpZXINCj4gYW5kIHRoZSBSZXNwb25kZXIgc2hvdWxk IGRvIGlmIHRoZSBjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUgUmVzcG9uZGVyDQo+IGlzIG5vdCBy ZWFkeSwgYnV0IHRoZXJlIGlzIG5vIHRleHQgYWJvdXQgaG93IHRvIHN3aXRjaCBvbi9vZmYgdGhp cw0KPiBjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUgUmVzcG9uZGVyLiBBRkFJSyBjb3VudGluZyBh dCB0aGUgUmVzcG9uZGVyDQo+IHdvbid0IGJlIHN3aXRjaGVkIG9uIGF1dG9tYXRpY2FsbHkgYWZ0 ZXIgcG93ZXIgdXAsIGFuZCBzb21lIG9wZXJhdGlvbg0KPiBpcyBuZWVkZWQgdG8gbWFrZSBjb3Vu dGluZyBiZWdpbi4gSSB0aGluayB0aGlzIHBvaW50IGlzIGFsc28gbmVjZXNzYXJ5DQo+IHRvIGJl IGV4cGxpY2l0bHkgZGVmaW5lZC4NCg0KVG8gcHV0IGl0IGFub3RoZXIgd2F5LCB0aGUgaW5pdGlh bCBxdWVyeSBtZXNzYWdlIGlzIGl0c2VsZiB0aGUgc2lnbmFsIHRvDQp0aGUgcmVzcG9uZGVyIHRv IHRha2Ugd2hhdGV2ZXIgaW5pdGlhbGl6YXRpb24gYWN0aW9ucyBhcmUgcmVxdWlyZWQgZm9yDQpp dCB0byBiZWdpbiBnZW5lcmF0aW5nIHVzZWZ1bCByZXNwb25zZXMuICBTdWNoIGFjdGlvbnMgbWF5 IGluY2x1ZGUNCiJzd2l0Y2hpbmcgb24gdGhlIGNvdW50aW5nIGZ1bmN0aW9uIiBvciBhbnl0aGlu ZyBlbHNlLCBhbmQgYXJlDQppbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQoNCi1kDQoNCj4gQmVz dCBSZWdhcmRzLA0KPiBYaWFvIE1pbg0KPg0KPg0KPiBEYW4gRnJvc3QgPGRhbmZyb3N0QGNpc2Nv LmNvbT4NCj4gMjAxMS8wMi8xNiAxOTowMg0KPg0KPiDK1bz+yMsNCj4geGlhby5taW4yQHp0ZS5j b20uY24NCj4gs63LzQ0KPiBtcGxzQGlldGYub3JnDQo+INb3zOINCj4gUmU6IFttcGxzXSBNUExT IFdHIExhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheS0wMQ0KPg0KPg0KPiBI aSBYaWFvIE1pbiwNCj4NCj4gT24gVHVlLCBGZWIgMTUsIDIwMTEgYXQgMTE6MTU6MzdBTSArMDgw MCwgeGlhby5taW4yQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gSGkgQXV0aG9ycywNCj4gPg0KPiA+ IEkgaGF2ZSBhIGNvbW1lbnQgb24gbG9zcyBtZWFzdXJlbWVudCBpbiB0aGlzIGRyYWZ0Lg0KPiA+ DQo+ID4gQWZ0ZXIgcmVjZWl2aW5nIExNIFF1ZXJ5IG1lc3NhZ2UsIHRoZSByZXNwb25kZXIgd291 bGQgcmVwbHkgTE0NCj4gPiBSZXNwb25zZSBtZXNzYWdlIHdoaWNoIHNob3VsZCB0YWtlIHNvbWUg Y291bnRlcnMuIEJ1dCBJIGNhbid0IGZpbmQNCj4gPiB0ZXh0IGluIHRoaXMgZHJhZnQgdG8gZGVz Y3JpYmUgaG93IHRoZSBjb3VudGluZyBmdW5jdGlvbiBhdCB0aGUNCj4gPiByZXNwb25kZXIgaXMg c3dpdGNoZWQgb24uIElNSE8gb25lIG1vcmUgYml0L2ZsYWcgc2hvdWxkIGJlIGRlZmluZWQgIGlu DQo+ID4gdGhlIExNIFF1ZXJ5IG1lc3NhZ2UgdG8gYWN0aXZhdGUgb3IgZGVhY3RpdmF0ZSB0aGUg Y291bnRpbmcgZnVuY3Rpb24NCj4gPiBhdCB0aGUgcmVzcG9uZGVyLiAgRGlkIEkgbWlzcyBzb21l dGhpbmc/DQo+DQo+IFRoZXJlIHNob3VsZCBiZSBubyBuZWVkIGZvciBhIHNlcGFyYXRlIGFjdGl2 YXRpb24gZmxhZyBvciBtZXNzYWdlLiAgVGhlDQo+IGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24g NC4xLjEgZXhwbGFpbnMgd2hhdCB0aGUgcmVzcG9uZGVyIGNhbiBkbyBpZiBpdA0KPiBpcyBub3Qg eWV0IHJlYWR5IHRvIHByb3ZpZGUgY291bnRlciBkYXRhLiAgSXQgY2FuIHNpbXBseSBub3QgcmVz cG9uZA0KPiB1bnRpbCBpdCBpcyByZWFkeSwgb3IgaXQgY2FuIHJlc3BvbmQgd2l0aCBhbiBhcHBy b3ByaWF0ZSBub3RpZmljYXRpb24NCj4gY29kZSBpbiB0aGUgbWVhbnRpbWUgKHRoZSBhcHByb3By aWF0ZSBjb2RlIGluIHRoaXMgY2FzZSB3b3VsZCBiZQ0KPiBOb3RpZmljYXRpb24gLSBJbml0aWFs aXphdGlvbiBJbiBQcm9ncmVzcywgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xKS4NCj4NCj4gQ2hl ZXJzLA0KPg0KPiAtZA0KPg0KPiA+IEJlc3QgUmVnYXJkcywgWGlhbyBNaW4NCg0K --Boundary_(ID_/d2KwLbdKB3ZSdtpYO0WJg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Responder can switch off = the counting if not receiving the LM message for certain time.

<= /p>
Linda Dunbar

<= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of xiao.min2@zte.com.cn
Sent: Sunday, February 20, 2011 7:24 PM
To: Dan Frost
Cc: mpls@ietf.org
Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-= 01

Dan,

I agree with you that the initial LM query message may be treate= d as counting
activation message, but that requires the responder to different= iate the first
LM query and other LM queries, and it's still not sure how to sw= itch off the
counting function at the responder when the LM function finished= .

BRs,
Xiao Min

Dan Frost <danfrost@cisco.com>

2011/02/18 20:14

=CA=D5=BC=FE=C8=CB<= /p>

xiao.min2@zte.com.cn

=B3=AD=CB=CD

mpls@ietf.org

=D6=F7=CC=E2

Re: [mpls] MPLS WG Last call on draft-ietf= -mpls-loss-delay-01

Hi Xiao Min,

On Thu, Feb 17, 2011 at 09:31:56AM +0800, xiao.min2@zte.com.cn wrot= e:
> Hi Dan,
>
> To my understanding, the texts you referred explain what the Queri= er
> and the Responder should do if the counting function at the Respon= der
> is not ready, but there is no text about how to switch on/off this=
> counting function at the Responder. AFAIK counting at the Responde= r
> won't be switched on automatically after power up, and some operat= ion
> is needed to make counting begin. I think this point is also neces= sary
> to be explicitly defined.

To put it another way, the initial query message is itself the signal t= o
the responder to take whatever initialization actions are required for<= /tt> it to begin generating useful responses. Such actions may include= "switching on the counting function" or anything else, and ar= e implementation-dependent. -d > Best Regards, > Xiao Min > > > Dan Frost <danfrost@cisco.com> > 2011/02/16 19:02 > > =CA=D5=BC=FE=C8=CB > xiao.min2@zte.com.cn > =B3=AD=CB=CD > mpls@ietf.org > =D6=F7=CC=E2 > Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01= > > > Hi Xiao Min, > > On Tue, Feb 15, 2011 at 11:15:37AM +0800, xiao.min2@zte.com.cn= wrote: > > Hi Authors, > > > > I have a comment on loss measurement in this draft. > > > > After receiving LM Query message, the responder would reply L= M > > Response message which should take some counters. But I can't= find > > text in this draft to describe how the counting function at t= he > > responder is switched on. IMHO one more bit/flag should be de= fined in > > the LM Query message to activate or deactivate the counting f= unction > > at the responder. Did I miss something? > > There should be no need for a separate activation flag or message.= The > last paragraph of Section 4.1.1 explains what the responder can do= if it > is not yet ready to provide counter data. It can simply not = respond > until it is ready, or it can respond with an appropriate notificat= ion > code in the meantime (the appropriate code in this case would be > Notification - Initialization In Progress, described in Section 3.= 1). > > Cheers, > > -d > > > Best Regards, Xiao Min
--Boundary_(ID_/d2KwLbdKB3ZSdtpYO0WJg)-- From nick.delregno@verizon.com Mon Feb 21 10:55:21 2011 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 9DDFB3A6E09; Mon, 21 Feb 2011 10:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNoezABpdAdE; Mon, 21 Feb 2011 10:55:18 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 3D5503A6E38; Mon, 21 Feb 2011 10:55:18 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00HCWDXB6Q10@firewall.verizonbusiness.com>; Mon, 21 Feb 2011 18:56:00 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGZ00A4KDXBXU00@omzismtp03.vzbi.com>; Mon, 21 Feb 2011 18:55:59 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00A6CDXAWX00@omzismtp03.vzbi.com>; Mon, 21 Feb 2011 18:55:59 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 18:55:58 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBD1F8.F8BB3703" Date: Mon, 21 Feb 2011 18:55:54 +0000 Message-id: <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: LAST WEEK!! PW/VCCV User Implementation Survey Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzADxnTEgA== References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 21 Feb 2011 18:55:58.0100 (UTC) FILETIME=[F9AAB540:01CBD1F8] Subject: [mpls] LAST WEEK!! PW/VCCV User Implementation Survey 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, 21 Feb 2011 18:55:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD1F8.F8BB3703 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: =20 This is the last week to participate in the PW/VCCV User Implementation Survey. The deadline for submissions is February 25th. The survey will be ended this Friday evening and the results analyzed. =20 We have 11 responses so far. =20 It is important that we get as many participants as possible to ensure fair representation in any future PW Control Word and VCCV related work in the PWE3 working group. =20 Thanks, Nick =20 =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 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBD1F8.F8BB3703 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: This is the = last week to participate in the PW/VCCV User Implementation = Survey. The deadline for submissions is February 25th. The = survey will be ended this Friday evening and the results = analyzed. We have 11 responses so far. It is = important that we get as many participants as possible to ensure fair = representation in any future PW Control Word and VCCV related work in = the PWE3 working group. Thanks, Nick =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 All: Per the = direction of the PWE3 working group, beginning in IETF77 and reinforced = in IETF78, the PWE3 working group is conducting a Service Provider = implementation survey related to: -          = Pseudowire Encapsulations -          = Control Word Support -          = Control Word Use -          = VCCV Control Channel Support -          = VCCV Control Channel Use http://www.surveymonkey.com/s= /pwe3 This is a short survey directed toward Service = Providers who currently operate networks using any of the defined PWE3 = encapsulations. The results of this survey will be used to = determine the direction of the Control Word support in current and = future encapsulations as well as solutions to VCCV interoperability = challenges. We sincerely urge all service providers to = participate. We ask that all equipment providers encourage = participation by their Service Provider customers. The more = feedback we receive, the better view of the existing network we can have = on which to base going-forward direction. If you have = any questions, regarding the survey, especially of a technical nature, = please contact me. If you have non-technical questions, feel free = to reach out to the PWE3 WG chairs and myself. The results = of the survey will be aggregated and shared at a high level. No = low-level details of network implementations will be shared. All = participant’s responses will remain private, if not = anonymous. All responses will require a valid email address to = help ensure the survey’s validity. Thanks, Nick Christopher N. “Nick” DelRegno, = PMTS CNT, Ethernet Network Architecture & = Design 400 International Pkwy Richardson, TX = 75081 Tel: 972-729-3411 Email: = Nick.DelRegno@verizon.com ------_=_NextPart_001_01CBD1F8.F8BB3703-- From xiao.min2@zte.com.cn Mon Feb 21 17:02:57 2011 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 34FD53A67B0 for ; Mon, 21 Feb 2011 17:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.243 X-Spam-Level: X-Spam-Status: No, score=-95.243 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsSKcO89c+tL for ; Mon, 21 Feb 2011 17:02:56 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 698F23A67AE for ; Mon, 21 Feb 2011 17:02:54 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 20595806486374; Tue, 22 Feb 2011 08:58:30 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.2918843361; Tue, 22 Feb 2011 09:03:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1M13Kkg067725; Tue, 22 Feb 2011 09:03:20 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6A8A9BB@DFWEML501-MBX.china.huawei.com> To: Linda Dunbar MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: xiao.min2@zte.com.cn Date: Tue, 22 Feb 2011 09:01:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-22 09:03:20, Serialize complete at 2011-02-22 09:03:20 Content-Type: multipart/alternative; boundary="=_alternative 00059E0E4825783F_=" X-MAIL: mse02.zte.com.cn p1M13Kkg067725 Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-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: Tue, 22 Feb 2011 01:02:57 -0000 This is a multipart message in MIME format. --=_alternative 00059E0E4825783F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SXQgc291bmRzIGFjY2VwdGFibGUgYnV0IElNSE8gbm90IHRoZSBwcmVmZXJyZWQgcmVzb2x1dGlv biBvbiB0aGlzIGlzc3VlLg0KSSB0aGluayBpdCdzIGJldHRlciB0byBoYXZlIGV4cGxpY2l0IG5v dGljZSBmcm9tIHRoZSBRdWVyaWVyIHRvIHRoZSANClJlc3BvbmRlciANCmFib3V0IHRoZSBjb3Vu dGluZyBhY3RpdmF0aW9uL2RlYWN0aXZhdGlvbiBhbmQgYWNrbm93bGVkZ2VtZW50IGZyb20gdGhl IA0KUmVzcG9uZGVyIA0KdG8gdGhlIFF1ZXJpZXIgaXMgYWxzbyBuZWVkZWQuDQpBbnl3YXksIHRo ZSBjb3JyZXNwb25kaW5nIHRleHQgZGVzZXJ2ZXMgdG8gYmUgYWRkZWQgdG8gdGhpcyBkcmFmdC4N Cg0KQlJzLA0KWGlhbyBNaW4NCg0KDQoNCg0KTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVh d2VpLmNvbT4gDQoyMDExLzAyLzIxIDIyOjIzDQoNCsrVvP7Iyw0KInhpYW8ubWluMkB6dGUuY29t LmNuIiA8eGlhby5taW4yQHp0ZS5jb20uY24+LCBEYW4gRnJvc3QgDQo8ZGFuZnJvc3RAY2lzY28u Y29tPg0Ks63LzQ0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0K1vfM4g0KUkU6IFtt cGxzXSBNUExTIFdHIExhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheS0wMQ0K DQoNCg0KDQoNCg0KUmVzcG9uZGVyIGNhbiBzd2l0Y2ggb2ZmIHRoZSBjb3VudGluZyBpZiBub3Qg cmVjZWl2aW5nIHRoZSBMTSBtZXNzYWdlIGZvciANCmNlcnRhaW4gdGltZS4gDQogDQpMaW5kYSBE dW5iYXINCiANCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KeGlhby5taW4yQHp0ZS5jb20uY24NClNlbnQ6IFN1 bmRheSwgRmVicnVhcnkgMjAsIDIwMTEgNzoyNCBQTQ0KVG86IERhbiBGcm9zdA0KQ2M6IG1wbHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUyBXRyBMYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1tcGxzLWxvc3MtZGVsYXktMDENCiANCg0KRGFuLCANCg0KSSBhZ3JlZSB3aXRoIHlvdSB0 aGF0IHRoZSBpbml0aWFsIExNIHF1ZXJ5IG1lc3NhZ2UgbWF5IGJlIHRyZWF0ZWQgYXMgDQpjb3Vu dGluZyANCmFjdGl2YXRpb24gbWVzc2FnZSwgYnV0IHRoYXQgcmVxdWlyZXMgdGhlIHJlc3BvbmRl ciB0byBkaWZmZXJlbnRpYXRlIHRoZSANCmZpcnN0IA0KTE0gcXVlcnkgYW5kIG90aGVyIExNIHF1 ZXJpZXMsIGFuZCBpdCdzIHN0aWxsIG5vdCBzdXJlIGhvdyB0byBzd2l0Y2ggb2ZmIA0KdGhlIA0K Y291bnRpbmcgZnVuY3Rpb24gYXQgdGhlIHJlc3BvbmRlciB3aGVuIHRoZSBMTSBmdW5jdGlvbiBm aW5pc2hlZC4gDQoNCkJScywgDQpYaWFvIE1pbiANCg0KDQoNCkRhbiBGcm9zdCA8ZGFuZnJvc3RA Y2lzY28uY29tPiANCjIwMTEvMDIvMTggMjA6MTQgDQoNCg0KytW8/sjLDQp4aWFvLm1pbjJAenRl LmNvbS5jbiANCrOty80NCm1wbHNAaWV0Zi5vcmcgDQrW98ziDQpSZTogW21wbHNdIE1QTFMgV0cg TGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1sb3NzLWRlbGF5LTAxDQogDQoNCg0KDQoNCg0K DQoNCg0KSGkgWGlhbyBNaW4sDQoNCk9uIFRodSwgRmViIDE3LCAyMDExIGF0IDA5OjMxOjU2QU0g KzA4MDAsIHhpYW8ubWluMkB6dGUuY29tLmNuIHdyb3RlOg0KPiBIaSBEYW4sDQo+IA0KPiBUbyBt eSB1bmRlcnN0YW5kaW5nLCB0aGUgdGV4dHMgeW91IHJlZmVycmVkIGV4cGxhaW4gd2hhdCB0aGUg UXVlcmllcg0KPiBhbmQgdGhlIFJlc3BvbmRlciBzaG91bGQgZG8gaWYgdGhlIGNvdW50aW5nIGZ1 bmN0aW9uIGF0IHRoZSBSZXNwb25kZXINCj4gaXMgbm90IHJlYWR5LCBidXQgdGhlcmUgaXMgbm8g dGV4dCBhYm91dCBob3cgdG8gc3dpdGNoIG9uL29mZiB0aGlzDQo+IGNvdW50aW5nIGZ1bmN0aW9u IGF0IHRoZSBSZXNwb25kZXIuIEFGQUlLIGNvdW50aW5nIGF0IHRoZSBSZXNwb25kZXINCj4gd29u J3QgYmUgc3dpdGNoZWQgb24gYXV0b21hdGljYWxseSBhZnRlciBwb3dlciB1cCwgYW5kIHNvbWUg b3BlcmF0aW9uDQo+IGlzIG5lZWRlZCB0byBtYWtlIGNvdW50aW5nIGJlZ2luLiBJIHRoaW5rIHRo aXMgcG9pbnQgaXMgYWxzbyBuZWNlc3NhcnkNCj4gdG8gYmUgZXhwbGljaXRseSBkZWZpbmVkLg0K DQpUbyBwdXQgaXQgYW5vdGhlciB3YXksIHRoZSBpbml0aWFsIHF1ZXJ5IG1lc3NhZ2UgaXMgaXRz ZWxmIHRoZSBzaWduYWwgdG8NCnRoZSByZXNwb25kZXIgdG8gdGFrZSB3aGF0ZXZlciBpbml0aWFs aXphdGlvbiBhY3Rpb25zIGFyZSByZXF1aXJlZCBmb3INCml0IHRvIGJlZ2luIGdlbmVyYXRpbmcg dXNlZnVsIHJlc3BvbnNlcy4gIFN1Y2ggYWN0aW9ucyBtYXkgaW5jbHVkZQ0KInN3aXRjaGluZyBv biB0aGUgY291bnRpbmcgZnVuY3Rpb24iIG9yIGFueXRoaW5nIGVsc2UsIGFuZCBhcmUNCmltcGxl bWVudGF0aW9uLWRlcGVuZGVudC4NCg0KLWQNCg0KPiBCZXN0IFJlZ2FyZHMsDQo+IFhpYW8gTWlu DQo+IA0KPiANCj4gRGFuIEZyb3N0IDxkYW5mcm9zdEBjaXNjby5jb20+IA0KPiAyMDExLzAyLzE2 IDE5OjAyDQo+IA0KPiDK1bz+yMsNCj4geGlhby5taW4yQHp0ZS5jb20uY24NCj4gs63LzQ0KPiBt cGxzQGlldGYub3JnDQo+INb3zOINCj4gUmU6IFttcGxzXSBNUExTIFdHIExhc3QgY2FsbCBvbiBk cmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheS0wMQ0KPiANCj4gDQo+IEhpIFhpYW8gTWluLA0KPiAN Cj4gT24gVHVlLCBGZWIgMTUsIDIwMTEgYXQgMTE6MTU6MzdBTSArMDgwMCwgeGlhby5taW4yQHp0 ZS5jb20uY24gd3JvdGU6DQo+ID4gSGkgQXV0aG9ycywNCj4gPiANCj4gPiBJIGhhdmUgYSBjb21t ZW50IG9uIGxvc3MgbWVhc3VyZW1lbnQgaW4gdGhpcyBkcmFmdC4NCj4gPiANCj4gPiBBZnRlciBy ZWNlaXZpbmcgTE0gUXVlcnkgbWVzc2FnZSwgdGhlIHJlc3BvbmRlciB3b3VsZCByZXBseSBMTQ0K PiA+IFJlc3BvbnNlIG1lc3NhZ2Ugd2hpY2ggc2hvdWxkIHRha2Ugc29tZSBjb3VudGVycy4gQnV0 IEkgY2FuJ3QgZmluZA0KPiA+IHRleHQgaW4gdGhpcyBkcmFmdCB0byBkZXNjcmliZSBob3cgdGhl IGNvdW50aW5nIGZ1bmN0aW9uIGF0IHRoZQ0KPiA+IHJlc3BvbmRlciBpcyBzd2l0Y2hlZCBvbi4g SU1ITyBvbmUgbW9yZSBiaXQvZmxhZyBzaG91bGQgYmUgZGVmaW5lZCAgaW4NCj4gPiB0aGUgTE0g UXVlcnkgbWVzc2FnZSB0byBhY3RpdmF0ZSBvciBkZWFjdGl2YXRlIHRoZSBjb3VudGluZyBmdW5j dGlvbg0KPiA+IGF0IHRoZSByZXNwb25kZXIuICBEaWQgSSBtaXNzIHNvbWV0aGluZz8NCj4gDQo+ IFRoZXJlIHNob3VsZCBiZSBubyBuZWVkIGZvciBhIHNlcGFyYXRlIGFjdGl2YXRpb24gZmxhZyBv ciBtZXNzYWdlLiAgVGhlDQo+IGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xLjEgZXhwbGFp bnMgd2hhdCB0aGUgcmVzcG9uZGVyIGNhbiBkbyBpZiBpdA0KPiBpcyBub3QgeWV0IHJlYWR5IHRv IHByb3ZpZGUgY291bnRlciBkYXRhLiAgSXQgY2FuIHNpbXBseSBub3QgcmVzcG9uZA0KPiB1bnRp bCBpdCBpcyByZWFkeSwgb3IgaXQgY2FuIHJlc3BvbmQgd2l0aCBhbiBhcHByb3ByaWF0ZSBub3Rp ZmljYXRpb24NCj4gY29kZSBpbiB0aGUgbWVhbnRpbWUgKHRoZSBhcHByb3ByaWF0ZSBjb2RlIGlu IHRoaXMgY2FzZSB3b3VsZCBiZQ0KPiBOb3RpZmljYXRpb24gLSBJbml0aWFsaXphdGlvbiBJbiBQ cm9ncmVzcywgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xKS4NCj4gDQo+IENoZWVycywNCj4gDQo+ IC1kDQo+IA0KPiA+IEJlc3QgUmVnYXJkcywgWGlhbyBNaW4NCg0KDQo= --=_alternative 00059E0E4825783F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IHNvdW5kcyBhY2NlcHRhYmxl IGJ1dCBJTUhPIG5vdCB0aGUNCnByZWZlcnJlZCByZXNvbHV0aW9uIG9uIHRoaXMgaXNzdWUuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIGl0J3MgYmV0 dGVyIHRvIGhhdmUgZXhwbGljaXQNCm5vdGljZSBmcm9tIHRoZSBRdWVyaWVyIHRvIHRoZSBSZXNw b25kZXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hYm91dCB0 aGUgY291bnRpbmcgYWN0aXZhdGlvbi9kZWFjdGl2YXRpb24NCmFuZCBhY2tub3dsZWRnZW1lbnQg ZnJvbSB0aGUgUmVzcG9uZGVyIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+dG8gdGhlIFF1ZXJpZXIgaXMgYWxzbyBuZWVkZWQuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bbnl3YXksIHRoZSBjb3JyZXNwb25kaW5nIHRleHQgZGVz ZXJ2ZXMNCnRvIGJlIGFkZGVkIHRvIHRoaXMgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CUnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5YaWFvIE1pbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5MaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJh ckBodWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDExLzAyLzIxIDIyOjIzPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3hpYW8ubWluMkB6dGUuY29tLmNuJnF1b3Q7 ICZsdDt4aWFvLm1pbjJAenRlLmNvbS5jbiZndDssDQpEYW4gRnJvc3QgJmx0O2RhbmZyb3N0QGNp c2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsg Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW21wbHNdIE1QTFMg V0cgTGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1sb3NzLWRlbGF5LTAxPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+UmVzcG9uZGVyIGNhbiBzd2l0Y2ggb2ZmDQp0aGUgY291bnRpbmcgaWYg bm90IHJlY2VpdmluZyB0aGUgTE0gbWVzc2FnZSBmb3IgY2VydGFpbiB0aW1lLiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkxpbmRhIER1 bmJhcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8 L2I+IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+eGlhby5taW4yQHp0ZS5jb20uY248Yj48YnI+DQpTZW50Ojwv Yj4gU3VuZGF5LCBGZWJydWFyeSAyMCwgMjAxMSA3OjI0IFBNPGI+PGJyPg0KVG86PC9iPiBEYW4g RnJvc3Q8Yj48YnI+DQpDYzo8L2I+IG1wbHNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4g UmU6IFttcGxzXSBNUExTIFdHIExhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxh eS0wMTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iy87M5SI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KRGFuLDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iy87M5SI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgaW5pdGlhbCBMTSBxdWVyeSBtZXNzYWdlIG1h eSBiZSB0cmVhdGVkIGFzIGNvdW50aW5nDQo8YnI+DQphY3RpdmF0aW9uIG1lc3NhZ2UsIGJ1dCB0 aGF0IHJlcXVpcmVzIHRoZSByZXNwb25kZXIgdG8gZGlmZmVyZW50aWF0ZSB0aGUNCmZpcnN0IDxi cj4NCkxNIHF1ZXJ5IGFuZCBvdGhlciBMTSBxdWVyaWVzLCBhbmQgaXQncyBzdGlsbCBub3Qgc3Vy ZSBob3cgdG8gc3dpdGNoIG9mZg0KdGhlIDxicj4NCmNvdW50aW5nIGZ1bmN0aW9uIGF0IHRoZSBy ZXNwb25kZXIgd2hlbiB0aGUgTE0gZnVuY3Rpb24gZmluaXNoZWQuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSLLzszlIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCkJScyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IsvOzOUiPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpYaWFvIE1pbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i y87M5SI+IDxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj5E YW4gRnJvc3QgJmx0O2RhbmZyb3N0QGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTEvMDIvMTggMjA6MTQ8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IsvOzOUiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9OSU+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSLLzszlIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9 OTAlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+eGlhby5taW4yQHp0ZS5jb20uY248L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IsvOzOUiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSLLzszlIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+bXBsc0BpZXRmLm9yZzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iy87M5SI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9IsvOzOUiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SZTogW21wbHNdIE1QTFMgV0cgTGFz dCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1sb3NzLWRlbGF5LTAxPC9mb250PjwvdGFibGU+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IsvOzOUiPiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lk dGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iy87M 5SI+PGJyPg0KPGJyPg0KPGJyPg0KSGkgWGlhbyBNaW4sPGJyPg0KPGJyPg0KT24gVGh1LCBGZWIg MTcsIDIwMTEgYXQgMDk6MzE6NTZBTSArMDgwMCwgeGlhby5taW4yQHp0ZS5jb20uY24gd3JvdGU6 PGJyPg0KJmd0OyBIaSBEYW4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvIG15IHVuZGVyc3RhbmRp bmcsIHRoZSB0ZXh0cyB5b3UgcmVmZXJyZWQgZXhwbGFpbiB3aGF0IHRoZSBRdWVyaWVyPGJyPg0K Jmd0OyBhbmQgdGhlIFJlc3BvbmRlciBzaG91bGQgZG8gaWYgdGhlIGNvdW50aW5nIGZ1bmN0aW9u IGF0IHRoZSBSZXNwb25kZXI8YnI+DQomZ3Q7IGlzIG5vdCByZWFkeSwgYnV0IHRoZXJlIGlzIG5v IHRleHQgYWJvdXQgaG93IHRvIHN3aXRjaCBvbi9vZmYgdGhpczxicj4NCiZndDsgY291bnRpbmcg ZnVuY3Rpb24gYXQgdGhlIFJlc3BvbmRlci4gQUZBSUsgY291bnRpbmcgYXQgdGhlIFJlc3BvbmRl cjxicj4NCiZndDsgd29uJ3QgYmUgc3dpdGNoZWQgb24gYXV0b21hdGljYWxseSBhZnRlciBwb3dl ciB1cCwgYW5kIHNvbWUgb3BlcmF0aW9uPGJyPg0KJmd0OyBpcyBuZWVkZWQgdG8gbWFrZSBjb3Vu dGluZyBiZWdpbi4gSSB0aGluayB0aGlzIHBvaW50IGlzIGFsc28gbmVjZXNzYXJ5PGJyPg0KJmd0 OyB0byBiZSBleHBsaWNpdGx5IGRlZmluZWQuPGJyPg0KPGJyPg0KVG8gcHV0IGl0IGFub3RoZXIg d2F5LCB0aGUgaW5pdGlhbCBxdWVyeSBtZXNzYWdlIGlzIGl0c2VsZiB0aGUgc2lnbmFsIHRvPGJy Pg0KdGhlIHJlc3BvbmRlciB0byB0YWtlIHdoYXRldmVyIGluaXRpYWxpemF0aW9uIGFjdGlvbnMg YXJlIHJlcXVpcmVkIGZvcjxicj4NCml0IHRvIGJlZ2luIGdlbmVyYXRpbmcgdXNlZnVsIHJlc3Bv bnNlcy4gJm5ic3A7U3VjaCBhY3Rpb25zIG1heSBpbmNsdWRlPGJyPg0KJnF1b3Q7c3dpdGNoaW5n IG9uIHRoZSBjb3VudGluZyBmdW5jdGlvbiZxdW90OyBvciBhbnl0aGluZyBlbHNlLCBhbmQgYXJl PGJyPg0KaW1wbGVtZW50YXRpb24tZGVwZW5kZW50Ljxicj4NCjxicj4NCi1kPGJyPg0KPGJyPg0K Jmd0OyBCZXN0IFJlZ2FyZHMsPGJyPg0KJmd0OyBYaWFvIE1pbjxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IERhbiBGcm9zdCAmbHQ7ZGFuZnJvc3RAY2lzY28uY29tJmd0OyA8YnI+DQom Z3Q7IDIwMTEvMDIvMTYgMTk6MDI8YnI+DQomZ3Q7IDxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0 OyB4aWFvLm1pbjJAenRlLmNvbS5jbjxicj4NCiZndDsgs63LzTxicj4NCiZndDsgbXBsc0BpZXRm Lm9yZzxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgUmU6IFttcGxzXSBNUExTIFdHIExhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheS0wMTxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEhpIFhpYW8gTWluLDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUdWUsIEZlYiAx NSwgMjAxMSBhdCAxMToxNTozN0FNICswODAwLCB4aWFvLm1pbjJAenRlLmNvbS5jbiB3cm90ZTo8 YnI+DQomZ3Q7ICZndDsgSGkgQXV0aG9ycyw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEkgaGF2ZSBhIGNvbW1lbnQgb24gbG9zcyBtZWFzdXJlbWVudCBpbiB0aGlzIGRyYWZ0Ljxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWZ0ZXIgcmVjZWl2aW5nIExNIFF1ZXJ5IG1lc3Nh Z2UsIHRoZSByZXNwb25kZXIgd291bGQgcmVwbHkgTE08YnI+DQomZ3Q7ICZndDsgUmVzcG9uc2Ug bWVzc2FnZSB3aGljaCBzaG91bGQgdGFrZSBzb21lIGNvdW50ZXJzLiBCdXQgSSBjYW4ndA0KZmlu ZDxicj4NCiZndDsgJmd0OyB0ZXh0IGluIHRoaXMgZHJhZnQgdG8gZGVzY3JpYmUgaG93IHRoZSBj b3VudGluZyBmdW5jdGlvbiBhdCB0aGU8YnI+DQomZ3Q7ICZndDsgcmVzcG9uZGVyIGlzIHN3aXRj aGVkIG9uLiBJTUhPIG9uZSBtb3JlIGJpdC9mbGFnIHNob3VsZCBiZSBkZWZpbmVkDQombmJzcDtp bjxicj4NCiZndDsgJmd0OyB0aGUgTE0gUXVlcnkgbWVzc2FnZSB0byBhY3RpdmF0ZSBvciBkZWFj dGl2YXRlIHRoZSBjb3VudGluZyBmdW5jdGlvbjxicj4NCiZndDsgJmd0OyBhdCB0aGUgcmVzcG9u ZGVyLiAmbmJzcDtEaWQgSSBtaXNzIHNvbWV0aGluZz88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhl cmUgc2hvdWxkIGJlIG5vIG5lZWQgZm9yIGEgc2VwYXJhdGUgYWN0aXZhdGlvbiBmbGFnIG9yIG1l c3NhZ2UuDQombmJzcDtUaGU8YnI+DQomZ3Q7IGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4x LjEgZXhwbGFpbnMgd2hhdCB0aGUgcmVzcG9uZGVyIGNhbiBkbw0KaWYgaXQ8YnI+DQomZ3Q7IGlz IG5vdCB5ZXQgcmVhZHkgdG8gcHJvdmlkZSBjb3VudGVyIGRhdGEuICZuYnNwO0l0IGNhbiBzaW1w bHkgbm90DQpyZXNwb25kPGJyPg0KJmd0OyB1bnRpbCBpdCBpcyByZWFkeSwgb3IgaXQgY2FuIHJl c3BvbmQgd2l0aCBhbiBhcHByb3ByaWF0ZSBub3RpZmljYXRpb248YnI+DQomZ3Q7IGNvZGUgaW4g dGhlIG1lYW50aW1lICh0aGUgYXBwcm9wcmlhdGUgY29kZSBpbiB0aGlzIGNhc2Ugd291bGQgYmU8 YnI+DQomZ3Q7IE5vdGlmaWNhdGlvbiAtIEluaXRpYWxpemF0aW9uIEluIFByb2dyZXNzLCBkZXNj cmliZWQgaW4gU2VjdGlvbiAzLjEpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IC1kPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQmVzdCBSZWdhcmRz LCBYaWFvIE1pbjxicj4NCjwvZm9udD4NCjxicj4NCg== --=_alternative 00059E0E4825783F_=-- From wwwrun@rfc-editor.org Mon Feb 21 17:19:36 2011 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 848243A67AE; Mon, 21 Feb 2011 17:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 nW-JkIL3lv0F; Mon, 21 Feb 2011 17:19:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 9E0363A67D0; Mon, 21 Feb 2011 17:19:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DDD87E0742; Mon, 21 Feb 2011 17:20:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110222012018.DDD87E0742@rfc-editor.org> Date: Mon, 21 Feb 2011 17:20:18 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6138 on LDP IGP Synchronization for Broadcast Networks 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, 22 Feb 2011 01:19:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6138 Title: LDP IGP Synchronization for Broadcast Networks Author: S. Kini, Ed., W. Lu, Ed. Status: Informational Stream: IETF Date: February 2011 Mailbox: sriganesh.kini@ericsson.com, wenhu.lu@ericsson.com Pages: 9 Characters: 20161 Updates: RFC5443 I-D Tag: draft-ietf-mpls-ldp-igp-sync-bcast-06.txt URL: http://www.rfc-editor.org/rfc/rfc6138.txt RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From vivien.sterling@gmail.com Tue Feb 22 01:26:13 2011 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 8537C3A677E; Tue, 22 Feb 2011 01:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EN9ynjaHZMJ; Tue, 22 Feb 2011 01:26:12 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 059923A65A6; Tue, 22 Feb 2011 01:26:11 -0800 (PST) Received: by bwz12 with SMTP id 12so3447407bwz.27 for ; Tue, 22 Feb 2011 01:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=G2etffR/qjnXH9giDS7En2AQmiLTc9K6/oRRgvusS9A=; b=q93fpiJtv8SUL/75YA2DPVOZ7qip1ryJPP5Zqd7Pm+3B5KJ9RRbbV4w2cXCdjVl0IB spI4EvVvUjZB1nD7rDldVcmT7uN7xM+0vjsMS8nF8GFTAQJVhueCB8uqqZB4s9ybZcHk DkYC/wMqvgOp6Me42G0nlb++fj5ffpyW/zfAw= 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=NEwfpDjkJtfcO935VWzXB9QfKMnfuJoAWX65BTNLK11VPWJqEYWk8i9jte8ZSOgY3N p7BaUxM8msAZULGTI2WwvXHgvXq8XxawGnWmruXj5ihCH5qrUJJSLn1oyp4/IEyTwbM2 q+/TAzZ25DONtG+l+GtmleL2+WDLX1hUs+Vvs= MIME-Version: 1.0 Received: by 10.204.46.154 with SMTP id j26mr2195524bkf.134.1298366815068; Tue, 22 Feb 2011 01:26:55 -0800 (PST) Received: by 10.204.32.82 with HTTP; Tue, 22 Feb 2011 01:26:55 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 10:26:55 +0100 Message-ID: From: Vivien Sterling To: "pwe3@ietf.org" , "mpls@ietf.org" , "mpls-tp@ietf.org" Content-Type: multipart/alternative; boundary=0016e6d77f15cce387049cdb942e Subject: Re: [mpls] [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-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: Tue, 22 Feb 2011 09:26:13 -0000 --0016e6d77f15cce387049cdb942e Content-Type: text/plain; charset=ISO-8859-1 Yes, support. -- Cheers, Vivien On Thu, Feb 17, 2011 at 2:34 PM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > This email begins a working group last call for > draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. > > This is a very short draft but since there are other MPLS-TP-related last > calls going on concurrently, this will be a three-week last call. > > This WG LC will end of 11th March 2011. > > Please respond with any comments to the PWE3 mailing list. > > Regards, > > Matthew and Andy > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016e6d77f15cce387049cdb942e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, support. =A0 -- Cheers, Vivien On Thu, Feb 17, 2011 at 2:34 PM, Bocci, Matthew = (Matthew) <matthew.bocci@alcatel-lucent.com> wrote: This email begins a working grou= p last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. This is= a very short draft but since there are other MPLS-TP-related last calls going on concurrently, this will be a three-week last call. Th= is WG LC will end of 11th March 2011. Please respond with any commen= ts to the PWE3 mailing list. Regards, Matthew and Andy _______________________________________________ pwe3 mailing lis= t pwe3@ietf.org https://www.ietf.o= rg/mailman/listinfo/pwe3 --0016e6d77f15cce387049cdb942e-- From ehudd@orckit.com Tue Feb 22 02:32:24 2011 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 401CE3A6866; Tue, 22 Feb 2011 02:32:24 -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 vLuibPt9S1QK; Tue, 22 Feb 2011 02:32:23 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 048EA3A6845; Tue, 22 Feb 2011 02:32:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 12:32:40 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306897922@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Thread-Index: AcvOp2qo3CL3sSTlSLeLd/7Gd8zznQD1ENqg References: From: "Ehud Doron" To: "Bocci, Matthew (Matthew)" , Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-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: Tue, 22 Feb 2011 10:32:24 -0000 Support Ehud=A0=A0=A0 Doron System Architect=20 Orckit - Corrigent -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew) Sent: Thursday, February 17, 2011 3:35 PM To: pwe3@ietf.org Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 This email begins a working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. This is a very short draft but since there are other MPLS-TP-related = last calls going on concurrently, this will be a three-week last call. This WG LC will end of 11th March 2011. Please respond with any comments to the PWE3 mailing list. Regards, Matthew and Andy =20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From ietfc@btconnect.com Tue Feb 22 06:54:16 2011 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 719953A68E8 for ; Tue, 22 Feb 2011 06:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 qiNiCdPDnHIo for ; Tue, 22 Feb 2011 06:54:15 -0800 (PST) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 45F213A68AC for ; Tue, 22 Feb 2011 06:54:14 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr07.btconnect.com with SMTP id BWC18816; Tue, 22 Feb 2011 14:53:39 +0000 (GMT) Message-ID: <002601cbd297$4f667340$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20110209193001.19667.86167.idtracker@localhost> Date: Tue, 22 Feb 2011 14:48:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D63CDF3.00A4, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D63CE42.01E7,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-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: Tue, 22 Feb 2011 14:54:16 -0000 A minor quirk; the expansions given in s2.3 of this I-D for MIP and MEP are out of line with those used in other MPLS I-Ds. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Wednesday, February 09, 2011 8:30 PM Subject: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-02.txt > 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 On-demand Connectivity Verification and Route Tracing > Author(s) : N. Bahadur, et al. > Filename : draft-ietf-mpls-tp-on-demand-cv-02.txt > Pages : 17 > Date : 2011-02-09 > > LSP-Ping is an existing and widely deployed OAM mechanism for MPLS > LSPs. This document describes extensions to LSP-Ping so that LSP- > Ping can be used for On-demand Connectivity Verification of MPLS-TP > LSPs. This document also clarifies procedures to be used for > processing the related OAM packets. Further, it describes procedures > for using LSP-Ping to perform Connectivity Verification and Route > Tracing functions in MPLS-TP networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From eosborne@cisco.com Wed Feb 23 05:30:45 2011 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 1D1B63A69F2; Wed, 23 Feb 2011 05:30:45 -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 aJYXQCnFrRc5; Wed, 23 Feb 2011 05:30:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 722533A6A05; Wed, 23 Feb 2011 05:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=5507; q=dns/txt; s=iport; t=1298467890; x=1299677490; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XnO2/s5i8i8Tjmfs6H+jxS/1hETcv50MrWkXh+6oNTI=; b=VPEB5IeAVZ5sZigjeHRQHtqHSU7fyb/MCxuetU6lYSofOR0qyJZdVXkB KbynFS9mQXXvsQJVFT/9cauMr9jg7maRABV4gCYJK5gRZRocZ8eX9V6FT nVb+sTjzVqhHQQr0Y6I+7/77NbV5nD68rOcexJXw73zTVh7Q4b04QJtI3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBAJabZE2tJV2c/2dsb2JhbACXTY5Mc6A8m3EChVwEhQ2Fd4RT X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="218618650" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2011 13:31:29 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p1NDVTDw006349; Wed, 23 Feb 2011 13:31:29 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 07:31:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2011 07:31:15 -0600 Message-ID: In-Reply-To: A<76CD132C3ADEF848BD84D028D243C927AADCA1@szxeml508-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-linear-protection-04 Thread-Index: AcvDl10fqyGU6Z/HTcaxkW43UzP3eAFXdT1gAUNLvlAAUdyZIAEE1HVQ References: <4D4A9478.7050704@pi.nu> <021101cbc9c7$d7c8b140$875a13c0$@com> A<76CD132C3ADEF848BD84D028D243C927AADCA1@szxeml508-mbx.china.huawei.com> From: "Eric Osborne (eosborne)" To: "Jie Dong" , , X-OriginalArrivalTime: 23 Feb 2011 13:31:29.0612 (UTC) FILETIME=[FA5EB0C0:01CBD35D] Subject: Re: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-linear-protection-04 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, 23 Feb 2011 13:30:45 -0000 Hi Jie- Two comments inline with EO# > > As Yaacov has mentioned, we would like the PSC to send messages > > anyways in the chance that they may get through. This is explicitly > > noted in section 4.3.3.2: >=20 > > --- > > "When the domain is in unavailable state the PSC messages may not get > > through and therefore the protection is more dependent on the local > > inputs rather than the remote messages (that may not be received)." > > ---- > > > > Is that sufficient, or do you think we need additional text to > > reinforce this point? >=20 > [Jie] I acknowledge this purpose, and my further comment would be the same > as to Yaacov: what about sending this message through working path if it > is known the transmitting direction of the protection path is in failure? > In this way the message is still sent on only one path. EO# We discussed this early on when writing the draft, but decided against it. The concern was that providing multiple channels to send a message on could open us up to complications and race conditions. What happens, for example, if you get different messages on the W and P SPMEs, for example? I see your point about only sending the message on one path, but there are some types of failure where one end could think an SPME is down and the other might not. What happens if the rx node thinks the P SPME is down (and thus expects messages on the W SPME), but the tx node thinks the P SPME is up, and thus does not send anything on the W SPME? Bottom line is that there are always going to be ugly cases we can't easily resolve, especially with the constraint that this protocol must be fairly simple; the more dynamic it is, the longer it will take to react to a failure, and in a protection protocol that's not something we can afford. > > > 8. Section 4.3.3, I go through this part fast, a general question is: > > are > > > the PSC operations for 4 different protection types identical ? In > > this > > > section there is no description about operation of each specific > > > protection type, but to my understanding, there may be different > > > operations, e.g., for bidirectional 1:1 protection, the end point > > > may > > need > > > to switch the sink selector and transmitting bridge simultaneously > > > according to some input, but for unidirectional 1:1 the end point > > > may > > only > > > need to switch the transmitting bridge OR the sink selector. And the > > PSC > > > message sent may also be different for different protection types. > > (Please > > > correct me if there is anything wrong with this thought). > > > > > > PSC is not, in my view, tightly coupled to the four protection types. > > That is to say, PSC is a tool that allows the device vendor and > > network operator to build protection in an MPLS-TP network. This > > protection can be one of the four protection types you describe, but > > PSC is merely a protocol to accomplish the end goal. It may, for > > example, be possible in the future to use PSC to build one or more > > types of 1:n protection; when and if this is done, the message types > > would likely remain the same as they are now. > > >=20 > I agree that PSC protocol can be used for all these protection types, and > may also be applicable to 1:n protection, but for each protection type the > state machine may be slightly different. The draft-tp-cc-cv-rdi also works > in this way. The message types are likely the same, but some fields in the > message may be different. EO# Can you be more specific? Which field(s) would be different? What functionality would these fields provide that can't be provided with PSC as defined in our draft? As part of the PSC work we looked at other protection protocols (you may notice a striking similarity to APS), and I didn't see any type-specific redefinition of fields in those. eric >=20 >=20 > Best regards, > Jie >=20 > > > > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] > > > > On Behalf Of Loa Andersson > > > > Sent: Thursday, February 03, 2011 7:42 PM > > > > To: mpls-tp@ietf.org; mpls@ietf.org > > > > Cc: ahmpls-tp@lists.itu.int > > > > Subject: [mpls-tp] mpls wg last call on > > > draft-ietf-mpls-tp-linear-protection-04 > > > > > > > > Working Group, > > > > > > > > this is to start a four week working group last call on "MPLS-TP > > > > Linear Protection" (draft-ietf-mpls-tp-linear-protection-04). > > > > > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > > > > > This working group last call ends on February 28, 2011. > > > > > > > > > > > > > > > > Loa, George and Ross > > > > > > > > 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 > > > > _______________________________________________ > > > > 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 takeda.tomonori@lab.ntt.co.jp Wed Feb 23 20:39:00 2011 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 8D4FC3A6968; Wed, 23 Feb 2011 20:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 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, 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 lGGJG-92sssF; Wed, 23 Feb 2011 20:38:59 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 53EAF3A6953; Wed, 23 Feb 2011 20:38:59 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p1O4dlWD007905; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0B17065F9; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 046BB65F1; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p1O4dYV4001648; Thu, 24 Feb 2011 13:39:46 +0900 Message-ID: <4D65E0F6.7050004@lab.ntt.co.jp> Date: Thu, 24 Feb 2011 13:39:18 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [mpls] iPOP 2011 submission deadline extended to March 4 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, 24 Feb 2011 04:39:00 -0000 (Apologies if you receive multiple copies of this message.) CCAMP, MPLS, MPLS-TP and PCE subscribers, Please find below iPOP 2011 CFP with the extended deadline (March 4th). Tomonori Takeda ------------------------------------------------------------- Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2011 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ 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 4, 2011 (extended) Notification of acceptance: April 4, 2011 Submission deadline of final presentation slides: April 22, 2011 The Technical Program Committee for iPOP 2011 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$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ---------------------------------------------------------------- From ietfc@btconnect.com Thu Feb 24 02:17:51 2011 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 B1A353A6846 for ; Thu, 24 Feb 2011 02:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FAKE_REPLY_C=2.012] 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 aWFHgZKyJAuL for ; Thu, 24 Feb 2011 02:17:50 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 7723B3A6A5D for ; Thu, 24 Feb 2011 02:17:49 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2bthomr14.btconnect.com with SMTP id BUR82608; Thu, 24 Feb 2011 10:18:36 +0000 (GMT) Message-ID: <000901cbd403$35fc2ae0$4001a8c0@gateway.2wire.net> From: "t.petch" To: Date: Thu, 24 Feb 2011 10:14:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D66307B.01EC, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4D66307D.029E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-oam-framework-11.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, 24 Feb 2011 10:17:51 -0000 Some thoughts for AUTH48 s.1 "OAM packets can be distinguished from the used data packets" Perhaps 'user' s3.4 Any MPLS-TP node silently discards any OAM packet received with an expired TTL and that it is not addressed to any of its MIPs or MEPs 'or which is not addressed'? s.4 "Note that there are no constrains imposed" Perhaps 'constraints' s.5.1.2 "with a consequent wrong traffic delivering." Perhaps 'with a consequence of delivering the wrong traffic.' Tom Petch ----- Original Message ----- From: To: Cc: Sent: Friday, February 11, 2011 11:00 AM Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-framework-11.txt > > 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 : Operations, Administration and Maintenance Framework for MPLS-based Transport Networks > Author(s) : D. Allan, et al. > Filename : draft-ietf-mpls-tp-oam-framework-11.txt > Pages : 65 > Date : 2011-02-11 > > The Transport Profile of Multi-Protocol Label Switching > (MPLS-TP) is a packet-based transport technology based on the > MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data > plane architectures. > > This document describes a framework to support a comprehensive > set of Operations, Administration and Maintenance (OAM) > procedures that fulfill the MPLS-TP OAM requirements for fault, > performance and protection-switching management and that do not > rely on the presence of a control plane. > > This document is a product of a joint Internet Engineering Task > Force (IETF) / International Telecommunications 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 as defined by the ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-11.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. > > > > From nick.delregno@verizon.com Fri Feb 25 07:20:43 2011 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 ED4493A68F1; Fri, 25 Feb 2011 07:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL4tXTjP8NWM; Fri, 25 Feb 2011 07:20:36 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 531B33A682C; Fri, 25 Feb 2011 07:20:35 -0800 (PST) Received: from omzismtp02.vzbi.com ([unknown] [165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LH60070WINRV2A0@firewall.verizonbusiness.com>; Fri, 25 Feb 2011 15:21:28 +0000 (GMT) Received: from omzismtp02.vzbi.com ([unknown] [127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LH600M0HINR8X00@omzismtp02.vzbi.com>; Fri, 25 Feb 2011 15:21:27 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LH600MC5INR5S00@omzismtp02.vzbi.com>; Fri, 25 Feb 2011 15:21:27 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 15:21:27 +0000 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBD4FF.AB5ADCFF" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 Feb 2011 15:21:19 +0000 Message-id: <14584D6EE26B314187A4F68BA206060006B14EB7@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: LAST CHANCE!! PW/VCCV User Implementation Survey Closes Today @ 5PM CST Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzADxnTEgADBYkhg References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 25 Feb 2011 15:21:27.0237 (UTC) FILETIME=[ABAFDF50:01CBD4FF] Subject: [mpls] LAST CHANCE!! PW/VCCV User Implementation Survey Closes Today @ 5PM CST 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, 25 Feb 2011 15:20:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD4FF.AB5ADCFF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All: =20 This is the last day to participate in the PW/VCCV User Implementation Survey. The survey closes today at 5PM CST. I will aggregate the responses and provide the results via a draft and presentation in Prague. =20 We have 18 responses so far. Thank you to all who have provided this valuable information! =20 Thanks, Nick =20 =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 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBD4FF.AB5ADCFF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All: This is the = last day to participate in the PW/VCCV User Implementation Survey. = The survey closes today at 5PM CST. I will aggregate the responses = and provide the results via a draft and presentation in = Prague. We have 18 responses so far. Thank you to all = who have provided this valuable information! Thanks, Nick =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 All: Per the = direction of the PWE3 working group, beginning in IETF77 and reinforced = in IETF78, the PWE3 working group is conducting a Service Provider = implementation survey related to: -          = Pseudowire Encapsulations -          = Control Word Support -          = Control Word Use -          = VCCV Control Channel Support -          = VCCV Control Channel Use http://www.surveymonkey.com/s= /pwe3 This is a short survey directed toward Service = Providers who currently operate networks using any of the defined PWE3 = encapsulations. The results of this survey will be used to = determine the direction of the Control Word support in current and = future encapsulations as well as solutions to VCCV interoperability = challenges. We sincerely urge all service providers to = participate. We ask that all equipment providers encourage = participation by their Service Provider customers. The more = feedback we receive, the better view of the existing network we can have = on which to base going-forward direction. If you have = any questions, regarding the survey, especially of a technical nature, = please contact me. If you have non-technical questions, feel free = to reach out to the PWE3 WG chairs and myself. The results = of the survey will be aggregated and shared at a high level. No = low-level details of network implementations will be shared. All = participant’s responses will remain private, if not = anonymous. All responses will require a valid email address to = help ensure the survey’s validity. Thanks, Nick Christopher N. “Nick” DelRegno, = PMTS CNT, Ethernet Network Architecture & = Design 400 International Pkwy Richardson, TX = 75081 Tel: 972-729-3411 Email: = Nick.DelRegno@verizon.com ------_=_NextPart_001_01CBD4FF.AB5ADCFF-- From lesnix@gmail.com Sun Feb 27 01:22:26 2011 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 C459A3A69DC for ; Sun, 27 Feb 2011 01:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 zaKzs912-mKm for ; Sun, 27 Feb 2011 01:22:25 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7674F3A69D9 for ; Sun, 27 Feb 2011 01:22:25 -0800 (PST) Received: by fxm15 with SMTP id 15so2941002fxm.31 for ; Sun, 27 Feb 2011 01:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=So+L9eSMk5/am75/9DIMAhSjZOo3lBc/TrZIK/3WkuE=; b=oMiyj2y3EPAp9bQSLnEQdsI44WmyeX77qhda/Te34mRQaCPEq+iHMAYab7AcMWP+tO aLGVOBRnH1sXOqCqMV5+3srWskJGZ/sKKsssyq/NG3P1INCiiBdZCmOMDCZ7CXv9N3n/ oZbxy9CFjpaEIuKZXZ9f9Lbq8CYZXgmEzJWbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=Sd7swA0uvrD+0Ta90M+cp9KvM5b+9crK0iSvCct7lWXH/zyrWEyiyz5TMhXgo8St8U 6TuF5uT97FX7oOQz20Y9pu1BRmZ2q+jwEVnTfnH0/BhNxyfTmVE4IabdbTsFBPkMvyJW E8L/u9iE2H1XNYemE/AleN1iSeJAHp3mQSWLg= Received: by 10.223.125.196 with SMTP id z4mr4862635far.124.1298798602075; Sun, 27 Feb 2011 01:23:22 -0800 (PST) Received: from [192.168.88.144] (home.lesnix.ru [80.251.120.67]) by mx.google.com with ESMTPS id 11sm1015372faw.44.2011.02.27.01.23.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 01:23:20 -0800 (PST) Message-ID: <4D6A1803.6040001@gmail.com> Date: Sun, 27 Feb 2011 12:23:15 +0300 From: Egor Zimin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ina Minei , Bob Thomas Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ofeoktistov@amt.ru, dginsburg@gmail.com, amolodkin@amt.ru Subject: [mpls] AddressList TLV in MAC Address Withdraw message 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, 27 Feb 2011 09:22:26 -0000 Hi Ina, Few days ago we had a deal with an interesting case of LDP interoperability. The root cause of our problem was the presence of empty "AddressList" TLV in LDP MacWithdraw message. Vendor "C" inserts this TLV in every MAC Withdraw message even if there are no addresses to withdraw. Their explanation: --- "RFC 4762 introduces the MAC List TLV as an optional TLV to the Address Withdraw message, used to withdraw MAC addresses. The addition of this optional TLV to the Address Withdraw message does not replace the Address List TLV. While it would be perfectly acceptable to withdraw both IPV4 addresses as well as MAC addresses in the same Address Withdraw message, it's not always the case that there is a need to withdraw IPV4 addresses at the same time that there is a need to withdraw MAC addresses. Also, given that the Address List TLV can not be omitted when sending an Address Message that withdraws MAC Addresses, the logical conclusion is to send an empty Address List TLV in the Address Withdraw message, along with the MAC List TLV. The empty address list TLV, while not explicitly specified, is not explicitly prohibited either. It would have been better had the RFCs been explicit on this subject, but the above logic is the best solution given the way that the RFCs are written." --- Vendor "J" implies, that "AddressList" TLV is not mandatory in MACWithdraw message. They omit this TLV in their messages. However, in addition, they perform a strange check for minimal TLV length in all incoming messages. Because of this check empty AddressList TLV (with length=2) considered as "Malformed TLV" and the session goes down. I haven't found any mention about checking for "too short TLV" in RFC 5036. However, point #11 in chapter "7. Changes from RFC 3036" states: --- 11. Added case for TLV length too short in the specification for handling malformed TLVs. --- It would be great to know your opinion about these questions: 1. The presence of empty AddressList TLV in MACWithdraw message. Is it mandatory or optional? 2. Checking incoming TLVs for minimal length. Is it correct behavior ? IMHO, it should be remembered about Jon Postel's law: "Be liberal in what you accept, and conservative in what you send" -- Best regards, Egor Zimin From zhang.fei3@zte.com.cn Sun Feb 27 17:33:12 2011 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 C417A3A6961; Sun, 27 Feb 2011 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Q9JuQv6RYP2F; Sun, 27 Feb 2011 17:33:11 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D3CD13A695E; Sun, 27 Feb 2011 17:33:10 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952043691617; Mon, 28 Feb 2011 09:28:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47420.2043691617; Mon, 28 Feb 2011 09:24:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1S1Xsf6038947; Mon, 28 Feb 2011 09:33:54 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: ccamp@ietf.org, mpls@ietf.org, mpls-tp@ietf.org MIME-Version: 1.0 X-KeepSent: 3D2BCB7D:7BE0C902-48257845:00045755; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 28 Feb 2011 09:34:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-28 09:33:53, Serialize complete at 2011-02-28 09:33:53 Content-Type: multipart/alternative; boundary="=_alternative 0008966748257845_=" X-MAIL: mse01.zte.com.cn p1S1Xsf6038947 Subject: [mpls] draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03 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, 28 Feb 2011 01:33:13 -0000 This is a multipart message in MIME format. --=_alternative 0008966748257845_= Content-Type: text/plain; charset="US-ASCII" Dear All We just updated the document about the creating of associated bidirectional LSPs, and below is the link: http://tools.ietf.org/id/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03.txt Compared with last version, the main changes are about the section of asymmetric associated bidirectional LSP: We used the object UPSTREAM_TSPEC to trigger the peer end to set up the reverse unidirectional LSP in last version, however the application scenario defined in http://tools.ietf.org/html/draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 is different from here. So a new object called REVERSE_TSPEC is used to replace the UPSTREAM_TSPCE object in this version. The other revisions are structural and editoral in nature, such as complementing more considerations about security, adding one sub-section of informativereference, temporarily moving George from the position of co-authors.... The authors would like to have more feedback from the mailing list before pushing this work forward. Grateful if you could review the document and post comments on the mailing list. Thanks and best regards Fei --=_alternative 0008966748257845_= Content-Type: text/html; charset="US-ASCII" Dear All We just updated the document about the creating of associated bidirectional LSPs, and below is the link: http://tools.ietf.org/id/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03.txt Compared with last version, the main changes are about the section of asymmetric associated bidirectional LSP: We used the object UPSTREAM_TSPEC to trigger the peer end to set up the reverse unidirectional LSP in last version, however the application scenario defined in http://tools.ietf.org/html/draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 is different from here. So a new object called REVERSE_TSPEC is used to replace the UPSTREAM_TSPCE object in this version. The other revisions are structural and editoral in nature, such as complementing more considerations about security, adding one sub-section of informativereference, temporarily moving George from the position of co-authors.... The authors would like to have more feedback from the mailing list before pushing this work forward. Grateful if you could review the document and post comments on the mailing list. Thanks and best regards Fei --=_alternative 0008966748257845_=-- From venkatflex@gmail.com Sun Feb 27 19:19:45 2011 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 2A1943A6A6D; Sun, 27 Feb 2011 19:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 wvJ-t14-7DYN; Sun, 27 Feb 2011 19:19:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 865233A6998; Sun, 27 Feb 2011 19:19:41 -0800 (PST) Received: by qwh6 with SMTP id 6so2815231qwh.31 for ; Sun, 27 Feb 2011 19:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=U8jMtV6i+2/vlAluEIVrpkK2gvhV9NJjQOpbJTQxSdU=; b=B0Rj8HJq4KRaAATqyjr6334TRwzH1LNdJr1ge20/iCGR07A2i6EQFlAj8HQlALjql9 Cbz5sQyqt7cyKGfiTg6Hi8qWxS2y5hr97MJgsmvtO8AI+8snKkc4xkf1Kyc7zYF0SmrV 7efnzLg8FyTO0V2R3/4QsdWm561u3N75eyz7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wtqpY0aGCLU9BaU2fSRZj3XRTZ9uzKWYMLq/vinoEV5/goKrWF2vUwv1t1cZlWcXj4 jYpFvmYmt9xkjAJasraJeo0sXOIcBS+qdtdhelesZkGC90i7lEbIwvmECcZTC7/7XP8g Dv5yeaIVVN3omaRbhHRTX4phgx6BQs5/VkAnI= MIME-Version: 1.0 Received: by 10.224.28.147 with SMTP id m19mr4073011qac.255.1298863240321; Sun, 27 Feb 2011 19:20:40 -0800 (PST) Received: by 10.224.20.71 with HTTP; Sun, 27 Feb 2011 19:20:40 -0800 (PST) Date: Sun, 27 Feb 2011 22:20:40 -0500 Message-ID: From: venkatesan mahalingam To: mpls , mpls-tp@ietf.org Content-Type: multipart/alternative; boundary=0015175cb07c0d1b76049d4f2a5f Subject: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review 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, 28 Feb 2011 03:19:45 -0000 --0015175cb07c0d1b76049d4f2a5f Content-Type: text/plain; charset=ISO-8859-1 Hi Team, We have uploaded the MPLS-TP TE MIB draft last week into IETF repository. This document provides an enhancement to the RFC-3812 for managing the Traffic Engineering tunnels for MPLS based transport networks in IP and Non-IP operator environments. Please review the draft and provide your valuable comments/suggestions. A URL of the draft is: http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt -- Best Regards, Venkatesan Mahalingam. --0015175cb07c0d1b76049d4f2a5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Team,We have uploaded the MPLS-TP TE MIB draft last week into IETF = repository. This document provides an enhancement = to the RFC-3812 for managing the Traffic Engineering tunnels=A0 for MPLS based transport networks in IP and Non-IP operator environments. Please review the draft and provide your valuable c= omments/suggestions. A URL of the draft is: = http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt -- <= br> Best Regards, Venkatesan Mahalingam. --0015175cb07c0d1b76049d4f2a5f-- From tnadeau@lucidvision.com Mon Feb 28 04:41:26 2011 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 064F03A6B2E for ; Mon, 28 Feb 2011 04:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.627, 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 mDbtcAudrwp1 for ; Mon, 28 Feb 2011 04:41:25 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id F3E273A6B1F for ; Mon, 28 Feb 2011 04:41:24 -0800 (PST) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DCB4F1A3371D; Mon, 28 Feb 2011 07:42:24 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary=Apple-Mail-9-614682341 Date: Mon, 28 Feb 2011 07:42:25 -0500 Message-Id: <8FBF21A0-222C-4D6A-A3A1-E94F65A08E3B@lucidvision.com> To: "mpls@ietf.org MPLS" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: "Sam.Aldrin@huawei.com Aldrin" Subject: [mpls] MPLS-TP MIBs 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, 28 Feb 2011 12:41:26 -0000 --Apple-Mail-9-614682341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I just wanted to send a note to the WG asking that people please = review a new draft we put together around adding SNMP MIB support for = MPLS-TP functions. The MIB is designed to leverage the existing = MPLS/PWE3 MIBs and extend them.=20 http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt --Tom --Apple-Mail-9-614682341 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi, I just wanted to send a note to the WG asking that people please review a new draft we put together around adding SNMP MIB support for MPLS-TP functions. The MIB is designed to leverage the existing MPLS/PWE3 MIBs and extend them. http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt --Tom --Apple-Mail-9-614682341-- From venkatflex@gmail.com Mon Feb 28 05:38:21 2011 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 5A53F3A6BF9; Mon, 28 Feb 2011 05:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 VCSOFuFoz+yW; Mon, 28 Feb 2011 05:38:20 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id B0DE23A6BF8; Mon, 28 Feb 2011 05:38:19 -0800 (PST) Received: by qyk29 with SMTP id 29so2048996qyk.10 for ; Mon, 28 Feb 2011 05:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hb2yrX6eVaKrJd+LYR5f0+/q8vk1q91WAT21W6JSCRc=; b=I/unJ3oNwm1PQG3Ob9Gw9hQ8AP1LAt9dwuDChr/yTYmxvuQnojgZbCYYzp8HlSUeb2 59iX/I2nz3hBIyAdn9CiQyXHf50/7ZMU01hQHxMPGTdgeIpD3c0xxhURQsfGbafvlkln z9sLPQ0Wwz9rJ4CQt+vU+WB3N6b2SLjkQYNTc= 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=GakKRG20ffvgOlvI7O5LyOazlxM/gLOoytWmqPSWjlZdLexcpqLMkZyahCsaLyK4bs vsT8etlRKrirwM4iH9IgFW1AkzgBj/ABekDy+sVVxR8NFG6FE6/kPLU8WWuc5jhhULVE XYBd7zGgdg9ufQdOlQPG4cc4blT4cwPyDv+c0= MIME-Version: 1.0 Received: by 10.224.20.11 with SMTP id d11mr2420881qab.205.1298900359526; Mon, 28 Feb 2011 05:39:19 -0800 (PST) Received: by 10.224.20.71 with HTTP; Mon, 28 Feb 2011 05:39:19 -0800 (PST) In-Reply-To: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE737@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE737@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Date: Mon, 28 Feb 2011 08:39:19 -0500 Message-ID: From: venkatesan mahalingam To: "Vijayanand C - ERS, HCL Tech" Content-Type: multipart/alternative; boundary=0015175cb83e873b92049d57cedd Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review 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, 28 Feb 2011 13:38:21 -0000 --0015175cb83e873b92049d57cedd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Vijay, Thanks for your review. Please find the responses inline. Regards, Venkat. On Mon, Feb 28, 2011 at 2:55 AM, Vijayanand C - ERS, HCL Tech < vijayc@hcl.com> wrote: > Hi venkatesh and authors, > > This draft specifies that for bidirectional LSPs there will be two > cross-connects with different mplsXCIndex but unique mplsXCLspId. > > VM>> There is a typo in the draft, there should be two cross-connects wit= h same mplsXCIndex for co-routed bidirectional tunnel. > Are you saying thsat the mplsXCLspId has to be globally unique ( rfc3813 > says it=92s the mplsLSPID which rfc 3811 says is the two byte LSPID in t= he > case of RSVP-TE LSPs) and be used to tie up the forward and reverse cross > connect entries ? > > > > You have also used the mplsXCLspId in the mplsTunnelXCPointer filed of th= e mplsTunnelTable > > (mplsTunnelXCPointer =3D > > mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.12, > > ) > > The XCPointer usually holds the index of the XC entry. ( > xcindex,insegindex,outsegindex). For mpls-tp bidirectional LSPs are you > mandating the use of mplsXClspid in the XCPointer implicitly makign it on= e > of the index fields of the XCEntry ? > > > VM>> No, we are not implicitly making mplsXClspid as the index field. We point any accessible XC mib object into an mplsTunnelXCPointer i.e associat= e any forward or reverse XC entry to an tunnel entry to get the XC index. Thi= s XC index will be used to fetch the forward and reverse XC informations for co-routed bi-directional tunnel. Hope this helps. Regards > > Vijay > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *venkatesan mahalingam > *Sent:* Monday, February 28, 2011 8:51 AM > *To:* mpls; mpls-tp@ietf.org > *Subject:* [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review > > > > Hi Team, > > We have uploaded the MPLS-TP TE MIB draft last week into IETF repository. > > > > This document provides an enhancement to the RFC-3812 for managing the > Traffic Engineering tunnels > > for MPLS based transport networks in IP and Non-IP operator environments. > > > > Please review the draft and provide your valuable comments/suggestions. > > > > A URL of the draft is: > > http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt > > > -- > Best Regards, > Venkatesan Mahalingam. > > ------------------------------ > ::DISCLAIMER:: > > -------------------------------------------------------------------------= ---------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect > the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modificatio= n, > distribution and / or publication of > this message without the prior written consent of the author of this e-ma= il > is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > > -------------------------------------------------------------------------= ---------------------------------------------- > --=20 Best Regards, Venkatesan Mahalingam. --0015175cb83e873b92049d57cedd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Vijay,Thanks for your review. Please find = the responses inline. Regards, Venkat. On Mon, Feb 28, 2011 at 2:55 AM, Vijayanand C = - ERS, HCL Tech <vij= ayc@hcl.com> wrote: Hi ve= nkatesh and authors, This = draft specifies that for bidirectional LSPs there will be two cross-connect= s with different mplsXCIndex but unique mplsXCLspId. VM>> There is a typo in the draft= , there should be two cross-connects with same mplsXCIndex for co-routed bi= directional tunnel. =A0 Are you saying thsat the mplsXCLspId has to be global= ly unique ( rfc3813 says it=92s the mplsLSPID =A0which rfc 3811 says is the= two byte LSPID in the case of RSVP-TE LSPs) and be used to tie up the forward and reverse cross connect = entries ? =A0 You have also used the = mplsXCLspId in the mplsTunnelXCPointer filed of the mplsTunnelTable = (mplsTunnelXCPoi= nter=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1= 2, ) =A0Th= e XCPointer usually holds the index of the XC entry. ( xcindex,insegindex,o= utsegindex). For mpls-tp bidirectional LSPs are you mandating the use of mp= lsXClspid in the XCPointer implicitly makign it one of the index fields of the XCEnt= ry ? =A0 VM>> No, we are not implicitly= making mplsXClspid as the index field. We point any accessible XC mib obje= ct into an mplsTunnelXCPointer i.e associate any forward or reverse XC entr= y to an tunnel entry to get the XC index. This XC index will be used to fet= ch the forward and reverse XC informations for co-routed bi-directional tun= nel. Hope this helps. Regar= ds Vijay= From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of venkatesan mahalingam Sent: Monday, February 28, 2011 8:51 AM To: mpls; mpls= -tp@ietf.org Subject: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review =A0 Hi Team, We have uploaded the MPLS-TP TE MIB draft last week = into IETF repository. =A0 This document provides an enhancement to the RFC-381= 2 for managing the Traffic Engineering tunnels=A0 for MPLS based transport networks in IP and Non-IP o= perator environments. =A0 Please review the draft and provide your valuable co= mments/suggestions. =A0 A URL of the draft is: http://tools.ietf.org/id/draft-vkst-mpl= s-tp-te-mib-00.txt -- Best Regards, Venkatesan Mahalingam. ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- -- Best Regards, Venkat= esan Mahalingam. --0015175cb83e873b92049d57cedd-- From wwwrun@core3.amsl.com Mon Feb 28 13:13:18 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F11453A6842; Mon, 28 Feb 2011 13:13:17 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110228211317.F11453A6842@core3.amsl.com> Date: Mon, 28 Feb 2011 13:13:17 -0800 (PST) Cc: Huub.van.Helvoort@huawei.com, mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS281 - Comments on the IETF MPLS working group last call on "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-03 (ref #050.01)" (ref #050.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:13:18 -0000 Title: LS281 - Comments on the IETF MPLS working group last call on "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-03 (ref #050.01)" (ref #050.02) Submission Date: 2011-02-28 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1022 Please reply by 2011-04-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Huub.van.Helvoort@huawei.com Purpose: For action Body: Attachment(s): LS281 - Comments on the IETF MPLS working group last call on "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-03 (ref #050.01)" (ref #050.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1193.pdf) From wwwrun@core3.amsl.com Mon Feb 28 13:20:50 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0D0973A6CAF; Mon, 28 Feb 2011 13:20:49 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110228212050.0D0973A6CAF@core3.amsl.com> Date: Mon, 28 Feb 2011 13:20:50 -0800 (PST) Cc: Huub.van.Helvoort@huawei.com, mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS289 - Reply to the IETF MPLS working group last call on "MPLS Fault Management OAM (ref #047.01)" (ref #047.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:20:50 -0000 Title: LS289 - Reply to the IETF MPLS working group last call on "MPLS Fault Management OAM (ref #047.01)" (ref #047.02) Submission Date: 2011-02-28 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1023 Please reply by 2011-04-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Huub.van.Helvoort@huawei.com Purpose: For action Body: Attachment(s): LS289 - Reply to the IETF MPLS working group last call on "MPLS Fault Management OAM (ref #047.01)" (ref #047.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1194.pdf)