From loa@pi.nu Tue Nov 1 10:50:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA31F0C38 for ; Tue, 1 Nov 2011 10:50:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FwhECg6yxs1 for ; Tue, 1 Nov 2011 10:50:07 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id EC8DA1F0C41 for ; Tue, 1 Nov 2011 10:50:06 -0700 (PDT) Received: from [10.154.180.254] (unknown [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 493422A8004; Tue, 1 Nov 2011 18:34:55 +0100 (CET) Message-ID: <4EB02DBD.5060305@pi.nu> Date: Tue, 01 Nov 2011 10:34:53 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , George Swallow , Ross Callon Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:50:07 -0000 Working Group, this is to start a two week poll to see if there is support to make draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Tue Nov 15. /Loa for the mpls wg 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 ping@pingpan.org Tue Nov 1 10:58:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5A21F0C68 for ; Tue, 1 Nov 2011 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udZ2Hb-FUDJo for ; Tue, 1 Nov 2011 10:58:24 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with SMTP id DB9A31F0C3B for ; Tue, 1 Nov 2011 10:58:23 -0700 (PDT) Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP; Tue, 01 Nov 2011 10:58:23 PDT Received: by mail-qy0-f180.google.com with SMTP id 38so789813qyl.18 for ; Tue, 01 Nov 2011 10:56:41 -0700 (PDT) Received: by 10.229.19.200 with SMTP id c8mr118432qcb.71.1320170199852; Tue, 01 Nov 2011 10:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.70 with HTTP; Tue, 1 Nov 2011 10:55:57 -0700 (PDT) In-Reply-To: <4EB02DBD.5060305@pi.nu> References: <4EB02DBD.5060305@pi.nu> From: Ping Pan Date: Tue, 1 Nov 2011 10:55:57 -0700 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=0016364eea12ce253904b0b01322 Cc: "mpls@ietf.org" , Ross Callon , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:58:24 -0000 --0016364eea12ce253904b0b01322 Content-Type: text/plain; charset=ISO-8859-1 Support On Tue, Nov 1, 2011 at 10:34 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-**and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg 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 > --0016364eea12ce253904b0b01322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

On Tue, Nov 1, 2011 at 10:34 AM, = Loa Andersson <loa@pi.nu<= /a>> wrote:
Working Group,

this is to start a two week poll to see if there is support to make
draft-fang-mpls-tp-use-cases-and-design an mpls working group draft.=

Pleased send your comments to the mpls working group mailing list
(mpls@ietf.org).

This poll ends Tue Nov 15.

/Loa
for the mpls wg chairs
--


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

--0016364eea12ce253904b0b01322-- From jeff.tantsura@ericsson.com Tue Nov 1 11:34:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAB711E8120 for ; Tue, 1 Nov 2011 11:34:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWBXjHRa5bDf for ; Tue, 1 Nov 2011 11:34:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 99E6711E810C for ; Tue, 1 Nov 2011 11:34:19 -0700 (PDT) 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 pA1IXq5J016192; Tue, 1 Nov 2011 13:33:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 1 Nov 2011 14:33:50 -0400 From: Jeff Tantsura To: Loa Andersson Date: Tue, 1 Nov 2011 14:33:51 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYxMyHaLN6qU5BSfuexUpmxX6MQA== Message-ID: <76E15469-CA7C-42D0-BD25-16CD857DAB3C@ericsson.com> References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Ross Callon , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:34:20 -0000 Very useful document, support Regards, Jeff On Nov 1, 2011, at 10:50 AM, "Loa Andersson" wrote: > Working Group, >=20 > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg chairs > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Tue Nov 1 12:30:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199E51F0CB0 for ; Tue, 1 Nov 2011 12:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtFupgZAUvBQ for ; Tue, 1 Nov 2011 12:30:20 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5A81F0C9D for ; Tue, 1 Nov 2011 12:30:20 -0700 (PDT) Received: from [10.100.68.175] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id D71D11F388F2; Tue, 1 Nov 2011 15:27:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4EB02DBD.5060305@pi.nu> Date: Tue, 1 Nov 2011 15:27:31 -0400 Content-Transfer-Encoding: 7bit Message-Id: <294AD1B0-B406-4995-896D-9EFA7B364DF7@lucidvision.com> References: <4EB02DBD.5060305@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1251.1) Cc: "mpls@ietf.org" , Ross Callon , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:30:21 -0000 +1 On Nov 1, 2011, at 1:34 PM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg 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 nurit.sprecher@nsn.com Tue Nov 1 15:08:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F111F0C4E for ; Tue, 1 Nov 2011 15:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POJDkI83Xpzd for ; Tue, 1 Nov 2011 15:08:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B87511F0C4C for ; Tue, 1 Nov 2011 15:08:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA1M8Str009447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Nov 2011 23:08:28 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA1M8NEI006631; Tue, 1 Nov 2011 23:08:28 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 23:08:23 +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: Tue, 1 Nov 2011 23:08:22 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326404AB8265@DEMUEXC014.nsn-intra.net> In-Reply-To: <4EB02DBD.5060305@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvmqCvOE+n3MQSlSRaUPTrUdbWAAInhLg References: <4EB02DBD.5060305@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , "MPLS-TP ad hoc team" , , "George Swallow" , "Ross Callon" X-OriginalArrivalTime: 01 Nov 2011 22:08:23.0556 (UTC) FILETIME=[C5CE3C40:01CC98E2] Subject: Re: [mpls] [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:08:33 -0000 Yes/support -----Original Message----- From: ext Loa Andersson [mailto:loa@pi.nu]=20 Sent: Tuesday, November 01, 2011 7:35 PM To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George Swallow; Ross Callon Subject: [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design Working Group, this is to start a two week poll to see if there is support to make draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Tue Nov 15. /Loa for the mpls wg chairs --=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 From venkatflex@gmail.com Tue Nov 1 15:10:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB35511E8132 for ; Tue, 1 Nov 2011 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=3.648, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KvMUmQtB0RZ for ; Tue, 1 Nov 2011 15:10:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B011E8136 for ; Tue, 1 Nov 2011 15:10:33 -0700 (PDT) Received: by wwi36 with SMTP id 36so2464612wwi.13 for ; Tue, 01 Nov 2011 15:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=JQGIcl/WRH99oR6B6DkFndqfUgMBJpMd9egToCOzCRo=; b=T7M31sGdk3ToMw0gWyT/A8nfYl8IMdPWmNteAAVOC8doJAbcpnEQdx71FAHO4fZPCW +H7cqJXdZrkqw4rrbhkeHGem8T8bqkO4GapSgo5a6o2dTq4zjNDzOMKCD2SHla8LQiML gViQHsBvSV/cfVa920Pd12edGlRzIp7tpN6Vg= MIME-Version: 1.0 Received: by 10.227.206.200 with SMTP id fv8mr1864863wbb.11.1320185400468; Tue, 01 Nov 2011 15:10:00 -0700 (PDT) Received: by 10.180.87.102 with HTTP; Tue, 1 Nov 2011 15:10:00 -0700 (PDT) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326404AB8265@DEMUEXC014.nsn-intra.net> References: <4EB02DBD.5060305@pi.nu> <077E41CFFD002C4CAB7DFA4386A5326404AB8265@DEMUEXC014.nsn-intra.net> Date: Tue, 1 Nov 2011 17:10:00 -0500 Message-ID: From: venkatesan mahalingam To: ext Loa Andersson , mpls@ietf.org, MPLS-TP ad hoc team , mpls-ads@tools.ietf.org, George Swallow , Ross Callon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:10:34 -0000 Yes/Support Regards, Venkat. On Tue, Nov 1, 2011 at 5:08 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: > Yes/support > > -----Original Message----- > From: ext Loa Andersson [mailto:loa@pi.nu] > Sent: Tuesday, November 01, 2011 7:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow; Ross Callon > Subject: [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design > > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg chairs > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From zheng.zhi@zte.com.cn Tue Nov 1 20:16:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07C41F0C86 for ; Tue, 1 Nov 2011 20:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.703 X-Spam-Level: X-Spam-Status: No, score=-101.703 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRxDVH8lwVuR for ; Tue, 1 Nov 2011 20:16:29 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 655AF1F0C55 for ; Tue, 1 Nov 2011 20:16:29 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713806486374; Wed, 2 Nov 2011 11:12:22 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.806486374; Wed, 2 Nov 2011 11:16:25 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id pA23GO5T045001 for ; Wed, 2 Nov 2011 11:16:24 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pA1BKcKg035318 for ; Tue, 1 Nov 2011 19:20:38 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201111020316.pA23GO5T045001@mse02.zte.com.cn> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Ryan Zheng Date: Tue, 1 Nov 2011 19:20:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-01 19:20:41, Serialize complete at 2011-11-01 19:20:41 Content-Type: multipart/alternative; boundary="=_alternative 003E81AD4825793B_=" X-MAIL: mse02.zte.com.cn pA23GO5T045001 X-MSS: AUDITRELEASE@mse02.zte.com.cn Subject: [mpls] Request comments on draft-zj-mpls-lsp-ping-reply-relay-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 03:16:30 -0000 This is a multipart message in MIME format. --=_alternative 003E81AD4825793B_= Content-Type: text/plain; charset="US-ASCII" Hi all, We have submitted a draft about the LSP Ping echo reply relay mechanism for the seamless MPLS and any other inter-area MPLS deployment scenarios. See the link below, http://tools.ietf.org/id/draft-zj-mpls-lsp-ping-reply-relay-00 Any comments and suggestions will be appreciated. Regards, The authors > > Abstract: > [RFC4379] describes the LSP Ping mechanism to detect data plane > failures. In some deployment scenario for the LSP traceroute, a > replying LSR may not have the available route to the initiator, and > the echo reply message sent to the initiator would be discarded. > Thus, the basic idea of traceroute procedure to localize fault could > not be achieved. This document describes extensions to LSP Ping > mechanism to enable the replying LSR to have the capability to relay > the echo reply by a set of routable intermediate nodes to the > initiator. -------------------------------------------------------- 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 003E81AD4825793B_= Content-Type: text/html; charset="US-ASCII"
Hi all,

We have submitted a draft about the LSP Ping echo reply relay mechanism for the seamless MPLS and any other inter-area MPLS deployment scenarios. See the link below,
http://tools.ietf.org/id/draft-zj-mpls-lsp-ping-reply-relay-00

Any comments and suggestions will be appreciated.

Regards,
The authors

>
> Abstract:
>    [RFC4379] describes the LSP Ping mechanism to detect data plane
>    failures.  In some deployment scenario for the LSP traceroute, a
>    replying LSR may not have the available route to the initiator, and
>    the echo reply message sent to the initiator would be discarded.
>    Thus, the basic idea of traceroute procedure to localize fault could
>    not be achieved.  This document describes extensions to LSP Ping
>    mechanism to enable the replying LSR to have the capability to relay
>    the echo reply by a set of routable intermediate nodes to the
>    initiator.

--------------------------------------------------------
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 003E81AD4825793B_=-- From scott.mansfield@ericsson.com Tue Nov 1 22:18:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF71F0C5F for ; Tue, 1 Nov 2011 22:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kWNuoDGaE0o for ; Tue, 1 Nov 2011 22:18:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F58E1F0C3E for ; Tue, 1 Nov 2011 22:18:47 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA25IjpS019988 for ; Wed, 2 Nov 2011 00:18:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 2 Nov 2011 01:18:40 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Wed, 2 Nov 2011 01:17:54 -0400 Thread-Topic: [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvmqk5aLeLjMOT868o1hX7QWqQQAYDo3w Message-ID: References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 05:18:48 -0000 =20 Yes/support Regards, -scott. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu]=20 > Sent: Tuesday, November 01, 2011 1:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team;=20 > mpls-ads@tools.ietf.org; George Swallow; Ross Callon > Subject: [AHMPLS-TP] poll on draft-fang-mpls-tp-use-cases-and-design >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support=20 > to make draft-fang-mpls-tp-use-cases-and-design an mpls=20 > working group draft. >=20 > Pleased send your comments to the mpls working group mailing=20 > list (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg chairs > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > = From cts@etri.re.kr Wed Nov 2 01:31:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D5611E80F4 for ; Wed, 2 Nov 2011 01:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.11 X-Spam-Level: X-Spam-Status: No, score=-99.11 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N2Yeqf5qB0B for ; Wed, 2 Nov 2011 01:31:25 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 414E311E80AC for ; Wed, 2 Nov 2011 01:31:25 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 2 Nov 2011 17:31:04 +0900 priority: normal thread-index: AcyZOcJaFjssmWaAT3CRddtYVzKktA== Thread-Topic: Update of draft-cheung-mpls-tp-mesh-protection From: "Taesik Cheung" To: Cc: Date: Wed, 2 Nov 2011 17:31:03 +0900 Comment: ??, ?, Message-ID: <439C69D59F8F4DAE99E98C354136083E@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B43A_01CC9985.324451A0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 02 Nov 2011 08:31:04.0197 (UTC) FILETIME=[C27BA350:01CC9939] Subject: [mpls] Update of draft-cheung-mpls-tp-mesh-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Taesik Cheung List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 08:31:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_B43A_01CC9985.324451A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_B43A_01CC9985.324451A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT1BcmlhbD4NCjxQIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48 Rk9OVCBmYWNlPUFyaWFsPkRlYXIgTVBMUyBXRywgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIGxhbmc9RU4t VVM+PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PEZPTlQgZmFjZT1BcmlhbD4mbmJzcDs8L0ZPTlQ+ PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1N c29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPUFyaWFsPlBsZWFzZSBmaW5k IGFuIHVwZGF0ZSBvZiBkcmFmdC1jaGV1bmctbXBscy10cC1tZXNoLXByb3RlY3Rpb246IDxTUEFO IHN0eWxlPSJtc28tdGFiLWNvdW50OiAxIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvRk9O VD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb1Bs YWluVGV4dD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQgZmFjZT1BcmlhbD4mbmJzcDs8L0ZP TlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48QSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jaGV1bmctbXBscy10cC1tZXNoLXByb3RlY3Rpb24tMDQiIHRhcmdl dD1fYmxhbms+PEZPTlQgZmFjZT1BcmlhbD5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jaGV1bmctbXBscy10cC1tZXNoLXByb3RlY3Rpb24tMDQ8L0ZPTlQ+PC9BPjwvU1BBTj48L1A+ DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFO IGxhbmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOzwvRk9OVD48L286cD48L1NQ QU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb1BsYWluVGV4 dD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9QXJpYWw+V2UgaGF2ZSBpbmNsdWRlZCBhIG51 bWJlciBvZiB1cGRhdGVzIGJhc2VkIG9uIGRpc2N1c3Npb25zIHdpdGggb3VyIG5ldyBjby1hdXRo b3JzLiBUaGVzZSBoYXZlIGJlZW4gZXhwYW5kZWQgYXMgbmV3IHRleHQgYW5kIHVwZGF0ZXMgZm9y OjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PU1zb1BsYWluVGV4dD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQgZmFjZT1BcmlhbD4mbmJz cDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPUFyaWFsPi0g Q2xhcmlmaWNhdGlvbiBvZiB0aGUgTWVzaCBQcm90ZWN0aW9uIEFyY2hpdGVjdHVyZTwvRk9OVD48 L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb1BsYWlu VGV4dD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9QXJpYWw+LSBOZXR3b3JrIFBsYW5uaW5n IGZvciBNZXNoIFByb3RlY3Rpb248L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm YWNlPUFyaWFsPi0gTWVzaCBQcm90ZWN0aW9uIFN3aXRjaGluZzwvRk9OVD48L1NQQU4+PC9QPg0K PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiBs YW5nPUVOLVVTPjxGT05UIGZhY2U9QXJpYWw+LSBQcmVlbXB0aW9uIGFuZCBSYWNlIENvbmRpdGlv bnM8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPUFyaWFsPi0gRXhhbXBs ZSBvZiBDb25uZWN0aW5nIEVuZC1Qb2ludHM8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48 Rk9OVCBmYWNlPUFyaWFsPi0gUHJvdGVjdGlvbiBMb2NraW5nPC9GT05UPjwvU1BBTj48L1A+DQo8 UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIGxh bmc9RU4tVVM+PEZPTlQgZmFjZT1BcmlhbD4tIE1lc3NhZ2luZyBhbmQgSW50ZXJhY3Rpb24gYmV0 d2VlbiBTRU4gYW5kIFNTTjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9 QXJpYWw+LSBWYXJpb3VzIE5JVHMgYW5kIHJlYWRhYmlsaXR5IHVwZGF0ZXM8L0ZPTlQ+PC9TUEFO PjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+ PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7PC9GT05UPjwvbzpw PjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxh aW5UZXh0PjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT1BcmlhbD5XZSB3b3VsZCBncmVhdGx5 IGFwcHJlY2lhdGUgV0cgcmV2aWV3IGFuZCBmZWVkYmFjay48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFu Zz1FTi1VUz48bzpwPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48 L1A+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg bXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt U0EiIGxhbmc9RU4tVVM+VGhhbmsgeW91LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1z aXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIGxhbmc9RU4tVVM+ PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT1B cmlhbD48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9QXJpYWw+PEZP TlQgZmFjZT1BcmlhbD48U1BBTiBsYW5nPUVOLVVTPlJlZ2FyZHMsPC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBsYW5nPUVOLVVTPlRhZXNpazwvU1BBTj48L0RJVj48L0RJ Vj48L0RJVj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsgRk9OVC1TSVpFOiAxMHB0 Ij48QlI+PC9ESVY+PC9GT05UPjwvRk9OVD48L1NQQU4+ ------=_NextPart_000_B43A_01CC9985.324451A0-- From cts@etri.re.kr Wed Nov 2 02:42:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBFB1F0CA4 for ; Wed, 2 Nov 2011 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.785 X-Spam-Level: X-Spam-Status: No, score=-98.785 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FVc52FH+l3S for ; Wed, 2 Nov 2011 02:42:04 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0C52F1F0CA2 for ; Wed, 2 Nov 2011 02:42:03 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 2 Nov 2011 18:42:03 +0900 priority: normal thread-index: AcyZQ6zrlEN0cZdfSrOGkz4o2gM+GQ== Thread-Topic: Request WG input on a Mesh Protection Question From: "Taesik Cheung" To: Cc: Date: Wed, 2 Nov 2011 18:42:03 +0900 Comment: ??, ?, Message-ID: <71EFEC4A44C846A5A5EEC10D9E16A3DD@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CEC0_01CC998F.1CDAB4D0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 02 Nov 2011 09:42:03.0240 (UTC) FILETIME=[AD120680:01CC9943] Subject: [mpls] Request WG input on a Mesh Protection Question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Taesik Cheung List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:42:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_CEC0_01CC998F.1CDAB4D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_CEC0_01CC998F.1CDAB4D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEw cHQiIGlkPW1zZ2JvZHk+DQo8RElWPjxTUEFOIGxhbmc9RU4tVVM+DQo8UCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIGxhbmc9RU4tVVM+RGVhciBN UExTIFdHLDwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9 TXNvUGxhaW5UZXh0PjxTUEFOIGxhbmc9RU4tVVM+PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8g bnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+Jm5i c3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz5BcyB5b3UgbWF5IGhhdmUgcmVjZW50bHkg bm90aWNlZCwgd2UgcmVjZW50bHkgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBkcmFmdC1jaGV1 bmctbXBscy10cC1tZXNoLXByb3RlY3Rpb24tMDQuIDwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIGxhbmc9RU4tVVM+VGhl IGF1dGhvcnMgb2YgdGhlIHNvbHV0aW9uIHdvdWxkIGxpa2UgdG8gaGVhciB0aGUgV0cgb3Bpbmlv biBmb3IgYSBzcGVjaWZpYyBxdWVzdGlvbi4gPC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz5TaG91bGQg dGhlIE1lc2ggUHJvdGVjdGlvbiBzb2x1dGlvbiBiZSBidWlsdCBvbiB0aGUgZXhpc3RpbmcgTGlu ZWFyIFByb3RlY3Rpb24gc29sdXRpb24/PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gbGFuZz1FTi1VUz48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L1A+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFz dDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiIGxhbmc9RU4tVVM+VGhhbmsgeW91LjwvU1BBTj48L0ZPTlQ+PC9E SVY+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlk aS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBt c28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFu Zz1FTi1VUz48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1V Uz48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1z by1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250 OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBt c28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiBsYW5n PUVOLVVTPjwvU1BBTj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlJlZ2FyZHMsPC9ESVY+DQo8 RElWPlRhZXNpazxCUj48L0RJVj48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvRElWPjwvRElWPjwvRElW Pg== ------=_NextPart_000_CEC0_01CC998F.1CDAB4D0-- From riccardo.martinotti@ericsson.com Wed Nov 2 02:52:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55761F0CA2 for ; Wed, 2 Nov 2011 02:52:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMaYf7XBnqxl for ; Wed, 2 Nov 2011 02:52:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D46941F0C9D for ; Wed, 2 Nov 2011 02:52:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-87-4eb112ca2bb2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 63.B1.20773.AC211BE4; Wed, 2 Nov 2011 10:52:10 +0100 (CET) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.76]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 2 Nov 2011 10:52:10 +0100 From: Riccardo Martinotti To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , George Swallow , Ross Callon Date: Wed, 2 Nov 2011 10:52:07 +0100 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvroMQRHybXmvTxCPjMc3Gmv3IgAhVBmA Message-ID: References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:52:12 -0000 Yes/Support. I believe this document explores some important aspects and should be adopt= ed as WG draft. BR Riccardo -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: marted=EC 1 novembre 2011 18.35 To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George Swa= llow; Ross Callon Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Working Group, this is to start a two week poll to see if there is support to make draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Tue Nov 15. /Loa for the mpls wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eosborne@cisco.com Wed Nov 2 04:38:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542511E815C for ; Wed, 2 Nov 2011 04:38:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFUDuWFXKY+P for ; Wed, 2 Nov 2011 04:38:35 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E917811E808A for ; Wed, 2 Nov 2011 04:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1135; q=dns/txt; s=iport; t=1320233916; x=1321443516; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=IgI96H2MzR+Xw2GlvEkjaD/RH2tcA3Ngej6SexoBQi4=; b=S2To3ScDCUGJrYKtfBdjc1Da8urTyfV3RWahrZCBobfsd3LJhSNIhm5R 44SzBL2Kh0XkJzJuLcINURplHj/wh55S3aYPEbaIDHdDwUPs3nK5N4ZWn R3gTkSAJ90qrVxMYMyCdvzKwCCMwWzMHwM8OIPxvxnKgEfaUBfPCnLZN4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAPYqsU6rRDoH/2dsb2JhbABDmXCOOoEegQWBcgEBAQQBAQEPAR0KNBcCAgIBCBEEAQELBhcBBgEaDB8JCAEBBAESCBqHaJZDAZ5QBAKILWEEiAeRR4xJ X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208";a="11875262" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 02 Nov 2011 11:38:35 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA2BcFjF010611; Wed, 2 Nov 2011 11:38:35 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 06:38:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 06:38:35 -0500 Message-ID: In-Reply-To: <4EB02DBD.5060305@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvrqvRY+wY25rQl6PQnuifXZnQQAlTgkQ References: <4EB02DBD.5060305@pi.nu> From: "Eric Osborne (eosborne)" To: "Loa Andersson" , , "MPLS-TP ad hoc team" , , "George Swallow (swallow)" , "Ross Callon" X-OriginalArrivalTime: 02 Nov 2011 11:38:34.0936 (UTC) FILETIME=[F4722B80:01CC9953] Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:38:36 -0000 Yes/support eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, November 01, 2011 1:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow (swallow); Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make draft-fang- > mpls-tp-use-cases-and-design an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Wed Nov 2 07:22:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8531F0C8E for ; Wed, 2 Nov 2011 07:22:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbls1hWf6rvH for ; Wed, 2 Nov 2011 07:22:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B04A121F8B09 for ; Wed, 2 Nov 2011 07:22:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2EMhWN016953; Wed, 2 Nov 2011 09:22:46 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.174]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 2 Nov 2011 10:22:44 -0400 From: David Allan I To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , "George Swallow (swallow)" , Ross Callon Date: Wed, 2 Nov 2011 10:22:43 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvrqvRY+wY25rQl6PQnuifXZnQQAlTgkQAAW4XKA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD522602EF3A@EUSAACMS0703.eamcs.ericsson.se> References: <4EB02DBD.5060305@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:22:48 -0000 +1=20 D > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, November 01, 2011 1:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow (swallow); Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make draft-fang- > mpls-tp-use-cases-and-design an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list=20 > (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg 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 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 gregory.mirsky@ericsson.com Wed Nov 2 07:47:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D711E80F2 for ; Wed, 2 Nov 2011 07:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd1vxhrw5H7u for ; Wed, 2 Nov 2011 07:47:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C24A11E80DA for ; Wed, 2 Nov 2011 07:47:34 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2ElR6L022219 for ; Wed, 2 Nov 2011 09:47:33 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 2 Nov 2011 10:47:28 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Wed, 2 Nov 2011 10:47:26 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvsDnw0A25PGKTw2uS2qwRSeqaQAr4NnA Message-ID: References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:47:40 -0000 =20 Yes/support Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Tuesday, November 01, 2011 10:35 AM To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George Swa= llow; Ross Callon Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Working Group, this is to start a two week poll to see if there is support to make draft-f= ang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@iet= f.org). This poll ends Tue Nov 15. /Loa for the mpls wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From cyril.margaria@nsn.com Tue Oct 11 02:55:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CBF21F8CF0; Tue, 11 Oct 2011 02:55:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiIysKvpnpx3; Tue, 11 Oct 2011 02:55:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E653E21F8C98; Tue, 11 Oct 2011 02:55:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9B9t3d6023147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 11:55:03 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9B9t3kN024233; Tue, 11 Oct 2011 11:55:03 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 11:54:54 +0200 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 Message-ID: In-Reply-To: <5E893DB832F57341992548CDBB333163A441635C81@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: FW: Last Call: (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDtCUb/u9p9AMlSei45fV6ZKDIUwAZGqzwAPjNjwA= References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com><60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se><05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> <5E893DB832F57341992548CDBB333163A441635C81@EMBX01-HQ.jnpr.net> From: "Margaria, Cyril (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 11 Oct 2011 09:54:54.0674 (UTC) FILETIME=[D3CB0320:01CC87FB] X-Mailman-Approved-At: Wed, 02 Nov 2011 08:43:07 -0700 Subject: Re: [mpls] R: FW: Last Call: (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 11 Oct 2011 09:55:06 -0000 X-Original-Date: Tue, 11 Oct 2011 11:54:51 +0200 X-List-Received-Date: Tue, 11 Oct 2011 09:55:06 -0000 Hi,=20 Same here: Yes/Support. Cyril > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > ext John E Drake > Sent: Thursday, October 06, 2011 1:11 PM > To: David Sinicrope; David Allan I > Cc: mpls@ietf.org; ietf@ietf.org > Subject: RE: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons forSelecting a Single Solution for > MPLS-TP OAM) to Informational RFC >=20 > As do I >=20 > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > > Of David Sinicrope > > Sent: Wednesday, October 05, 2011 7:11 PM > > To: David Allan I > > Cc: mpls@ietf.org; ietf@ietf.org > > Subject: Re: [mpls] R: FW: Last Call: > considerations-01.txt> (The Reasons for Selecting a Single Solution > > for MPLS-TP OAM) to Informational RFC > > > > I concur with Dave's comment and support publication of the draft. > > Dave > > > > > > > > On Oct 5, 2011, at 7:06 PM, "David Allan I" > > wrote: > > > > > I think it is unfortunate that we are in a situation where such a > > document has utility. But ultimately it does. > > > > > > Therefore I support the publication of draft-sprecher... > > > > > > D > > > > > > > > > > > >> MPLS Working Group, > > >> > > >> Please be aware of the IETF last call as shown below. The document > > was > > >> presented for publication as an individual RFC with IETF consensus > > and > > >> AD sponsorship. > > >> > > >> This draft is clearly close and relevant to the work you do, but > > after > > >> discussing with the chairs I came to the conclusion that it does > > >> not comment on the technical or process decisions of the MPLS > > >> working groups, and it does not attempt to make any technical > > >> evaluations or definitions within the scope of the MPLS working > > >> group. It is more > > of > > >> a philosophical analysis of the way the IETF approaches the "two > > >> solutions" problem with special reference to MPLS-TP OAM. > > >> > > >> Thus, I am accepting the document as AD Sponsored rather than > > running > > >> it through the MPLS working group. My reasoning is that the > working > > >> group has got plenty to do working on technical issues without > > >> being diverted into wider IETF philosophy. > > >> > > >> As an AD Sponsored I-D it is subject to a four week IETF last > call. > > >> That is plenty of opportunity for everyone to comment and express > > >> their views. Please send your comments to the IETF mailing list as > > >> described below, or (in exceptional circumstances) direct to the > > IESG. > > >> > > >> Thanks, > > >> Adrian > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From sam.aldrin@gmail.com Mon Oct 24 18:05:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2E21F8CF4 for ; Mon, 24 Oct 2011 18:05:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA+vGKIhwFqy for ; Mon, 24 Oct 2011 18:05:28 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9BD921F8CF3 for ; Mon, 24 Oct 2011 18:05:28 -0700 (PDT) Received: by ggnv1 with SMTP id v1so7593808ggn.31 for ; Mon, 24 Oct 2011 18:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aIT/RPfyg3snfiVF2mW4O/J8Cfq2Cxar3gWq3m2ndMw=; b=vKGbNk/JUXNRa1rC7bswwCfco53SOkE/spHKMzaOIaKiQ3zFPYk4j8siQ/XuR+J5ik yRk9srBAoC4gOLs5tspt5EcyPfHmfdkM2z5VwhGqoQv/MLn3/TwoTQkYe56iD7DMFwma qdJtWYuQo1EIt0+JQmoF6h+0i8jhlgPyv8FKQ= Received: by 10.68.57.102 with SMTP id h6mr51910273pbq.7.1319504727955; Mon, 24 Oct 2011 18:05:27 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id 3sm2705667pbx.14.2011.10.24.18.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 18:05:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Sam Aldrin In-Reply-To: <4EA56F96.7040404@pi.nu> Date: Mon, 24 Oct 2011 18:05:25 -0700 Content-Transfer-Encoding: 7bit Message-Id: <908A9527-55E2-4738-A685-36F8E2E452AC@gmail.com> References: <4EA56F96.7040404@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 02 Nov 2011 08:43:07 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:34:58 -0000 Yes, support. -sam On Oct 24, 2011, at 7:00 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Sun Nov 6. > > /Loa > for the mpls wg 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 eric.gray@ericsson.com Wed Nov 2 14:40:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409781F0C63 for ; Wed, 2 Nov 2011 14:40:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSUCI2lz2XiB for ; Wed, 2 Nov 2011 14:40:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1151F0C59 for ; Wed, 2 Nov 2011 14:40:52 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2LeFMa010308; Wed, 2 Nov 2011 16:40:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 2 Nov 2011 17:40:10 -0400 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , George Swallow , Ross Callon Date: Wed, 2 Nov 2011 17:40:08 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvsOxQta479ABTg2I9XnIaqs+UQA6IebA Message-ID: References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:40:53 -0000 I think the document is very useful, but have some concerns about how the title/suject-matter fits into the long established norm for RFCs published by the MPLS working group. Looking it over, and discussing it with a few colleagues, it seems to me that this would be a very useful working group document if it were "MPLS-TP Applicability" or perhaps "MPLS-TP Applicability; Use Cases and Design." I would be interested in hearing from the authors what they might feel about this... -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Tuesday, November 01, 2011 1:35 PM To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George Swa= llow; Ross Callon Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Working Group, this is to start a two week poll to see if there is support to make draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Tue Nov 15. /Loa for the mpls wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lberger@labn.net Wed Nov 2 17:22:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829B11E80E0 for ; Wed, 2 Nov 2011 17:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.944 X-Spam-Level: X-Spam-Status: No, score=-99.944 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afyiBTgMAWFL for ; Wed, 2 Nov 2011 17:22:15 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id C465811E80F1 for ; Wed, 2 Nov 2011 17:22:14 -0700 (PDT) Received: (qmail 22277 invoked by uid 0); 3 Nov 2011 00:22:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Nov 2011 00:22:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hDkWYH53006jpsXTRq3jaxsPPJbRcd5LiPoimH2tXsY=; b=C/rFThDjZR93uh+GYYJip/FocO5bwDZ2+yRntlo6jSwM3zPJHqUaAMXCRKhPOfw2kq8BanhcXrNEwgzBiSRr9EYcDW6sNWyzHZuHMz/PI4kHB5LNAO1700Gx1CVZdC8x; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RLl4Q-00008S-9u; Wed, 02 Nov 2011 18:22:14 -0600 Message-ID: <4EB1DEBA.7020505@labn.net> Date: Wed, 02 Nov 2011 20:22:18 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: mpls@ietf.org Subject: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 00:22:16 -0000 Authors, Your draft includes sections covering MEG and MEP identifiers, but unlike rfc6370, no sections on Tunnel, LSP and PW identifiers. Is the text in section 4 intended to cover these cases? The ICC_Operator_ID-based MEG_ID may be applied equally to a single MPLS-TP Section, LSP or Pseudowire. If yes, I think the section (heading and body) is misleading and should be revised to explicitly state its scope (and to maintain parallelism with rfc6370.) If not, are you planning to add sections that parallel rfc6370 or am I missing something? Much thanks, Lou From binnyjeshan@gmail.com Wed Nov 2 21:20:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0111E80AA for ; Wed, 2 Nov 2011 21:20:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDjg+YV9CNjH for ; Wed, 2 Nov 2011 21:20:03 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3611E80C7 for ; Wed, 2 Nov 2011 21:20:02 -0700 (PDT) Received: by faas12 with SMTP id s12so1339639faa.31 for ; Wed, 02 Nov 2011 21:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PhH3nvXi8a9VuhI9BXGIDZy/wqMrdbCK+KDTyvo1ftc=; b=N9ZUWQ4AjFlQ09R7KtjEsJHf/FwRbLAFG9JNlZ8xPnaylvKOxMfxrfPUtYHKUGpYC3 DCIJ4+zQQMMc7G35fP223vMxKZEc1ZLxiujRSAcF6PS9dwwa0H7zqPUNKT4BUGPPU/2H O8529025r5VPspmMhXhajBd8OZaPB9wzvyPNA= MIME-Version: 1.0 Received: by 10.223.6.129 with SMTP id 1mr2840845faz.17.1320294002116; Wed, 02 Nov 2011 21:20:02 -0700 (PDT) Received: by 10.223.102.66 with HTTP; Wed, 2 Nov 2011 21:20:02 -0700 (PDT) In-Reply-To: <908A9527-55E2-4738-A685-36F8E2E452AC@gmail.com> References: <4EA56F96.7040404@pi.nu> <908A9527-55E2-4738-A685-36F8E2E452AC@gmail.com> Date: Thu, 3 Nov 2011 09:50:02 +0530 Message-ID: From: binny jeshan To: Sam Aldrin Content-Type: multipart/alternative; boundary=0015174761eefec96104b0cce6a2 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 04:20:04 -0000 --0015174761eefec96104b0cce6a2 Content-Type: text/plain; charset=ISO-8859-1 Yes, Support !! -Binny Jeshan On 25 October 2011 06:35, Sam Aldrin wrote: > Yes, support. > > -sam > On Oct 24, 2011, at 7:00 AM, Loa Andersson wrote: > > > Working Group, > > > > this is to start a two week poll to see if there is support to make > > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. > > > > Pleased send your comments to the mpls working group mailing list > > (mpls@ietf.org). > > > > This poll ends Sun Nov 6. > > > > /Loa > > for the mpls wg 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0015174761eefec96104b0cce6a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, Support !!

-Binny Jeshan

On 25 October 2011 06:35, Sam Aldrin <sam.aldrin@gmail.com> wrote:=
Yes, support.

-sam
On Oct 24, 2011, at 7= :00 AM, Loa Andersson wrote:

> Working Group,
>
> this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft.<= br> >
> Pleased send your comments to the mpls working group mailing list
> (mpls@ietf.org).
>
> This poll ends Sun Nov 6.
>
> /Loa
> for the mpls wg chairs
> --
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com=
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 7= 17 52 13
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

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

--0015174761eefec96104b0cce6a2-- From lufang@cisco.com Wed Nov 2 22:28:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6740811E80C0 for ; Wed, 2 Nov 2011 22:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.167 X-Spam-Level: X-Spam-Status: No, score=-5.167 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EsnyWJ-SnPG for ; Wed, 2 Nov 2011 22:28:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5202311E8080 for ; Wed, 2 Nov 2011 22:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2385; q=dns/txt; s=iport; t=1320298097; x=1321507697; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Lqxt6b0YtmYcXtHfjSsJtJU0hbDOZMYKfNBxF65BgYU=; b=Dp5pBDJdM+fu4uh1m8Z3vP7WvqavmzQd2F2C9sOqXzfgnWHT+VK3GJvW BNMfVSaXtO4ImsDUw7DOBLoncvaSUhj5bQr/vlU46geJ73FcuITYoPto1 uVYHuJQXECG0xUUORlHAjgnbJC0quKfClk7j42kYPfTAHOSDmfg763zCh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAADMmsk6tJV2Z/2dsb2JhbABEmX2OW4EfgQWBcgEBAQQBAQEPAR0KNBcCAgIBCBEEAQELBhcBBgEaDB8JCAEBBAESCBqHaJYPAZ5tBAKIO2EEiAiRSIxJ X-IronPort-AV: E=Sophos;i="4.69,447,1315180800"; d="scan'208";a="33009454" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Nov 2011 05:28:03 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA35S3Zh013858; Thu, 3 Nov 2011 05:28:03 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 00:28:03 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 00:28:01 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA353@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvsOxQta479ABTg2I9XnIaqs+UQA6IebAABBIkJA= References: <4EB02DBD.5060305@pi.nu> From: "Luyuan Fang (lufang)" To: "Eric Gray" , "Loa Andersson" , , "MPLS-TP ad hocteam" , , "George Swallow (swallow)" , "Ross Callon" X-OriginalArrivalTime: 03 Nov 2011 05:28:03.0662 (UTC) FILETIME=[5BFCB6E0:01CC99E9] Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:28:18 -0000 Eric, Thanks for your comments.=20 The suggested title "MPLS-TP Applicability; Use Cases and Design" is OK with me, assume we don't encounter process issues - it should not, but will check with the chairs. Luyuan=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: Wednesday, November 02, 2011 5:40 PM > To: Loa Andersson; mpls@ietf.org; MPLS-TP ad hocteam; mpls- > ads@tools.ietf.org; George Swallow (swallow); Ross Callon > Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 >=20 >=20 > I think the document is very useful, but have some concerns about > how the title/suject-matter fits into the long established norm > for RFCs published by the MPLS working group. >=20 > Looking it over, and discussing it with a few colleagues, it seems > to me that this would be a very useful working group document if it > were "MPLS-TP Applicability" or perhaps "MPLS-TP Applicability; Use > Cases and Design." >=20 > I would be interested in hearing from the authors what they might > feel about this... >=20 > -- > Eric >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, November 01, 2011 1:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow; Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg 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 > _______________________________________________ > 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 renu.agarwal@gmail.com Wed Nov 2 22:38:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103D11E808B for ; Wed, 2 Nov 2011 22:38:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgQj015M5vig for ; Wed, 2 Nov 2011 22:38:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2885111E8086 for ; Wed, 2 Nov 2011 22:38:20 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1168801iae.31 for ; Wed, 02 Nov 2011 22:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mT/dEILhy+mD/4jR8vV23Lz1HcoQUFnip9rQ0x5sg9Q=; b=pP2Efr283dm4yXnz8j1xldQNE2S9cVG75hYMYU2Znli/6eGuU/dowWsKAE3iDU+XPt S7KsbVwQhVEVSUmdF/412ZC48rVZVQdiyprvyw5b7zqHuruQD2iq335Jht/XiMYcNIS0 712wxjbYiBu0MMR3eUZXW+tu5djAkMsI3v5Ws= MIME-Version: 1.0 Received: by 10.231.45.135 with SMTP id e7mr1483632ibf.12.1320298698566; Wed, 02 Nov 2011 22:38:18 -0700 (PDT) Received: by 10.231.148.1 with HTTP; Wed, 2 Nov 2011 22:38:18 -0700 (PDT) In-Reply-To: References: <4EA56F96.7040404@pi.nu> <908A9527-55E2-4738-A685-36F8E2E452AC@gmail.com> Date: Thu, 3 Nov 2011 11:08:18 +0530 Message-ID: From: Renu Agarwal To: binny jeshan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Sam Aldrin Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:38:20 -0000 yes, support!! On Thu, Nov 3, 2011 at 9:50 AM, binny jeshan wrote: > Yes, Support !! > -Binny Jeshan > > On 25 October 2011 06:35, Sam Aldrin wrote: >> >> Yes, support. >> >> -sam >> On Oct 24, 2011, at 7:00 AM, Loa Andersson wrote: >> >> > Working Group, >> > >> > this is to start a two week poll to see if there is support to make >> > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. >> > >> > Pleased send your comments to the mpls working group mailing list >> > (mpls@ietf.org). >> > >> > This poll ends Sun Nov 6. >> > >> > /Loa >> > for the mpls wg chairs >> > -- >> > -- >> > >> > >> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: l= oa.andersson@ericsson.com >> > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >> > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13 >> > _______________________________________________ >> > 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 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From renu.agarwal@gmail.com Wed Nov 2 22:39:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D31F0C5C for ; Wed, 2 Nov 2011 22:39:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW375XLwP84d for ; Wed, 2 Nov 2011 22:39:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1707A1F0C42 for ; Wed, 2 Nov 2011 22:39:53 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1170487iae.31 for ; Wed, 02 Nov 2011 22:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gXlxYlDU9+iJwyWUbjAmeoGu+ykLZiHMl7QRqu5zFzY=; b=Q072Y77SpY/+imGt+wL4oi5rlBR7pqh6/7/3G96dzcfyd6IurwtJE9MsDHHalBcPnt Ssf+16/Lj0FtDEVJ5vv+P1mTNLOk9+3hHnDTq0IFTLPOhZXyIxKT/3k/aPQDchCurkHM x9/Ih8lX+kNYliR1Gxoc+KCi8lvbPYq7Cl8FE= MIME-Version: 1.0 Received: by 10.50.47.201 with SMTP id f9mr1982864ign.18.1320298792777; Wed, 02 Nov 2011 22:39:52 -0700 (PDT) Received: by 10.231.148.1 with HTTP; Wed, 2 Nov 2011 22:39:52 -0700 (PDT) In-Reply-To: <238542D917511A45B6B8AA806E875E25073CA353@XMB-RCD-201.cisco.com> References: <4EB02DBD.5060305@pi.nu> <238542D917511A45B6B8AA806E875E25073CA353@XMB-RCD-201.cisco.com> Date: Thu, 3 Nov 2011 11:09:52 +0530 Message-ID: From: Renu Agarwal To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls-ads@tools.ietf.org, MPLS-TP ad hocteam Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:39:53 -0000 yes, support On Thu, Nov 3, 2011 at 10:58 AM, Luyuan Fang (lufang) wr= ote: > Eric, > > Thanks for your comments. > The suggested title "MPLS-TP Applicability; Use Cases and Design" is OK > with me, assume we don't encounter process issues - it should not, but > will check with the chairs. > > Luyuan > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Eric Gray >> Sent: Wednesday, November 02, 2011 5:40 PM >> To: Loa Andersson; mpls@ietf.org; MPLS-TP ad hocteam; mpls- >> ads@tools.ietf.org; George Swallow (swallow); Ross Callon >> Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >> >> >> >> I think the document is very useful, but have some concerns about >> how the title/suject-matter fits into the long established norm >> for RFCs published by the MPLS working group. >> >> Looking it over, and discussing it with a few colleagues, it seems >> to me that this would be a very useful working group document if it >> were "MPLS-TP Applicability" or perhaps "MPLS-TP Applicability; Use >> Cases and Design." >> >> I would be interested in hearing from the authors what they might >> feel about this... >> >> -- >> Eric >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Loa Andersson >> Sent: Tuesday, November 01, 2011 1:35 PM >> To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; > George >> Swallow; Ross Callon >> Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >> >> Working Group, >> >> this is to start a two week poll to see if there is support to make >> draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. >> >> Pleased send your comments to the mpls working group mailing list >> (mpls@ietf.org). >> >> This poll ends Tue Nov 15. >> >> /Loa >> for the mpls wg chairs >> -- >> >> >> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: > loa.andersson@ericsson.com >> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: += 46 10 717 52 13 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13 >> _______________________________________________ >> mpls 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From mach.chen@huawei.com Wed Nov 2 23:49:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627941F0C54 for ; Wed, 2 Nov 2011 23:49:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6jmmm95p709 for ; Wed, 2 Nov 2011 23:49:27 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0322D1F0C42 for ; Wed, 2 Nov 2011 23:49:27 -0700 (PDT) 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 <0LU200L64O6MJ3@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 03 Nov 2011 14:47:10 +0800 (CST) Received: from szxrg02-dlp.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 <0LU20025BO65MQ@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 03 Nov 2011 14:47:10 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AES64471; Thu, 03 Nov 2011 14:47:06 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 14:47:01 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.245]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 03 Nov 2011 14:46:58 +0800 Date: Thu, 03 Nov 2011 06:46:58 +0000 From: Mach Chen In-reply-to: <4EB02DBD.5060305@pi.nu> X-Originating-IP: [10.108.4.63] To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , George Swallow , Ross Callon Message-id: 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] poll on draft-fang-mpls-tp-use-cases-and-design Thread-index: AQHMmL7Jb83ceLGsL0+aYfP+ereUrpWatyRw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB02DBD.5060305@pi.nu> Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 06:49:28 -0000 Yes/Support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Wednesday, November 02, 2011 1:35 AM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow; Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design > > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg 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 nitinb@juniper.net Thu Nov 3 03:31:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961711E80D3 for ; Thu, 3 Nov 2011 03:31:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mImjJ0kV85mw for ; Thu, 3 Nov 2011 03:31:42 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 89E1A11E80AC for ; Thu, 3 Nov 2011 03:31:42 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP; Thu, 03 Nov 2011 03:31:42 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 3 Nov 2011 03:25:20 -0700 From: Nitin Bahadur To: Ross Callon , "mpls@ietf.org" Date: Thu, 3 Nov 2011 03:25:18 -0700 Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgKECIpK Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 10:31:43 -0000 Support publication of the document. Thanks NItin On 10/21/11 8:34 PM, "Ross Callon" wrote: Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-o= am-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Trans= port Networks"). Please send comments to the mpls@ietf.org mailing l= ist. This working group last call ends on Saturday November 5th. George, Loa and Ross MPLS WG co-chairs From Dirk.Schroetter@ecitele.com Thu Nov 3 03:43:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1B11E80DC for ; Thu, 3 Nov 2011 03:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgjEG37wwGVK for ; Thu, 3 Nov 2011 03:43:57 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 10DA41F0C62 for ; Thu, 3 Nov 2011 03:43:56 -0700 (PDT) X-Env-Sender: Dirk.Schroetter@ecitele.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1320317033!2743251!4 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 11747 invoked from network); 3 Nov 2011 10:43:55 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-21.messagelabs.com with SMTP; 3 Nov 2011 10:43:55 -0000 X-AuditID: 93eaf2e7-b7bbfae0000006db-bb-4eb27e37b92b Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 6C.D1.01755.73E72BE4; Thu, 3 Nov 2011 13:42:47 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 3 Nov 2011 12:42:57 +0200 From: Dirk Schroetter To: "mpls@ietf.org" Date: Thu, 3 Nov 2011 12:42:56 +0200 Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgKEoH6Q Message-ID: <44686921E7526C4ABC1833F87EA55A7B6AE712189B@ILPTMAIL02.ecitele.com> 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_44686921E7526C4ABC1833F87EA55A7B6AE712189BILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA3VTf0gTYRjmu9N1Ts/OqfllBes0g0rbMsNIo7BI+7GEoj+EsHP72o62u7m7 zFWUWDQwglKIkqgZyygqU0wTtWQamSSaEsXWL1ARVyStQvppdzu0QfT99Xzv87zPPffxvgSu 8amSCZYTkYNjrLRKHVETCAbSuWNNBt3Pq9nZvms3IjeAfI/nG1YIiipADsNxvMiISGtCgjGX LnSwZYzRSWtZUy6tp7V2K2NENsSJuTRjtyPORK9Xa/85OZKM5bSIM/ImljPn0gW7dqZnZ2et TdfT69NS9Jnr1LstrKBF6TaGtWptSBAYM9JKlX3NuOWLdwyzN+eXf7s0gFcAz8YqEEVAajW8 M12tUvA8OPimQcJqQkN1AthdPQSUSw2AXv9trAoQhIrKhBN1oeYEKgX2nDsdKeMIKhUOP2sL 4XgqH/pPNQJFUwAnR85gCl4Fh0+3ANmGpHbCz+6jcllDbYMnWx6E5FHUdnjhqyuUB0h5pvpu hVpxKgn6Rq9gSk4KejoGcAUnwomR35GKPhG+cjUARc/DH713Q5ik4uCTi6MRZ0FCbZhVbZis Nkym1FdAd3tQpeDlsL7uPT6Dn3aNYOF1N5hzEySyVrtYYjPr9BnIyIrIijKMvK0JKIMxfh98 v5LqBRQB6Biyt7LRoIlkygSnzQvmExidSH7imgya2BLe5LQwgqXYcdCKBC+ABE4nkPO3Shxp YpyHkYOfoTZLD34OT4428tIIcmJxpk73/wudRI4ZP+zQUGZpAA8gZEeOGZ+FBEFD8jovfSLO gcyofD9rFf/SGBElx4iRYtyVNaRgZ2wCa1b4PrA4OYlslwlKJiwHudleeSWOT09PB0CS9NPx ZL2sipEWZrY7IBljkvHFoQbZWFqOWSq5AqSd/yXGHhveNNGDFt1rm1v6OIdv3VNZkNX8rgst KRl0rKvzxxe2fX77Yt5cg9/p6rdkbHrnqX4UnbflWtnD/svHszoXvnHZV3a/7E3d+3qIvbyN +Nj9/USruzvW9bxmY1dpf3HQZ2hdGmyuWlPJXs0rn6JTXhYdup43Od5xpH7y/AI6QrAw+mW4 Q2D+ACLOh6rtAwAA Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 10:43:59 -0000 --_000_44686921E7526C4ABC1833F87EA55A7B6AE712189BILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yes/Support /Dirk From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross= Callon Sent: Freitag, 21. Oktober 2011 17:05 To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-oa= m-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transpor= t Networks"). Please send comments to the mpls@ietf.org mailing list= . This working group last call ends on Saturday November 5th. George, Loa and Ross MPLS WG co-chairs This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_44686921E7526C4ABC1833F87EA55A7B6AE712189BILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yes/Support

 

/Dirk

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon
Sent: Freitag, 21. Oktober 2011 17:05
To: mpls@ietf.org
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt

 

Working Group,

 

This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Se= t for  MPLS based Transport Networks").

 

Please send comments to the mpls@ietf.org mail= ing list.

 

This working group last call ends on Saturday November 5th= . <= /span>

&= nbsp;

George, Loa and Ross

MPLS WG co-chairs

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_44686921E7526C4ABC1833F87EA55A7B6AE712189BILPTMAIL02eci_-- From Rolf.Winter@neclab.eu Thu Nov 3 04:25:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C311E80E8 for ; Thu, 3 Nov 2011 04:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv-HppllvZA7 for ; Thu, 3 Nov 2011 04:25:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9757F11E8088 for ; Thu, 3 Nov 2011 04:25:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F276828000084; Thu, 3 Nov 2011 12:25:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSYDqm59hX9D; Thu, 3 Nov 2011 12:25:30 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D3B0828000081; Thu, 3 Nov 2011 12:25:20 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.17]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 3 Nov 2011 12:24:17 +0100 From: Rolf Winter To: Lou Berger Thread-Topic: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 Thread-Index: AQHMmb6zV/zSCIErS0Kkv6fI3VXoJJWa+N1g Date: Thu, 3 Nov 2011 11:24:17 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D24F55B06@PALLENE.office.hd> References: <4EB1DEBA.7020505@labn.net> In-Reply-To: <4EB1DEBA.7020505@labn.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:25:01 -0000 Hi Lou, section 3 states: " The same substitution procedure applies to all identifiers specified in RFC 6370 [RFC6370] except for the other alternatives mentioned in this document." So basically, we give a formula to create these identifiers. You are asking= to spell them all out, is that correct?=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Donnerstag, 3. November 2011 01:22 > To: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 >=20 > Authors, >=20 > Your draft includes sections covering MEG and MEP identifiers, but > unlike rfc6370, no sections on Tunnel, LSP and PW identifiers. Is the > text in section 4 intended to cover these cases? >=20 > The ICC_Operator_ID-based MEG_ID may be applied equally to a single > MPLS-TP Section, LSP or Pseudowire. >=20 > If yes, I think the section (heading and body) is misleading and should > be revised to explicitly state its scope (and to maintain parallelism > with rfc6370.) If not, are you planning to add sections that parallel > rfc6370 or am I missing something? >=20 > Much thanks, > Lou > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From yaakov_s@rad.com Thu Nov 3 05:00:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B478E11E80D2 for ; Thu, 3 Nov 2011 05:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4MGheCRjOUr for ; Thu, 3 Nov 2011 05:00:37 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id DB39B11E8088 for ; Thu, 3 Nov 2011 05:00:28 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 3 Nov 2011 13:54:53 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Thu, 3 Nov 2011 14:00:18 +0200 From: Yaakov Stein To: "mpls@ietf.org" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AQHMmiAnXyCpjBX9oECjWQQ2RpHrdg== Date: Thu, 3 Nov 2011 12:00:17 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9040E822E@EXRAD5.ad.rad.co.il> References: <077E41CFFD002C4CAB7DFA4386A5326404AFC32C@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326404AFC32C@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:00:37 -0000 I fully support the publication of this document. When I first saw the LC email I was not going to respond, due to the draft name "oam-analysis". Just before erasing the email I remembered that two drafts were merged and went back to see what the final version contains.=20 The OAM solution developed in the IETF, for various process reasons, is described in a complex set of separate documents (the basic BFD-based CC-CV, the LSP ping for on-demand OAM, the loss and delay measurement method and its profile, the lock instruction, the CSF message, the "fault" draft, ...). Without this overview one can easily get lost. For that reason I would suggest holding up final publication of this docume= nt until all the constituent pieces have RFC numbers, so that this document could function as the first point of entry. Y(J)S From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Ross Callon Sent: Friday, October 21, 2011 5:05 PM To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Working Group, =A0 This is to start a two week working group last call on draft-ietf-mpls-tp-o= am-analysis-06.txt ("An Overview of the OAM Tool Set for=A0 MPLS based Tran= sport Networks"). =A0 Please send comments to the mpls@ietf.org mailing list. =A0 This working group last call ends on Saturday November 5th.=20 =A0 George, Loa and Ross MPLS WG co-chairs =A0 From lberger@labn.net Thu Nov 3 06:17:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA20511E8110 for ; Thu, 3 Nov 2011 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.96 X-Spam-Level: X-Spam-Status: No, score=-99.96 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzuoXCUjaROd for ; Thu, 3 Nov 2011 06:17:30 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 27F2F11E811E for ; Thu, 3 Nov 2011 06:17:30 -0700 (PDT) Received: (qmail 20185 invoked by uid 0); 3 Nov 2011 13:17:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 3 Nov 2011 13:17:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oRL2V/YrgndhVB4oyHJr3w0HurH7iiChUit8iboZniY=; b=msKppaj2IMfoTjaD794vkHEggGtYylpVdmWzpKZMDCTq4ZS6IDQ6OQ9NZ/HksOfO0olNZ0Kagk4IYV/RAz6WqE7YxRbi0NU74vkTZP8xwPE3css9AFcpRGFnPoW2EaEP; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RLxAf-0004oz-Mu; Thu, 03 Nov 2011 07:17:29 -0600 Message-ID: <4EB2946E.9080100@labn.net> Date: Thu, 03 Nov 2011 09:17:34 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Rolf Winter References: <4EB1DEBA.7020505@labn.net> <791AD3077F94194BB2BDD13565B6295D24F55B06@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D24F55B06@PALLENE.office.hd> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" Subject: Re: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:17:30 -0000 Rolf, > You are asking to spell them all out, is that correct? Yes. Thanks, Lou On 11/3/2011 7:24 AM, Rolf Winter wrote: > Hi Lou, > > section 3 states: > > " The same substitution procedure applies to all identifiers specified > in RFC 6370 [RFC6370] except for the other alternatives mentioned in > this document." > > So basically, we give a formula to create these identifiers. You are asking to spell them all out, is that correct? > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Lou Berger >> Sent: Donnerstag, 3. November 2011 01:22 >> To: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: [mpls] Question on draft-ietf-mpls-tp-itu-t-identifiers-02 >> >> Authors, >> >> Your draft includes sections covering MEG and MEP identifiers, but >> unlike rfc6370, no sections on Tunnel, LSP and PW identifiers. Is the >> text in section 4 intended to cover these cases? >> >> The ICC_Operator_ID-based MEG_ID may be applied equally to a single >> MPLS-TP Section, LSP or Pseudowire. >> >> If yes, I think the section (heading and body) is misleading and should >> be revised to explicitly state its scope (and to maintain parallelism >> with rfc6370.) If not, are you planning to add sections that parallel >> rfc6370 or am I missing something? >> >> Much thanks, >> Lou >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > From agmalis@gmail.com Thu Nov 3 07:14:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9208A11E80C2 for ; Thu, 3 Nov 2011 07:14:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF3lkQctwI1L for ; Thu, 3 Nov 2011 07:14:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1EEB11E80AF for ; Thu, 3 Nov 2011 07:14:25 -0700 (PDT) Received: by qadc10 with SMTP id c10so1457321qad.31 for ; Thu, 03 Nov 2011 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=USYKm4oHSfy7MM69PAkYf6Chjh5eCS6d59J/hW9t+04=; b=ZSDMCLqZHOco1vnrwqHSReD2RXca0OP6XlUI5thker7IaKi2vKGCaUWe6lU1ZU5+pJ nq0v4Coc/mujs6xHvu7saCY0eaLDnxsWv8Ih191Q/zvEyXB0jPRvlIG0xVuLjzVzWHyK czYcYRzEeMb5DOrNPzg+/Zoq66nTP92xccbUs= Received: by 10.229.10.198 with SMTP id q6mr1134208qcq.208.1320329665180; Thu, 03 Nov 2011 07:14:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.153.210 with HTTP; Thu, 3 Nov 2011 07:14:04 -0700 (PDT) In-Reply-To: <07F7D7DED63154409F13298786A2ADC9040E822E@EXRAD5.ad.rad.co.il> References: <077E41CFFD002C4CAB7DFA4386A5326404AFC32C@DEMUEXC014.nsn-intra.net> <07F7D7DED63154409F13298786A2ADC9040E822E@EXRAD5.ad.rad.co.il> From: "Andrew G. Malis" Date: Thu, 3 Nov 2011 10:14:04 -0400 Message-ID: To: Yaakov Stein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 14:14:26 -0000 Like Yaakov, I also support publication. To Yaakov's last point, since the constituent pieces are all normative references, this document will automatically be held by the RFC Editor until they all have RFC numbers. Cheers, Andy On Thu, Nov 3, 2011 at 8:00 AM, Yaakov Stein wrote: > I fully support the publication of this document. > > When I first saw the LC email I was not going to respond, > due to the draft name "oam-analysis". > Just before erasing the email I remembered that two drafts were merged > and went back to see what the final version contains. > > The OAM solution developed in the IETF, for various process reasons, > is described in a complex set of separate documents > (the basic BFD-based CC-CV, the LSP ping for on-demand OAM, > the loss and delay measurement method and its profile, > the lock instruction, the CSF message, the "fault" draft, ...). > Without this overview one can easily get lost. > > For that reason I would suggest holding up final publication of this docu= ment > until all the constituent pieces have RFC numbers, > so that this document could function as the first point of entry. > > Y(J)S > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of e= xt Ross Callon > Sent: Friday, October 21, 2011 5:05 PM > To: mpls@ietf.org > Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.t= xt > > Working Group, > > This is to start a two week working group last call on draft-ietf-mpls-tp= -oam-analysis-06.txt ("An Overview of the OAM Tool Set for=A0 MPLS based Tr= ansport Networks"). > > Please send comments to the mpls@ietf.org mailing list. > > This working group last call ends on Saturday November 5th. > > George, Loa and Ross > MPLS WG co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From danfrost@cisco.com Thu Nov 3 08:48:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E911E8138 for ; Thu, 3 Nov 2011 08:48:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvvB34OExngG for ; Thu, 3 Nov 2011 08:48:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B109911E812C for ; Thu, 3 Nov 2011 08:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=182; q=dns/txt; s=iport; t=1320335285; x=1321544885; h=from:to:subject:in-reply-to:references:date:message-id: mime-version; bh=SC5C+cBhqlwWkFKU0rWrrEqeHoszIyiMMvsvShLScIo=; b=mDjT7vSHqrHu+hsOkGPUdXcYD+ng4zDjplCzbzeBDZxrb7oq8lvSDR8X KuyTjIpAOJGzF8hMjodqZ/kMxLtwJa0kA0xTicBJJ+FyQ/jA1uFr9ArgZ NRQVq0Aa3TAfE7n6tXj2OpoWoftXnmMuARXgVlYKmgTrDE646/rvldbT3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HAJi2sk6tJV2a/2dsb2JhbABEmj+POYEFgXIBAQEEEgEZDk8LISUPAQR+nX4BnmiJHwSUGJFl X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208";a="33130137" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2011 15:48:05 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA3Fm565005046 for ; Thu, 3 Nov 2011 15:48:05 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id pA3Fm4EH010408 for ; Thu, 3 Nov 2011 11:48:04 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id pA3Fm4Eh010407; Thu, 3 Nov 2011 15:48:04 GMT X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: mpls@ietf.org In-Reply-To: (Ross Callon's message of "Fri, 21 Oct 2011 11:04:37 -0400") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Thu, 03 Nov 2011 15:48:04 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:48:06 -0000 Support. It's essential to have a consolidated overview of MPLS-TP OAM for the benefit of readers trying to pick their way through the RFC maze. This draft provides that. -d From eric.gray@ericsson.com Thu Nov 3 09:13:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6F1F0CB5 for ; Thu, 3 Nov 2011 09:13:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym13y1kM+MT0 for ; Thu, 3 Nov 2011 09:13:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 972DF1F0CB2 for ; Thu, 3 Nov 2011 09:13:58 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA3GDc0l004003; Thu, 3 Nov 2011 11:13:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 3 Nov 2011 12:13:46 -0400 From: Eric Gray To: "Luyuan Fang (lufang)" , Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hocteam , "mpls-ads@tools.ietf.org" , "George Swallow (swallow)" , Ross Callon Date: Thu, 3 Nov 2011 12:13:45 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvsOxQta479ABTg2I9XnIaqs+UQA6IebAABBIkJAAFrsJQA== Message-ID: References: <4EB02DBD.5060305@pi.nu> <238542D917511A45B6B8AA806E875E25073CA353@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25073CA353@XMB-RCD-201.cisco.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] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:13:59 -0000 Luyuan, That would make this draft align with one fo the document roles we definitely need to support. Thanks! I support accepting this draft as a WG document. -- Eric=20 -----Original Message----- From: Luyuan Fang (lufang) [mailto:lufang@cisco.com]=20 Sent: Thursday, November 03, 2011 1:28 AM To: Eric Gray; Loa Andersson; mpls@ietf.org; MPLS-TP ad hocteam; mpls-ads@t= ools.ietf.org; George Swallow (swallow); Ross Callon Subject: RE: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Importance: High Eric, Thanks for your comments.=20 The suggested title "MPLS-TP Applicability; Use Cases and Design" is OK with me, assume we don't encounter process issues - it should not, but will check with the chairs. Luyuan=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: Wednesday, November 02, 2011 5:40 PM > To: Loa Andersson; mpls@ietf.org; MPLS-TP ad hocteam; mpls- > ads@tools.ietf.org; George Swallow (swallow); Ross Callon > Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 >=20 >=20 > I think the document is very useful, but have some concerns about > how the title/suject-matter fits into the long established norm > for RFCs published by the MPLS working group. >=20 > Looking it over, and discussing it with a few colleagues, it seems > to me that this would be a very useful working group document if it > were "MPLS-TP Applicability" or perhaps "MPLS-TP Applicability; Use > Cases and Design." >=20 > I would be interested in hearing from the authors what they might > feel about this... >=20 > -- > Eric >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Tuesday, November 01, 2011 1:35 PM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow; Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Tue Nov 15. >=20 > /Loa > for the mpls wg 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 > _______________________________________________ > 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 hongk@cisco.com Thu Nov 3 09:19:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB61D11E80E3 for ; Thu, 3 Nov 2011 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rPKtJ94fK3U for ; Thu, 3 Nov 2011 09:19:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 872D111E80DA for ; Thu, 3 Nov 2011 09:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=10750; q=dns/txt; s=iport; t=1320337198; x=1321546798; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=ZsC4sZ0XndWBDyHCGo919Kjp/qgrg/xpYl2lKY3wTV8=; b=WAhL+a3U5pf3z7hnCe28Lc1oDlvZ9fAoQyXUHHg+nQSJBipn8JSd2wVO s0OnJsDudMHNYbmF5N5rWCvdNM0DpRy2NW956dUSLEEoZ+gePiO2JWyjC uWTAgMb7df/4FyGBRbBEqlApDoOAJdu+xjIVcKUeraWjBB6ietgBcUqY+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEHAMy+sk6tJV2a/2dsb2JhbABEgk2Xco85gQWBcgEBAQQSAQkRAz4bAgEIEQQBAQsGFwEGAUUJCAEBBBMIGp16AZ5piD1iBIgIkUqMSQ X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208,217";a="33143476" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2011 16:19:58 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA3GJwGp024030 for ; Thu, 3 Nov 2011 16:19:58 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 11:19:58 -0500 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_01CC9A44.6DEC281E" Date: Thu, 3 Nov 2011 11:19:56 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC0550EF15@XMB-RCD-103.cisco.com> In-Reply-To: <44686921E7526C4ABC1833F87EA55A7B6AE712189B@ILPTMAIL02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] MPLS WG last call ondraft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgKEoH6QAAuHh7A= References: <44686921E7526C4ABC1833F87EA55A7B6AE712189B@ILPTMAIL02.ecitele.com> From: "Kyung-Yeop Hong (hongk)" To: X-OriginalArrivalTime: 03 Nov 2011 16:19:58.0214 (UTC) FILETIME=[6E13B260:01CC9A44] Subject: Re: [mpls] MPLS WG last call ondraft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:19:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9A44.6DEC281E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. =20 I support the publication. This document provides a thorough overview of the OAM toolset for MPLS transport networks. =20 KY =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Freitag, 21. Oktober 2011 17:05 To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt =20 Working Group, =20 This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transport Networks"). =20 Please send comments to the mpls@ietf.org mailing list. =20 This working group last call ends on Saturday November 5th.=20 =20 George, Loa and Ross MPLS WG co-chairs =20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC9A44.6DEC281E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support.

 

I support the publication. This document provides a = thorough overview of the OAM toolset for MPLS transport networks.

 

KY

 

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: Freitag, 21. Oktober 2011 17:05
To: mpls@ietf.org
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt

 

Working Group,

 =

This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM = Tool Set for  MPLS based Transport Networks").

 =

Please send comments to the mpls@ietf.org = mailing list.

 =

This working group last call ends on Saturday November 5th. =

 =

George, Loa and Ross

MPLS WG co-chairs

 =

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies thereof. =

------_=_NextPart_001_01CC9A44.6DEC281E-- From loa@pi.nu Thu Nov 3 09:25:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF91F0C8B; Thu, 3 Nov 2011 09:25:06 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADMJQIkKbOwZ; Thu, 3 Nov 2011 09:25:06 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E47341F0C7C; Thu, 3 Nov 2011 09:25:05 -0700 (PDT) Received: from [10.154.180.254] (unknown [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 653BB2A8004; Thu, 3 Nov 2011 17:25:03 +0100 (CET) Message-ID: <4EB2C05C.5070809@pi.nu> Date: Thu, 03 Nov 2011 09:25:00 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:25:08 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-security-framework-02.txt. Please review the document and send comments to the mpls working group mailing list (mpls@ietf.org). This working group last call ends on November 16th. /Loa for the mpls wg co-charis -- 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 nurit.sprecher@nsn.com Thu Nov 3 09:27:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA5F11E813A; Thu, 3 Nov 2011 09:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsD2+UohstAk; Thu, 3 Nov 2011 09:27:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B17EB11E8099; Thu, 3 Nov 2011 09:27:36 -0700 (PDT) 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 pA3GRZY9009737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 17:27:35 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA3GRXw3012380; Thu, 3 Nov 2011 17:27:35 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 17:27:04 +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: Thu, 3 Nov 2011 17:26:53 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326404AFC739@DEMUEXC014.nsn-intra.net> In-Reply-To: <4EB2C05C.5070809@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AcyaRSyQeeKq0da0RwCJ/zH5JycWeAAADNbQ References: <4EB2C05C.5070809@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , X-OriginalArrivalTime: 03 Nov 2011 16:27:04.0299 (UTC) FILETIME=[6C0B1BB0:01CC9A45] Cc: CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:27:37 -0000 I think it is a very important document and I support its publication... Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Thursday, November 03, 2011 6:25 PM To: mpls@ietf.org Cc: CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-security-framework-02.txt. Please review the document and send comments to the mpls working group mailing list (mpls@ietf.org). This working group last call ends on November 16th. /Loa for the mpls wg co-charis --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Thu Nov 3 10:13:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAC411E8123 for ; Thu, 3 Nov 2011 10:13:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q0DuVL-oP3m for ; Thu, 3 Nov 2011 10:13:45 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB4A11E8118 for ; Thu, 3 Nov 2011 10:13:45 -0700 (PDT) Received: from [10.154.180.254] (unknown [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 39D602A8004; Thu, 3 Nov 2011 18:13:42 +0100 (CET) Message-ID: <4EB2CBC2.6000601@pi.nu> Date: Thu, 03 Nov 2011 10:13:38 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" References: <077E41CFFD002C4CAB7DFA4386A5326404AFC32C@DEMUEXC014.nsn-intra.net> <07F7D7DED63154409F13298786A2ADC9040E822E@EXRAD5.ad.rad.co.il> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Additional information - Re: MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:13:46 -0000 All, all the documents that Yaakov and Andy refers to are in AUTH48, so there should not be a problem. The exception is the *draft-ietf-pwe3-static-pw-status* which is (were) on the IESG agenda today. This draft covers the CSF functionality for PWs, this is all that will be in the first set of MPLS-TP documents. That the status is good for the referenced documents is no coincidence, the wg chairs waited to last call the document until such a time that we had (almost) all the docs approved. We have tried to put the draft-ietf-mpls-tp-csf on the agenda a couple of times, we have had very little traction. This one reason that we took the draft out of the first set of mpls-tp draft. The other reason were that we for the first set did not need CSF other than for PWs. If there are real interest in progressing the draft this should start with careful review and proposals how to re-write the scope of the document and carefully explaining why the function is needed. /Loa On 2011-11-03 07:14, Andrew G. Malis wrote: > Like Yaakov, I also support publication. > > To Yaakov's last point, since the constituent pieces are all normative > references, this document will automatically be held by the RFC Editor > until they all have RFC numbers. > > Cheers, > Andy > > On Thu, Nov 3, 2011 at 8:00 AM, Yaakov Stein wrote: >> I fully support the publication of this document. >> >> When I first saw the LC email I was not going to respond, >> due to the draft name "oam-analysis". >> Just before erasing the email I remembered that two drafts were merged >> and went back to see what the final version contains. >> >> The OAM solution developed in the IETF, for various process reasons, >> is described in a complex set of separate documents >> (the basic BFD-based CC-CV, the LSP ping for on-demand OAM, >> the loss and delay measurement method and its profile, >> the lock instruction, the CSF message, the "fault" draft, ...). >> Without this overview one can easily get lost. >> >> For that reason I would suggest holding up final publication of this document >> until all the constituent pieces have RFC numbers, >> so that this document could function as the first point of entry. >> >> Y(J)S >> >> >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Ross Callon >> Sent: Friday, October 21, 2011 5:05 PM >> To: mpls@ietf.org >> Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt >> >> Working Group, >> >> This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transport Networks"). >> >> Please send comments to the mpls@ietf.org mailing list. >> >> This working group last call ends on Saturday November 5th. >> >> George, Loa and Ross >> MPLS WG co-chairs >> >> _______________________________________________ >> 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 -- 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 vero.zheng@huawei.com Thu Nov 3 19:40:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE61F11E80B6 for ; Thu, 3 Nov 2011 19:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq0J18SMlUOA for ; Thu, 3 Nov 2011 19:40:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE311E8073 for ; Thu, 3 Nov 2011 19:40:48 -0700 (PDT) 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 <0LU400DIO7EQCM@szxga05-in.huawei.com> for mpls@ietf.org; Fri, 04 Nov 2011 10:40:03 +0800 (CST) Received: from szxrg01-dlp.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 <0LU4004FE7EI7D@szxga05-in.huawei.com> for mpls@ietf.org; Fri, 04 Nov 2011 10:40:02 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW19263; Fri, 04 Nov 2011 10:40:00 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 10:39:53 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 10:39:52 +0800 Date: Fri, 04 Nov 2011 02:39:52 +0000 From: Vero Zheng In-reply-to: <4EB02DBD.5060305@pi.nu> X-Originating-IP: [10.108.4.58] To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-ads@tools.ietf.org" , George Swallow , Ross Callon Message-id: <2EEA459CD95CCB4988BFAFC0F2287B5C2589CFEC@SZXEML520-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] poll on draft-fang-mpls-tp-use-cases-and-design Thread-index: AQHMmL7BA/rzCdcAvEqnv0Dtjp90xpWcBG+g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB02DBD.5060305@pi.nu> Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 02:40:48 -0000 Yes/Support BR, Vero > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Wednesday, November 02, 2011 1:35 AM > To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George > Swallow; Ross Callon > Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design > > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg 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 lufang@cisco.com Thu Nov 3 20:16:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6180311E8095 for ; Thu, 3 Nov 2011 20:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGjp4JoVf+hu for ; Thu, 3 Nov 2011 20:16:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9200611E8073 for ; Thu, 3 Nov 2011 20:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1048; q=dns/txt; s=iport; t=1320376604; x=1321586204; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=xOydXPS5bHPb4qpKkymy1Gx1Xwz8vBGWrejBiA0d0nc=; b=l/SVr1haoUiQUF9fr8/YhyjQV9oaV253ZnLfGwwG5gjoHuvaGMB7vKHa KeE+6PNA/hNupFmyRXKeF5yWJL1ixw8/dldeeguCdctRFQFlmYpzLnGgh Jj8SHN2OQtezpK8ZwQ9gc6On92pTSgHiRvHmZhUIIIhTPUTNm+ZMUPx+i c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAABdYs06tJV2Y/2dsb2JhbABDmgiOW4EhgQWBcgEBAQQBAQEPAR0KNBcCAgIBCBEEAQELBhcBBgEaDB8JCAEBBAESCBqHaJY8AZ5WBAKIO2IEiAiRSoxJ X-IronPort-AV: E=Sophos;i="4.69,453,1315180800"; d="scan'208";a="33300971" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 04 Nov 2011 03:16:44 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA43GiEf013462; Fri, 4 Nov 2011 03:16:44 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 22:16:43 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 22:16:41 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA738@XMB-RCD-201.cisco.com> In-Reply-To: <4EA56F96.7040404@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVWDUMsoEujCLRc2EjzSmHhgixwISrZRQ References: <4EA56F96.7040404@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , X-OriginalArrivalTime: 04 Nov 2011 03:16:43.0925 (UTC) FILETIME=[2DB60450:01CC9AA0] Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 03:16:45 -0000 Yes, support. Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, October 24, 2011 10:01 AM > To: mpls@ietf.org > Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Sun Nov 6. >=20 > /Loa > for the mpls wg 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From yaacov.weingarten@nsn.com Fri Nov 4 01:32:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6921F85A8 for ; Fri, 4 Nov 2011 01:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDTyEwoZ3LBd for ; Fri, 4 Nov 2011 01:32:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9148621F8591 for ; Fri, 4 Nov 2011 01:32:25 -0700 (PDT) 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 pA48WOTX007357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 09:32:24 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA48WMoi007678 for ; Fri, 4 Nov 2011 09:32:23 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 09:32:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9ACC.3B063B83" Date: Fri, 4 Nov 2011 09:32:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgKyWmFA References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 04 Nov 2011 08:32:04.0477 (UTC) FILETIME=[3B3D22D0:01CC9ACC] Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:32:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9ACC.3B063B83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support publication of the document =20 BR, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Ross Callon Sent: Friday, October 21, 2011 5:05 PM To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt =20 Working Group, =20 This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transport Networks"). =20 Please send comments to the mpls@ietf.org mailing list. =20 This working group last call ends on Saturday November 5th.=20 =20 George, Loa and Ross MPLS WG co-chairs =20 ------_=_NextPart_001_01CC9ACC.3B063B83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/Support publication of the = document

 

BR,

yaacov

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Ross Callon
Sent: Friday, October 21, 2011 5:05 = PM
To: mpls@ietf.org
Subject: [mpls] MPLS WG last = call on = draft-ietf-mpls-tp-oam-analysis-06.txt

<= p class=3DMsoNormal = style=3D'margin-left:36.0pt'> 

Working = Group,

 =

This is to = start a two week working group last call on = draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM = Tool Set for  MPLS based Transport = Networks").

 =

Please = send comments to the mpls@ietf.org = mailing list.

 =

This = working group last call ends on Saturday November 5th. =

 =

George, = Loa and Ross

MPLS WG = co-chairs

 =

------_=_NextPart_001_01CC9ACC.3B063B83-- From yaacov.weingarten@nsn.com Fri Nov 4 01:48:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CA221F8B29 for ; Fri, 4 Nov 2011 01:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFtAAjwnvIan for ; Fri, 4 Nov 2011 01:48:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83B21F8B24 for ; Fri, 4 Nov 2011 01:48:13 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA48m8Ng003625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 09:48:08 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA48m24m001770 for ; Fri, 4 Nov 2011 09:48:08 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 09:48:03 +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: Fri, 4 Nov 2011 09:34:11 +0100 Message-ID: In-Reply-To: <4EB02DBD.5060305@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Thread-Index: AcyYvrzXN52rfXVwSTeUF4FSb1cD6wCDaBFA References: <4EB02DBD.5060305@pi.nu> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 04 Nov 2011 08:48:03.0735 (UTC) FILETIME=[77004A70:01CC9ACE] Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:48:15 -0000 Yes/Support I think that this definitely needs more discussion within the WG and should be discussed. BR, yaacov -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Tuesday, November 01, 2011 7:35 PM To: mpls@ietf.org; MPLS-TP ad hoc team; mpls-ads@tools.ietf.org; George Swallow; Ross Callon Subject: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design Working Group, this is to start a two week poll to see if there is support to make draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Tue Nov 15. /Loa for the mpls wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From jie.dong@huawei.com Fri Nov 4 02:48:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8180121F8AB8 for ; Fri, 4 Nov 2011 02:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLLUhKo5RSCd for ; Fri, 4 Nov 2011 02:48:25 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5521F8AB0 for ; Fri, 4 Nov 2011 02:48:25 -0700 (PDT) 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 <0LU400E7GR4HQB@szxga05-in.huawei.com> for mpls@ietf.org; Fri, 04 Nov 2011 17:45:53 +0800 (CST) Received: from szxrg02-dlp.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 <0LU400GY4R1W2S@szxga05-in.huawei.com> for mpls@ietf.org; Fri, 04 Nov 2011 17:45:53 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET68268; Fri, 04 Nov 2011 17:45:52 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 17:45:45 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.220]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 17:45:44 +0800 Date: Fri, 04 Nov 2011 09:45:42 +0000 From: Jie Dong X-Originating-IP: [10.108.4.57] To: "mpls@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927229F4ED7@szxeml509-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: en-US, zh-CN Thread-topic: Comments on draft-weingarten-mpls-tp-ring-protection-06 Thread-index: Acya1oQkEkmaA6JvQ7S2g+rIofFNNw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:48:26 -0000 Hi, Here are some comments on this tp ring protection draft. 1. This draft describes the label stack operation of each protection mechanism. For better clarity, I would recommend using the same protected LSP as example when possible, i.e. using LSR-B as the ingress and LSR-E as the egress in all description of p2p protection, and describes the label stack operation from the ingress to the egress. 2. Label operation in the last paragraph before 2.3.1, "packets arrive at LSR-B with label [LI], and then send out to LSR-A with [[PA(F)|L1]]". Should B swap the inner label LI with LE, which is expected by the egress LSR-F? 3. Label stack operation of wrapping in sec 2.3.2 needs some clarification: "1. The data packet arrives at LSR-A with label stack [LI+S] (i.e. top label from the LSP and bottom-of-stack indicator)" If the section takes the protected LSP in figure 1 as example, LSR-A is the ingress of SPME A-F, NOT the ingress of the ring. If the ingress LSR is B, packets arrive at A may contain the label for SPME B-A, and the inner LSP label LI should be swapped on LSR-B. "2. In the normal case (no switching), LSR-A forwards the packet with label stack [PA1(F)|LE+S] (i.e. swap the label for the LSP, to be acceptable to the SPME egress, and push the label for the primary SPME from LSR-A to LSR-F)." "LE" is defined as "the label of the LSP that is expected at the egress point from the ring", but here it is used as the label expected by SPME egress. Since the inner LSP label needs be swapped each time the SPME label is popped, using "LE" for this operation may be confusing. It would be clearer to define a new term for this. 4. In some specifications "+S" is added to the LSP label. Does it also allow carrying PW label or other labels in the label stack? Best regards, Jie From ietfc@btconnect.com Fri Nov 4 07:44:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8CE21F8C1C for ; Fri, 4 Nov 2011 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUxGDz8dRcMy for ; Fri, 4 Nov 2011 07:44:23 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5539021F8C0D for ; Fri, 4 Nov 2011 07:44:22 -0700 (PDT) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr10.btconnect.com with SMTP id EYZ01144; Fri, 04 Nov 2011 14:44:16 +0000 (GMT) Message-ID: <025201cc9af7$1c66cac0$4001a8c0@gateway.2wire.net> From: "t.petch" To: Date: Fri, 4 Nov 2011 14:38:27 +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.0A0B0303.4EB3FA3F.0088, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.4.140016:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4EB3FA41.0015,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:44:24 -0000 Some possible tweaks. s3.2 "A bit MUST NOT be set .. " suggest "The A bit MUST NOT be set ..." to make it clear that this is a reference to A bit and not to a bit. s3.3.1 last paragraph would be good to recommend (SHOULD) a error reply and return code here (2?) s3.3.2 last paragraph Flag field is defined in 3.2 not 3.3 s5 I would like more detail. I understand the attack but do not know how to prevent it. Active attackers forging source addresses are a major problem with SMTP; how damaging, and how hard to prevent, will be forged reply addresses, along with whatever sub-TLV the attacker sees devilment in? If active attackers are excluded by other means, then that would be worth a mention. I never know when you need a reference to Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", IETF RFC 5226, May 2008 RP; I know what RP means; Rendezvous Point (multicast), or Route Processor(routing) or Relying Party(sidr/bgpsec). I would prefer to see it spelt out most of the time, and only abbreviated when it is part of something else, but that may be my unusual context. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Monday, October 31, 2011 3:40 AM Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.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 : Return Path Specified LSP Ping > Author(s) : Mach(Guoyi) Chen > Wei Cao > So Ning > Frederic Jounay > Simon Delord > Filename: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt > Pages : 18 > Date: 2011-10-30 > > This document defines extensions to the failure-detection protocol > for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > known as "LSP Ping" that allow selection of the LSP to use for the > echo reply return path.Enforcing a specific return path can be used > to verify bidirectional connectivity and also increase LSP ping > robustness.It may also be used by Bidirectional Forwarding > Detection (BFD) for MPLS bootstrap signaling thereby making BFD for > MPLS more robust. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pi ng-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pin g-04.txt > > TF. From gregory.mirsky@ericsson.com Fri Nov 4 10:49:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0138721F8BA8 for ; Fri, 4 Nov 2011 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6-wdERklqz0 for ; Fri, 4 Nov 2011 10:49:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D837821F8BA6 for ; Fri, 4 Nov 2011 10:49:11 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA4Hmq9N009068 for ; Fri, 4 Nov 2011 12:49:11 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 4 Nov 2011 13:49:07 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Date: Fri, 4 Nov 2011 13:49:06 -0400 Thread-Topic: draft-ietf-mpls-tp-security-framework-02 WG LC comments Thread-Index: AcybGgxjlB4s6jzET2u4deeiHC4mAQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE14D2174EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] draft-ietf-mpls-tp-security-framework-02 WG LC comments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:49:13 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE14D2174EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please consider my comments listed below: * Section 1.1 "There are also needs for MPLS-TP and MPLS interworking= " seems ambiguous. Perhaps "There are also needs for MPLS-TP and non-MPLS-T= P interworking". * Section 1.2 "G-ACh (control plane attack, DoS attack, message inter= cept, etc.)" I think that G-ACh might be used to launch attack on the data = plane, e.g. trigger protection switchover or lock a connection, as well. * Section 1.2 "Data plane authentication" isn't it part of G-ACh issu= es? * Section 3 "...the data plane should continue to forward packets wit= hout being impacted". I think that separation of Control Plane and Data Pla= ne implies that all enabled in the data plane operations, e.g. OAM, protect= ion, will act without impact in case control plane and/or management plane = are under attack. * Section 3. Split requirements into single statements without "as we= ll as" and enumerate them * Section 4.2 might add 'c' to list of possible attacks via G-ACh to = trigger protection switchover and/or restoration; locking of a transport co= nnection. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE14D2174EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please consider my comments listed below:
•     = ;  Section 1.1 “There are also = needs for MPLS-TP and MPLS interworking” seems ambiguous. Perhaps = 220;There are also needs for MPLS-TP and non-MPLS-TP interworking”.
•     = ;  Section 1.2 “G-ACh (control = plane attack, DoS attack, message intercept, etc.)” I think that G-AC= h might be used to launch attack on the data plane, e.g. trigger protection= switchover or lock a connection, as well.
•     = ;  Section 1.2 “Data plane auth= entication” isn’t it part of G-ACh issues?
•     = ;  Section 3 “…the data p= lane should continue to forward packets without being impacted”. I th= ink that separation of Control Plane and Data Plane implies that all enable= d in the data plane operations, e.g. OAM, protection, will act without impact in case control p= lane and/or management plane are under attack.
•     = ;  Section 3. Split requirements into= single statements without “as well as” and enumerate them
•     = ;  Section 4.2 might add ‘cR= 17; to list of possible attacks via G-ACh to trigger protection switchover = and/or restoration; locking of a transport connection.
 
        Regards,
           &nbs= p;    Greg
 
 
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE14D2174EUSAACMS0715e_-- From wwwrun@rfc-editor.org Fri Nov 4 18:33:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1321F0C57; Fri, 4 Nov 2011 18:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA+OATdOBkaG; Fri, 4 Nov 2011 18:33:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 385CE1F0C54; Fri, 4 Nov 2011 18:33:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 138C862199; Fri, 4 Nov 2011 18:29:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111105012900.138C862199@rfc-editor.org> Date: Fri, 4 Nov 2011 18:29:00 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6388 on Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:33:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6388 Title: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author: IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas Status: Standards Track Stream: IETF Date: November 2011 Mailbox: ice@cisco.com, ina@juniper.net, kireeti@juniper.net, bobthomas@alum.mit.edu Pages: 39 Characters: 86457 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-p2mp-15.txt URL: http://www.rfc-editor.org/rfc/rfc6388.txt This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP 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 multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 4 18:47:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4A21F891D; Fri, 4 Nov 2011 18:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w38iSH+oxU2; Fri, 4 Nov 2011 18:47:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B121F88B7; Fri, 4 Nov 2011 18:47:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1DC5672F0F8; Fri, 4 Nov 2011 18:29:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111105012951.1DC5672F0F8@rfc-editor.org> Date: Fri, 4 Nov 2011 18:29:51 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6424 on Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:47:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6424 Title: Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels Author: N. Bahadur, K. Kompella, G. Swallow Status: Standards Track Stream: IETF Date: November 2011 Mailbox: nitinb@juniper.net, kireeti@juniper.net, swallow@cisco.com Pages: 23 Characters: 48270 Updates: RFC4379 I-D Tag: draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt URL: http://www.rfc-editor.org/rfc/rfc6424.txt This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hongk@cisco.com Sat Nov 5 06:19:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059BD21F88AB for ; Sat, 5 Nov 2011 06:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huEBY5ZdOneT for ; Sat, 5 Nov 2011 06:19:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F521F886A for ; Sat, 5 Nov 2011 06:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=1174; q=dns/txt; s=iport; t=1320499160; x=1321708760; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=n5L4u/Nis/YpbvAId5QH6Gvze/LmJO9k2/2Kg1X3ZG4=; b=Ogh01XgAvyeT/1gps8fHCIKYIz35pQ423N3dty7up0y/lShI0EUH/fuC GszmuBRtwOCAN8VtNW7vU2C8igonUsuSmXjgyATkkB54wuP3ZfQ/ZW94U iATp1QDs5QRMREjgvrzxsiI7uh08xqsWBwIo7HN4UM9b6jegfgt+lVLo8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAADk3tU6tJXG8/2dsb2JhbABDmhSOVIEggQWBcgEBAQEDAQEBDwEdCjQXAgICAQgRBAEBCwYXAQYBGgwfCQgBAQQBEggah2iYOwGdagQCiEZjBIgLkVCMUA X-IronPort-AV: E=Sophos;i="4.69,460,1315180800"; d="scan'208";a="33610870" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2011 13:19:17 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA5DJGpE014568; Sat, 5 Nov 2011 13:19:16 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 Nov 2011 08:19:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Nov 2011 08:19:17 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC055A86C2@XMB-RCD-103.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25073CA738@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVWDUMsoEujCLRc2EjzSmHhgixwISrZRQAEdOWoA= References: <4EA56F96.7040404@pi.nu> <238542D917511A45B6B8AA806E875E25073CA738@XMB-RCD-201.cisco.com> From: "Kyung-Yeop Hong (hongk)" To: "Loa Andersson" , X-OriginalArrivalTime: 05 Nov 2011 13:19:16.0809 (UTC) FILETIME=[84EC1390:01CC9BBD] Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 13:19:21 -0000 Yes/support. KY > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, October 24, 2011 10:01 AM > To: mpls@ietf.org > Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Sun Nov 6. >=20 > /Loa > for the mpls wg 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 > _______________________________________________ > 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 martin.vigoureux@alcatel-lucent.com Sat Nov 5 07:26:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1883C21F84A3 for ; Sat, 5 Nov 2011 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTfBsY9yxEcR for ; Sat, 5 Nov 2011 07:26:29 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5588C21F847C for ; Sat, 5 Nov 2011 07:26:28 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pA5EQPRU025899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 5 Nov 2011 09:26:26 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA5EQP2M006961 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 Nov 2011 09:26:25 -0500 Received: from [135.244.34.211] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 5 Nov 2011 09:26:24 -0500 Message-ID: <4EB54784.2040503@alcatel-lucent.com> Date: Sat, 5 Nov 2011 15:26:12 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 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.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [mpls] IETF82 - MPLS Sessions - Agenda Uploaded X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 14:26:30 -0000 Hi, you can find the preliminary agenda here: http://www.ietf.org/proceedings/82/agenda/mpls.txt Please note that it is till draft and we are still working on producing a final version. Typically, we might have to reduce the duration of certain slots. Let me know. regards, martin From mach.chen@huawei.com Sun Nov 6 19:21:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2B81F0C34 for ; Sun, 6 Nov 2011 19:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaS-NtLUy+6x for ; Sun, 6 Nov 2011 19:21:57 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0421F848B for ; Sun, 6 Nov 2011 19:21:57 -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 <0LU900KTJTC6PY@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 07 Nov 2011 11:21:42 +0800 (CST) Received: from szxrg02-dlp.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 <0LU9004OPTAUW2@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 07 Nov 2011 11:21:42 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU23653; Mon, 07 Nov 2011 11:21:41 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 11:21:39 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.102]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 11:21:32 +0800 Date: Mon, 07 Nov 2011 03:21:32 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.108.4.54] To: Ross Callon , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HqenaCCS2bOsjpHG1PSLEg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgM+YpQg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 03:21:58 -0000 --Boundary_(ID_HqenaCCS2bOsjpHG1PSLEg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes/Support. Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, October 21, 2011 11:05 PM To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transport Networks"). Please send comments to the mpls@ietf.org mailing list. This working group last call ends on Saturday November 5th. George, Loa and Ross MPLS WG co-chairs --Boundary_(ID_HqenaCCS2bOsjpHG1PSLEg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Yes/Support.

 

Best regards,

Mach

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Friday, October 21, 2011 11:05 PM
To: mpls@ietf.org
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt

 

Working Group,

 

This is to start a two week working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for  MPLS based Transport Networks").

 

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

 

This working group last call ends on Saturday November 5th.

 

George, Loa and Ross

MPLS WG co-chairs

 

--Boundary_(ID_HqenaCCS2bOsjpHG1PSLEg)-- From mach.chen@huawei.com Sun Nov 6 19:29:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902F11F0C38 for ; Sun, 6 Nov 2011 19:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kDu5GeuFwgN for ; Sun, 6 Nov 2011 19:29:29 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2001F0C34 for ; Sun, 6 Nov 2011 19:29:29 -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 <0LU900BLSTMZ8E@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 07 Nov 2011 11:28:11 +0800 (CST) Received: from szxrg02-dlp.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 <0LU9004Y6TLVWH@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 07 Nov 2011 11:28:11 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU24253; Mon, 07 Nov 2011 11:28:10 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 11:28:05 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.102]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 11:28:00 +0800 Date: Mon, 07 Nov 2011 03:27:59 +0000 From: Mach Chen In-reply-to: <025201cc9af7$1c66cac0$4001a8c0@gateway.2wire.net> X-Originating-IP: [10.108.4.54] To: "t.petch" Message-id: 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] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt Thread-index: AQHMmwBBMbTQRLrzyEqU6zsOzs/hopWgs3Kg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <025201cc9af7$1c66cac0$4001a8c0@gateway.2wire.net> Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 03:29:30 -0000 Hi Tom, Many thanks for your valuable comments! Please see my reply inline... > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, November 04, 2011 9:38 PM > To: Mach Chen > Cc: mpls@ietf.org > Subject: Re: [mpls] I-D Action: > draft-ietf-mpls-return-path-specified-lsp-ping-04.txt > > Some possible tweaks. > > s3.2 > "A bit MUST NOT be set .. " > suggest > "The A bit MUST NOT be set ..." > to make it clear that this is a reference to A bit and not to a bit. Yes, will fix it. > > s3.3.1 last paragraph > would be good to recommend (SHOULD) a error reply and return code here (2?) > > s3.3.2 last paragraph > Flag field is defined in 3.2 not 3.3 Good catch, will fix it. > > s5 I would like more detail. I understand the attack but do not know how to > prevent it. Active attackers forging source addresses are a major problem > with > SMTP; how damaging, and how hard to prevent, will be forged reply addresses, > along with whatever sub-TLV the attacker sees devilment in? If active > attackers > are excluded by other means, then that would be worth a mention. OK, we will carefully consider this and add more text in the next version. > > I never know when you need a reference to > Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations > Section in RFCs", IETF RFC 5226, May 2008 OK, will add the reference in the next revision. > > RP; I know what RP means; Rendezvous Point (multicast), or Route > Processor(routing) or Relying Party(sidr/bgpsec). I would prefer to see it > spelt out most of the time, and only abbreviated when it is part of something > else, but that may be my unusual context. Reasonable request, I will re-examine the document and try to make it clearer. Many thanks, Mach > > Tom Petch > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, October 31, 2011 3:40 AM > Subject: [mpls] I-D Action: > draft-ietf-mpls-return-path-specified-lsp-ping-04.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 : Return Path Specified LSP Ping > > Author(s) : Mach(Guoyi) Chen > > Wei Cao > > So Ning > > Frederic Jounay > > Simon Delord > > Filename: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt > > Pages : 18 > > Date: 2011-10-30 > > > > This document defines extensions to the failure-detection protocol > > for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > > known as "LSP Ping" that allow selection of the LSP to use for > the > > echo reply return path.Enforcing a specific return path can be used > > to verify bidirectional connectivity and also increase LSP ping > > robustness.It may also be used by Bidirectional Forwarding > > Detection (BFD) for MPLS bootstrap signaling thereby making BFD for > > MPLS more robust. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pi > ng-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-pin > g-04.txt > > > > TF. From wwwrun@rfc-editor.org Mon Nov 7 08:38:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA921F8B30; Mon, 7 Nov 2011 08:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F64ZiKwWIffE; Mon, 7 Nov 2011 08:38:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EA62B21F8A7A; Mon, 7 Nov 2011 08:38:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 49BA3B1E005; Mon, 7 Nov 2011 08:34:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111107163414.49BA3B1E005@rfc-editor.org> Date: Mon, 7 Nov 2011 08:34:14 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6389 on MPLS Upstream Label Assignment for LDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:38:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6389 Title: MPLS Upstream Label Assignment for LDP Author: R. Aggarwal, JL. Le Roux Status: Standards Track Stream: IETF Date: November 2011 Mailbox: raggarwa_1@yahoo.com, jeanlouis.leroux@orange-ftgroup.com Pages: 13 Characters: 30935 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-upstream-10.txt URL: http://www.rfc-editor.org/rfc/rfc6389.txt This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Mon Nov 7 08:46:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F521F8C5B; Mon, 7 Nov 2011 08:46:05 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5raSudEfcd7W; Mon, 7 Nov 2011 08:46:05 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D06B621F8C41; Mon, 7 Nov 2011 08:46:04 -0800 (PST) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0E9842A8004; Mon, 7 Nov 2011 17:46:01 +0100 (CET) Message-ID: <4EB80B45.7040603@pi.nu> Date: Mon, 07 Nov 2011 08:45:57 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" References: <4EA4535E.5010708@pi.nu> In-Reply-To: <4EA4535E.5010708@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , draft-weingarten-mpls-tp-ring-protection@tools.ietf.org, MPLS-TP ad hoc team , pwe3@ietf.org Subject: Re: [mpls] [PWE3] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:46:05 -0000 Working Group, this poll is closed! And we have a new working group document! Could the authors please publish draft-ietf-mpls-tp-ring-protection-00 as soon as it becomes possible during the IETF week, that is identical with the version we polled (changing only file name and dates) /Loa for the wg chairs On 2011-10-23 10:48, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Sun Nov 6. > > /Loa > for the mpls wg 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 jmh@joelhalpern.com Mon Nov 7 13:38:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07121F86A5 for ; Mon, 7 Nov 2011 13:38:13 -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.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE9ocCzCPPWj for ; Mon, 7 Nov 2011 13:38:12 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6639011E809F for ; Mon, 7 Nov 2011 13:38:12 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 23938E2AB2 for ; Mon, 7 Nov 2011 13:38:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C3BC634131A for ; Mon, 7 Nov 2011 13:38:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-48.clppva.btas.verizon.net [71.161.52.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 110AD341319 for ; Mon, 7 Nov 2011 13:38:09 -0800 (PST) Message-ID: <4EB84FC0.9010103@joelhalpern.com> Date: Mon, 07 Nov 2011 16:38:08 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" References: <49044C2B7F64814BAA8D09EA7B8D72321D0E638FBD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <49044C2B7F64814BAA8D09EA7B8D72321D0E638FBD@EUSAACMS0701.eamcs.ericsson.se> X-Forwarded-Message-Id: <49044C2B7F64814BAA8D09EA7B8D72321D0E638FBD@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] Comments on draft-ietf-mpls-tp-security-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 21:38:13 -0000 Major: Several of these requirements are pure assertions. For the reader to use them, it is very helpful if explanations of the security analysis that goes with the assertion exist somewhere. (This applies to mechanism requirements. Requirements like "preventing DoS" don't need explanations of what the security issue is :-) I think this is an important part of the framework that users need. Structurally, it seems very odd to have the requirements before the threats. In my experience, the threats drive the requirements. Moderate: In describing the requirements in section 3, the text first says: "This document does not mandate that an MPLS-TP network must fulfill all security requirements listed to be secure." I understand the general idea of this statement. However, it is not clear how this statements relates to the MUST phrasing in the list which follows that. Are the MUSTs mandatory? I think that the idea is better described in section 5. Related to this, some of the bullets use "or" terminology, resulting in it being unclear what is being mandated. For example, in the second bullet, it says "MUST support … with or without NMS or OSS". Does that mean that the requirement is met if the system supports only CLI, or only SNMP, or does the text actually require that both be supported? It seems that the connection in the second requirement between non-control plane provisioning support and trust boundaries really needs some justification. I understand that service providers have a requirement for hiding topology. But is that really a security requirement? In section 4, I am not sure what "A MPLS-TP configuration transiting the public Internet" is. It does not seem to match any of the scenarios. I presume "transiting" was carefully chosen to be different from "connecting to". It would seem helpful if there were more explanation of what was intended. The text leading into sections 4.1 and 4.2 says "The following sections discuss …" But sections 4.1 and 4.2 are merely enumerated lists. They do not discuss anything. It is not even clear what the enumeration accomplishes, since it includes things that are MPLS general, things that are nearly impossible in MPLS-TP, and things that are MPLS-TP specific. It seems to me that if this is the MPLS-TP Security Framework that we need to be clear in the threats list as to which threats are dealt with elsewhere, which threats are changed by the MPLS-TP mechanisms, and which threats are new with MPLS-TP. Also, we should either discuss the threats, or not claim to be discussing them. Minor: Could there be some clarification on what is meant by non-IP path options vs IP loopback option? Maybe a section reference to another document, or a few extra words as to what thing is not IP. I would suggest that the extra wording path would allow for some explanation of why the use of non-IP address may help improve security. (It is very common for operators to filter control traffic at the border already.) Could "port access control" in the MCC requirements be better explained? I can think of several possible meanings in this context. The next to last requirement is not written as a requirement. It is a list of general things that are useful to do. In section 4, it refers to security being generally a tradeoff between "expense and risk". There are several possible meanings for this sentence. For at least some of them, I would think "cost" (which includes manpower and other issues as well as actual cash expenses) would be a better word than "expense". Editorial: Section 1.1, fourth paragraph: I think the reference to 5921 was supposed to be a reference to 5920? Why is AC: Attachment Circuit defined in section 2.1 instead of in the list of terminology in section 1? Should Security Reference Model 3 (section 2.3) state explicitly that the two PEs and the devices in between are under the control of a single operator? It would be easier to reference the requirements if they had numbers. (R.1, R.2… for example.) Is there a reason that in the list of requirements in section 3 some items have o and some have *? (If these are replaced with unique ids, then the question becomes moot.) Section 5.5 is empty. From rcallon@juniper.net Tue Nov 8 10:02:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F821F8B40 for ; Tue, 8 Nov 2011 10:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZLilvnSygYR for ; Tue, 8 Nov 2011 10:02:16 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D0ADB21F87D3 for ; Tue, 8 Nov 2011 10:02:15 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Nov 2011 10:02:15 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Nov 2011 09:59:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 8 Nov 2011 12:59:13 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 8 Nov 2011 12:59:12 -0500 Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQgONRCvA 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_DF7F294AF4153D498141CBEFADB17704C6F20F490EEMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 18:02:17 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C6F20F490EEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This WG last call has now been completed, and the document has passed last = call. However, there are minor comments from Tom Petch that need to be considered= . I will ask the authors to update the document to reflect these comments, = and to work offline with Tom to make sure that his comments are adequately = addressed. My understanding is that the authors may also have gotten offlin= e editorial comments from Dan Frost that will be reflected in the update. We will wait for the updated document before submitting draft-ietf-mpls-tp-= oam-analysis for publication. Since it is currently past the time that Inte= rnet Drafts can be submitted for publication prior to Taipei, any update to= the document will need to wait until at least next Monday. Thanks, Ross (as MPLS WG co-chair) From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Friday, October 21, 2011 11:05 AM To: mpls@ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-o= am-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Transp= ort Networks"). Please send comments to the mpls@ietf.org mailing lis= t. This working group last call ends on Saturday November 5th. George, Loa and Ross MPLS WG co-chairs --_000_DF7F294AF4153D498141CBEFADB17704C6F20F490EEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This WG last call has n= ow been completed, and the document has passed last call.

 

However, there= are minor comments from Tom Petch that need to be considered. I will ask t= he authors to update the document to reflect these comments, and to work of= fline with Tom to make sure that his comments are adequately addressed. My = understanding is that the authors may also have gotten offline editorial co= mments from Dan Frost that will be reflected in the update.

 

We will wait= for the updated document before submitting draft-ietf-mpls-tp-oam-analysis= for publication. Since it is currently past the time that Internet Drafts = can be submitted for publication prior to Taipei, any update to the documen= t will need to wait until at least next Monday.

 

Thanks, Ross<= /span>

(as MPLS WG co-chair)

 

 

From: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] On Behalf Of Ross Callon
Sent: Friday, O= ctober 21, 2011 11:05 AM
To: mpls@ietf.org
Subject: [mp= ls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt<= /span>

 

Working Group,

 =

This is to start a two week = working group last call on draft-ietf-mpls-tp-oam-analysis-06.txt ("An= Overview of the OAM Tool Set for  MPLS based Transport Networks"= ).

 

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

 

This w= orking group last call ends on Saturday November 5th.

 

George, Loa and Ross

MPLS W= G co-chairs

 =

= --_000_DF7F294AF4153D498141CBEFADB17704C6F20F490EEMBX01WFjnprn_-- From pabloisnot@gmail.com Wed Nov 9 05:57:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6221F8B52 for ; Wed, 9 Nov 2011 05:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZrRxuMkE5mO for ; Wed, 9 Nov 2011 05:57:19 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF79821F8B37 for ; Wed, 9 Nov 2011 05:57:19 -0800 (PST) Received: by qyl16 with SMTP id 16so4648890qyl.10 for ; Wed, 09 Nov 2011 05:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=86YHFtyID3qxdrn4mdtkmAp1C5eR5YyfcTPTJN3jAAI=; b=XGZdd/Gztcw38GvdSFl+V2uSKBel7R7uIjB40IrJdV3ii6OjHDFkjoK9QGAcIe7m16 6efxz7aSPfv607RH52MwqMm3o1roKCNQWzfxearnACMXx+m6wNuQMiOZpyskireRo/MW 8skpjIVlei+DJap5/F5/XdQ20TEUFOaT/9Xog= MIME-Version: 1.0 Received: by 10.182.13.1 with SMTP id d1mr493899obc.74.1320847039088; Wed, 09 Nov 2011 05:57:19 -0800 (PST) Received: by 10.182.47.7 with HTTP; Wed, 9 Nov 2011 05:57:18 -0800 (PST) In-Reply-To: <4EA56F96.7040404@pi.nu> References: <4EA56F96.7040404@pi.nu> Date: Wed, 9 Nov 2011 08:57:18 -0500 Message-ID: From: Pablo Frank To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d044402f0914a1804b14daa63 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 13:57:20 -0000 --f46d044402f0914a1804b14daa63 Content-Type: text/plain; charset=ISO-8859-1 Yes/support. Pablo On Mon, Oct 24, 2011 at 10:00 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-**protection an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Sun Nov 6. > > /Loa > for the mpls wg 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 > --f46d044402f0914a1804b14daa63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes/support.

Pablo

On = Mon, Oct 24, 2011 at 10:00 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

this is to start a two week poll to see if there is support to make
draft-weingarten-mpls-tp-ring-protection an mpls working group draft= .

Pleased send your comments to the mpls working group mailing list
(mpls@ietf.org).

This poll ends Sun Nov 6.

/Loa
for the mpls wg chairs
--
--


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

--f46d044402f0914a1804b14daa63-- From martin.vigoureux@alcatel-lucent.com Thu Nov 10 05:40:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4121F8A71 for ; Thu, 10 Nov 2011 05:40:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YSDeb69rT5N for ; Thu, 10 Nov 2011 05:40:23 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2621F8A6F for ; Thu, 10 Nov 2011 05:40:22 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAADe7B3013609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 10 Nov 2011 14:40:20 +0100 Received: from [172.27.205.177] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 10 Nov 2011 14:39:57 +0100 Message-ID: <4EBBD42D.80904@alcatel-lucent.com> Date: Thu, 10 Nov 2011 14:39:57 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 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.69 on 155.132.188.83 Subject: [mpls] IETF 82 - MPLS Sessions - Time to send slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 13:40:24 -0000 All, the final agenda is available here: http://www.ietf.org/proceedings/82/agenda/mpls.txt Please have a look at it. It is now time for the speakers to send me the slides. To those who have a slot, * on Monday: please send me the slides, no later than Sunday, 7pm, Taipei time * on Thursday: please send me the slides, no later than Wednesday, 7pm, Taipei time Failure to provide the slides in time will most likely lead to the move of your slot at the end of Thursday's session. Knowing that the agenda is full, it would be a pity to loose your slot. Also, I do remind you that the slot duration is both for your presentation and the Q&As after. Thank you Martin From gregory.mirsky@ericsson.com Thu Nov 10 09:53:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88721F8A7E; Thu, 10 Nov 2011 09:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmRusaoVeBSr; Thu, 10 Nov 2011 09:53:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 08ADC21F8A69; Thu, 10 Nov 2011 09:53:52 -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 pAAHrNl5026011; Thu, 10 Nov 2011 11:53:48 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 10 Nov 2011 12:53:38 -0500 From: Gregory Mirsky To: "msiva@cisco.com" , "sboutros@cisco.com" , George Swallow , "ssaxena@cisco.com" , "vishwas@ipinfusion.com" , "aldrin.ietf@gmail.com" , "mpls@ietf.org" , "pwe3@ietf.org" Date: Thu, 10 Nov 2011 12:53:37 -0500 Thread-Topic: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 Thread-Index: Acyf0awuBIdnzneBSOq5ZgqYVk9tiQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE157F29FEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 17:53:54 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE157F29FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: * Introduction considers scenario when an intermediate S-PE originate= s LSP Ping and may address an S-PE. Is that valid scenario for on-demand OA= M? If S-PE can generate OAM message, can LSR generate it too? AFAIK, SPME m= ust be used for Segment LSP OAM but the document assumes that for MS-PW S-P= E may generate LSP Ping addressed to another S- or T-PE. * Perhaps TTL is not the best method to be used in S-PE to S-PE OAM (= LSP Ping). I think that Sender's MIP ID can be used to determine correct TT= L value for LSP Echo Reply. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE157F29FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below:<= /div>
•     = ;  Introduction considers scenario wh= en an intermediate S-PE originates LSP Ping and may address an S-PE. Is tha= t valid scenario for on-demand OAM? If S-PE can generate OAM message, can LSR generate it too? AFAIK, SPME must be used for Segment LSP OAM but the d= ocument assumes that for MS-PW S-PE may generate LSP Ping addressed to anot= her S- or T-PE.
•     = ;  Perhaps TTL is not the best method= to be used in S-PE to S-PE OAM (LSP Ping). I think that Sender’s MIP= ID can be used to determine correct TTL value for LSP Echo Reply.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE157F29FEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Thu Nov 10 11:03:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B80521F8A6C for ; Thu, 10 Nov 2011 11:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzmMiDmtq9F1 for ; Thu, 10 Nov 2011 11:03:19 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4C12221F8497 for ; Thu, 10 Nov 2011 11:03:19 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAAJ3F7Z010986; Thu, 10 Nov 2011 13:03:17 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 10 Nov 2011 14:03:09 -0500 From: Gregory Mirsky To: "rolf.winter@neclab.eu" , Eric Gray , "huub.van.helvoort@huawei.com" , "malcolm.betts@zte.com.cn" , "mpls@ietf.org" Date: Thu, 10 Nov 2011 14:03:07 -0500 Thread-Topic: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Thread-Index: Acyf22GeBiBpqfReTauMgILYhIMJXA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15EFDDBEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 19:03:20 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFDDBEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I have a question about the scope of the document. Introduction references = only bi-directional LSPs in "RFC 6370 [RFC6370] defines a set of MPLS-TP tr= ansport and management entity identifiers to support bidirectional (co-rout= ed and associated) point-to-point MPLS-TP LSPs ..." I think that RFC 6370 i= mplicitly defines ID for p2p unidirectional LSP as well in the following fo= rmat: A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID or if globally unique LSP ID required A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::L= SP_Num Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFDDBEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I have a question about the scope of the document. Introduction refere= nces only bi-directional LSPs in “RFC 6370 [RFC6370] defines a set of= MPLS-TP transport and management entity identifiers to support bidirection= al (co-routed and associated) point-to-point MPLS-TP LSPs …” I think that RFC 6370 implicitly defines ID for= p2p unidirectional LSP as well in the following format:
A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID
or if globally unique LSP ID required
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Nu= m}::LSP_Num
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFDDBEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Thu Nov 10 13:22:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38BA21F87C2 for ; Thu, 10 Nov 2011 13:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWuIlmKM6gBI for ; Thu, 10 Nov 2011 13:22:57 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 697E221F88B7 for ; Thu, 10 Nov 2011 13:22:57 -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 pAALMmOm010844; Thu, 10 Nov 2011 15:22:55 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 10 Nov 2011 16:22:51 -0500 From: Gregory Mirsky To: "danfrost@cisco.com" , "stbryant@cisco.com" , "Bocci, Matthew (Matthew)" , "mpls@ietf.org" Date: Thu, 10 Nov 2011 16:22:51 -0500 Thread-Topic: Comment to draft-fbb-mpls-gach-adv-00 Thread-Index: Acyf7ubNgzzU74IGQfqAmd9mEDFtxA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15EFEF4EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comment to draft-fbb-mpls-gach-adv-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 21:22:58 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFEF4EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I've got one question in regard to use of Authentication Data in GAP messag= e. My understanding is that Authentication Data is mandatory part of the GA= P message. I think that authentication is important to provide adequate sec= urity but it is optional capability. Authentication support can be signaled= by A-flag (can be allocated from one of two Reserved fields of the GAP mas= sage) and Authentication of the GAP message provided by optional Authentica= tion Data TLV. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFEF4EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I've got one question in regard to use of Authentication Data in GAP m= essage. My understanding is that Authentication Data is mandatory part of t= he GAP message. I think that authentication is important to provide adequat= e security but it is optional capability. Authentication support can be signaled by A-flag (can be allocated from one= of two Reserved fields of the GAP massage) and Authentication of the GAP m= essage provided by optional Authentication Data TLV.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15EFEF4EUSAACMS0715e_-- From binnyjeshan@gmail.com Thu Nov 10 20:18:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5441F0C3D; Thu, 10 Nov 2011 20:18:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giBoQr2ZoWC3; Thu, 10 Nov 2011 20:18:33 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4397C1F0C35; Thu, 10 Nov 2011 20:18:33 -0800 (PST) Received: by faas12 with SMTP id s12so4219711faa.31 for ; Thu, 10 Nov 2011 20:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+LHZTCA66KlmQ4lb2MEjKgmbeNP7TQQA4lTffhqJ28k=; b=bo+lH4McIWRlgMJfI/vWIC2XpM0nVr6AXxYUjVXYGIW43pd48RWMNm7SoIYTULZpcZ IKCcSIEtK35n9Pmop7wu0cFYnaOI5IMStDy/saB8qY4nNVoAgfij9eJaQeHB7yrG9SFW sqAEqNlIAohOX9+mwzU2SHxeuv0LKe7RriYGw= MIME-Version: 1.0 Received: by 10.223.5.14 with SMTP id 14mr16056670fat.34.1320985110843; Thu, 10 Nov 2011 20:18:30 -0800 (PST) Received: by 10.223.103.5 with HTTP; Thu, 10 Nov 2011 20:18:29 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 09:48:29 +0530 Message-ID: From: binny jeshan To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001517475fb049114004b16dd03d Cc: "mpls@ietf.org" , "vishwas@ipinfusion.com" , "msiva@cisco.com" , "sboutros@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 04:18:34 -0000 --001517475fb049114004b16dd03d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I second Greg to his first point, with some understanding i have about the roles of maintenance points in OAM. Ideally for a MSPW case, having two MEPs at the ends of the MSPW, and MIPs at the intermediate stitching locations could possibly be easily maintainable. In such a architecture, MIPs are expected to respond to requests addressed to it (or likely when it needs to process a OAM packet) and its not expected to 'originate' a packet. http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11 IMHO, Segments should be monitored independently, and MEPs at the end of such segments (those are the LSRs in a MSPW) can originate this LSP Ping.. Please correct in case i missed anything. Regards, Binny J On 10 November 2011 23:23, Gregory Mirsky wrot= e: > Dear Authors, et al., > Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: > =95 Introduction considers scenario when an intermediate S-PE > originates LSP Ping and may address an S-PE. Is that valid scenario for > on-demand OAM? If S-PE can generate OAM message, can LSR generate it too? > AFAIK, SPME must be used for Segment LSP OAM but the document assumes tha= t > for MS-PW S-PE may generate LSP Ping addressed to another S- or T-PE. > =95 Perhaps TTL is not the best method to be used in S-PE to S-PE O= AM > (LSP Ping). I think that Sender=92s MIP ID can be used to determine corre= ct > TTL value for LSP Echo Reply. > > Regards, > Greg > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --001517475fb049114004b16dd03d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I second Greg to his first point, with some understanding i have about the = roles of maintenance points in OAM. Ideally for a MSPW case, having two MEP= s at the ends of the MSPW, and MIPs at the intermediate stitching locations= could possibly be easily maintainable. In such a architecture, MIPs are ex= pected to respond to requests addressed to it (or likely when it needs to p= rocess a OAM packet) and its not expected to 'originate' a packet.= =A0http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11

IMHO, Segments should be monitored independently, and MEPs a= t the end of such segments (those are the LSRs in a MSPW) =A0can originate = this LSP Ping..

Please correct in case i missed an= ything.

Regards,
Binny J

On 10 November 2011 23:23, Gregory Mirsky &l= t;gregory.mirsky@ericsson.co= m> wrote:
Dear Authors, et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below:<= /div>
=95=A0=A0=A0=A0=A0=A0 Introduction considers scenario when an intermediate S-P= E originates LSP Ping and may address an S-PE. Is that valid scenario for o= n-demand OAM? If S-PE can generate OAM message, can LSR generate it too? AFAIK, SPME must be used for Segment LSP OAM but the d= ocument assumes that for MS-PW S-PE may generate LSP Ping addressed to anot= her S- or T-PE.
=95=A0=A0=A0=A0=A0=A0 Perhaps TTL is not the best method to be used in S-PE to= S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to determi= ne correct TTL value for LSP Echo Reply.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
=A0

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


--001517475fb049114004b16dd03d-- From sam.aldrin@gmail.com Thu Nov 10 23:57:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB78B1F0C36; Thu, 10 Nov 2011 23:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ic5dvgEco4C; Thu, 10 Nov 2011 23:57:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 449AF1F0C34; Thu, 10 Nov 2011 23:57:40 -0800 (PST) Received: by iaeo4 with SMTP id o4so5011078iae.31 for ; Thu, 10 Nov 2011 23:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=hMvB3X2yJ9I74hEEOA6sQUzYjLRN18uYVMH5+OggESY=; b=EeQ+c29Y1S1GdCrUDZV0n9s8I+9sP/Zz38rKXQFa91jDN+LZRjDAjbusCcVvyBGar7 7I9w2J9Z9HH2ICqhcUCoZlJcZlxjDM9Fo1Qj0b9n3JMyIxcqwcYgA2jupUJXahHY8hc5 JVgY8/zdxcA95mnldTYH/smMZ5rHr+rgakNms= Received: by 10.231.1.9 with SMTP id 9mr2533742ibd.58.1320998259705; Thu, 10 Nov 2011 23:57:39 -0800 (PST) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id eb23sm15023538ibb.2.2011.11.10.23.57.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 23:57:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_32151DCA-B6C0-47F2-947A-72A96F37325E" From: Sam Aldrin In-Reply-To: Date: Thu, 10 Nov 2011 23:57:36 -0800 Message-Id: <5D714E47-5841-4D48-AE83-8BE57B5B44A9@gmail.com> References: To: Gregory Mirsky X-Mailer: Apple Mail (2.1251.1) Cc: "mpls@ietf.org" , "vishwas@ipinfusion.com" , "msiva@cisco.com" , "sboutros@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 07:57:44 -0000 --Apple-Mail=_32151DCA-B6C0-47F2-947A-72A96F37325E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greg, See inline for my comments On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote: > Dear Authors, et al., > Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: > =95 Introduction considers scenario when an intermediate S-PE = originates LSP Ping and may address an S-PE. Is that valid scenario for = on-demand OAM? %SAM - Yes. We do that already. For ex: interAS optionB. > If S-PE can generate OAM message, can LSR generate it too? %SAM- If it can, why not? But in the case of LSR, it doesn't have info = of PW's. > AFAIK, SPME must be used for Segment LSP OAM but the document assumes = that for MS-PW S-PE may generate LSP Ping addressed to another S- or = T-PE. > =95 Perhaps TTL is not the best method to be used in S-PE to = S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to = determine correct TTL value for LSP Echo Reply. %SAM - It doesn't work in non-TP cases, where MIP ID doesn't exist. This = draft do not just address TP networks. HTH. -sam > =20 > Regards, > Greg --Apple-Mail=_32151DCA-B6C0-47F2-947A-72A96F37325E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Greg,

See inline for my = comments
On Nov 10, 2011, at 9:53 AM, Gregory Mirsky = wrote:

Dear Authors, et = al.,
Please find my comments to = draft-ietf-mpls-lsp-ping-ttl-tlv-01 below:
=95       Introduction considers scenario when an intermediate S-PE = originates LSP Ping and may address an S-PE. Is that valid scenario for = on-demand OAM?
%SAM = - Yes. We do that already. For ex: interAS optionB.
If S-PE can generate OAM = message, can LSR generate it too? =
%SAM- If it can, = why not? But in the case of LSR, it doesn't have info of = PW's.
AFAIK, SPME must be used = for Segment LSP OAM but the document assumes that for MS-PW S-PE may = generate LSP Ping addressed to another S- or = T-PE.
=95       Perhaps TTL is not the best method to be used in S-PE to = S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to = determine correct TTL value for LSP Echo = Reply.
%SAM - It = doesn't work in non-TP cases, where MIP ID doesn't exist. This draft do = not just address TP = networks.

HTH.
-sam
 
       = ; = Regards,
         &= nbsp;      = Greg

= --Apple-Mail=_32151DCA-B6C0-47F2-947A-72A96F37325E-- From sam.aldrin@gmail.com Fri Nov 11 00:04:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA71F0C62; Fri, 11 Nov 2011 00:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fupr65M54UQv; Fri, 11 Nov 2011 00:04:05 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACC1F0C5F; Fri, 11 Nov 2011 00:04:04 -0800 (PST) Received: by gye5 with SMTP id 5so3158445gye.31 for ; Fri, 11 Nov 2011 00:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=o5lvOAC8Twwrz3j8+gbY7Z6D0mq8GUC1mqueXMH5Q08=; b=SiHk1P4QswWZWM8kPEFpuG36hhfpwUsbVoaxtfV4c+nUopkPg3430f+DFtEbJ2ydLV Wm1gZVb5qLR6GqkffA84uw5nvU2P8D2vbz/d/FwsmXHD/0YEkKKR6QHKkNQkdN+gMkd3 wIDhbyORsm3zPZgp5+zMfijWCoj2pDQCnCPQY= Received: by 10.68.20.234 with SMTP id q10mr15949035pbe.27.1320998644430; Fri, 11 Nov 2011 00:04:04 -0800 (PST) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id s4sm28161329pbq.8.2011.11.11.00.04.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 00:04:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C2BB13F-5FFF-473C-9D49-72F7E219AE37" From: Sam Aldrin In-Reply-To: Date: Fri, 11 Nov 2011 00:04:01 -0800 Message-Id: References: To: binny jeshan X-Mailer: Apple Mail (2.1251.1) Cc: "mpls@ietf.org" , "vishwas@ipinfusion.com" , "msiva@cisco.com" , "sboutros@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] [PWE3] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 08:04:07 -0000 --Apple-Mail=_0C2BB13F-5FFF-473C-9D49-72F7E219AE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See inline for my comments. On Nov 10, 2011, at 8:18 PM, binny jeshan wrote: > I second Greg to his first point, with some understanding i have about = the roles of maintenance points in OAM. Ideally for a MSPW case, having = two MEPs at the ends of the MSPW, and MIPs at the intermediate stitching = locations could possibly be easily maintainable. %SAM - Not necessarily true. One would want to perform OAM operations = between SPE's itself. There is no restriction to do that. > In such a architecture, MIPs are expected to respond to requests = addressed to it (or likely when it needs to process a OAM packet) and = its not expected to 'originate' a packet. = http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11 %SAM - This draft is not just for TP networks. -sam >=20 > IMHO, Segments should be monitored independently, and MEPs at the end = of such segments (those are the LSRs in a MSPW) can originate this LSP = Ping.. >=20 > Please correct in case i missed anything. >=20 > Regards, > Binny J >=20 > On 10 November 2011 23:23, Gregory Mirsky = wrote: > Dear Authors, et al., > Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: > =95 Introduction considers scenario when an intermediate S-PE = originates LSP Ping and may address an S-PE. Is that valid scenario for = on-demand OAM? If S-PE can generate OAM message, can LSR generate it = too? AFAIK, SPME must be used for Segment LSP OAM but the document = assumes that for MS-PW S-PE may generate LSP Ping addressed to another = S- or T-PE. > =95 Perhaps TTL is not the best method to be used in S-PE to = S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to = determine correct TTL value for LSP Echo Reply. > =20 > Regards, > Greg > =20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 --Apple-Mail=_0C2BB13F-5FFF-473C-9D49-72F7E219AE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = inline for my comments.
On Nov 10, 2011, at 8:18 PM, binny = jeshan wrote:

I second Greg to his first point, with some understanding = i have about the roles of maintenance points in OAM. Ideally for a MSPW = case, having two MEPs at the ends of the MSPW, and MIPs at the = intermediate stitching locations could possibly be easily = maintainable.
%SAM - Not necessarily true. One would want to = perform OAM operations between SPE's itself. There is no restriction to = do that.
In such a architecture, MIPs are = expected to respond to requests addressed to it (or likely when it needs = to process a OAM packet) and its not expected to 'originate' a = packet. ht= tp://tools.ietf.org/html/draft-ietf-mpls-tp-oam-framework-11%SAM - This draft is not just for TP = networks.

-sam
=
IMHO, Segments should be monitored independently, and = MEPs at the end of such segments (those are the LSRs in a MSPW) =  can originate this LSP Ping..

Please = correct in case i missed anything.

Regards,
Binny J

On 10 November 2011 23:23, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
Dear Authors, et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 = below:
=95       Introduction considers scenario when an intermediate S-PE = originates LSP Ping and may address an S-PE. Is that valid scenario for = on-demand OAM? If S-PE can generate OAM message, can LSR generate it too? AFAIK, SPME must be used for Segment LSP OAM but = the document assumes that for MS-PW S-PE may generate LSP Ping addressed = to another S- or T-PE.
=95       Perhaps TTL is not the best method to be used in S-PE to = S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to = determine correct TTL value for LSP Echo Reply.
 
        Regards,
=
           &nb= sp;    Greg
 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3



= --Apple-Mail=_0C2BB13F-5FFF-473C-9D49-72F7E219AE37-- From eric.gray@ericsson.com Fri Nov 11 03:32:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C6C21F86EE for ; Fri, 11 Nov 2011 03:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84UsMdWOI3ll for ; Fri, 11 Nov 2011 03:32:20 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2975B21F86EC for ; Fri, 11 Nov 2011 03:32:20 -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 pABBW5p2031890; Fri, 11 Nov 2011 05:32:15 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 11 Nov 2011 06:32:01 -0500 From: Eric Gray To: Gregory Mirsky Date: Fri, 11 Nov 2011 06:31:58 -0500 Thread-Topic: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Thread-Index: Acyf22GeBiBpqfReTauMgILYhIMJXAAAjfkA 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_C0AC8FAB6849AB4FADACCC70A949E2F1190C20AC09EUSAACMS0701e_" MIME-Version: 1.0 Cc: "huub.van.helvoort@huawei.com" , "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 11:32:22 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1190C20AC09EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, This draft is only interested in addressing identifiers associated = with bi-directional LSP - at least at present. RFC 6370 does define identifiers that can be us= ed for this case, that are based on IP/MPLS conventions. So the statement is accurate. However, we could try to make it clearer that we're not saying that= RFC 6370 is limited to the bi-directional case. The difficulty lies in trying to make = this clearer without complicating the text with information that is not relevant to this draft. For example, if we explicily state that RFC 6370 includes support f= or IP/MPLS based identifiers for unidirectional LSPs, we would also need to explicitly= state that this type of identifier either doesn't apply to this dcoument, or is out of scop= e. In general, I don't think it is necessarily a good idea to add text to a document that th= en makes it necessary to add additional text to clarify that the previously added text = is out of scope in the document. Perhaps you can suggest wording that makes the fact that RFC 6370 d= oes not limit identifiers to the bi-directional case clearer, without making it nec= essary to then add that this document is limited in this respect? -- Eric _____________________________________________ From: Gregory Mirsky Sent: Thursday, November 10, 2011 2:03 PM To: rolf.winter@neclab.eu; Eric Gray; huub.van.helvoort@huawei.com; mal= colm.betts@zte.com.cn; mpls@ietf.org Subject: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Importance: High Dear Authors, et al., I have a question about the scope of the document. Introduction references = only bi-directional LSPs in "RFC 6370 [RFC6370] defines a set of MPLS-TP tr= ansport and management entity identifiers to support bidirectional (co-rout= ed and associated) point-to-point MPLS-TP LSPs ..." I think that RFC 6370 i= mplicitly defines ID for p2p unidirectional LSP as well in the following fo= rmat: A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID or if globally unique LSP ID required A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::L= SP_Num Regards, Greg --_000_C0AC8FAB6849AB4FADACCC70A949E2F1190C20AC09EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,
 
        Thi= s draft is only interested in addressing identifiers associated with bi-dir= ectional
LSP - at least at present.  RFC 6370 d= oes define identifiers that can be used for this case,
that are based on IP/MPLS conventions.  S= o the statement is accurate.
 
        How= ever, we could try to make it clearer that we're not saying that RFC 6370 i= s
limited to the bi-directional case.  The = difficulty lies in trying to make this clearer without
complicating the text with information that is= not relevant to this draft.
 
        For= example, if we explicily state that RFC 6370 includes support for IP/MPLS<= /font>
based identifiers for unidirectional LSPs, we = would also need to explicitly state that this
type of identifier either doesn't apply to thi= s dcoument, or is out of scope.  In general, I
don't think it is necessarily a good idea to a= dd text to a document that then makes it
necessary to add additional text to clarify th= at the previously added text is out of scope
in the document.
 
        Per= haps you can suggest wording that makes the fact that RFC 6370 does not
limit identifiers to the bi-directional case c= learer, without making it necessary to then add
that this document is limited in this respect?=
 
--
Eric
_________________________= ____________________
From:    Gregory Mirsky&nbs= p;
Sent:   Thursday, November 10, 2= 011 2:03 PM
To:     rolf.winter@ne= clab.eu; Eric Gray; huub.van.helvoort@huawei.com; malcolm.betts@zte.com.cn;= mpls@ietf.org
Subject:      &n= bsp; Comments to draft-ietf-mpls-tp-itu-t-identifiers-02
Importance:     High
 
Dear Authors, et al.,
I have a question about the scope of the document. Introduction refere= nces only bi-directional LSPs in “RFC 6370 [RFC6370] defines a set of= MPLS-TP transport and management entity identifiers to support bidirection= al (co-routed and associated) point-to-point MPLS-TP LSPs …” I think that RFC 6370 implicitly defines ID for= p2p unidirectional LSP as well in the following format:
A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID
or if globally unique LSP ID required
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Nu= m}::LSP_Num
 
        Regards,
           &nbs= p;    Greg
 
 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1190C20AC09EUSAACMS0701e_-- From loa@pi.nu Fri Nov 11 09:31:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3740A21F8AEA for ; Fri, 11 Nov 2011 09:31:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fj93C8e6-SA for ; Fri, 11 Nov 2011 09:31:07 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89F21F8AD3 for ; Fri, 11 Nov 2011 09:31:05 -0800 (PST) Received: from [172.20.0.206] (unknown [203.69.99.17]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 5B0732A8004; Fri, 11 Nov 2011 18:30:50 +0100 (CET) Message-ID: <4EBD5BC8.2090208@pi.nu> Date: Sat, 12 Nov 2011 02:30:48 +0900 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Eric Gray References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "huub.van.helvoort@huawei.com" , "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 17:31:08 -0000 Eric, throughout the mpls-tp project it has been said that mpls-tp includes the LSP topology constructs as defined in RFC5654 2.1 General Requirements. "7 MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths." "8 MPLS-TP MUST support unidirectional point-to-multipoint transport paths." I think that should be the scope of this (mpls-tp) draft also, alternatively if we make applicable to co-routed bidirectional LSP only, the reason for this needs to be very clearly stated in the draft. /Loa On 2011-11-11 20:31, Eric Gray wrote: > Greg, > This draft is only interested in addressing identifiers associated with > bi-directional > LSP - at least at present. RFC 6370 *does* define identifiers that can > be used for this case, > that are based on IP/MPLS conventions. So the statement is accurate. > However, we could try to make it clearer that we're not saying that RFC > 6370 is > limited to the bi-directional case. The difficulty lies in trying to > make this clearer without > complicating the text with information that is not relevant to this draft. > For example, if we explicily state that RFC 6370 includes support for > IP/MPLS > based identifiers for unidirectional LSPs, we would also need to > explicitly state that this > type of identifier either doesn't apply to this dcoument, or is out of > scope. In general, I > don't think it is necessarily a good idea to add text to a document that > then makes it > necessary to add additional text to clarify that the previously added > text is out of scope > in the document. > Perhaps you can suggest wording that makes the fact that RFC 6370 does not > limit identifiers to the bi-directional case clearer, without making it > necessary to then add > that this document is limited in this respect? > -- > Eric > _____________________________________________ > *From: *Gregory Mirsky > *Sent: *Thursday, November 10, 2011 2:03 PM > *To: *rolf.winter@neclab.eu; Eric Gray; huub.van.helvoort@huawei.com; > malcolm.betts@zte.com.cn; mpls@ietf.org > *Subject: *Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 > *Importance: *High > Dear Authors, et al., > I have a question about the scope of the document. Introduction > references only bi-directional LSPs in “RFC 6370 [RFC6370] defines a set > of MPLS-TP transport and management entity identifiers to support > bidirectional (co-routed and associated) point-to-point MPLS-TP LSPs …” > I think that RFC 6370 implicitly defines ID for p2p unidirectional LSP > as well in the following format: > A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID > or if globally unique LSP ID required > A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::LSP_Num > Regards, > Greg > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Alexander.Vainshtein@ecitele.com Sat Nov 12 00:47:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CE521F84C3 for ; Sat, 12 Nov 2011 00:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F42reH9vFbs6 for ; Sat, 12 Nov 2011 00:47:51 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 0FF4C21F84C5 for ; Sat, 12 Nov 2011 00:47:50 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1321087638!52797972!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 29252 invoked from network); 12 Nov 2011 08:47:18 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-5.tower-27.messagelabs.com with SMTP; 12 Nov 2011 08:47:18 -0000 X-AuditID: 93eaf2e7-b7f496d000000e76-2e-4ebe40ad4cc6 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id C6.1A.03702.DA04EBE4; Sat, 12 Nov 2011 11:47:25 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 12 Nov 2011 10:47:47 +0200 From: Alexander Vainshtein To: "danfrost@cisco.com" , "Stewart Bryant (stbryant@cisco.com)" , "matthew.bocci@alcatel-lucent.com" Date: Sat, 12 Nov 2011 10:47:47 +0200 Thread-Topic: A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv Thread-Index: AQHMoRfA95loNZo36U+XziZtvDbQEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760111F1195968ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURTO3ZndnVZHxra1txtkjGewza62yQpbjVSUsEjRRKQ1dq/dYXdm MzOVViTqB2UjQrRKEURp0QZVj6BFH5oi6lnVBz+0pa1fIkRp10yH6h//vnPO9537nXvPJTBT ntFCcLyMRJ71M4ZI/HDfl6/WipQal21/3QzH97KwzlEX6gSOtnMX9I6n3SdACp62u6dan1bw 86o+raTkh24Vtj4PLGB5XpBZGdEeJLmdzCqR28a6cxma8zgZO0MH/awbBRAvOxk2GES8h0mO XKAkOZ5GvFvwcLzXySxNX2l1OJLmWe1M8vQp9oT5kWt8nEQja4Dl/HQASRLrRbSSUQ3zHuSh NwsiLfsQLW48jPl6rx0yBB9n5NR/ycfyQPWyEIggIJUIy4tbcA2Ph8/eXTaEQCRhou4B2Hji oVELjgDY115hVFkGygkrL3UOs2KoKgCfnA8PBxjVooP9384YVBZOTYMNg58xFUdTG2DlgafK GUZFwcIryWo2hoqHg801QMUktRoW3b85jIHi4vujcp2KMcoM27pO6TR3FCy524xpOBb2fhjS a/xY2JF/GWh8AX4qHMC1nuNg07GuP5PFwQdlrfhBEFM8qm3xKEnxKImWj4ethQUGDc+G58/0 Yxq2wqNDtfjo/GlgvAhiOX9Q3hTw2uzxyM3JyI/i3UKgEmg78/EWGDg1tRZQBGCiyCvBapdJ z26TcgO1II7QMbHkG1uNyzR2k+DJ9bGSL0vM9iOpFkACY2LIfScVOulhc7cjUfhbWqzc8SHM MsYtqI8tZyXYbP8PGDPZ7f68wkR5lRXcilAQiX/7zCAI6vqLkNGC8wKPGEgScxUn40TkRTmb Ob/8j6kjIlRHUYqjBrvCIaUgG5A4r1Z/BCZbzOQYVUypBV82P6JVP87OcDjcB8zK/NFkkyqP UrZ0RN2nNNYpjXFaHVVSfspIyZIHljyv72lyZa19v+V9yq+2DpfgStu38vXc9NtxN5d3N2N7 4lBZoq1jICv1yf6Zmf3rjlVsuNGbNKFx0bXKtZkXk6J2vWw3T9xanuEMiPl70psfDGI7Fs9J feVa+HZvfnammehJqCoqFSIKuKKJx0vIqtDCs01FpYXpR+68nZRaWl7fXcfgko+1z8JEif0N JsCSmRMEAAA= Cc: "mpls@ietf.org" , Vladimir Kleiner , Yaniv Tsabari , Mishael Wexler , Gideon Agmon , Oded Mann , Rotem Cohen Subject: [mpls] A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 08:47:52 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111F1195968ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dan, Stewart, Matthew and all, I have a comment on draft-fbb-mpls-tp-ethernet-addressing and draft-fbb-mpls= -gach-adv. It stems from my reservations regarding the following text in the= Section 2 "P2P Link Addressing" of draft-fbb-mpls-tp-ethernet-addressing: The approach which SHOULD be used, in view of these considerations, is therefore to use as the destination MAC address an Ethernet multicast address reserved for MPLS-TP for use over point-to-point links. The address allocated for this purpose by the Internet Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX. An MPLS-TP implementation MUST process Ethernet frames received over a point-to- point link with this destination MAC address by default. The address allocated for this purpose by the Internet Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX. An MPLS-TP implementation MUST process Ethernet frames received over a point-to- point link with this destination MAC address by default. The problem, as I see it, is that in certain cases the operator of the MPLS-= TP node does not know whether the link in question is a P2P link or an MP2MP= one. E.g., consider the case when several MPLS-TP islands are interconnecte= d over an IP/MPLS core using an Ethernet service provided in this core. Furt= her consider the case when the application for this interconnection requires= only "hub-and-spoke" connectivity. s that the spoke NEs only see a single h= ub peer behind their (seemingly P2P) Ethernet link. However, the actual conn= ectivity between the hub and the spokes could be provided by the operator of= the IP/MPLS core in two different ways: * As a bunch of P2P Ethernet PWs, each of them using a dedicated VLAN as its A= C at the hub side, and the entire port as its AC at the spoke side * As a single VPLS service using the entire port as its AC at each side. It is worth noticing that the IP/MPLS core operator could change the type of= connectivity it provides for interconnection of the MPLS-TP islands, and th= e spoke nodes should remain completely unaware of that fact - unless they ha= ve been using multicast Ethernet addressing for the traffic they have been s= ending to the hub node. At the same time it is clear that MPLS-TP nodes MUST accept Ethernet frames= with the reserved (well-known) multicast address for the G-ACh Advertisemen= t Protocol (draft-fbb-mpls-gach-adv) to work properly. Hence I would suggest the following changes to the two drafts: 1. Move the definition of the well-known multicast MAC Address for MPLS-TP= from draft-fbb-mpls-tp-ethernet-addressing to draft-fbb-mpls-gach-adv 2. Specify that G-ACH Advertisement protocol MUST use this address as the= destination MAC address when it runs over Ethernet links 3. In draft-fbb-mpls-tp-ethernet-addressing: * Indicate that using the well-known multicast MAC Address for MPLS-TP= for the non-G-ACh traffic, while possible, is NOT RECOMMENDED due to the fr= agile nature of the P2P vs. P2MP link nature * Indicate that support of the G-ACh Advertisement protocol is RECOMME= NDED in MPLS-TP using Ethernet links * Indicate that using the MAC address of the intended peer port (wheth= er statically configured or discovered via any means including the G-ACh Adv= ertisement protocol), in addition to being MANDATORY on MP2MP links is RECOM= MENDED also on links presumed to be P2P. Hopefully these notes will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111F1195968ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dan, Stewart, Matthew and all,
I have a comment on draft-fb= b-mpls-tp-ethernet-a= ddressing and draft-fbb-mpls-gach-= adv. It stems from my reservations reg= arding the following text in the Section 2 "P2P Link Addressing= " of  draft-fbb-mpls-tp-ethernet-addressing:
The approach which SHOULD be used, in view of these considerations, <=
/pre>

is therefore to use as the destination MAC address an Ethernet
multicast address reserved for MPLS-TP for use over point-to-point
links.  The address allocated for this purpose by the Internet
Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX.  An MPLS-TP
implementation MUST process Ethernet frames received over a point-to-
point link with this destination MAC address by default. 
The address a=
llocated for this purpose by the Internet
Assigned Numbers Authority (IANA) is 01-00-5E-XX-XX-XX.  An MPLS-TP
implementation MUST process Ethernet frames received over a point-to-
point link with this destination MAC address by default.
The problem, as I see it, is= that in certain cases the operator of the MPLS-TP node does not know whethe= r the link in question is a P2P link or an MP2MP one. E.g., consider the cas= e when several MPLS-TP islands are interconnected over an IP/MPLS core using an Ethernet service provided in t= his core. Further consider the case when the application for this interconne= ction requires only "hub-and-spoke" connectivity. s that the spoke= NEs only see a single hub peer behind their (seemingly P2P) Ethernet link. = However, the actual connectivity between the hub and the spokes could be pro= vided by the operator of the IP/MPLS core in two different ways:
  • As a bunch of P2P Ethernet PWs, each of= them using a dedicated VLAN as its AC at the hub side, and the entire port= as its AC at the spoke side
  • As a single VPLS service using the entir= e port as its AC at each side.

It is worth noticing that the IP/MPLS core= operator could change the type of connectivity it provides for interconnect= ion of the MPLS-TP islands, and the spoke nodes should remain completely una= ware of that fact - unless they have been using multicast Ethernet addressing for the traffic they have bee= n sending to the hub node.

 

At the same time it is clear that MPL= S-TP nodes MUST accept Ethernet frames with the reserved (well-k= nown) multicast address for the G-ACh Advertisement Proto= col (draft-fbb-mpls-gach-adv) to work properly.

 

Hence I would suggest the following change= s to the two drafts:

  1. Move the definition of the well= -known multicast MAC Address for MPLS-TP from draft-fbb-mpls-tp-ethernet-addressing&= nbsp; to draft-fbb-mpls-gach-= adv
  2. Specify that G-ACH Advertisem= ent protocol MUST use this address as the destination MAC address when it ru= ns over Ethernet links
  3. In draft-fbb-mpls-tp-ethernet-addressing:
    • Indicate that using the well-known m= ulticast MAC Address for MPLS-TP for the non-G-ACh traf= fic, while possible, is NOT RECOMMENDED due to the fragile nature of the P2P= vs. P2MP link nature
    • Indicate that support of the G-ACh Advertisement protocol is RECOMMENDED in MPLS-TP using Ethernet= links
    • Indicate that using the MAC address= of the intended peer port (whether statically configured or discovered via= any means including the G-ACh Advertisement protocol), in add= ition to being MANDATORY on MP2MP links is RECOMMENDED also on links presumed to be P2P.

Hopefully these notes will be useful.

 

Regards,

     Sasha

 

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111F1195968ILPTMAIL02e_-- From martin.vigoureux@alcatel-lucent.com Sun Nov 13 01:28:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374A221F8B03 for ; Sun, 13 Nov 2011 01:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aInWI9AM4S3I for ; Sun, 13 Nov 2011 01:28:08 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70B21F8B02 for ; Sun, 13 Nov 2011 01:28:08 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pAD9S8V5019236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 13 Nov 2011 03:28:08 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAD9S7Xw016253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 13 Nov 2011 03:28:08 -0600 Received: from [135.244.32.252] (135.3.62.245) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 13 Nov 2011 03:27:43 -0600 Message-ID: <4EBF8D8C.1060302@alcatel-lucent.com> Date: Sun, 13 Nov 2011 10:27:40 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 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.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [mpls] Information concerning MPLS WG Sessions @IETF82 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 09:28:09 -0000 Session I; Monday, 09:00-11:30 On site participation: Room 201 DEF Remote participation: Webex link: https://ietf.webex.com/ietf/j.php?ED=147327777&UID=1223699247&PW=NNmFmODk3YjMz&RT=MiM0OA== Webex Meeting Number: 642 320 481 Audio stream: http://ietf82streaming.dnsalias.net/ietf/ietf827.m3u Chat room: mpls@jabber.ietf.org Session II; Thursday, 15:20-17:20 On site participation: Room 201 DEF Remote participation: Webex link: https://ietf.webex.com/ietf/j.php?ED=147326812&UID=1223698282&PW=NOWE3N2I1ODcx&RT=MiM0OA== Webex Meeting Number: 646 329 715 Audio stream: http://ietf82streaming.dnsalias.net/ietf/ietf827.m3u Chat room: mpls@jabber.ietf.org Agenda, presentations and minutes: http://tools.ietf.org/wg/mpls/agenda?item=agenda82.html https://datatracker.ietf.org/meeting/82/materials.html From danfrost@cisco.com Sun Nov 13 07:56:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B121F891D for ; Sun, 13 Nov 2011 07:56:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4c874X5991Y for ; Sun, 13 Nov 2011 07:56:03 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 39FF221F861E for ; Sun, 13 Nov 2011 07:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=732; q=dns/txt; s=iport; t=1321199764; x=1322409364; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=4KIkV9gP47kPa9sCxiqzkPfVQusjruk5mD/YVg6IjcM=; b=XxviuVmnrY//xmJdJ0+kVVQnsQd18m8PuLtPDWBo/BN/RtDx21LT1CQu 9WtN/uX8bonBhi7nv1YSr1Yx64B4i6R4Rq5KONTUZnYWn4E/nYqacDJX4 afbj4FEOVuDGuIINdVcUIzxMtG3xLtv0Q30s0zHPahyETByESoMONFo6z Q=; X-IronPort-AV: E=Sophos;i="4.69,503,1315180800"; d="scan'208";a="35497502" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 13 Nov 2011 15:56:04 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pADFu3IV025658; Sun, 13 Nov 2011 15:56:03 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id pADFu39f022884; Sun, 13 Nov 2011 10:56:03 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id pADFu1N0022883; Sun, 13 Nov 2011 15:56:01 GMT Date: Sun, 13 Nov 2011 15:56:00 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20111113155600.GA22776@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: Oded Mann , Vladimir Kleiner , "mpls@ietf.org" , Yaniv Tsabari , Mishael Wexler , Gideon Agmon , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:56:04 -0000 Hi Sasha, On Sat, Nov 12, 2011 at 10:47:47AM +0200, Alexander Vainshtein wrote: > ... > The problem, as I see it, is that in certain cases the operator of the > MPLS-TP node does not know whether the link in question is a P2P link > or an MP2MP one. To quote Section 2 of the ethernet-addressing draft: The use of broadcast or multicast addressing is applicable only when the attached Ethernet link is known to be point-to-point. If a link is not known to be point-to-point, these forms of addressing MUST NOT be used. So in situations such as those you describe, where the operator is not certain a link is and will remain point-to-point, it is considered multipoint by default. Cheers, -d From Alexander.Vainshtein@ecitele.com Sun Nov 13 08:24:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADD921F8ACC for ; Sun, 13 Nov 2011 08:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Bn0mOa-bDT for ; Sun, 13 Nov 2011 08:23:59 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id D0AEB21F8ABE for ; Sun, 13 Nov 2011 08:23:58 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1321201431!3988131!3 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 25603 invoked from network); 13 Nov 2011 16:23:57 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-21.messagelabs.com with SMTP; 13 Nov 2011 16:23:57 -0000 X-AuditID: 93eaf2e7-b7f496d000000e76-3d-4ebffd12ad5e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7F.28.03702.21DFFBE4; Sun, 13 Nov 2011 19:23:30 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 13 Nov 2011 18:23:56 +0200 From: Alexander Vainshtein To: Dan Frost Date: Sun, 13 Nov 2011 18:23:55 +0200 Thread-Topic: A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv Thread-Index: AcyiHMIHvKEFGtCOTHq6Btj5bLlCYQAARvSQ Message-ID: References: <20111113155600.GA22776@cisco.com> In-Reply-To: <20111113155600.GA22776@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0zUWBjNnXZKGaiWUZzL/KrXV3QFZkTNGBmyyRqDTzRqorgG6vQy0zjT mbSVMCbKKLus9o8QjQFEQUWDYER8BLO7hiy7kYhvf/nA9yuOKLuCGkXFlkZk/537feec79z2 uzRh76WctCipWJb4IKJs5K74m/50++f2pa7qe5TnfeOgxfO3dhd4bh8+avVceVoLfiRzf312 zpq7e6DVmtvQ8MGyjMiPgWxeksIqr2JOwIrPi5bJYjHviyJOFLzIjbhIkPfhEJZUL+IjESwJ KMeWrRdFicOSLyyIkt+LFqzIS/d4Zs1Jd6OcyRPcWXNtKwOiwuH0EC8GuRBWFN6POb1iBJYE LHBFYZlTA5iTC3cRga0dbVSke1xJ9e4BMgYq7RqgacjOhI8uZ2ggUYfj4LV7LZQGbLSdbQfw QMt5q3nYA2DL9b4Eg0WxXniy+S5l4LEsgrGdhyyGEcHeIWBtnlEm2Unw3b5XFgOPYQth7cFL pAYSdDoPT+SYwhmwsusfYGCGXQ47Pz8YMrSzxbDzTBVh4EQ2E+7f/mVoKNCjve86NuRIsA54 +0mdxYzMwoY/rxImToUvHn+xmvxU2P1bCzD502H9H28oE/8Ajxx4SZhzU+CF6iekqU2DfzXe JCuAo2bEiJoR8poR8poR8npANoFUMRhR14f8LncG9okqDuIMXzh0Epj78vws+Fg3sQOwNEDJ zGpX+1K7lS9WoqEOkEZbUCpT3qOXRq0PC9EArwQK5I1BrHQASBNoLBNt1HuMwEc3YTn8reXR v3El4UzyhY0frRZkuVz/OyAH89TXs8TO+vWN24BxBMvfpFNomj1zQ0twklJYwggy0mt9QIqM /bikSAyq35kWOtEIkayHyIwbIZQIH1JEv9nvAuOdDkYzxKzRCGyUhrXGOykdHByMA4d+5THM BoOVrC/lsDquG1t0Y5I7ZxjrD2O45YyBrnV9n9Y9QLUrhYdtaW1VPz3O7R7dm9n48+JT5fN/ Z679W1Qxg5yntaYs3Duq734++Ra/nl6XqPV/TBJfTNlWYA2scr2aOlB2tvzy9s15/YWL6iry t5ZnNyVv+6+0NKnn+MXjZVt2lP1yqjmrJG6jWmO3Tm+ZvWbTjbVz5Yfeeb1rqzrnI1IJ8O5p hKzwXwEYdQbuAgQAAA== Cc: Oded Mann , Vladimir Kleiner , "mpls@ietf.org" , Yaniv Tsabari , Mishael Wexler , Gideon Agmon , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 16:24:00 -0000 Dan, Lots of thanks for a prompt response. As I see it, there are two different aspects of Ethernet addressing for MPLS= -TP: - addressing used by the "transport applications" - addressing used by various "helper protocols" (including G-ACh Advertisem= ent protocol). With the two drafts as today this differentiation is not clear. E.g., suppos= e that the operator intends to run MPLS-TP over a link that is not known to= be a P2P one, and cannot use ARP over this link to resolve MAC address(es)= of the potential MPLS-TP peers reachable via this link. The text from Section 2 which you quote says that multicast addressing MUST= NOT be used with MPLS-TP. If interpreted strictly, this can be understood a= s a prohibition to use it also for the G-Ach-based advertisement protocol be= cause it does not really differ from any other MPLS-TP traffic. Hence the need (as I see it) to refactor the two drafts in such a way that t= he G-Ach advertisement protocol over Ethernet links would (if used) always u= se the well-known multicast address. In order to achieve that this address m= ust be defined in the draft that defines the G-Ach advertisement protocol, a= nd its usage with this protocol MUST be allowed on all types of links. When it comes to transport applications - IMHO and FWIW a link that has been= a P2P one yesterday may easily become a P2MP link tomorrow. Hence it seems useful to me to stress that while multicast addressing MAY be= used by the transport applications on kinks known to be P2P, it is still NO= T RECOMMENDED. Hopefully this clarifies my position. Regards, Sasha > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com] > Sent: Sunday, November 13, 2011 5:56 PM > To: Alexander Vainshtein > Cc: Stewart Bryant (stbryant@cisco.com); matthew.bocci@alcatel- > lucent.com; mpls@ietf.org; Mishael Wexler; Rotem Cohen; Gideon Agmon; > Andrew Sergeev; Vladimir Kleiner; Yaniv Tsabari; Oded Mann > Subject: Re: A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and > draft-fbb-mpls-gach-adv > > Hi Sasha, > > On Sat, Nov 12, 2011 at 10:47:47AM +0200, Alexander Vainshtein wrote: > > ... > > The problem, as I see it, is that in certain cases the operator of the > > MPLS-TP node does not know whether the link in question is a P2P link > > or an MP2MP one. > > To quote Section 2 of the ethernet-addressing draft: > > The use of broadcast or multicast addressing is applicable only when > the attached Ethernet link is known to be point-to-point. If a link > is not known to be point-to-point, these forms of addressing MUST NOT > be used. > > So in situations such as those you describe, where the operator is not > certain a link is and will remain point-to-point, it is considered > multipoint by default. > > Cheers, > > -d This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From danfrost@cisco.com Sun Nov 13 14:11:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1833E21F8AE6 for ; Sun, 13 Nov 2011 14:11:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+MyEfSopCTG for ; Sun, 13 Nov 2011 14:11:17 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4221F8ADC for ; Sun, 13 Nov 2011 14:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=2235; q=dns/txt; s=iport; t=1321222277; x=1322431877; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6dZJgXeyegwqc3bzNFqBAd7y8bKyTZrGvWRpCP7g0Lc=; b=c2lUgvtW094/XpYvEVI/MBmK7kA3Ha6Kvvuw9Su/0i6q4B2EJT5LP0nY JAV8H1OEofHLc/Pygp/rhne1YacxJ+OoV6bTS9dbDzueFEmA4NXEkXFDi 8iq1mpUMF7lEtHOm+432eWosZ5xyNJXvmEImEN3/OoYO5AjzzowJqDACX c=; X-IronPort-AV: E=Sophos;i="4.69,503,1315180800"; d="scan'208";a="35545685" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2011 22:11:16 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pADMBFOF017110; Sun, 13 Nov 2011 22:11:16 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id pADMBFrO026771; Sun, 13 Nov 2011 17:11:15 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id pADMBDWo026770; Sun, 13 Nov 2011 22:11:13 GMT Date: Sun, 13 Nov 2011 22:11:13 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20111113221113.GA26558@cisco.com> References: <20111113155600.GA22776@cisco.com> 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: Oded Mann , Vladimir Kleiner , "mpls@ietf.org" , Yaniv Tsabari , Mishael Wexler , Gideon Agmon , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [mpls] A comment on draft-fbb-mpls-tp-ethernet-addressing-00 and draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 22:11:18 -0000 Hi Sasha, On Sun, Nov 13, 2011 at 06:23:55PM +0200, Alexander Vainshtein wrote: > As I see it, there are two different aspects of Ethernet addressing > for MPLS-TP: > - addressing used by the "transport applications" > - addressing used by various "helper protocols" (including G-ACh > Advertisement protocol). > > With the two drafts as today this differentiation is not clear. E.g., > suppose that the operator intends to run MPLS-TP over a link that is > not known to be a P2P one, and cannot use ARP over this link to > resolve MAC address(es) of the potential MPLS-TP peers reachable via > this link. > > The text from Section 2 which you quote says that multicast addressing > MUST NOT be used with MPLS-TP. If interpreted strictly, this can be > understood as a prohibition to use it also for the G-Ach-based > advertisement protocol because it does not really differ from any > other MPLS-TP traffic. That's not the intent. The last paragraph of Section 2 is intended to refer only to use of the multicast address defined in that section. We can certainly clarify this. > Hence the need (as I see it) to refactor the two drafts in such a way > that the G-Ach advertisement protocol over Ethernet links would (if > used) always use the well-known multicast address. In order to achieve > that this address must be defined in the draft that defines the G-Ach > advertisement protocol, and its usage with this protocol MUST be > allowed on all types of links. This is already the case. Section 7 of the GAP draft defines the Ethernet multicast address used by the GAP and places no restrictions on the link type. > When it comes to transport applications - IMHO and FWIW a link that > has been a P2P one yesterday may easily become a P2MP link tomorrow. > Hence it seems useful to me to stress that while multicast addressing > MAY be used by the transport applications on kinks known to be P2P, it > is still NOT RECOMMENDED. I'm not sure I'd state it quite this way, but I agree that it would at least be good to stress this potential pitfall of the point-to-point multicast address. Cheers, -d > Hopefully this clarifies my position. > > Regards, Sasha From gregory.mirsky@ericsson.com Sun Nov 13 14:49:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0C921F8B0E; Sun, 13 Nov 2011 14:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T13t0ryR6Qb; Sun, 13 Nov 2011 14:49:37 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3CC21F8B01; Sun, 13 Nov 2011 14:49:37 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pADMnXfE005233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Nov 2011 16:49:34 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 13 Nov 2011 17:49:32 -0500 From: Gregory Mirsky To: Sam Aldrin Date: Sun, 13 Nov 2011 17:49:30 -0500 Thread-Topic: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 Thread-Index: AcygR5cjSwT5ho8bQxufOnTjzdbjxwCDgfbg Message-ID: References: <5D714E47-5841-4D48-AE83-8BE57B5B44A9@gmail.com> In-Reply-To: <5D714E47-5841-4D48-AE83-8BE57B5B44A9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15F0688EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "vishwas@ipinfusion.com" , "msiva@cisco.com" , "sboutros@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 22:49:38 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0688EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sam, apologies for delayed response. Please find my notes in-lined tagged GIM>> Regards, Greg ________________________________ From: Sam Aldrin [mailto:sam.aldrin@gmail.com] Sent: Thursday, November 10, 2011 11:58 PM To: Gregory Mirsky Cc: msiva@cisco.com; sboutros@cisco.com; George Swallow; ssaxena@cisco.com;= vishwas@ipinfusion.com; mpls@ietf.org; pwe3@ietf.org Subject: Re: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 Greg, See inline for my comments On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote: Dear Authors, et al., Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: * Introduction considers scenario when an intermediate S-PE originate= s LSP Ping and may address an S-PE. Is that valid scenario for on-demand OA= M? %SAM - Yes. We do that already. For ex: interAS optionB. GIM>> AFAIK, MIP is not to originate OAM packets but only to reply. An S-PE= is a MIP in MS-PW and thus ismy question. SPME removes such restriction fo= r an LSR but I don't know if itcan beremoved for an S-PE. If S-PE can generate OAM message, can LSR generate it too? %SAM- If it can, why not? But in the case of LSR, it doesn't have info of P= W's. GIM>> Because of restriction on MIP generating OAM packets that isimposed i= n MPLS-TP. AFAIK, SPME must be used for Segment LSP OAM but the document assumes that = for MS-PW S-PE may generate LSP Ping addressed to another S- or T-PE. * Perhaps TTL is not the best method to be used in S-PE to S-PE OAM (= LSP Ping). I think that Sender's MIP ID can be used to determine correct TT= L value for LSP Echo Reply. %SAM - It doesn't work in non-TP cases, where MIP ID doesn't exist. GIM>> I believe that MIP does exist in non-MPLS-TP PSN. This draft do not just address TP networks. G IM>> I didn't find this being explicitly stated. HTH. -sam Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0688EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3Dx-msg://935/>
Dear Sam,
apologies for delayed response. Please find my not= es=20 in-lined tagged GIM>>
 
  &n= bsp; Regards,
        Greg

From: Sam Aldrin [mailto:sam.aldrin@gma= il.com]=20
Sent: Thursday, November 10, 2011 11:58 PM
To: Gregory= =20 Mirsky
Cc: msiva@cisco.com; sboutros@cisco.com; George Swallow;=20 ssaxena@cisco.com; vishwas@ipinfusion.com; mpls@ietf.org;=20 pwe3@ietf.org
Subject: Re: Comments to=20 draft-ietf-mpls-lsp-ping-ttl-tlv-01

Greg,

See inline for my comments
On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote:

Dear Authors, et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01=20 below:
•       Introduction considers scenario when an interm= ediate=20 S-PE originates LSP Ping and may address an S-PE. Is that valid scenario = for=20 on-demand OAM?
%SAM - Yes. We do that already. For ex: interAS optionB. 
GIM>> AFAIK, MIP is not to originate OAM packets but on= ly to=20 reply. An S-PE is a MIP in MS-PW and thus ismy question. SPME removes = such=20 restriction for an LSR but I don't know if itcan beremoved for an=20 S-PE. 
I= f S-PE=20 can generate OAM message, can LSR generate it too?=20
%SAM- If it can, why not? But in the case of LSR, it doesn't have info= of=20 PW's. 
GIM>> Because of restriction on MIP generating OAM packets t= hat=20 isimposed in MPLS-TP. 
A= FAIK,=20 SPME must be used for Segment LSP OAM but the document assumes that for M= S-PW=20 S-PE may generate LSP Ping addressed to another S- or=20 T-PE.
•       Perhaps TTL is not the best method to be used = in S-PE=20 to S-PE OAM (LSP Ping). I think that Sender’s MIP ID can be used to= determine=20 correct TTL value for LSP Echo=20 Reply.
%SAM - It doesn't work in non-TP cases, where MIP ID doesn't=20 exist.  
GIM>> I believe that MIP = does exist in=20 non-MPLS-TP PSN. 
 
  This draft = do not=20 just address TP networks. 
G IM&g= t;> I=20 didn't find this being explicitly stated.
HTH.
-sam
 
        Regards,
           &n= bsp;   =20 Greg

--_000_FE60A4E52763E84B935532D7D9294FF12EE15F0688EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Sun Nov 13 14:58:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFE21F8997 for ; Sun, 13 Nov 2011 14:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmreaQLldvHU for ; Sun, 13 Nov 2011 14:58:31 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A95C021F85A4 for ; Sun, 13 Nov 2011 14:58:31 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pADMvwBH005370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Nov 2011 16:57:58 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 17:57:57 -0500 From: Gregory Mirsky To: "ppan@infinera.com" , "rrao@infinera.com" , "blu@infinera.com" , "lufang@cisco.com" , "andrew.g.malis@verizon.com" , "zhangfata@huawei.com" , "sam.aldrin@huavei.com" , "zhangfei3@zte.com" , "SriMohanS@Tellabs.com" , "mpls@ietf.org" Date: Sun, 13 Nov 2011 17:57:55 -0500 Thread-Topic: Comments to draft-pan-shared-mesh-protection-03 Thread-Index: AcyiV65QBBLeHGnyRwim85VvUXaFHQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15F0689EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-pan-shared-mesh-protection-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 22:58:33 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0689EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please kindly consider my comemnts to the draft-pan-shared-mesh-protection-= 03: * Introduction. I don't have other examples of Shared Mesh Protection= in transport networks even though it's been referred as common mechanism. * Section 3 "All paths are established via MPLS-TP control plane prio= r to network failure." Can paths be statically configured? * Section 3 "All paths are assumed to be bi-directional." Is it impor= tant whether LSP is co-routed or associated? * Section 3.1 "Upon the detection of network failure, the headend nod= es will transmit activation messages along the MPLS LSP's." I assume that a= ctivation messages being sent along protecting MPLS-TP LSP. * Section 3.1 Since labels are per platform all line modules must per= form activation in coordinated manner to avoid possible inconsistency in th= e data plane. * Section 4.1 It is unlikely that Signal Degrade is applicable to Pac= ket Transport Networks * Section 5.1 What is MPLS label stack when activating protecting LSP= ? * Section 5 Is Seq(uence) signed or unsigned integer and what are val= id numbers, i.e. is 0 a valid number? * Section 5.2 Is sending a message blocking event or there's a window= of unack'ed messages allowed? * Section 5.2 Is number of re-tries (default 3) negotiable or configu= rable parameter? * Section 5.2 Failure to activate reported as alarm. How other failur= es reported? * Section 5.2 All operations use reliable transport? Is that necessar= y? * Section 6.1 "...a next-hop node will locate the corresponding path = and activate the path" what information carried in the activation message r= efers to a path intended to be activated? I think that there's "chicken-egg= " problem in activation procedure as described in the document. * Section 6.2 How deactivation of bidirectional section handled in re= gard to sending ACK? Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0689EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please kindly consider my comemnts to the draft-pan-shared-mesh-protec= tion-03:
•     = ;  Introduction. I don’t have o= ther examples of Shared Mesh Protection in transport networks even though i= t’s been referred as common mechanism.
•     = ;  Section 3 “All paths are est= ablished via MPLS-TP control plane prior to network failure.” Can pat= hs be statically configured?
•     = ;  Section 3 “All paths are ass= umed to be bi-directional.” Is it important whether LSP is co-routed = or associated?
•     = ;  Section 3.1 “Upon the detect= ion of network failure, the headend nodes will transmit activation messages= along the MPLS LSP's.” I assume that activation messages being sent = along protecting MPLS-TP LSP.
•     = ;  Section 3.1 Since labels are per p= latform all line modules must perform activation in coordinated manner to a= void possible inconsistency in the data plane.
•     = ;  Section 4.1 It is unlikely that Si= gnal Degrade is applicable to Packet Transport Networks
•     = ;  Section 5.1 What is MPLS label sta= ck when activating protecting LSP?
•     = ;  Section 5 Is Seq(uence) signed or = unsigned integer and what are valid numbers, i.e. is 0 a valid number?
•     = ;  Section 5.2 Is sending a message b= locking event or there’s a window of unack’ed messages allowed?=
•     = ;  Section 5.2 Is number of re-tries = (default 3) negotiable or configurable parameter?
•     = ;  Section 5.2 Failure to activate re= ported as alarm. How other failures reported?
•     = ;  Section 5.2 All operations use rel= iable transport? Is that necessary?
•     = ;  Section 6.1 “…a next-h= op node will locate the corresponding path and activate the path” wha= t information carried in the activation message refers to a path intended t= o be activated? I think that there’s “chicken-egg” problem in activation = procedure as described in the document.
•     = ;  Section 6.2 How deactivation of bi= directional section handled in regard to sending ACK?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0689EUSAACMS0715e_-- From sboutros@cisco.com Sun Nov 13 15:45:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759AD21F8B25; Sun, 13 Nov 2011 15:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV46tZeUdsHr; Sun, 13 Nov 2011 15:45:51 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBB21F8B1D; Sun, 13 Nov 2011 15:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=5855; q=dns/txt; s=iport; t=1321227951; x=1322437551; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=YMRO68sWlZKI0wQDl/VpOq6yAr5HHVlgp888+UdSToA=; b=PvoRFeY8eMYKiqpogD7hAHlEzikEC6CBprDFcfz6DltgTkFdxwc+i60u hpvy3VcTiiyRFfrqzGFvG+GqiKl1Bxey/e+QAPdNANMc9vXtovHhmbklR 3hMUV4cHmohQmFNbEEAnQT3RyO3ep/wMeyo5iiOCmHKnJlxD6UU/Uum/T M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAAKZVwE6rRDoJ/2dsb2JhbABCiBORYo8OeIEFgXIBAQEDARIBZgULBwQRBAEBAScHGQglCQgGARIih2CZSAGdNIl/BIdfMZFihQeHTw X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208,217";a="12307994" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Nov 2011 23:45:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pADNjp0m014996; Sun, 13 Nov 2011 23:45:51 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 15:45:51 -0800 Received: from sboutros-wxp01.ciswco.com ([10.21.166.85]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 15:45:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Nov 2011 15:45:45 -0800 To: Gregory Mirsky , Sam Aldrin From: Sami Boutros In-Reply-To: References: <5D714E47-5841-4D48-AE83-8BE57B5B44A9@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34337421==.ALT" Message-ID: X-OriginalArrivalTime: 13 Nov 2011 23:45:50.0718 (UTC) FILETIME=[5FF159E0:01CCA25E] Cc: "mpls@ietf.org" , "vishwas@ipinfusion.com" , "msiva@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 23:45:52 -0000 --=====================_34337421==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 02:49 PM 11/13/2011, Gregory Mirsky wrote: >Dear Sam, >apologies for delayed response. Please find my notes in-lined tagged GIM>> > > Regards, > Greg > > >---------- >From: Sam Aldrin [mailto:sam.aldrin@gmail.com] >Sent: Thursday, November 10, 2011 11:58 PM >To: Gregory Mirsky >Cc: msiva@cisco.com; sboutros@cisco.com; George=20 >Swallow; ssaxena@cisco.com;=20 >vishwas@ipinfusion.com; mpls@ietf.org; pwe3@ietf.org >Subject: Re: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 > >Greg, > >See inline for my comments >On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote: > >>Dear Authors, et al., >>Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: >>=95 Introduction considers scenario when an=20 >>intermediate S-PE originates LSP Ping and may=20 >>address an S-PE. Is that valid scenario for on-demand OAM? >%SAM - Yes. We do that already. For ex: interAS optionB. >GIM>> AFAIK, MIP is not to originate OAM packets=20 >but only to reply. An S-PE is a MIP in MS-PW and=20 >thus ismy question. SPME removes such=20 >restriction for an LSR but I don't know if itcan beremoved for an S-PE. Sami: This would be fine to use SPME for MPLS-TP. >>If S-PE can generate OAM message, can LSR generate it too? >%SAM- If it can, why not? But in the case of=20 >LSR, it doesn't have info of PW's. >GIM>> Because of restriction on MIP generating=20 >OAM packets that isimposed in MPLS-TP. >>AFAIK, SPME must be used for Segment LSP OAM=20 >>but the document assumes that for MS-PW S-PE=20 >>may generate LSP Ping addressed to another S- or T-PE. >>=95 Perhaps TTL is not the best method to=20 >>be used in S-PE to S-PE OAM (LSP Ping). I think=20 >>that Sender=92s MIP ID can be used to determine=20 >>correct TTL value for LSP Echo Reply. >%SAM - It doesn't work in non-TP cases, where MIP ID doesn't exist. >GIM>> I believe that MIP does exist in non-MPLS-TP PSN. > Sami: The tool is useful to debug issues on a segment of a multisegment PWs. > This draft do not just address TP networks. >G IM>> I didn't find this being explicitly stated. Thanks, Sami --=====================_34337421==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 02:49 PM 11/13/2011, Gregory Mirsky wrote:
Dear Sam,
apologies for delayed response. Please find my notes in-lined tagged GIM>>
 
    Regards,
        Greg

From: Sam Aldrin [ mailto:sam.aldrin@gmail.com]
Sent: Thursday, November 10, 2011 11:58 PM
To: Gregory Mirsky
Cc: msiva@cisco.com; sboutros@cisco.com; George Swallow; ssaxena@cisco.com; vishwas@ipinfusion.com; mpls@ietf.org; pwe3@ietf.org
Subject: Re: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01

Greg,

See inline for my comments
On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote:

Dear Authors, = et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below:
=95      = ; Introduction considers scenario when an intermediate S-PE originates LSP Ping and may address an S-PE. Is that valid scenario for on-demand OAM?
%SAM - Yes. We do that already. For ex: interAS optionB.
GIM>> AFAIK, MIP is not to originate OAM packets but only to reply. An S-PE is a MIP in MS-PW and thus ismy question. SPME removes such restriction for an LSR but I don't know if itcan beremoved for an S-PE.

Sami: This would be fine to use SPME for MPLS-TP.

If S-PE can generate OAM message, can LSR generate it too?
%SAM- If it can, why not? But in the case of LSR, it doesn't have info of PW's.
GIM>> Because of restriction on MIP generating OAM packets that isimposed in MPLS-TP.
AFAIK, SPME= must be used for Segment LSP OAM but the document assumes that for MS-PW S-PE may generate LSP Ping addressed to another S- or T-PE.
=95      = ; Perhaps TTL is not the best method to be used in S-PE to S-PE OAM (LSP Ping). I think that Sender=92s MIP ID can be used to determine correct TTL value for LSP Echo Reply.
%SAM - It doesn't work in non-TP cases, where MIP ID doesn't exist.
GIM>> I believe that MIP does exist in non-MPLS-TP PSN.
 

Sami: The tool is useful to debug issues on a segment of a multisegment PWs.

  This draft do not just address TP networks.
G IM>> I didn't find this being explicitly stated.

Thanks,

Sami

--=====================_34337421==.ALT-- From gregory.mirsky@ericsson.com Sun Nov 13 17:01:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F6C11E8099 for ; Sun, 13 Nov 2011 17:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asmH2VRdP4oB for ; Sun, 13 Nov 2011 17:01:04 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8486221F86FF for ; Sun, 13 Nov 2011 17:01:04 -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 pAE10vUF025539; Sun, 13 Nov 2011 19:00:59 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 20:00:57 -0500 From: Gregory Mirsky To: "cts@etri.re.kr" , "ryoo@etri.re.kr" , "yaacov.weingarten@nsn.com" , "nurit.sprecher@nsn.com" , "daniel@olddog.co.uk" , "mpls@ietf.org" Date: Sun, 13 Nov 2011 20:00:53 -0500 Thread-Topic: Comments to draft-cheung-mpls-tp-mesh-protection-04 Thread-Index: AcyiaNnehLInzu7eQiSZpQe5VQbCqQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15F068FEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-cheung-mpls-tp-mesh-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:01:05 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F068FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please kindly consider my comments to the document: * Section 3.3 Specific configuration of DCN should not required. It s= hould be sufficient to require that the DCN exists and provides full connec= tivity to all LSRs in SPMG. * Shared protection for bi-directional co-routed p2p LSP can represen= t separate study case. Would encourage narrowing the scope to this special = case and leaving other cases for further study. * Section 3.6.2 How does tail LER knows the N number, number of SENs = it must inform? Can number of SENs change, be dynamic parameter? How's the = tail LER will know their identities? * Section 4.1 Would suggest to add ASCII-art figure of a Shared Mesh = Protection message itself. * Section 4.1 SMP message has its own versioning. What is the value? Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15F068FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please kindly consider my comments to the document:
•     = ;  Section 3.3 Specific configuration= of DCN should not required. It should be sufficient to require that the DC= N exists and provides full connectivity to all LSRs in SPMG.<= /div>
•     = ;  Shared protection for bi-direction= al co-routed p2p LSP can represent separate study case. Would encourage nar= rowing the scope to this special case and leaving other cases for further study.
•     = ;  Section 3.6.2 How does tail LER kn= ows the N number, number of SENs it must inform? Can number of SENs change,= be dynamic parameter? How’s the tail LER will know their identities?=
•     = ;  Section 4.1 Would suggest to add A= SCII-art figure of a Shared Mesh Protection message itself.
•     = ;  Section 4.1 SMP message has its ow= n versioning. What is the value?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F068FEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Sun Nov 13 17:12:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49321F8564 for ; Sun, 13 Nov 2011 17:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uePK0wxEygP for ; Sun, 13 Nov 2011 17:12:47 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3F21F8560 for ; Sun, 13 Nov 2011 17:12:47 -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 pAE1Ch1G025785; Sun, 13 Nov 2011 19:12:44 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 20:12:38 -0500 From: Gregory Mirsky To: "Huaimochen@huawei.com" , "Ning.So@verizonbusiness.com" , Autumn Liu , "mpls@ietf.org" Date: Sun, 13 Nov 2011 20:12:35 -0500 Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Thread-Index: Acyian5b+IJtfGT4QvW8Dx67gFMv+w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15F0690EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:12:48 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0690EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please consider my comments to the document: * Section 4.1 Not clear how Reference model in Figure 1 positioned re= lative to CE-PE demarcation. Is Node S a CE node and nodes R1, Ra - PEs? I= f S is CE, then, in my view, this is PWE3 redundancy scenario. If S is part= of MPLS PSN, then what is sourced by S node? Is S a head-end of e2e PWE3? * Section 4.4 suggests using very unnatural OAM configuration to dete= ct failure of immediate link and/or node. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0690EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please consider my comments to the document:
•     = ;  Section 4.1 Not clear how Referenc= e model in Figure 1 positioned relative to CE-PE demarcation. Is Node S a C= E node and nodes R1, Ra – PEs= ?  If S is CE, then, in my view, this is PWE3 redundancy scenario. If S is part o= f MPLS PSN, then what is sourced by S node? Is S a head-end of e2e PWE3?
•     = ;  Section 4.4 suggests using very un= natural OAM configuration to detect failure of immediate link and/or node.<= /font>
 
        Regards,
           &nbs= p;    Greg
 
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0690EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Sun Nov 13 17:13:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084C921F858C for ; Sun, 13 Nov 2011 17:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyyMzfoqf6dW for ; Sun, 13 Nov 2011 17:13:33 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0797321F8586 for ; Sun, 13 Nov 2011 17:13:32 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAE1DUIX007936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Nov 2011 19:13:30 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 13 Nov 2011 20:13:29 -0500 From: Gregory Mirsky To: "Huaimochen@huawei.com" , "Ning.So@verizonbusiness.com" , Autumn Liu , "mpls@ietf.org" Date: Sun, 13 Nov 2011 20:13:28 -0500 Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-04 Thread-Index: Acyiap2UEvFtT0Z8TrOXLfWpm5hxyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EE15F0691EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:13:34 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0691EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please kindly consider my comments: * Section 4.1 Figure 1 I think that presented scenario is scenario mo= re suitable for PWE3 WG * Section 4.1 "The backup sub LSP used to protect the primary egress = node L1 is from its previous hop node R3 to the backup egress node La." I'd= note that there might be situation when R3, as characterized in the docume= nt, can not be connected by sub-LSP to the particular node La. * Section 4.4 "Destination node" is usually referred as CE in PWE3 Re= ference model. * Section 4.4 I think that OAM (BFD) between CE and "previous hop" is= not realistic as it crosses administration domain's border. * Section 5. IMO, protection of PE and CE-PE link is outside of scope= of the MPLS WG. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0691EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please kindly consider my comments:
•     = ;  Section 4.1 Figure 1 I think that = presented scenario is scenario more suitable for PWE3 WG
•     = ;  Section 4.1 “The backup sub = LSP used to protect the primary egress node L1 is from its previous hop nod= e R3 to the backup egress node La.” I’d note that there might b= e situation when R3, as characterized in the document, can not be connected by sub-LSP to th= e particular node La.
•     = ;  Section 4.4 “Destination nod= e” is usually referred as CE in PWE3 Reference model.
•     = ;  Section 4.4 I think that OAM (BFD)= between CE and “previous hop” is not realistic as it crosses a= dministration domain’s border.
•     = ;  Section 5. IMO, protection of PE a= nd CE-PE link is outside of scope of the MPLS WG.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EE15F0691EUSAACMS0715e_-- From lizho.jin@gmail.com Sun Nov 13 17:36:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E902E21F8801 for ; Sun, 13 Nov 2011 17:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.089 X-Spam-Level: X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JKvUW7NDoen for ; Sun, 13 Nov 2011 17:36:36 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55B21F86A0 for ; Sun, 13 Nov 2011 17:36:36 -0800 (PST) Received: by qadb40 with SMTP id b40so3926051qad.10 for ; Sun, 13 Nov 2011 17:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3CdQTalCOmZR7iYLMly+vijlfOAUpGjvbh7XSjKYYDI=; b=KHJrXyFn/RSTNzTfENrKiYhQForkVx2l/8tFxVD/EkxPnIs5M1LGtM7FJKT755KWL3 yusWWqUr/s8deCqfdBFg0EF/l5xGxg/wmSNL+SAeePbDhwIqLuMKez7/joW/nD68ft7v jL3gnxKDjWkFao8i8TzvsokrUxfz+G8DsMXBg= MIME-Version: 1.0 Received: by 10.224.104.134 with SMTP id p6mr5248294qao.5.1321234595794; Sun, 13 Nov 2011 17:36:35 -0800 (PST) Received: by 10.224.2.201 with HTTP; Sun, 13 Nov 2011 17:36:35 -0800 (PST) Date: Mon, 14 Nov 2011 09:36:35 +0800 Message-ID: From: Lizhong Jin To: mach@huawei.com Content-Type: multipart/alternative; boundary=bcaec54316c0bf4ec004b1a7e656 Cc: mpls@ietf.org Subject: [mpls] Comments of draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:36:37 -0000 --bcaec54316c0bf4ec004b1a7e656 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach, Because of time limited at the session, I need some clarification on the list. Both draft-ietf-mpls-return-path-specified-lsp-ping section 3.2 and draft-ietf-mpls-tp-on-demand-cv-07 section 3.4.1 provide the feature of "the Responder SHOULD return reverse path FEC information". What's the difference between the two drafts? It seems they provide the same feature with different way. Thank you. Lizhong --bcaec54316c0bf4ec004b1a7e656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mach,
Because of time limited at the session, I need some clarification on t= he list.
Both draft-ietf-mpls-return-path-specified-lsp-ping section 3.2 and dr= aft-ietf-mpls-tp-on-demand-cv-07 section 3.4.1 provide the feature of "= ;the Responder SHOULD return reverse path FEC information".
What's the difference between the two drafts? It seems they provid= e the same feature with different way.
=A0
Thank you.
Lizhong
--bcaec54316c0bf4ec004b1a7e656-- From scott.mansfield@ericsson.com Sun Nov 13 17:37:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1578521F867F for ; Sun, 13 Nov 2011 17:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36GGQ5mjTwzu for ; Sun, 13 Nov 2011 17:37:05 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3121F8461 for ; Sun, 13 Nov 2011 17:37:05 -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 pAE1b3ed026332 for ; Sun, 13 Nov 2011 19:37:04 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 20:37:00 -0500 From: Scott Mansfield To: "mpls@ietf.org" Date: Sun, 13 Nov 2011 20:36:09 -0500 Thread-Topic: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" Thread-Index: AcyEajHrMcshJcuTSFyJm7e6i8WJkgeA11Pw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:37:06 -0000 This is the liaison from the ITU-T that includes information about the Glob= al MEG ID. Uses the Country Code and the ICC to make the MEG ID globally u= nique. Regards, -scott.=20 > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Thursday, October 06, 2011 4:52 PM > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > Cc: yoichi.maeda@ttc.or.jp;=20 > Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org;=20 > lear@cisco.com; Scott Mansfield;=20 > huub.van.helvoort@huawei.com; tsbsg15@itu.int;=20 > greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS331 - Corrigendum 1 to=20 > Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >=20 > Title: LS331 - Corrigendum 1 to Recommendation ITU-T=20 > G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL=20 > of the IETF Web page: /liaison/1100/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > swallow@cisco.com, loa@pi.nu) > Cc:=20 > yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl > s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: huub.van.helvoort@huawei.com > Purpose: For information >=20 > Body: The experts of Q10/15 would like to inform you that=20 > they have agreed to a corrigendum for Recommendation ITU-T=20 > G.8013/Y.1731 "OAM functions and mechanisms for Ethernet=20 > based networks." > This corrigendum provides the definition of a globally unique=20 > MEG-ID by using the Country Code (CC) and ITU-T Carrier Code (ICC). > Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T=20 > G.8013/Y.1731". > Attachment(s): >=20 > LS331 - Corrigendum 1 to Recommendation ITU-T=20 > G.8013/Y.1731: Global MEG_ID - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1279.pdf >=20 >=20 > = From scott.mansfield@ericsson.com Sun Nov 13 17:53:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3464711E80FE for ; Sun, 13 Nov 2011 17:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdjZLAs9K-iP for ; Sun, 13 Nov 2011 17:53:34 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA811E8080 for ; Sun, 13 Nov 2011 17:53:34 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAE1rCSl008766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Nov 2011 19:53:12 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 13 Nov 2011 20:53:11 -0500 From: Scott Mansfield To: "greg.jones@itu.int" , "huub.van.helvoort@huawei.com" Date: Sun, 13 Nov 2011 20:52:20 -0500 Thread-Topic: [mpls] FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" Thread-Index: AcyEajHrMcshJcuTSFyJm7e6i8WJkgeA11PwAACHHzA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:53:35 -0000 Greg and Huub, Looking at the text of liaison, the actual text of the corrigendum 1 is not= attached to the liaison. Currently the document is only available to ITU-= T TIES members since the document is still "pre-published". Can you please provide the document? Regards, -scott.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Scott Mansfield > Sent: Sunday, November 13, 2011 8:36 PM > To: mpls@ietf.org > Subject: [mpls] FW: New Liaison Statement, "LS331 -=20 > Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >=20 > This is the liaison from the ITU-T that includes information=20 > about the Global MEG ID. Uses the Country Code and the ICC=20 > to make the MEG ID globally unique. >=20 > Regards, > -scott.=20 >=20 > > -----Original Message----- > > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > > Sent: Thursday, October 06, 2011 4:52 PM > > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > > Cc: yoichi.maeda@ttc.or.jp; > > Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org; lear@cisco.com;=20 > > Scott Mansfield; huub.van.helvoort@huawei.com; tsbsg15@itu.int;=20 > > greg.jones@itu.int; hiroshi.ota@itu.int > > Subject: New Liaison Statement, "LS331 - Corrigendum 1 to=20 > > Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" > >=20 > > Title: LS331 - Corrigendum 1 to Recommendation ITU-T > > G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL of the=20 > > IETF Web page: /liaison/1100/ > >=20 > > From: ITU-T SG 15 (Greg Jones ) > > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > > swallow@cisco.com, loa@pi.nu) > > Cc:=20 > > yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl > > s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com > > Reponse Contact:=20 > > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > > Technical Contact: huub.van.helvoort@huawei.com > > Purpose: For information > >=20 > > Body: The experts of Q10/15 would like to inform you that they have=20 > > agreed to a corrigendum for Recommendation ITU-T > > G.8013/Y.1731 "OAM functions and mechanisms for Ethernet based=20 > > networks." > > This corrigendum provides the definition of a globally=20 > unique MEG-ID=20 > > by using the Country Code (CC) and ITU-T Carrier Code (ICC). > > Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T=20 > > G.8013/Y.1731". > > Attachment(s): > >=20 > > LS331 - Corrigendum 1 to Recommendation ITU-T > > G.8013/Y.1731: Global MEG_ID - pdf body=20 > > https://datatracker.ietf.org/documents/LIAISON/file1279.pdf > >=20 > >=20 > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From mach.chen@huawei.com Sun Nov 13 17:57:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C67B21F8510 for ; Sun, 13 Nov 2011 17:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=-4.424, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKO8FSyp034N for ; Sun, 13 Nov 2011 17:57:29 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 23D5A21F8505 for ; Sun, 13 Nov 2011 17:57:23 -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 <0LUM00MJUO3KDF@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 09:57:20 +0800 (CST) Received: from szxrg02-dlp.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 <0LUM0078IO36U3@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 09:57:20 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY64866; Mon, 14 Nov 2011 09:57:19 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 09:57:17 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 09:57:11 +0800 Date: Mon, 14 Nov 2011 01:57:10 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [172.24.2.41] To: Lizhong Jin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [mpls] Comments of draft-ietf-mpls-return-path-specified-lsp-ping-04 Thread-index: AQHMom3fFVuyPYoH00GYd163YzTBwpWrmUG1 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:57:30 -0000 SGkgTGl6aG9uZywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpJIHNlZSB0aGUgZGlm ZmVyZW5jZSBpcyB0aGF0IGRyYWZ0LW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5n IG1haW5seSBhcHBsaWVzIHRvIElQL01QTFMgc2NlbmFyaW8sIGFuZCBpdCBtYXkgYmUgYXBwbHkg dG8gTVBMUy1UUCBzY2VuYXJpbzsgYW5kIGRyYWZ0LWlldGYtbXBscy10cC1vbi1kZW1hbmQtY3Yt MDcgYXBwbGllcyB0byBNUExTLVRQIHNjZW5hcmlvcy4NCg0KVGhlIHJldHVybiBwYXRoIHZhbGlk YXRpb24gd2FzIGZpcnN0bHkgcHJvcG9zZWQgaW4gZHJhZnQtbXBscy1yZXR1cm4tcGF0aC1zcGVj aWZpZWQtbHNwLXBpbmcgZHJhZnQsIGFuZCBpdCdzIG9ubHkgb25lIG9mIHRoZSBmdWN0aW9ucyBv ZiByZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbXBscy1i b3VuY2VzQGlldGYub3JnIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGl6aG9uZyBKaW4g W2xpemhvLmppbkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxMcTqMTHUwjE0yNUgOTozNg0Ktb06 IE1hY2ggQ2hlbg0KQ2M6IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFttcGxzXSBDb21tZW50cyBvZiBk cmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0DQoNCkhpIE1h Y2gsDQpCZWNhdXNlIG9mIHRpbWUgbGltaXRlZCBhdCB0aGUgc2Vzc2lvbiwgSSBuZWVkIHNvbWUg Y2xhcmlmaWNhdGlvbiBvbiB0aGUgbGlzdC4NCkJvdGggZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1w YXRoLXNwZWNpZmllZC1sc3AtcGluZyBzZWN0aW9uIDMuMiBhbmQgZHJhZnQtaWV0Zi1tcGxzLXRw LW9uLWRlbWFuZC1jdi0wNyBzZWN0aW9uIDMuNC4xIHByb3ZpZGUgdGhlIGZlYXR1cmUgb2YgInRo ZSBSZXNwb25kZXIgU0hPVUxEIHJldHVybiByZXZlcnNlIHBhdGggRkVDIGluZm9ybWF0aW9uIi4N CldoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzPyBJdCBzZWVtcyB0 aGV5IHByb3ZpZGUgdGhlIHNhbWUgZmVhdHVyZSB3aXRoIGRpZmZlcmVudCB3YXkuDQoNClRoYW5r IHlvdS4NCkxpemhvbmcNCg== From akatlas@gmail.com Sun Nov 13 18:33:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFA511E8167 for ; Sun, 13 Nov 2011 18:33:04 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds3y5yOK26kn for ; Sun, 13 Nov 2011 18:33:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77B6811E8148 for ; Sun, 13 Nov 2011 18:33:03 -0800 (PST) Received: by iaeo4 with SMTP id o4so8654607iae.31 for ; Sun, 13 Nov 2011 18:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DvRsTNxAYA9HMYxP/v080+wZqm3GyU3bbHVqWTBTPkc=; b=pGjPFdlijW8emctJo9tVZfqmwMQ1Ms+7K97Ld26iS7RGZ1lbKZHL/MqrBIDF9EBvC6 1l5uCvNr2+JftN4uNTs0li/Y/DfRfbmD4X7LGyS6SfH+MBRn3X6VkVQAWeqKjZYoim77 SEbID7zsny+D9s3rw2ZyRFZWPBrl78dfSrCNM= MIME-Version: 1.0 Received: by 10.50.194.229 with SMTP id hz5mr21507145igc.36.1321237983183; Sun, 13 Nov 2011 18:33:03 -0800 (PST) Received: by 10.50.184.229 with HTTP; Sun, 13 Nov 2011 18:33:03 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 21:33:03 -0500 Message-ID: From: Alia Atlas To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] quick comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:33:04 -0000 First, I think that this draft is useful without more forwarding detail. I prefer the option where the MT-ID is included as part of the FEC TLV; I think this provides more flexibility. I am looking at this from the perspective of the forwarding and signalling needed for draft-atlas-rtgwg-mrt-frr-architecture-01. Alia From aldrin.ietf@gmail.com Sun Nov 13 18:33:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D949911E8170; Sun, 13 Nov 2011 18:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCTUKx0dMZz4; Sun, 13 Nov 2011 18:33:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 731B211E8169; Sun, 13 Nov 2011 18:33:34 -0800 (PST) Received: by ggnr5 with SMTP id r5so454321ggn.31 for ; Sun, 13 Nov 2011 18:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=hS6eFRixUSlA8p3cLcvcMkpu4JemxGUyvJpae5IrAVg=; b=Xku/HwD4Jm+TjnjIH9NwPEyCCmtg9yKcBhDnbyfhYPfw6+9nlAyk6c9/OIbb2ljGOB XCf562LU2PmIA2gvRpBmAlRO/lZ/Vf1YRBYN9QuBNlaAuZnQmGOtUvkn+VyZWtLZKGu2 LvveWKuDyoqvHKeRnlAy2Lkvl7YSvMr1/21Tg= Received: by 10.236.190.99 with SMTP id d63mr11465020yhn.73.1321238013905; Sun, 13 Nov 2011 18:33:33 -0800 (PST) Received: from ?IPv6:2001:df8::16:8152:e422:c408:c286? ([2001:df8:0:16:8152:e422:c408:c286]) by mx.google.com with ESMTPS id y71sm28675365yhh.6.2011.11.13.18.33.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:33:33 -0800 (PST) References: <5D714E47-5841-4D48-AE83-8BE57B5B44A9@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-D4FFE502-319B-4802-BEB5-7743E999BC7D Message-Id: <9A5A618B-C437-47BF-B870-CCBD2D440D30@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Sun, 13 Nov 2011 18:33:27 -0800 To: Gregory Mirsky Cc: "mpls@ietf.org" , Sam Aldrin , "vishwas@ipinfusion.com" , "sboutros@cisco.com" , "msiva@cisco.com" , "pwe3@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:33:36 -0000 --Apple-Mail-D4FFE502-319B-4802-BEB5-7743E999BC7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Greg, Thanks for your reply. Please see my replies inline with %SAM2. Sent from my iPad On Nov 13, 2011, at 2:49 PM, Gregory Mirsky wr= ote: > Dear Sam, > apologies for delayed response. Please find my notes in-lined tagged GIM>>= > =20 > Regards, > Greg >=20 > From: Sam Aldrin [mailto:sam.aldrin@gmail.com]=20 > Sent: Thursday, November 10, 2011 11:58 PM > To: Gregory Mirsky > Cc: msiva@cisco.com; sboutros@cisco.com; George Swallow; ssaxena@cisco.com= ; vishwas@ipinfusion.com; mpls@ietf.org; pwe3@ietf.org > Subject: Re: Comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 >=20 > Greg, >=20 > See inline for my comments > On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote: >=20 >> Dear Authors, et al., >> Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01 below: >> =E2=80=A2 Introduction considers scenario when an intermediate S-PE= originates LSP Ping and may address an S-PE. Is that valid scenario for on-= demand OAM? > %SAM - Yes. We do that already. For ex: interAS optionB.=20 > GIM>> AFAIK, MIP is not to originate OAM packets but only to reply. An S-P= E is a MIP in MS-PW and thus ismy question. SPME removes such restriction fo= r an LSR but I don't know if itcan beremoved for an S-PE.=20 %SAM2- AFAIK, MIP not originating OAM packets is applicable for TP networks.= SPE originating OAM packet, for ex: lsp ping, was implemented much earlier t= o the TP OAM framework came into being. Could you point to any reference, wh= y the same restriction is applicable to non TP as well? >> If S-PE can generate OAM message, can LSR generate it too? > %SAM- If it can, why not? But in the case of LSR, it doesn't have info of P= W's.=20 > GIM>> Because of restriction on MIP generating OAM packets that isimposed i= n MPLS-TP.=20 %SAM2- what about Non-TP networks? Having OAM from SPE to SPE/TPE is very u= seful for debugging. >> AFAIK, SPME must be used for Segment LSP OAM but the document assumes tha= t for MS-PW S-PE may generate LSP Ping addressed to another S- or T-PE. >> =E2=80=A2 Perhaps TTL is not the best method to be used in S-PE to S= -PE OAM (LSP Ping). I think that Sender=E2=80=99s MIP ID can be used to dete= rmine correct TTL value for LSP Echo Reply. > %SAM - It doesn't work in non-TP cases, where MIP ID doesn't exist. =20 > GIM>> I believe that MIP does exist in non-MPLS-TP PSN.=20 > =20 > This draft do not just address TP networks.=20 > G IM>> I didn't find this being explicitly stated. %Text could be added if needed. My understanding is, unless explicitly menti= oned as 'TP', it is applicable for all of MPLS, not just TP. But, point take= n. Sam > HTH. > -sam >> =20 >> Regards, >> Greg >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-D4FFE502-319B-4802-BEB5-7743E999BC7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Greg,

Thanks for your reply. Please see my replies inline with %SAM2.
<= br>Sent from my iPad

On Nov 13, 2011, at 2:49 PM, Gregory Mirs= ky <gregory.mirsky@ericsso= n.com> wrote:

= =
Dear Sam,
apologies for delayed response. Ple= ase find my notes=20 in-lined tagged GIM>>
 
 &nb= sp;  Regards,<= /span>
 &nb= sp;      Greg

From: Sam Aldrin [mailto:sam.aldrin@= gmail.com]=20
Sent: Thursday, November 10, 2011 11:58 PM
To: Gregory=20= Mirsky
Cc: msiva@cisco.com;= sboutros@cisco.com; George Swallo= w;=20 ssaxena@cisco.com; vishwas@ipinfusion.com; mpls@ietf.org;=20 pwe3@ietf.org
Subject: Re: Co= mments to=20 draft-ietf-mpls-lsp-ping-ttl-tlv-01

Greg,

See inline for my comments
On Nov 10, 2011, at 9:53 AM, Gregory Mirsky wrote:

Dear Authors, et al.,
Please find my comments to draft-ietf-mpls-lsp-ping-ttl-tlv-01=20 below:
=E2=80=A2    &n= bsp;  Introduction considers scenario when an intermediate=20 S-PE originates LSP Ping and may address an S-PE. Is that valid scenario f= or=20 on-demand OAM?
%SAM - Yes. We do that already. For ex: interAS optionB. =
GIM>> AFAIK, MIP is not to originate OAM packets bu= t only to=20 reply. An S-PE is a MIP in MS-PW and thus ismy question. SPME removes s= uch=20 restriction for an LSR but I don't know if itcan beremoved for an=20 S-PE. 
%SAM2- AFAIK, MIP no= t originating OAM packets is applicable for TP networks. SPE originating OAM= packet, for ex: lsp ping, was implemented much earlier to the TP OAM framew= ork came into being. Could you point to any reference, why the same restrict= ion is applicable to non TP as well?
=
If= S-PE=20 can generate OAM message, can LSR generate it too?=20
%SAM- If it can, why not? But in the case of LSR, it doesn't have info o= f=20 PW's. 
GIM>> Because of restriction on MIP generating OAM packe= ts that=20 isimposed in MPLS-TP. 
%SAM= 2- what about Non-TP networks?  Having OAM from SPE to SPE/TPE is very u= seful for debugging.
AFA= IK,=20 SPME must be used for Segment LSP OAM but the document assumes that for MS= -PW=20 S-PE may generate LSP Ping addressed to another S- or=20 T-PE.
=E2=80=A2    &n= bsp;  Perhaps TTL is not the best method to be used in S-PE=20 to S-PE OAM (LSP Ping). I think that Sender=E2=80=99s MIP ID can be used t= o determine=20 correct TTL value for LSP Echo=20 Reply.
%SAM - It doesn't work in non-TP cases, where MIP ID doesn't=20 exist.  
GIM>> I believe that MIP does exi= st in=20 non-MPLS-TP PSN. 
 
  This draft do not= =20 just address TP networks. 
G I= M>> I=20 didn't find this being explicitly stated.
%Text could be added if needed. My unders= tanding is, unless explicitly mentioned as 'TP', it is applicable for all of= MPLS, not just TP. But, point taken.

Sam
HTH.
-sam
 
        Regards,
           &nb= sp;   =20 Greg

____________________= ___________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman= /listinfo/mpls
= --Apple-Mail-D4FFE502-319B-4802-BEB5-7743E999BC7D-- From lberger@labn.net Sun Nov 13 18:35:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E211E816E for ; Sun, 13 Nov 2011 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.68 X-Spam-Level: X-Spam-Status: No, score=-99.68 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxOEbjTszN79 for ; Sun, 13 Nov 2011 18:35:34 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 647C411E815F for ; Sun, 13 Nov 2011 18:35:34 -0800 (PST) Received: (qmail 11919 invoked by uid 0); 14 Nov 2011 02:35:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 14 Nov 2011 02:35:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=LxKJHYmG8ZN04mC552edgveeLoh5IrNQMK4jR1LhOX0=; b=YjfYFiSvtcPru+UnY/C1N+748FshbBcPpL6l6lLVENka6OWZBuClBhezszFfolQpFE73DRT73kVgX5K/yOp6GxLPs29Gi/cc2CwfuwZIGkFhaxBRT7/iqcfCcQkjztdr; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RPmOT-0000NM-4g; Sun, 13 Nov 2011 19:35:33 -0700 Message-ID: <4EC07E73.8050901@labn.net> Date: Mon, 14 Nov 2011 10:35:31 +0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "huub.van.helvoort@huawei.com" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" , "greg.jones@itu.int" Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:35:35 -0000 Huub, As the scope of this document (ITU-T G.8013/Y.1731) is just MEG IDs, I guess this means that draft-ietf-mpls-tp-itu-t-identifiers will need to explicitly define how to go from ICC-based MEG IDs to ICC_based LSPs&Tunnels, right? Lou On 11/14/2011 9:52 AM, Scott Mansfield wrote: > Greg and Huub, > > Looking at the text of liaison, the actual text of the corrigendum 1 > is not attached to the liaison. Currently the document is only > available to ITU-T TIES members since the document is still > "pre-published". > > Can you please provide the document? > > Regards, > -scott. > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Scott Mansfield >> Sent: Sunday, November 13, 2011 8:36 PM >> To: mpls@ietf.org >> Subject: [mpls] FW: New Liaison Statement, "LS331 - >> Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >> >> This is the liaison from the ITU-T that includes information >> about the Global MEG ID. Uses the Country Code and the ICC >> to make the MEG ID globally unique. >> >> Regards, >> -scott. >> >>> -----Original Message----- >>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>> Sent: Thursday, October 06, 2011 4:52 PM >>> To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu >>> Cc: yoichi.maeda@ttc.or.jp; >>> Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org; lear@cisco.com; >>> Scott Mansfield; huub.van.helvoort@huawei.com; tsbsg15@itu.int; >>> greg.jones@itu.int; hiroshi.ota@itu.int >>> Subject: New Liaison Statement, "LS331 - Corrigendum 1 to >>> Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >>> >>> Title: LS331 - Corrigendum 1 to Recommendation ITU-T >>> G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL of the >>> IETF Web page: /liaison/1100/ >>> >>> From: ITU-T SG 15 (Greg Jones ) >>> To: Multiprotocol Label Switching (rcallon@juniper.net, >>> swallow@cisco.com, loa@pi.nu) >>> Cc: >>> yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl >>> s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com >>> Reponse Contact: >>> tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int >>> Technical Contact: huub.van.helvoort@huawei.com >>> Purpose: For information >>> >>> Body: The experts of Q10/15 would like to inform you that they have >>> agreed to a corrigendum for Recommendation ITU-T >>> G.8013/Y.1731 "OAM functions and mechanisms for Ethernet based >>> networks." >>> This corrigendum provides the definition of a globally >> unique MEG-ID >>> by using the Country Code (CC) and ITU-T Carrier Code (ICC). >>> Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T >>> G.8013/Y.1731". >>> Attachment(s): >>> >>> LS331 - Corrigendum 1 to Recommendation ITU-T >>> G.8013/Y.1731: Global MEG_ID - pdf body >>> https://datatracker.ietf.org/documents/LIAISON/file1279.pdf >>> >>> >>> >> _______________________________________________ >> 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 Sun Nov 13 18:50:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057BB21F85A4 for ; Sun, 13 Nov 2011 18:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.342 X-Spam-Level: X-Spam-Status: No, score=-107.342 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq4LxI83Uofb for ; Sun, 13 Nov 2011 18:50:29 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 005DD21F858D for ; Sun, 13 Nov 2011 18:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3620; q=dns/txt; s=iport; t=1321239029; x=1322448629; h=message-id:date:from:reply-to:mime-version:to:subject; bh=tAyiT1twvxImO9m6eh8UMi1wcamxecolwc05V9Oei/8=; b=HZCWA3LAUyhdW+3EqgohLxNjAjk/t/5KGowPNNDNtIn/m2/RKmhPY0fq /lCXMS0T3SoTh00i1Sg3g77Ht19R3SudypmdO5fPyDspOAz2cLz7QYCWw Y4hGkdaFypcQBRcwkWmOF/ZlqdbAN/hFLcGHj42V/PVRvjnyiNL4WMNXt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicIALOBwE6Q/khM/2dsb2JhbABCqXx+B4ILAQIBYiAdFAIYAwIBAgFLDQgBAR6gKYEmAYMuDwGZfol/BJQukXk X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208,217";a="2979089" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 14 Nov 2011 02:50:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAE2oRRj029247 for ; Mon, 14 Nov 2011 02:50:27 GMT Received: from dhcp-1222.meeting.ietf.org (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id pAE2oPbm026847; Mon, 14 Nov 2011 02:50:26 GMT Message-ID: <4EC081F1.6010402@cisco.com> Date: Mon, 14 Nov 2011 02:50:25 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="------------020009040108070602030807" Subject: [mpls] draft-fbb-mpls-gach-adv and LMP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 14 Nov 2011 02:50:30 -0000 This is a multi-part message in MIME format. --------------020009040108070602030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was asked just now about the use of LMP instead of defining a new protocol. I just took a quick look at RFC4204 in the introduction it says: The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. SB> We do not need this fast keep alive - BFD provides the fast SB> KA in MPLS-TP. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify the TE link configuration. LMP requires that a pair of nodes have at least one active bi- directional control channel between them. SB> We may not have this. Each direction of the control channel is identified by a Control Channel Id (CC_Id), and the two directions are coupled together using the LMP Config message exchange. Except for Test messages, which may be limited by the transport mechanism for in-band messaging, all LMP packets are run over UDP with an LMP port number. SB> We may not have UDP/IP available in MPLS-TP SB> A number of the authors of LMP were in the room, so if SB> they think that we should consider elements of LMP for this SB> purpose, then perhaps we can talk whilst we are at IETF. - Stewart --------------020009040108070602030807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
I was asked just now about the use of LMP instead of defining
a new protocol.

I just took a quick look at RFC4204 in the introduction it
says:


The two core procedures of LMP are control channel management and
link property correlation.  Control channel management is used to
establish and maintain control channels between adjacent nodes.  This
is done using a Config message exchange and a fast keep-alive
mechanism between the nodes.  

SB> We do not need this fast keep alive - BFD provides the fast
SB> KA in MPLS-TP.


The latter is required if lower-level
mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link
properties and verify the TE link configuration.

LMP requires that a pair of nodes have at least one active bi-
directional control channel between them. 

SB> We may not have this.

Each direction of the
control channel is identified by a Control Channel Id (CC_Id), and
the two directions are coupled together using the LMP Config message
exchange.  Except for Test messages, which may be limited by the
transport mechanism for in-band messaging, all LMP packets are run
over UDP with an LMP port number. 

SB> We may not have UDP/IP available in MPLS-TP

SB> A number of the authors of LMP were in the room, so if
SB> they think that we should consider elements of LMP for this
SB> purpose, then perhaps we can talk whilst we are at IETF.

- Stewart
--------------020009040108070602030807-- From internet-drafts@ietf.org Sun Nov 13 18:57:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC31F0CAB; Sun, 13 Nov 2011 18:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ19-jKJ5g4n; Sun, 13 Nov 2011 18:57:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7CE1F0C8A; Sun, 13 Nov 2011 18:57:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111114025750.9328.29285.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2011 18:57:50 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ring-protection-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:57:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Applicability of MPLS-TP Linear Protection for Ring Topo= logies Author(s) : Yaacov Weingarten Stewart Bryant Nurit Sprecher Danielle Ceccarelli Diego Caviglia Francesco Fondelli Marco Corsi Bo Wu Xuehui Dai Filename : draft-ietf-mpls-tp-ring-protection-00.txt Pages : 28 Date : 2011-11-13 This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-00.txt From huubatwork@gmail.com Sun Nov 13 19:16:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02541F0CAD for ; Sun, 13 Nov 2011 19:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXmZSxpnv9TI for ; Sun, 13 Nov 2011 19:16:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10A1F0C8E for ; Sun, 13 Nov 2011 19:16:41 -0800 (PST) Received: by yenq4 with SMTP id q4so2846013yen.31 for ; Sun, 13 Nov 2011 19:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mYGtmpIpnjC+AXVd/53f0AkaAbiY+QG6UyY+2QKKaJo=; b=nru+gJadNKXsOuUEAOaf7ZC5ua6gjWC7cRHr+FZjM9tPTgRuBjrD7nBfuLu5lN/gNQ ZYscmMdw7gI9I2m7IPzv6I4U0XupjSutB+4oeQjvoT5jtqdj6LzIlcdJbkw76lonBcfi aFzSdYGsZ5TsswukvKIyatOKqGRXax4ZQIcfs= Received: by 10.236.195.4 with SMTP id o4mr11794649yhn.6.1321240601595; Sun, 13 Nov 2011 19:16:41 -0800 (PST) Received: from dhcp-166c.meeting.ietf.org (dhcp-166c.meeting.ietf.org. [130.129.22.108]) by mx.google.com with ESMTPS id o64sm28851353yhk.3.2011.11.13.19.16.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 19:16:41 -0800 (PST) Message-ID: <4EC08815.8010107@gmail.com> Date: Mon, 14 Nov 2011 04:16:37 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Lou Berger References: <4EC07E73.8050901@labn.net> In-Reply-To: <4EC07E73.8050901@labn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:16:42 -0000 Hello Lou, You wrote: > As the scope of this document (ITU-T G.8013/Y.1731) is just MEG IDs, I > guess this means that draft-ietf-mpls-tp-itu-t-identifiers will need to > explicitly define how to go from ICC-based MEG IDs to ICC_based > LSPs&Tunnels, right? The draft-ietf-mpls-tp-itu-t-identifiers described how the Global_ID can be based on CC and ICC. RFC6370 defines how LSPs&Tunnels use the Global_ID to provide a global unique number. Regards, huub. > On 11/14/2011 9:52 AM, Scott Mansfield wrote: >> Greg and Huub, >> >> Looking at the text of liaison, the actual text of the corrigendum 1 >> is not attached to the liaison. Currently the document is only >> available to ITU-T TIES members since the document is still >> "pre-published". >> >> Can you please provide the document? >> >> Regards, >> -scott. >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> Behalf Of Scott Mansfield >>> Sent: Sunday, November 13, 2011 8:36 PM >>> To: mpls@ietf.org >>> Subject: [mpls] FW: New Liaison Statement, "LS331 - >>> Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >>> >>> This is the liaison from the ITU-T that includes information >>> about the Global MEG ID. Uses the Country Code and the ICC >>> to make the MEG ID globally unique. >>> >>> Regards, >>> -scott. >>> >>>> -----Original Message----- >>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>> Sent: Thursday, October 06, 2011 4:52 PM >>>> To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu >>>> Cc: yoichi.maeda@ttc.or.jp; >>>> Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org; lear@cisco.com; >>>> Scott Mansfield; huub.van.helvoort@huawei.com; tsbsg15@itu.int; >>>> greg.jones@itu.int; hiroshi.ota@itu.int >>>> Subject: New Liaison Statement, "LS331 - Corrigendum 1 to >>>> Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >>>> >>>> Title: LS331 - Corrigendum 1 to Recommendation ITU-T >>>> G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL of the >>>> IETF Web page: /liaison/1100/ >>>> >>>> From: ITU-T SG 15 (Greg Jones) >>>> To: Multiprotocol Label Switching (rcallon@juniper.net, >>>> swallow@cisco.com, loa@pi.nu) >>>> Cc: >>>> yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl >>>> s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com >>>> Reponse Contact: >>>> tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int >>>> Technical Contact: huub.van.helvoort@huawei.com >>>> Purpose: For information >>>> >>>> Body: The experts of Q10/15 would like to inform you that they have >>>> agreed to a corrigendum for Recommendation ITU-T >>>> G.8013/Y.1731 "OAM functions and mechanisms for Ethernet based >>>> networks." >>>> This corrigendum provides the definition of a globally >>> unique MEG-ID >>>> by using the Country Code (CC) and ITU-T Carrier Code (ICC). >>>> Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T >>>> G.8013/Y.1731". >>>> Attachment(s): >>>> >>>> LS331 - Corrigendum 1 to Recommendation ITU-T >>>> G.8013/Y.1731: Global MEG_ID - pdf body >>>> https://datatracker.ietf.org/documents/LIAISON/file1279.pdf >>>> >>>> >>>> >>> _______________________________________________ >>> 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 >> >> >> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 我爱外点一七三一 From sriganesh.kini@ericsson.com Sun Nov 13 19:38:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22A011E81AE for ; Sun, 13 Nov 2011 19:38:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgNz-XhZ905O for ; Sun, 13 Nov 2011 19:38:03 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7024E11E80AE for ; Sun, 13 Nov 2011 19:38:03 -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 pAE3bxG8029316; Sun, 13 Nov 2011 21:38:00 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 22:37:56 -0500 From: Sriganesh Kini To: "draft-bitar-mpls-isis-explicit-null-label@tools.ietf.org" Date: Sun, 13 Nov 2011 22:37:54 -0500 Thread-Topic: Comment on draft-bitar-mpls-isis-explicit-null-label Thread-Index: AcyifswBUkVd/50ZTjWiGUI1oJziFg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 03:38:04 -0000 R3V5cywNCg0KSSB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIGxvb2sgYXQgZHJhZnQtIGtpbmktcHdl My1lbmNhcC1lZmZpY2llbnQtaXAtIHRoYXQgdXNlcyBHUkUgdG8gc2VuZCBJc2lzLiBUaGlzIGRv ZXMgbm90IHJlcXVpcmUgYW4gZXh0cmEgbGFiZWwuDQoNCg0KDQotIFNyaQ0KDQpTZW50IGZyb20g bXkgaVBhZA0K From gregimirsky@gmail.com Sun Nov 13 21:35:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACC11E80F8 for ; Sun, 13 Nov 2011 21:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1zIjRtmpQEw for ; Sun, 13 Nov 2011 21:35:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A64911E80D4 for ; Sun, 13 Nov 2011 21:35:23 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so5620516vcb.31 for ; Sun, 13 Nov 2011 21:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=n6pP4XBo1XEzhurAJsuJ1CeGp7dznTN/5DmNxb0Sy2A=; b=MAB14hj7d0gtZ56dbCJuTAZ5lVFy529NZJY2TffP5PsXd5XzGIig4sQGscX9qJhDJ1 JxKMNg8AoYvCaXru9d5ke2M4OmNFVAH3kqdF46aB7e1m4c0onT4lxLMtPobfOhPgjfJR sd8AT0cAeJNMaooKGKAzqbyLC34LX05wZxmT4= MIME-Version: 1.0 Received: by 10.52.94.102 with SMTP id db6mr32994748vdb.118.1321248922943; Sun, 13 Nov 2011 21:35:22 -0800 (PST) Received: by 10.220.94.198 with HTTP; Sun, 13 Nov 2011 21:35:22 -0800 (PST) Date: Sun, 13 Nov 2011 21:35:22 -0800 Message-ID: From: Greg Mirsky To: Dan Frost , stbryant@cisco.com, BOCCI Matthew , mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307cff0ab6402e04b1ab3cb2 Subject: [mpls] GAP Request operation over unidirectional constructs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 05:35:24 -0000 --20cf307cff0ab6402e04b1ab3cb2 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, et al., I'd like to continue the discussion we've started at the meeting. I think that it is possible for LSRs to be interconnected only by unidirectional sections/links. In that case: - should request sender explicitly specify scope of the request? That might require addition of Node Identifier TLV to the list in Section 4.1. - how addressee responds? I think that rules set forth in the last paragraph of Section 4.1 might be too restrictive to operate GAP Request TLV over unidirectional constructs. Regards, Greg --20cf307cff0ab6402e04b1ab3cb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors, et al.,
I'd like to continue the discussion we've = started at the meeting. I think that it is possible for LSRs to be intercon= nected only by unidirectional sections/links. In that case:
  • shou= ld request sender explicitly specify scope of the request? That might requi= re addition of Node Identifier TLV to the list in Section 4.1.
  • how addressee responds?
I think that rules set forth in t= he last paragraph of Section 4.1 might be too restrictive to operate GAP Re= quest TLV over unidirectional constructs.

Regards,
Greg
--20cf307cff0ab6402e04b1ab3cb2-- From eric.gray@ericsson.com Sun Nov 13 21:50:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63911E81E7 for ; Sun, 13 Nov 2011 21:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUx+XF+pvvRt for ; Sun, 13 Nov 2011 21:50:16 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15AAF11E81E4 for ; Sun, 13 Nov 2011 21:50:15 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAE5oEM0032560 for ; Sun, 13 Nov 2011 23:50:15 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Nov 2011 00:50:09 -0500 From: Eric Gray To: "mpls@ietf.org" Date: Mon, 14 Nov 2011 00:50:08 -0500 Thread-Topic: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Thread-Index: AQJ54nkN6OkHAN02OVw3K7PcoGnpegJZAdbylDvCvjCAAsfrIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 05:50:17 -0000 Forwarding in plain text... ________________________________ From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Saturday, November 12, 2011 6:03 AM To: Eric Gray Cc: mpls@ietf.org Subject: RE: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Eric, Can I propose a solution based on the idea that RFC 6370 contains adequate= =20 description of what is included in RFC 6370?=20 Don't spend time in your I-D describing what is in RFC 6370. Thus: OLD RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management entity identifiers to support bidirectional (co-routed and associated) point-to-point MPLS-TP LSPs, including PWs and Sections which follow the IP/MPLS conventions. NEW RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management entity identifiers that follow the IP/MPLS conventions. END Can I also use this email to question the text in the very next paragraph? = You have This document specifies an alternative way to uniquely identify an operator/service provider based on ITU-T conventions and specifies how this operator/service provider identifier can be used to make the existing set of MPLS-TP transport and management entity identifiers, defined by RFC 6370 [RFC6370], globally unique. My concern is mainly with "and specifies...make the existing...globally uni= que".=20 There is an implication in this that the identifiers in RFC 6370 are someho= w=20 incapable of being globally unique, whereas the Global_ID of RFC 6370 is gl= obally=20 unique.=20 I would also note that your I-D continues to make use of some identifiers f= rom=20 RFC 6370, but this text implies the I-D is an entirely alternative approach= .=20 Can I suggest: OLD This document specifies an alternative way to uniquely identify an operator/service provider based on ITU-T conventions and specifies how this operator/service provider identifier can be used to make the existing set of MPLS-TP transport and management entity identifiers, defined by RFC 6370 [RFC6370], globally unique. NEW This document specifies an alternative way to construct MPLS-TP identifiers replacing some elements of the identifiers defined in=20 RFC 6370 [RFC6370] with objects following current ITU-T identifier conventions. END Cheers, Adrian From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Gray Sent: 11 November 2011 11:32 To: Gregory Mirsky Cc: huub.van.helvoort@huawei.com; mpls@ietf.org Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Greg, This draft is only interested in addressing identifiers associated= =20 with bi-directional LSP - at least at present. RFC 6370 does define=20 identifiers that can be used for this case, that are based on IP/MPLS=20 conventions. So the statement is accurate. However, we could try to make it clearer that we're not saying that= =20 RFC 6370 is limited to the bi-directional case. The difficulty lies in try= ing=20 to make this clearer without complicating the text with information that is= =20 not relevant to this draft. For example, if we explicily state that RFC 6370 includes support f= or=20 IP/MPLS based identifiers for unidirectional LSPs, we would also need to=20 explicitly state that this type of identifier either doesn't apply to this= =20 document, or is out of scope. In general, I don't think it is necessarily = a=20 good idea to add text to a document that then makes it necessary to add=20 additional text to clarify that the previously added text is out of scope i= n=20 the document.=20 Perhaps you can suggest wording that makes the fact that RFC 6370 d= oes not limit identifiers to the bi-directional case clearer, without making it= =20 necessary to then add that this document is limited in this respect? -- Eric _____________________________________________=20 From: Gregory Mirsky =20 Sent: Thursday, November 10, 2011 2:03 PM To: rolf.winter@neclab.eu; Eric Gray; huub.van.helvoort@huawei.com;=20 malcolm.betts@zte.com.cn; mpls@ietf.org Subject: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 Importance: High Dear Authors, et al., I have a question about the scope of the document. Introduction references = only=20 bi-directional LSPs in "RFC 6370 [RFC6370] defines a set of MPLS-TP transpo= rt=20 and management entity identifiers to support bidirectional (co-routed and=20 associated) point-to-point MPLS-TP LSPs ..." I think that RFC 6370 implicit= ly=20 defines ID for p2p unidirectional LSP as well in the following format: A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID or if globally unique LSP ID required A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::L= SP_Num Regards, Greg= From lizho.jin@gmail.com Sun Nov 13 22:36:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909491F0C72 for ; Sun, 13 Nov 2011 22:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc-zspcBgvhe for ; Sun, 13 Nov 2011 22:36:59 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E19141F0C4F for ; Sun, 13 Nov 2011 22:36:58 -0800 (PST) Received: by qadb40 with SMTP id b40so4052885qad.10 for ; Sun, 13 Nov 2011 22:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMFbdbKAHjobFnkanujhB7kGbMkshtOlkmPQTuoyg9A=; b=u/OOetpJEE5ihW1S1A4RoZ+S6kzO71b/FPxG91Q1z0LT75XkPrwouSMbVE568WMcbL /WVgKLa/9/i1W7c+txRrFWk0RxMrnD0aQT6Ks9wlk+k6a5BRsXUKqcbeaYeY2w2PkPbV 4v4B9+gZz4n5Kqx3Om9Z9KvUoYke4eGpDSCNw= MIME-Version: 1.0 Received: by 10.224.104.134 with SMTP id p6mr5450301qao.5.1321249360324; Sun, 13 Nov 2011 21:42:40 -0800 (PST) Received: by 10.224.2.201 with HTTP; Sun, 13 Nov 2011 21:42:40 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Nov 2011 13:42:40 +0800 Message-ID: From: Lizhong Jin To: Mach Chen Content-Type: multipart/alternative; boundary=bcaec54316c0c8270d04b1ab5668 Cc: mpls@ietf.org Subject: Re: [mpls] Comments of draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 06:36:59 -0000 --bcaec54316c0c8270d04b1ab5668 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thanks Mach. Then could I understand the two drafts define the same feature with different way? This really confuses me. Regards Lizhong =D4=DA 2011=C4=EA11=D4=C214=C8=D5 =C9=CF=CE=E79:57=A3=ACMach Chen =D0=B4=B5=C0=A3=BA > Hi Lizhong, > > Thanks for your comments. > > I see the difference is that draft-mpls-return-path-specified-lsp-ping > mainly applies to IP/MPLS scenario, and it may be apply to MPLS-TP > scenario; and draft-ietf-mpls-tp-on-demand-cv-07 applies to MPLS-TP > scenarios. > > The return path validation was firstly proposed in > draft-mpls-return-path-specified-lsp-ping draft, and it's only one of the > fuctions of return-path-specified-lsp-ping. > > Best regards, > Mach > ________________________________________ > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mpls-bounces@ietf.org] =B4=FA= =B1=ED Lizhong Jin [ > lizho.jin@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 9:36 > =B5=BD: Mach Chen > Cc: mpls@ietf.org > =D6=F7=CC=E2: [mpls] Comments of draft-ietf-mpls-return-path-specified-ls= p-ping-04 > > Hi Mach, > Because of time limited at the session, I need some clarification on the > list. > Both draft-ietf-mpls-return-path-specified-lsp-ping section 3.2 and > draft-ietf-mpls-tp-on-demand-cv-07 section 3.4.1 provide the feature of > "the Responder SHOULD return reverse path FEC information". > What's the difference between the two drafts? It seems they provide the > same feature with different way. > > Thank you. > Lizhong > --bcaec54316c0c8270d04b1ab5668 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Thanks Mach. Then could I understand the two drafts define the same fe= ature with different way? This really confuses me.
 
Regards
Lizhong

=D4=DA 2011=C4=EA11=D4=C214=C8=D5 =C9=CF=CE=E79:= 57=A3=ACMach Chen <mach.chen@huawei.com>=D0=B4=B5=C0=A3=BA
Hi Lizhong,

Thanks for yo= ur comments.

I see the difference is that draft-mpls-return-path-spe= cified-lsp-ping mainly applies to IP/MPLS scenario, and it may be apply to = MPLS-TP scenario; and draft-ietf-mpls-tp-on-demand-cv-07 applies to MPLS-TP= scenarios.

The return path validation was firstly proposed in draft-mpls-return-pa= th-specified-lsp-ping draft, and it's only one of the fuctions of retur= n-path-specified-lsp-ping.

Best regards,
Mach
________________= ________________________
=B7=A2=BC=FE=C8=CB: mpls-bounces@i= etf.org [mpls-bounces@ietf.org= ] =B4=FA=B1=ED Lizhong Jin [lizh= o.jin@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8= =D5 9:36
=B5=BD: Mach Chen
Cc: mpls@ietf.org=
=D6=F7=CC=E2: [mpls] Comments of draft-ietf-mpls-return-path-specified-= lsp-ping-04

Hi Mach,
Because of time limited at the session, I= need some clarification on the list.
Both draft-ietf-mpls-return-path-s= pecified-lsp-ping section 3.2 and draft-ietf-mpls-tp-on-demand-cv-07 sectio= n 3.4.1 provide the feature of "the Responder SHOULD return reverse pa= th FEC information".
What's the difference between the two drafts? It seems they provide the= same feature with different way.

Thank you.
Lizhong

--bcaec54316c0c8270d04b1ab5668-- From sriganesh.kini@ericsson.com Sun Nov 13 22:38:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722111E8213 for ; Sun, 13 Nov 2011 22:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGpqcTCGogQl for ; Sun, 13 Nov 2011 22:38:48 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A011E81F1 for ; Sun, 13 Nov 2011 22:38:48 -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 pAE6cfVA014409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2011 00:38:41 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 14 Nov 2011 01:38:40 -0500 From: Sriganesh Kini To: Mach Chen Date: Mon, 14 Nov 2011 01:38:38 -0500 Thread-Topic: =?utf-8?B?W21wbHNdIOetlOWkjTogIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBscy1y?= =?utf-8?B?ZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQ=?= Thread-Index: AcyimAt3mKE/ZwJzT+Obgq5sL9ybng== Message-ID: <636D3924-BE55-478F-AB1F-F8CEFADC8817@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb2YgZHJhZnQtaWV0Zi1tcGxz?= =?utf-8?q?-return-path-specified-lsp-ping-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 06:38:49 -0000 TWFjaA0KDQpZb3VyIGRyYWZ0IHJlZmVycyB0byBtcGxzLVRQIHJlcXVpcmVtZW50cyByZmMgaW4g cHJvYmxlbSBzdG10LiBZb3VyIGFwcGxpY2FiaWxpdHkgc3RtdCBiZWxvdyBkb2Vzbid0IHNlZW0g aW5saW5lIHdpdGggdGhhdC4NCg0KLSBTcmkNCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gTm92 IDE0LCAyMDExLCBhdCA5OjU3IEFNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPiB3 cm90ZToNCg0KPiBIaSBMaXpob25nLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0K PiANCj4gSSBzZWUgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBkcmFmdC1tcGxzLXJldHVybi1wYXRo LXNwZWNpZmllZC1sc3AtcGluZyBtYWlubHkgYXBwbGllcyB0byBJUC9NUExTIHNjZW5hcmlvLCBh bmQgaXQgbWF5IGJlIGFwcGx5IHRvIE1QTFMtVFAgc2NlbmFyaW87IGFuZCBkcmFmdC1pZXRmLW1w bHMtdHAtb24tZGVtYW5kLWN2LTA3IGFwcGxpZXMgdG8gTVBMUy1UUCBzY2VuYXJpb3MuDQo+IA0K PiBUaGUgcmV0dXJuIHBhdGggdmFsaWRhdGlvbiB3YXMgZmlyc3RseSBwcm9wb3NlZCBpbiBkcmFm dC1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBkcmFmdCwgYW5kIGl0J3Mgb25s eSBvbmUgb2YgdGhlIGZ1Y3Rpb25zIG9mIHJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZy4N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gTWFjaA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IOWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3JnIFttcGxz LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMaXpob25nIEppbiBbbGl6aG8uamluQGdtYWlsLmNv bV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTHmnIgxNOaXpSA5OjM2DQo+IOWIsDogTWFjaCBD aGVuDQo+IENjOiBtcGxzQGlldGYub3JnDQo+IOS4u+mimDogW21wbHNdIENvbW1lbnRzIG9mIGRy YWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQNCj4gDQo+IEhp IE1hY2gsDQo+IEJlY2F1c2Ugb2YgdGltZSBsaW1pdGVkIGF0IHRoZSBzZXNzaW9uLCBJIG5lZWQg c29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBsaXN0Lg0KPiBCb3RoIGRyYWZ0LWlldGYtbXBscy1y ZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcgc2VjdGlvbiAzLjIgYW5kIGRyYWZ0LWlldGYt bXBscy10cC1vbi1kZW1hbmQtY3YtMDcgc2VjdGlvbiAzLjQuMSBwcm92aWRlIHRoZSBmZWF0dXJl IG9mICJ0aGUgUmVzcG9uZGVyIFNIT1VMRCByZXR1cm4gcmV2ZXJzZSBwYXRoIEZFQyBpbmZvcm1h dGlvbiIuDQo+IFdoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzPyBJ dCBzZWVtcyB0aGV5IHByb3ZpZGUgdGhlIHNhbWUgZmVhdHVyZSB3aXRoIGRpZmZlcmVudCB3YXku DQo+IA0KPiBUaGFuayB5b3UuDQo+IExpemhvbmcNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From mach.chen@huawei.com Sun Nov 13 22:40:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9482111E8214 for ; Sun, 13 Nov 2011 22:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-3.318, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvLHr-OW2GrC for ; Sun, 13 Nov 2011 22:40:35 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8411E821E for ; Sun, 13 Nov 2011 22:40:35 -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 <0LUN00IEU13OTW@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 14:38:12 +0800 (CST) Received: from szxrg01-dlp.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 <0LUN004PE11JE1@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 14:38:12 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA41047; Mon, 14 Nov 2011 14:38:11 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 14:38:10 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 14:38:02 +0800 Date: Mon, 14 Nov 2011 06:38:01 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [172.24.2.41] To: Lizhong Jin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [mpls] Comments of draft-ietf-mpls-return-path-specified-lsp-ping-04 Thread-index: AQHMom3fFVuyPYoH00GYd163YzTBwpWrmUG1//+8OACAAI/jkg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 06:40:36 -0000 SGkgTGl6aG9uZywNCg0KTm90IGFjY3VyYXRlbHksIHRoZSB0d28gZHJhZnRzIGRlZmluZSB0aGVp ciBvd24gZnVjbmlvbnMgdG8gc29sdmUgdGhlaXIgb3duIGlzc3Vlcy4gUmV0dXJuIHBhdGggdmFs aWRhdGlvbiBpcyBqdXN0IG9uZSBvZiB0aGUgZnVjdGlvbnMuIEluIGFkZHRpb24sIGFzIEkgc2Fp ZCBpbiB0aGUgcHJldmlvdXMgZW1haWwsIHJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBk cmFmdCBtYWlubHkgYXBwbHkgdG8gSVAvTVBMUyBuZXR3b3JrLiBBbmQgdGhlIG1wbHMtdHAtb24t ZGVtYW5kLWN2IGRyYWZ0IGlzIGRlc2lnbmVkIGZvciBNUExTLVRQIG5ldHdvcmsuDQoNCkJlc3Qg cmVnYXJkcywNCk1hY2gNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogTGl6aG9uZyBKaW4gW2xpemhvLmppbkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAx McTqMTHUwjE0yNUgMTM6NDINCrW9OiBNYWNoIENoZW4NCkNjOiBtcGxzQGlldGYub3JnDQrW98zi OiBSZTogW21wbHNdIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVj aWZpZWQtbHNwLXBpbmctMDQNCg0KVGhhbmtzIE1hY2guIFRoZW4gY291bGQgSSB1bmRlcnN0YW5k IHRoZSB0d28gZHJhZnRzIGRlZmluZSB0aGUgc2FtZSBmZWF0dXJlIHdpdGggZGlmZmVyZW50IHdh eT8gVGhpcyByZWFsbHkgY29uZnVzZXMgbWUuDQoNClJlZ2FyZHMNCkxpemhvbmcNCg0K1NogMjAx McTqMTHUwjE0yNUgyc/O5zk6NTejrE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb208bWFp bHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj7QtLXAo7oNCkhpIExpemhvbmcsDQoNClRoYW5rcyBm b3IgeW91ciBjb21tZW50cy4NCg0KSSBzZWUgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBkcmFmdC1t cGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBtYWlubHkgYXBwbGllcyB0byBJUC9N UExTIHNjZW5hcmlvLCBhbmQgaXQgbWF5IGJlIGFwcGx5IHRvIE1QTFMtVFAgc2NlbmFyaW87IGFu ZCBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTA3IGFwcGxpZXMgdG8gTVBMUy1UUCBz Y2VuYXJpb3MuDQoNClRoZSByZXR1cm4gcGF0aCB2YWxpZGF0aW9uIHdhcyBmaXJzdGx5IHByb3Bv c2VkIGluIGRyYWZ0LW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nIGRyYWZ0LCBh bmQgaXQncyBvbmx5IG9uZSBvZiB0aGUgZnVjdGlvbnMgb2YgcmV0dXJuLXBhdGgtc3BlY2lmaWVk LWxzcC1waW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIExpemhvbmcgSmluIFtsaXpoby5qaW5AZ21haWwuY29t PG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPl0NCreiy83KsbzkOiAyMDExxOoxMdTCMTTI1SA5 OjM2DQq1vTogTWFjaCBDaGVuDQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz4NCtb3zOI6IFttcGxzXSBDb21tZW50cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgt c3BlY2lmaWVkLWxzcC1waW5nLTA0DQoNCkhpIE1hY2gsDQpCZWNhdXNlIG9mIHRpbWUgbGltaXRl ZCBhdCB0aGUgc2Vzc2lvbiwgSSBuZWVkIHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgbGlzdC4N CkJvdGggZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBzZWN0 aW9uIDMuMiBhbmQgZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC1jdi0wNyBzZWN0aW9uIDMu NC4xIHByb3ZpZGUgdGhlIGZlYXR1cmUgb2YgInRoZSBSZXNwb25kZXIgU0hPVUxEIHJldHVybiBy ZXZlcnNlIHBhdGggRkVDIGluZm9ybWF0aW9uIi4NCldoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSB0d28gZHJhZnRzPyBJdCBzZWVtcyB0aGV5IHByb3ZpZGUgdGhlIHNhbWUgZmVhdHVy ZSB3aXRoIGRpZmZlcmVudCB3YXkuDQoNClRoYW5rIHlvdS4NCkxpemhvbmcNCg0K From hongk@cisco.com Sun Nov 13 22:57:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759C11E80A0 for ; Sun, 13 Nov 2011 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8cSYW0+2XGf for ; Sun, 13 Nov 2011 22:57:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 904B211E8094 for ; Sun, 13 Nov 2011 22:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=6828; q=dns/txt; s=iport; t=1321253817; x=1322463417; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qh1Cucsgky6+kH3kYQh78C5aS/ayhDogFUhFgIW6HBg=; b=cVRurtIeh3ovQI/it4V3Rzlrd/wPLJHRUIoITCg+Y8muXty5UWEpnHtZ YMmqKIZOaHn+dcW6+e0IqXIEVe5fAK4V95q+IYCoVuAJrg17y5d0VIEAF FPOO4JN56FxPOsLK24qyDcmulLo4BJCPk2arIaYMcWJdjopKyNnFWXDaq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAADC7wE6tJV2Y/2dsb2JhbABChQCUd48FgQGBBYFyAQEBAgEBAQEBDwEQDQQzBAMLBQcEAgEGAhEDAQEBAQICBgYTBAECAgIBASUfCAEIAQEEARIIGodgCJksAYxZgWqPBASBMIc5M2MEiBCRYoM6iRo X-IronPort-AV: E=Sophos;i="4.69,506,1315180800"; d="scan'208";a="35637519" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 14 Nov 2011 06:56:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAE6uu0Y030554; Mon, 14 Nov 2011 06:56:56 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 00:56:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 14 Nov 2011 00:56:51 -0600 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC0565199D@XMB-RCD-103.cisco.com> In-Reply-To: <4EC08815.8010107@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" Thread-Index: Acyie9m4qp0kTFZLSVevYHgyhvulkwAG9ncw References: <4EC07E73.8050901@labn.net> <4EC08815.8010107@gmail.com> From: "Kyung-Yeop Hong (hongk)" To: , "Lou Berger" X-OriginalArrivalTime: 14 Nov 2011 06:56:56.0426 (UTC) FILETIME=[991B2CA0:01CCA29A] Cc: mpls@ietf.org Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 06:57:02 -0000 SW4gZHJhZnQtaWV0Zi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzOg0KLi4uLi4NCjMuICBVc2Ug b2YgdGhlIElDQ19PcGVyYXRvcl9JRA0KDQpBcyBhbiBleGFtcGxlLCBhbiBJbnRlcmZhY2UgSWRl bnRpZmllciAoSUZfSUQpIGluIFJGQyA2MzcwIFtSRkM2MzcwXQ0KICAgaXMgc3BlY2lmaWVkIGFz IHRoZSBjb25jYXRlbmF0aW9uIG9mIHRoZSBOb2RlX0lEIChhIHVuaXF1ZSAzMi1iaXQNCiAgIHZh bHVlIGFzc2lnbmVkIGJ5IHRoZSBvcGVyYXRvcikgYW5kIHRoZSBJbnRlcmZhY2UgTnVtYmVyIChJ Rl9OdW0sIGENCiAgIDMyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyIGFzc2lnbmVkIGJ5IHRoZSBvcGVy YXRvciB0aGF0IGlzIHVuaXF1ZQ0KICAgd2l0aGluIHRoZSBzY29wZSBvZiBhIE5vZGVfSUQpLiAg DQouLi4uLg0KDQpSRkMgNjM3MCBkZWZpbmVzIGFuIElGX0lEIHRvIGJlIGEgNjQtYml0IGlkZW50 aWZpZXIgZm9ybWVkIGJ5IGNvbmNhdGVuYXRpbmcgYSAzMi1iaXQgb2YgTm9kZSBJRCBhbmQgYSAz Mi1iaXQgb2YgSUZfTnVtLg0KDQpUaGUgVU1DIHVzZWQgaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLWl0 dS10LWlkZW50aWZpZXJzIGhhcyBhIG1heGltdW0gbnVtYmVyIG9mIDcgY2hhcmFjdGVycyBvZiA3 IGJpdHMuDQoNCkhvdyBjYW4gSUZfSUQgYmUgZm9ybWVkIHdpdGggNyBjaGFyYWN0ZXJzIG9mIDcg Yml0cz8NCg0KS1kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDEzLCAyMDExIDEwOjE3 IFBNDQpUbzogTG91IEJlcmdlcg0KQ2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBs c10gRlc6IEZXOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJMUzMzMSAtIENvcnJpZ2VuZHVtIDEg dG8gUmVjb21tZW5kYXRpb24gSVRVLVQgRy44MDEzL1kuMTczMTogR2xvYmFsIE1FR19JRCINCg0K SGVsbG8gTG91LA0KDQpZb3Ugd3JvdGU6DQoNCj4gQXMgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQgKElUVS1UIEcuODAxMy9ZLjE3MzEpIGlzIGp1c3QgTUVHIElEcywgSQ0KPiBndWVzcyB0aGlz IG1lYW5zIHRoYXQgZHJhZnQtaWV0Zi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzIHdpbGwgbmVl ZCB0bw0KPiBleHBsaWNpdGx5IGRlZmluZSBob3cgdG8gZ28gZnJvbSBJQ0MtYmFzZWQgTUVHIElE cyB0byBJQ0NfYmFzZWQNCj4gTFNQcyZUdW5uZWxzLCByaWdodD8NCg0KVGhlIGRyYWZ0LWlldGYt bXBscy10cC1pdHUtdC1pZGVudGlmaWVycyBkZXNjcmliZWQgaG93IHRoZQ0KR2xvYmFsX0lEIGNh biBiZSBiYXNlZCBvbiBDQyBhbmQgSUNDLg0KUkZDNjM3MCBkZWZpbmVzIGhvdyBMU1BzJlR1bm5l bHMgdXNlIHRoZSBHbG9iYWxfSUQgdG8gcHJvdmlkZQ0KYSBnbG9iYWwgdW5pcXVlIG51bWJlci4N Cg0KUmVnYXJkcywgaHV1Yi4NCg0KDQoNCj4gT24gMTEvMTQvMjAxMSA5OjUyIEFNLCBTY290dCBN YW5zZmllbGQgd3JvdGU6DQo+PiBHcmVnIGFuZCBIdXViLA0KPj4NCj4+IExvb2tpbmcgYXQgdGhl IHRleHQgb2YgbGlhaXNvbiwgdGhlIGFjdHVhbCB0ZXh0IG9mIHRoZSBjb3JyaWdlbmR1bSAxDQo+ PiBpcyBub3QgYXR0YWNoZWQgdG8gdGhlIGxpYWlzb24uICBDdXJyZW50bHkgdGhlIGRvY3VtZW50 IGlzIG9ubHkNCj4+IGF2YWlsYWJsZSB0byBJVFUtVCBUSUVTIG1lbWJlcnMgc2luY2UgdGhlIGRv Y3VtZW50IGlzIHN0aWxsDQo+PiAicHJlLXB1Ymxpc2hlZCIuDQo+Pg0KPj4gQ2FuIHlvdSBwbGVh c2UgcHJvdmlkZSB0aGUgZG9jdW1lbnQ/DQo+Pg0KPj4gUmVnYXJkcywNCj4+IC1zY290dC4NCj4+ DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVoYWxmIE9m IFNjb3R0IE1hbnNmaWVsZA0KPj4+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTMsIDIwMTEgODoz NiBQTQ0KPj4+IFRvOiBtcGxzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogW21wbHNdIEZXOiBOZXcg TGlhaXNvbiBTdGF0ZW1lbnQsICJMUzMzMSAtDQo+Pj4gQ29ycmlnZW5kdW0gMSB0byBSZWNvbW1l bmRhdGlvbiBJVFUtVCBHLjgwMTMvWS4xNzMxOiBHbG9iYWwgTUVHX0lEIg0KPj4+DQo+Pj4gVGhp cyBpcyB0aGUgbGlhaXNvbiBmcm9tIHRoZSBJVFUtVCB0aGF0IGluY2x1ZGVzIGluZm9ybWF0aW9u DQo+Pj4gYWJvdXQgdGhlIEdsb2JhbCBNRUcgSUQuICBVc2VzIHRoZSBDb3VudHJ5IENvZGUgYW5k IHRoZSBJQ0MNCj4+PiB0byBtYWtlIHRoZSBNRUcgSUQgZ2xvYmFsbHkgdW5pcXVlLg0KPj4+DQo+ Pj4gUmVnYXJkcywNCj4+PiAtc2NvdHQuDQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4gRnJvbTogTGlhaXNvbiBTdGF0ZW1lbnQgTWFuYWdlbWVudCBUb29sIFttYWls dG86bHNtdEBpZXRmLm9yZ10NCj4+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIwMTEg NDo1MiBQTQ0KPj4+PiBUbzogcmNhbGxvbkBqdW5pcGVyLm5ldDsgc3dhbGxvd0BjaXNjby5jb207 IGxvYUBwaS5udQ0KPj4+PiBDYzogeW9pY2hpLm1hZWRhQHR0Yy5vci5qcDsNCj4+Pj4gU3RldmUu VHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb207IG1wbHNAaWV0Zi5vcmc7IGxlYXJAY2lzY28u Y29tOw0KPj4+PiBTY290dCBNYW5zZmllbGQ7IGh1dWIudmFuLmhlbHZvb3J0QGh1YXdlaS5jb207 IHRzYnNnMTVAaXR1LmludDsNCj4+Pj4gZ3JlZy5qb25lc0BpdHUuaW50OyBoaXJvc2hpLm90YUBp dHUuaW50DQo+Pj4+IFN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkxTMzMxIC0gQ29y cmlnZW5kdW0gMSB0bw0KPj4+PiBSZWNvbW1lbmRhdGlvbiBJVFUtVCBHLjgwMTMvWS4xNzMxOiBH bG9iYWwgTUVHX0lEIg0KPj4+Pg0KPj4+PiBUaXRsZTogTFMzMzEgLSBDb3JyaWdlbmR1bSAxIHRv IFJlY29tbWVuZGF0aW9uIElUVS1UDQo+Pj4+IEcuODAxMy9ZLjE3MzE6IEdsb2JhbCBNRUdfSUQg U3VibWlzc2lvbiBEYXRlOiAyMDExLTEwLTA2IFVSTCBvZiB0aGUNCj4+Pj4gSUVURiBXZWIgcGFn ZTogL2xpYWlzb24vMTEwMC8NCj4+Pj4NCj4+Pj4gRnJvbTogSVRVLVQgU0cgMTUgIChHcmVnIEpv bmVzPGdyZWcuam9uZXNAaXR1LmludD4pDQo+Pj4+IFRvOiBNdWx0aXByb3RvY29sIExhYmVsIFN3 aXRjaGluZyAocmNhbGxvbkBqdW5pcGVyLm5ldCwNCj4+Pj4gc3dhbGxvd0BjaXNjby5jb20sIGxv YUBwaS5udSkNCj4+Pj4gQ2M6DQo+Pj4+IHlvaWNoaS5tYWVkYUB0dGMub3IuanAsU3RldmUuVHJv d2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb20sbXBsDQo+Pj4+IHNAaWV0Zi5vcmcsbGVhckBjaXNj by5jb20sc2NvdHQubWFuc2ZpZWxkQGVyaWNzc29uLmNvbQ0KPj4+PiBSZXBvbnNlIENvbnRhY3Q6 DQo+Pj4+IHRzYnNnMTVAaXR1LmludCxncmVnLmpvbmVzQGl0dS5pbnQsaGlyb3NoaS5vdGFAaXR1 LmludA0KPj4+PiBUZWNobmljYWwgQ29udGFjdDogaHV1Yi52YW4uaGVsdm9vcnRAaHVhd2VpLmNv bQ0KPj4+PiBQdXJwb3NlOiBGb3IgaW5mb3JtYXRpb24NCj4+Pj4NCj4+Pj4gQm9keTogVGhlIGV4 cGVydHMgb2YgUTEwLzE1IHdvdWxkIGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IHRoZXkgaGF2ZQ0K Pj4+PiBhZ3JlZWQgdG8gYSBjb3JyaWdlbmR1bSBmb3IgUmVjb21tZW5kYXRpb24gSVRVLVQNCj4+ Pj4gRy44MDEzL1kuMTczMSAiT0FNIGZ1bmN0aW9ucyBhbmQgbWVjaGFuaXNtcyBmb3IgRXRoZXJu ZXQgYmFzZWQNCj4+Pj4gbmV0d29ya3MuIg0KPj4+PiBUaGlzIGNvcnJpZ2VuZHVtIHByb3ZpZGVz IHRoZSBkZWZpbml0aW9uIG9mIGEgZ2xvYmFsbHkNCj4+PiB1bmlxdWUgTUVHLUlEDQo+Pj4+IGJ5 IHVzaW5nIHRoZSBDb3VudHJ5IENvZGUgKENDKSBhbmQgSVRVLVQgQ2FycmllciBDb2RlIChJQ0Mp Lg0KPj4+PiBBdHRhY2g6IFRENDc3L1BMRU4sICJDb3JyaWdlbmR1bSAxIHRvIFJlY29tbWVuZGF0 aW9uIElUVS1UDQo+Pj4+IEcuODAxMy9ZLjE3MzEiLg0KPj4+PiBBdHRhY2htZW50KHMpOg0KPj4+ Pg0KPj4+PiAgICAgIExTMzMxIC0gQ29ycmlnZW5kdW0gMSB0byBSZWNvbW1lbmRhdGlvbiBJVFUt VA0KPj4+PiBHLjgwMTMvWS4xNzMxOiBHbG9iYWwgTUVHX0lEIC0gcGRmIGJvZHkNCj4+Pj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlMTI3OS5wZGYN Cj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+DQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbXBscyBt YWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCj4+DQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBs c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg0KDQotLSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueC ueS4gOS4g+S4ieS4gA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From lizho.jin@gmail.com Mon Nov 14 01:24:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7921F8E49 for ; Mon, 14 Nov 2011 01:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[AWL=-3.109, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRMFwEr-t-tD for ; Mon, 14 Nov 2011 01:24:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B325621F84D4 for ; Mon, 14 Nov 2011 01:24:30 -0800 (PST) Received: by qadb40 with SMTP id b40so4163049qad.10 for ; Mon, 14 Nov 2011 01:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=62JZcRvy4dMu8Dwig1YwRL3ur7EgVC8dMX5GZDpvgS0=; b=NFJ17PYqaIsMyorKC0mPcVFfgSBSV85thFCjohsTjO+BPi3crQnawwpGR6RHXN8IpM RAkwWsp2w89Hx9BLjmhuZ0EUvBHFT7JVuDmxIeda6cZ47thFDpA8vSm0RveTWvmxZWoj qo0o+u+Hi4Ljre+vmdhcJvPbN/MagRDcFFRAk= MIME-Version: 1.0 Received: by 10.224.71.7 with SMTP id f7mr13305550qaj.57.1321262669356; Mon, 14 Nov 2011 01:24:29 -0800 (PST) Received: by 10.224.2.201 with HTTP; Mon, 14 Nov 2011 01:24:29 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Nov 2011 17:24:29 +0800 Message-ID: From: Lizhong Jin To: Mach Chen Content-Type: multipart/alternative; boundary=bcaec51b9cf30fdf4a04b1ae7004 Cc: "mpls@ietf.org" Subject: Re: [mpls] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBs?= =?gb2312?b?cy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 09:24:53 -0000 --bcaec51b9cf30fdf4a04b1ae7004 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Mach, Accurately saying is: the two drafts define the same feature of "reponse should return via reverse path" with different way. I think the WG should define only one way. During the meeting, you said, draft-return-path-specified-lsp-ping also applies to MPLS-TP. The draft should explicitly say whether it is for MPLS or both MPLS and MPLS-TP. Thanks Lizhong =D4=DA 2011=C4=EA11=D4=C214=C8=D5 =CF=C2=CE=E72:38=A3=ACMach Chen =D0=B4=B5=C0=A3=BA > Hi Lizhong, > > Not accurately, the two drafts define their own fucnions to solve their > own issues. Return path validation is just one of the fuctions. In addtio= n, > as I said in the previous email, return-path-specified-lsp-ping draft > mainly apply to IP/MPLS network. And the mpls-tp-on-demand-cv draft is > designed for MPLS-TP network. > > Best regards, > Mach > ________________________________________ > =B7=A2=BC=FE=C8=CB: Lizhong Jin [lizho.jin@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 13:42 > =B5=BD: Mach Chen > Cc: mpls@ietf.org > =D6=F7=CC=E2: Re: [mpls] Comments of > draft-ietf-mpls-return-path-specified-lsp-ping-04 > > Thanks Mach. Then could I understand the two drafts define the same > feature with different way? This really confuses me. > > Regards > Lizhong > > =D4=DA 2011=C4=EA11=D4=C214=C8=D5 =C9=CF=CE=E79:57=A3=ACMach Chen mach.chen@huawei.com>>=D0=B4=B5=C0=A3=BA > Hi Lizhong, > > Thanks for your comments. > > I see the difference is that draft-mpls-return-path-specified-lsp-ping > mainly applies to IP/MPLS scenario, and it may be apply to MPLS-TP > scenario; and draft-ietf-mpls-tp-on-demand-cv-07 applies to MPLS-TP > scenarios. > > The return path validation was firstly proposed in > draft-mpls-return-path-specified-lsp-ping draft, and it's only one of the > fuctions of return-path-specified-lsp-ping. > > Best regards, > Mach > ________________________________________ > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [ > mpls-bounces@ietf.org] =B4=FA=B1=ED Lizhong= Jin [ > lizho.jin@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 9:36 > =B5=BD: Mach Chen > Cc: mpls@ietf.org > =D6=F7=CC=E2: [mpls] Comments of draft-ietf-mpls-return-path-specified-l= sp-ping-04 > > Hi Mach, > Because of time limited at the session, I need some clarification on the > list. > Both draft-ietf-mpls-return-path-specified-lsp-ping section 3.2 and > draft-ietf-mpls-tp-on-demand-cv-07 section 3.4.1 provide the feature of > "the Responder SHOULD return reverse path FEC information". > What's the difference between the two drafts? It seems they provide the > same feature with different way. > > Thank you. > Lizhong > > --bcaec51b9cf30fdf4a04b1ae7004 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Mach,
Accurately saying is:  the two drafts define the same feature of = "reponse should return via reverse path" with different way.= I think the WG should define only one way.
During the meeting, you said, draft-return-path-specified-lsp-pin= g also applies to MPLS-TP. The draft should explicitly say whether it is fo= r MPLS or both MPLS and MPLS-TP.
 
Thanks
Lizhong
 
=D4=DA 2011=C4=EA11=D4=C214=C8=D5 =CF=C2=CE=E72:= 38=A3=ACMach Chen <mach.chen@huawei.com>=D0=B4=B5=C0=A3=BA
Hi Lizhong,

Not accuratel= y, the two drafts define their own fucnions to solve their own issues. Retu= rn path validation is just one of the fuctions. In addtion, as I said in th= e previous email, return-path-specified-lsp-ping draft mainly apply to IP/M= PLS network. And the mpls-tp-on-demand-cv draft is designed for MPLS-TP net= work.

Best regards,
Mach
________________________________________
= =B7=A2=BC=FE=C8=CB: Lizhong Jin [liz= ho.jin@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8= =D5 13:42
=B5=BD: Mach Chen
Cc: mpls@ietf.org
=D6=F7=CC=E2: Re: [mpls] Comments of draft-ietf= -mpls-return-path-specified-lsp-ping-04

Thanks Mach. Then could I understand the two drafts d= efine the same feature with different way? This really confuses me.

= Regards
Lizhong

=D4=DA 2011=C4=EA11=D4=C214=C8=D5 =C9=CF=CE= =E79:57=A3=ACMach Chen <mach.che= n@huawei.com<mailto:mach.che= n@huawei.com>>=D0=B4=B5=C0=A3=BA
Hi Lizhong,

Thanks for your comments.

I see= the difference is that draft-mpls-return-path-specified-lsp-ping mainly ap= plies to IP/MPLS scenario, and it may be apply to MPLS-TP scenario; and dra= ft-ietf-mpls-tp-on-demand-cv-07 applies to MPLS-TP scenarios.

The return path validation was firstly proposed in draft-mpls-return-pa= th-specified-lsp-ping draft, and it's only one of the fuctions of retur= n-path-specified-lsp-ping.

Best regards,
Mach
________________= ________________________
=B7=A2=BC=FE=C8=CB: mpls-bou= nces@ietf.org<mailto:mpls-b= ounces@ietf.org> [mpls-boun= ces@ietf.org<mailto:mpls-bo= unces@ietf.org>] =B4=FA=B1=ED Lizhong Jin [lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 9:36=
=B5=BD: Mach Chen
Cc: mpls@ie= tf.org<mailto:mpls@ietf.org>=
=D6=F7=CC=E2: [mpls] Comments of draft-ietf-mpls-return-p= ath-specified-lsp-ping-04

Hi Mach,
Because of time limited at the= session, I need some clarification on the list.
Both draft-ietf-mpls-re= turn-path-specified-lsp-ping section 3.2 and draft-ietf-mpls-tp-on-demand-c= v-07 section 3.4.1 provide the feature of "the Responder SHOULD return= reverse path FEC information".
What's the difference between the two drafts? It seems they provide the= same feature with different way.

Thank you.
Lizhong


--bcaec51b9cf30fdf4a04b1ae7004-- From mach.chen@huawei.com Mon Nov 14 01:39:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B7721F8F50 for ; Mon, 14 Nov 2011 01:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-2.654, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js5chI49nysJ for ; Mon, 14 Nov 2011 01:39:44 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 01F7521F8D70 for ; Mon, 14 Nov 2011 01:39:07 -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 <0LUN00M949G8L5@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 17:38:32 +0800 (CST) Received: from szxrg02-dlp.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 <0LUN003YM9G79Q@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 17:38:32 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEZ06766; Mon, 14 Nov 2011 17:38:31 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 17:38:29 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 17:38:20 +0800 Date: Mon, 14 Nov 2011 09:38:19 +0000 From: Mach Chen In-reply-to: <636D3924-BE55-478F-AB1F-F8CEFADC8817@ericsson.com> X-Originating-IP: [172.24.2.40] To: Sriganesh Kini Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?W21wbHNdILTwuLQ6ICBDb21tZW50cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0?= =?gb2312?Q?urn-path-specified-lsp-ping-04?= Thread-index: AQHMopg9CtiSP/ucuUmXuK9E0g2KG5WsFVMz X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <636D3924-BE55-478F-AB1F-F8CEFADC8817@ericsson.com> Cc: "mpls@ietf.org" , Lizhong Jin Subject: [mpls] =?gb2312?b?tPC4tDogILTwuLQ6ICBDb21tZW50cyBvZiBkcmFmdC1p?= =?gb2312?b?ZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 09:39:47 -0000 U3Jpo6wNCg0KUmVmZXIgdG8gdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnQgcmZjIGlzIG1haW5seSBm b3IgcmVmZXJyaW5nIHRvIHRoZSBkZWZpaW5ldGlvbiBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgTFNQIGFuZCBJTUhPIHRoZSBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIHNob3VsZCBu b3Qgb25seSBiZWxvbmcgdG8gTVBMUy1UUC4gIE9mIGNhdXNlLCBJIGFtIG5vdCBzYXlpbmcgcmV0 dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nIGNhbiBub3QgYmUgdXNlZCBmb3IgTVBMUy1UUCBu ZXR3b3JrLiBJZiBpdCBpcyB1c2VkIGluIE1QTFMtVFAgc2NlbmFyaW8sIHllcywgZm9yIHRoZSBy ZXR1cm4gcGF0aCB2YWxpZGF0aW9uLCB0aGUgdHdvIGRyYWZ0cyBvdmVybGFwIG9uIHRoZSBmdW5j dGlvbi4gQnV0IHN1cHBvc2UgdGhhdCBvZiB0aGUgcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1w aW5nIGNhbiBhcHBseSB0byBtb3JlIGdlbmVyYWwgc2NlbmFyaW9zIHdoaWxlIHRoZSBvdGhlciBj YW5ub3QsIHNvIGluIHNvbWUgaG93IHRoZXkgbWF5IGNvbXBsZW1lbnQgZWFjaCBvdGhlci4NCg0K QmVzdCByZWdhcmQsDQpNYWNoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IFNyaWdhbmVzaCBLaW5pIFtzcmlnYW5lc2gua2luaUBlcmljc3Nvbi5jb21d DQq3osvNyrG85DogMjAxMcTqMTHUwjE0yNUgMTQ6MzgNCrW9OiBNYWNoIENoZW4NCkNjOiBMaXpo b25nIEppbjsgbXBsc0BpZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSC08Li0OiAgQ29tbWVudHMg b2YgZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZy0wNA0KDQpN YWNoDQoNCllvdXIgZHJhZnQgcmVmZXJzIHRvIG1wbHMtVFAgcmVxdWlyZW1lbnRzIHJmYyBpbiBw cm9ibGVtIHN0bXQuIFlvdXIgYXBwbGljYWJpbGl0eSBzdG10IGJlbG93IGRvZXNuJ3Qgc2VlbSBp bmxpbmUgd2l0aCB0aGF0Lg0KDQotIFNyaQ0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiBOb3Yg MTQsIDIwMTEsIGF0IDk6NTcgQU0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+IHdy b3RlOg0KDQo+IEhpIExpemhvbmcsDQo+DQo+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCj4N Cj4gSSBzZWUgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBkcmFmdC1tcGxzLXJldHVybi1wYXRoLXNw ZWNpZmllZC1sc3AtcGluZyBtYWlubHkgYXBwbGllcyB0byBJUC9NUExTIHNjZW5hcmlvLCBhbmQg aXQgbWF5IGJlIGFwcGx5IHRvIE1QTFMtVFAgc2NlbmFyaW87IGFuZCBkcmFmdC1pZXRmLW1wbHMt dHAtb24tZGVtYW5kLWN2LTA3IGFwcGxpZXMgdG8gTVBMUy1UUCBzY2VuYXJpb3MuDQo+DQo+IFRo ZSByZXR1cm4gcGF0aCB2YWxpZGF0aW9uIHdhcyBmaXJzdGx5IHByb3Bvc2VkIGluIGRyYWZ0LW1w bHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nIGRyYWZ0LCBhbmQgaXQncyBvbmx5IG9u ZSBvZiB0aGUgZnVjdGlvbnMgb2YgcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLg0KPg0K PiBCZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbXBscy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIExpemhvbmcgSmluIFtsaXpoby5qaW5AZ21haWwuY29tXQ0KPiC3osvN yrG85DogMjAxMcTqMTHUwjE0yNUgOTozNg0KPiC1vTogTWFjaCBDaGVuDQo+IENjOiBtcGxzQGll dGYub3JnDQo+INb3zOI6IFttcGxzXSBDb21tZW50cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJu LXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0DQo+DQo+IEhpIE1hY2gsDQo+IEJlY2F1c2Ugb2Yg dGltZSBsaW1pdGVkIGF0IHRoZSBzZXNzaW9uLCBJIG5lZWQgc29tZSBjbGFyaWZpY2F0aW9uIG9u IHRoZSBsaXN0Lg0KPiBCb3RoIGRyYWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQt bHNwLXBpbmcgc2VjdGlvbiAzLjIgYW5kIGRyYWZ0LWlldGYtbXBscy10cC1vbi1kZW1hbmQtY3Yt MDcgc2VjdGlvbiAzLjQuMSBwcm92aWRlIHRoZSBmZWF0dXJlIG9mICJ0aGUgUmVzcG9uZGVyIFNI T1VMRCByZXR1cm4gcmV2ZXJzZSBwYXRoIEZFQyBpbmZvcm1hdGlvbiIuDQo+IFdoYXQncyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzPyBJdCBzZWVtcyB0aGV5IHByb3ZpZGUg dGhlIHNhbWUgZmVhdHVyZSB3aXRoIGRpZmZlcmVudCB3YXkuDQo+DQo+IFRoYW5rIHlvdS4NCj4g TGl6aG9uZw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From mach.chen@huawei.com Mon Nov 14 02:11:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E74911E80B4 for ; Mon, 14 Nov 2011 02:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.237 X-Spam-Level: X-Spam-Status: No, score=0.237 tagged_above=-999 required=5 tests=[AWL=-2.212, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6rVsvbiv-DZ for ; Mon, 14 Nov 2011 02:11:11 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC511E8155 for ; Mon, 14 Nov 2011 02:07:29 -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 <0LUN001FYAO17R@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 18:04:50 +0800 (CST) Received: from szxrg01-dlp.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 <0LUN00I8WANMJX@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 14 Nov 2011 18:04:49 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA64102; Mon, 14 Nov 2011 18:04:49 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 18:04:46 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 18:02:34 +0800 Date: Mon, 14 Nov 2011 10:02:34 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [172.24.2.40] To: Lizhong Jin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogW21wbHNdIENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbXBscy1yZXR1?= =?gb2312?Q?rn-path-specified-lsp-ping-04?= Thread-index: AQHMom3fFVuyPYoH00GYd163YzTBwpWrmUG1//+8OACAAI/jkv//rheAgACKQXI= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogtPC4tDogIENvbW1lbnRzIG9mIGRyYWZ0LWll?= =?gb2312?b?dGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmctMDQ=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 10:11:13 -0000 TGl6aG9uZywNCg0KQXMgSSByZXBsaWVkIHRvIFNyaSBpbiB0aGUgcHJldmlvdXMgZW1haWwsIHRo ZSBvdmVybGFwIGlzIG9ubHkgb24gdGhlICJyZXZlcnNlL3JldHVybiBwYXRoIHZhbGlkYXRpb24i LCBhbmQgdGhleSBvbmx5IG92ZXJsYXAgd2hlbiB0aGUgcmV0dXJuIHBhdGggaXMgdGhlIHJldmVy c2UgcGF0aCBvZiBhIGJpZGlyZWN0aW9uYWwgTFNQLiBPdGhlciBzY2VuYXJpb3MsIGUuZy4sIHVu aWRpcmVjdGlvbmFsIExTUCwgcmV0dXJuIHBhdGggaXMgbm90IHRoZSByZXZlcnNlIHBhdGggb2Yg dGhlIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGUgdHAtb24tZGVtYW5kIGRyYWZ0IGNhbiBub3QgYmUg YXBwbGllZCBhbnkgbW9yZSwgYmVjYXVzZSBpdCBleHBsaWNpdGx5IHJlcXVpcmVzIHRoZSBlY2hv IHJlcGx5IG11c3Qgc2VuZCBhbG9uZyB0aGUgcmV2ZXJzZSBwYXRoIG9mIHRoZSBiaWRpcmVjdGlv bmFsIExTUC4gU28sIEkgc2F5IHRoZXkgYXJlIHNvbWV0aW1lcyBjb21wbGVtZW50YXJ5LiANCg0K QmVzdCByZWdhcmQsDQpNYWNoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IExpemhvbmcgSmluIFtsaXpoby5qaW5AZ21haWwuY29tXQ0Kt6LLzcqxvOQ6 IDIwMTHE6jEx1MIxNMjVIDE3OjI0DQq1vTogTWFjaCBDaGVuDQpDYzogbXBsc0BpZXRmLm9yZw0K 1vfM4jogUmU6ILTwuLQ6IFttcGxzXSBDb21tZW50cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJu LXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0DQoNCkhpIE1hY2gsDQpBY2N1cmF0ZWx5IHNheWlu ZyBpczogIHRoZSB0d28gZHJhZnRzIGRlZmluZSB0aGUgc2FtZSBmZWF0dXJlIG9mICJyZXBvbnNl IHNob3VsZCByZXR1cm4gdmlhIHJldmVyc2UgcGF0aCIgd2l0aCBkaWZmZXJlbnQgd2F5LiBJIHRo aW5rIHRoZSBXRyBzaG91bGQgZGVmaW5lIG9ubHkgb25lIHdheS4NCkR1cmluZyB0aGUgbWVldGlu ZywgeW91IHNhaWQsIGRyYWZ0LXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBhbHNvIGFw cGxpZXMgdG8gTVBMUy1UUC4gVGhlIGRyYWZ0IHNob3VsZCBleHBsaWNpdGx5IHNheSB3aGV0aGVy IGl0IGlzIGZvciBNUExTIG9yIGJvdGggTVBMUyBhbmQgTVBMUy1UUC4NCg0KVGhhbmtzDQpMaXpo b25nDQoNCtTaIDIwMTHE6jEx1MIxNMjVIM/CzucyOjM4o6xNYWNoIENoZW4gPG1hY2guY2hlbkBo dWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+0LS1wKO6DQpIaSBMaXpob25n LA0KDQpOb3QgYWNjdXJhdGVseSwgdGhlIHR3byBkcmFmdHMgZGVmaW5lIHRoZWlyIG93biBmdWNu aW9ucyB0byBzb2x2ZSB0aGVpciBvd24gaXNzdWVzLiBSZXR1cm4gcGF0aCB2YWxpZGF0aW9uIGlz IGp1c3Qgb25lIG9mIHRoZSBmdWN0aW9ucy4gSW4gYWRkdGlvbiwgYXMgSSBzYWlkIGluIHRoZSBw cmV2aW91cyBlbWFpbCwgcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nIGRyYWZ0IG1haW5s eSBhcHBseSB0byBJUC9NUExTIG5ldHdvcmsuIEFuZCB0aGUgbXBscy10cC1vbi1kZW1hbmQtY3Yg ZHJhZnQgaXMgZGVzaWduZWQgZm9yIE1QTFMtVFAgbmV0d29yay4NCg0KQmVzdCByZWdhcmRzLA0K TWFjaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBM aXpob25nIEppbiBbbGl6aG8uamluQGdtYWlsLmNvbTxtYWlsdG86bGl6aG8uamluQGdtYWlsLmNv bT5dDQq3osvNyrG85DogMjAxMcTqMTHUwjE0yNUgMTM6NDINCrW9OiBNYWNoIENoZW4NCkNjOiBt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K1vfM4jogUmU6IFttcGxzXSBDb21t ZW50cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0 DQoNClRoYW5rcyBNYWNoLiBUaGVuIGNvdWxkIEkgdW5kZXJzdGFuZCB0aGUgdHdvIGRyYWZ0cyBk ZWZpbmUgdGhlIHNhbWUgZmVhdHVyZSB3aXRoIGRpZmZlcmVudCB3YXk/IFRoaXMgcmVhbGx5IGNv bmZ1c2VzIG1lLg0KDQpSZWdhcmRzDQpMaXpob25nDQoNCtTaIDIwMTHE6jEx1MIxNMjVIMnPzuc5 OjU3o6xNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVh d2VpLmNvbT48bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVh d2VpLmNvbT4+PtC0tcCjug0KSGkgTGl6aG9uZywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz Lg0KDQpJIHNlZSB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0IGRyYWZ0LW1wbHMtcmV0dXJuLXBhdGgt c3BlY2lmaWVkLWxzcC1waW5nIG1haW5seSBhcHBsaWVzIHRvIElQL01QTFMgc2NlbmFyaW8sIGFu ZCBpdCBtYXkgYmUgYXBwbHkgdG8gTVBMUy1UUCBzY2VuYXJpbzsgYW5kIGRyYWZ0LWlldGYtbXBs cy10cC1vbi1kZW1hbmQtY3YtMDcgYXBwbGllcyB0byBNUExTLVRQIHNjZW5hcmlvcy4NCg0KVGhl IHJldHVybiBwYXRoIHZhbGlkYXRpb24gd2FzIGZpcnN0bHkgcHJvcG9zZWQgaW4gZHJhZnQtbXBs cy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcgZHJhZnQsIGFuZCBpdCdzIG9ubHkgb25l IG9mIHRoZSBmdWN0aW9ucyBvZiByZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcuDQoNCkJl c3QgcmVnYXJkcywNCk1hY2gNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmc+PG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4+IFttcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZz48bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnPj5dILT6se0gTGl6aG9uZyBKaW4gW2xpemhvLmppbkBnbWFpbC5jb208bWFpbHRvOmxp emhvLmppbkBnbWFpbC5jb20+PG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPG1haWx0bzpsaXpo by5qaW5AZ21haWwuY29tPj5dDQq3osvNyrG85DogMjAxMcTqMTHUwjE0yNUgOTozNg0Ktb06IE1h Y2ggQ2hlbg0KQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PG1haWx0bzpt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4NCtb3zOI6IFttcGxzXSBDb21tZW50 cyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLTA0DQoN CkhpIE1hY2gsDQpCZWNhdXNlIG9mIHRpbWUgbGltaXRlZCBhdCB0aGUgc2Vzc2lvbiwgSSBuZWVk IHNvbWUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgbGlzdC4NCkJvdGggZHJhZnQtaWV0Zi1tcGxzLXJl dHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZyBzZWN0aW9uIDMuMiBhbmQgZHJhZnQtaWV0Zi1t cGxzLXRwLW9uLWRlbWFuZC1jdi0wNyBzZWN0aW9uIDMuNC4xIHByb3ZpZGUgdGhlIGZlYXR1cmUg b2YgInRoZSBSZXNwb25kZXIgU0hPVUxEIHJldHVybiByZXZlcnNlIHBhdGggRkVDIGluZm9ybWF0 aW9uIi4NCldoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzPyBJdCBz ZWVtcyB0aGV5IHByb3ZpZGUgdGhlIHNhbWUgZmVhdHVyZSB3aXRoIGRpZmZlcmVudCB3YXkuDQoN ClRoYW5rIHlvdS4NCkxpemhvbmcNCg0KDQo= From internet-drafts@ietf.org Mon Nov 14 05:32:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C5A21F8CE0; Mon, 14 Nov 2011 05:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnlWZRXufVLa; Mon, 14 Nov 2011 05:32:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B166921F8CD4; Mon, 14 Nov 2011 05:32:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111114133244.17080.39099.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2011 05:32:44 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-gtsm-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 13:32:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : The Generalized TTL Security Mechanism (GTSM) for Label = Distribution Protocol (LDP) Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-gtsm-04.txt Pages : 8 Date : 2011-11-14 The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-04.txt From pabloisnot@gmail.com Mon Nov 14 08:26:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46211E82EC for ; Mon, 14 Nov 2011 08:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpftFViKn-JM for ; Mon, 14 Nov 2011 08:26:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B64711E82DC for ; Mon, 14 Nov 2011 08:26:37 -0800 (PST) Received: by ggnr5 with SMTP id r5so1191823ggn.31 for ; Mon, 14 Nov 2011 08:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4gnyUXkoKSqOOYK31IdI17OoQo2L66lrNEurVu5hYko=; b=LspkNv9NEosV5u0385Chs5dma5SB+v4lvgraLe8OD6N/p7BY3+X+i+MaSHJTMjBcSp hs42kCTpfRMUuaoMQeipbb+PWyAxFgBeI9UAIOr/auXGOGFArA1oKhHcfmSEXWSSCbaJ M5s0RHp+2GKRr1h6CCyxxW1ewlb7CbC12jZzE= MIME-Version: 1.0 Received: by 10.182.44.9 with SMTP id a9mr5159468obm.61.1321287996540; Mon, 14 Nov 2011 08:26:36 -0800 (PST) Received: by 10.182.47.7 with HTTP; Mon, 14 Nov 2011 08:26:36 -0800 (PST) In-Reply-To: <71EFEC4A44C846A5A5EEC10D9E16A3DD@etri.info> References: <71EFEC4A44C846A5A5EEC10D9E16A3DD@etri.info> Date: Mon, 14 Nov 2011 11:26:36 -0500 Message-ID: From: Pablo Frank To: Taesik Cheung Content-Type: multipart/alternative; boundary=f46d044785a7ae069204b1b455c8 Cc: mpls@ietf.org Subject: Re: [mpls] Request WG input on a Mesh Protection Question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 16:26:38 -0000 --f46d044785a7ae069204b1b455c8 Content-Type: text/plain; charset=ISO-8859-1 Hi Taesik, I suppose it depends on what you mean by your question. Your current version of the draft already relies on the PSC as a kind of slave protocol to a new mesh-protection protocol that coordinates their activities. In a sense, your proposal is already built on the existing linear protection solution. Are you asking the WG to endorse this idea or do you have something else in mind? One possibility is that you mean to enhance the existing PSC protocol to include features that you need for mesh protection (perhaps a lockout mechanism or shared-mesh-protection-group IDs, etc). I think this is a worthy effort but I can see how it would be difficult. What did the authors have in mind when asking this question? regards, Pablo On Wed, Nov 2, 2011 at 5:42 AM, Taesik Cheung wrote: > Dear MPLS WG, > > **** ** > > As you may have recently noticed, we recently posted an updated version > draft-cheung-mpls-tp-mesh-protection-04. > > The authors of the solution would like to hear the WG opinion for a > specific question. > > Should the Mesh Protection solution be built on the existing Linear > Protection solution? > > ** ** > Thank you. > > Regards, > Taesik > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --f46d044785a7ae069204b1b455c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Taesik,

I suppose it depends on what you mean by your= question. =A0Your current version of the draft already relies on the PSC a= s a kind of slave protocol to a new mesh-protection protocol that coordinat= es their activities. =A0In a sense, your proposal is already built on the e= xisting linear protection solution.

Are you asking the WG to endorse this idea or do you ha= ve something else in mind? =A0One possibility is that you mean to enhance t= he existing PSC protocol to include features that you need for mesh protect= ion (perhaps a lockout mechanism or shared-mesh-protection-group IDs, etc).= =A0I think this is a worthy effort but I can see how it would be difficult= .

What did the authors have in mind when asking this ques= tion?

regards,
Pablo

On Wed, Nov 2, 2011 at 5:42 AM, Taesik Cheung <cts@etri.re.kr> w= rote:

Dear MPLS WG,

=A0

As you may have recent= ly noticed, we recently posted an updated version draft-cheung-mpls-tp-mesh= -protection-04.

The authors of the sol= ution would like to hear the WG opinion for a specific question.

Should the Mesh Protec= tion solution be built on the existing Linear Protection solution?

=A0

Tha= nk you.
=A0
Regards,
Taesik

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


--f46d044785a7ae069204b1b455c8-- From lberger@labn.net Mon Nov 14 17:16:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3715311E819E for ; Mon, 14 Nov 2011 17:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9+N7mc5opZy for ; Mon, 14 Nov 2011 17:16:09 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 8A3FE11E819A for ; Mon, 14 Nov 2011 17:16:09 -0800 (PST) Received: (qmail 17186 invoked by uid 0); 15 Nov 2011 01:16:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 15 Nov 2011 01:16:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zk81OajNUO4UHjgswRFDll8Yjuok06FcHHsp+kWM6IY=; b=t7r2m3azN17+APE3elDZBZZlurrVIGo366X9LPDL07Bnp4NoNSJq+g9AOl0ET75iNDyxMM4H4Y3hVnq+uvedIGhEd2Ndxt/4mlGqW0w1LSWKxMqtXFj68zIQYJiNXFZP; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RQ7dA-0007TE-OC; Mon, 14 Nov 2011 18:16:09 -0700 Message-ID: <4EC1BD58.2020007@labn.net> Date: Tue, 15 Nov 2011 09:16:08 +0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: huubatwork@gmail.com References: <4EC07E73.8050901@labn.net> <4EC08815.8010107@gmail.com> In-Reply-To: <4EC08815.8010107@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:16:10 -0000 Huub, I guess I didn't make my self sufficiently clear. Let me try again. If I understood the comments made in the meeting correctly, the statement made is that the usage of CC:ICC (ICC_GLOBAL_ID) is defined by the ITU-T and that the liaison referenced by Scott identifies the reference for this definition. Is this correct? Assuming this is correct, the referenced ITU-T document only covers usage of CC:ICC within the scope of a MEG_ID. So this raises the question of where is the ITU-T definition for usage of CC:ICC for MPLS LSPs & tunnels. I surmised that such a definition does not exist, and therefor postulated that draft-ietf-mpls-tp-itu-t-identifiers will provide an LSP/Tunnel definition based on the ITU-T MEG_ID. So, is this conclusion correct? Much thanks, Lou On 11/14/2011 11:16 AM, Huub van Helvoort wrote: > Hello Lou, > > You wrote: > >> As the scope of this document (ITU-T G.8013/Y.1731) is just MEG IDs, I >> guess this means that draft-ietf-mpls-tp-itu-t-identifiers will need to >> explicitly define how to go from ICC-based MEG IDs to ICC_based >> LSPs&Tunnels, right? > > The draft-ietf-mpls-tp-itu-t-identifiers described how the > Global_ID can be based on CC and ICC. > RFC6370 defines how LSPs&Tunnels use the Global_ID to provide > a global unique number. > > Regards, huub. > > > >> On 11/14/2011 9:52 AM, Scott Mansfield wrote: >>> Greg and Huub, >>> >>> Looking at the text of liaison, the actual text of the corrigendum 1 >>> is not attached to the liaison. Currently the document is only >>> available to ITU-T TIES members since the document is still >>> "pre-published". >>> >>> Can you please provide the document? >>> >>> Regards, >>> -scott. >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>> Behalf Of Scott Mansfield >>>> Sent: Sunday, November 13, 2011 8:36 PM >>>> To: mpls@ietf.org >>>> Subject: [mpls] FW: New Liaison Statement, "LS331 - >>>> Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >>>> >>>> This is the liaison from the ITU-T that includes information >>>> about the Global MEG ID. Uses the Country Code and the ICC >>>> to make the MEG ID globally unique. >>>> >>>> Regards, >>>> -scott. >>>> >>>>> -----Original Message----- >>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>>> Sent: Thursday, October 06, 2011 4:52 PM >>>>> To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu >>>>> Cc: yoichi.maeda@ttc.or.jp; >>>>> Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org; lear@cisco.com; >>>>> Scott Mansfield; huub.van.helvoort@huawei.com; tsbsg15@itu.int; >>>>> greg.jones@itu.int; hiroshi.ota@itu.int >>>>> Subject: New Liaison Statement, "LS331 - Corrigendum 1 to >>>>> Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >>>>> >>>>> Title: LS331 - Corrigendum 1 to Recommendation ITU-T >>>>> G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL of the >>>>> IETF Web page: /liaison/1100/ >>>>> >>>>> From: ITU-T SG 15 (Greg Jones) >>>>> To: Multiprotocol Label Switching (rcallon@juniper.net, >>>>> swallow@cisco.com, loa@pi.nu) >>>>> Cc: >>>>> yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl >>>>> s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com >>>>> Reponse Contact: >>>>> tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int >>>>> Technical Contact: huub.van.helvoort@huawei.com >>>>> Purpose: For information >>>>> >>>>> Body: The experts of Q10/15 would like to inform you that they have >>>>> agreed to a corrigendum for Recommendation ITU-T >>>>> G.8013/Y.1731 "OAM functions and mechanisms for Ethernet based >>>>> networks." >>>>> This corrigendum provides the definition of a globally >>>> unique MEG-ID >>>>> by using the Country Code (CC) and ITU-T Carrier Code (ICC). >>>>> Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T >>>>> G.8013/Y.1731". >>>>> Attachment(s): >>>>> >>>>> LS331 - Corrigendum 1 to Recommendation ITU-T >>>>> G.8013/Y.1731: Global MEG_ID - pdf body >>>>> https://datatracker.ietf.org/documents/LIAISON/file1279.pdf >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > From gregimirsky@gmail.com Mon Nov 14 18:19:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8981F0D3F for ; Mon, 14 Nov 2011 18:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyDlEfK2AvQw for ; Mon, 14 Nov 2011 18:19:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C17DF1F0CE0 for ; Mon, 14 Nov 2011 18:19:31 -0800 (PST) Received: by vws5 with SMTP id 5so6869266vws.31 for ; Mon, 14 Nov 2011 18:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yS4oTB8i2CNfSBr38jC4PFx61ysWOXP0hgiE5efgrXs=; b=VuIxUdTBzxcsvMcT73IexwrWFRQkBTrnMMPomuIYc0LHMeRbICBX+aLlTeVjlJpzhc dR0M120gZ/dA0WRJu21d1CgaJvJR2kyiRFh8x4VzTyfE/N4S8tlKFQ/jtiEhDvv+d6vT N/gWflUuL6BrL0bl+aBGvFv3o2Q/TgxLJHU+I= MIME-Version: 1.0 Received: by 10.52.35.70 with SMTP id f6mr39087357vdj.84.1321323571102; Mon, 14 Nov 2011 18:19:31 -0800 (PST) Received: by 10.220.94.198 with HTTP; Mon, 14 Nov 2011 18:19:31 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Nov 2011 18:19:31 -0800 Message-ID: From: Greg Mirsky To: Eric Gray , Adrian Farrel Content-Type: multipart/alternative; boundary=20cf307d000a16c5c604b1bc9ea9 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:19:33 -0000 --20cf307d000a16c5c604b1bc9ea9 Content-Type: text/plain; charset=ISO-8859-1 Dear Adrian, text you've proposed addresses my concern. Regards, Greg On Sun, Nov 13, 2011 at 9:50 PM, Eric Gray wrote: > Forwarding in plain text... > > ________________________________ > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, November 12, 2011 6:03 AM > To: Eric Gray > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 > > > > Eric, > > Can I propose a solution based on the idea that RFC 6370 contains adequate > description of what is included in RFC 6370? > > Don't spend time in your I-D describing what is in RFC 6370. Thus: > > OLD > > RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management > entity identifiers to support bidirectional (co-routed and > associated) point-to-point MPLS-TP LSPs, including PWs and Sections > which follow the IP/MPLS conventions. > > NEW > > RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management > entity identifiers that follow the IP/MPLS conventions. > > END > > Can I also use this email to question the text in the very next paragraph? > You have > > This document specifies an alternative way to uniquely identify an > operator/service provider based on ITU-T conventions and specifies > how this operator/service provider identifier can be used to make the > existing set of MPLS-TP transport and management entity identifiers, > defined by RFC 6370 [RFC6370], globally unique. > > My concern is mainly with "and specifies...make the existing...globally > unique". > There is an implication in this that the identifiers in RFC 6370 are > somehow > incapable of being globally unique, whereas the Global_ID of RFC 6370 is > globally > unique. > > I would also note that your I-D continues to make use of some identifiers > from > RFC 6370, but this text implies the I-D is an entirely alternative > approach. > > Can I suggest: > > OLD > > This document specifies an alternative way to uniquely identify an > operator/service provider based on ITU-T conventions and specifies > how this operator/service provider identifier can be used to make the > existing set of MPLS-TP transport and management entity identifiers, > defined by RFC 6370 [RFC6370], globally unique. > > NEW > > This document specifies an alternative way to construct MPLS-TP > identifiers replacing some elements of the identifiers defined in > RFC 6370 [RFC6370] with objects following current ITU-T identifier > conventions. > > END > > Cheers, > > Adrian > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: 11 November 2011 11:32 > To: Gregory Mirsky > Cc: huub.van.helvoort@huawei.com; mpls@ietf.org > Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 > > Greg, > > This draft is only interested in addressing identifiers associated > with bi-directional LSP - at least at present. RFC 6370 does define > identifiers that can be used for this case, that are based on IP/MPLS > conventions. So the statement is accurate. > > However, we could try to make it clearer that we're not saying that > RFC 6370 is limited to the bi-directional case. The difficulty lies in > trying > to make this clearer without complicating the text with information that is > not relevant to this draft. > > For example, if we explicily state that RFC 6370 includes support > for > IP/MPLS based identifiers for unidirectional LSPs, we would also need to > explicitly state that this type of identifier either doesn't apply to this > document, or is out of scope. In general, I don't think it is necessarily > a > good idea to add text to a document that then makes it necessary to add > additional text to clarify that the previously added text is out of scope > in > the document. > > Perhaps you can suggest wording that makes the fact that RFC 6370 > does > not limit identifiers to the bi-directional case clearer, without making it > necessary to then add that this document is limited in this respect? > > -- > Eric > _____________________________________________ > > From: Gregory Mirsky > Sent: Thursday, November 10, 2011 2:03 PM > To: rolf.winter@neclab.eu; Eric Gray; huub.van.helvoort@huawei.com; > malcolm.betts@zte.com.cn; mpls@ietf.org > Subject: Comments to draft-ietf-mpls-tp-itu-t-identifiers-02 > Importance: High > > Dear Authors, et al., > > I have a question about the scope of the document. Introduction references > only > bi-directional LSPs in "RFC 6370 [RFC6370] defines a set of MPLS-TP > transport > and management entity identifiers to support bidirectional (co-routed and > associated) point-to-point MPLS-TP LSPs ..." I think that RFC 6370 > implicitly > defines ID for p2p unidirectional LSP as well in the following format: > > A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID > > or if globally unique LSP ID required > > > A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::LSP_Num > > Regards, > > Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307d000a16c5c604b1bc9ea9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Adrian,
text you've proposed addresses my concern.

Regar= ds,
Greg

On Sun, Nov 13, 2011 at 9:50 = PM, Eric Gray <eric.gray@ericsson.com> wrote:
Forwarding in plain text...

________________________________

From: Adrian Farrel [mailto:adrian@o= lddog.co.uk]
Sent: Saturday, November 12, 2011 6:03 AM
To: Eric Gray
Cc: mpls@ietf.org
Subject: RE: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02



Eric,

Can I propose a solution based on the idea that RFC 6370 contains adequate<= br> description of what is included in RFC 6370?

Don't spend time in your I-D describing what is in RFC 6370. Thus:

OLD

=A0 RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management =A0 entity identifiers to support bidirectional (co-routed and
=A0 associated) point-to-point MPLS-TP LSPs, including PWs and Secti= ons
=A0 which follow the IP/MPLS conventions.

NEW

=A0 RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management
=A0 entity identifiers that follow the IP/MPLS conventions.

END

Can I also use this email to question the text in the very next paragraph? = You have

=A0 This document specifies an alternative way to uniquely identify an
=A0 operator/service provider based on ITU-T conventions and specifies
=A0 how this operator/service provider identifier can be used to make the<= br> =A0 existing set of MPLS-TP transport and management entity identifiers, =A0 defined by RFC 6370 [RFC6370], globally unique.

My concern is mainly with "and specifies...make the existing...globall= y unique".
There is an implication in this that the identifiers in RFC 6370 are someho= w
incapable of being globally unique, whereas the Global_ID of RFC 6370 is gl= obally
unique.

I would also note that your I-D continues to make use of some identifiers f= rom
RFC 6370, but this text implies the I-D is an entirely alternative approach= .

Can I suggest:

OLD

=A0 This document specifies an alternative way to uniquely identify an
=A0 operator/service provider based on ITU-T conventions and specifies
=A0 how this operator/service provider identifier can be used to make the<= br> =A0 existing set of MPLS-TP transport and management entity identifiers, =A0 defined by RFC 6370 [RFC6370], globally unique.

NEW

=A0 This document specifies an alternative way to construct MPLS-TP
=A0 identifiers replacing some elements of the identifiers defined in
=A0 RFC 6370 [RFC6370] with objects following current ITU-T identifier
=A0 conventions.

END

Cheers,

Adrian

From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Eric Gray
Sent: 11 November 2011 11:32
To: Gregory Mirsky
Cc: huub.van.helvoort@huawe= i.com; mpls@ietf.org
Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-itu-t-identifiers-02

Greg,

=A0 =A0 =A0 =A0This draft is only interested in addressing identifiers ass= ociated
with bi-directional LSP - at least at present. =A0RFC 6370 does defin= e
identifiers that can be used for this case, that are base= d on IP/MPLS
conventions. =A0So the statement is accurate.

=A0 =A0 =A0 =A0However, we could try to make it clearer that we're not= saying that
RFC 6370 is limited to the bi-directional case. =A0The difficulty lies in t= rying
to make this clearer without complicating the text with information that is=
not relevant to this draft.

=A0 =A0 =A0 =A0For example, if we explicily state that RFC 6370 includes s= upport for
IP/MPLS based identifiers for unidirectional LSPs, we would also need to explicitly state that this type of identifier either doesn't apply to t= his
document, or is out of scope. =A0In general, I don't think it is = necessarily a
good idea to add text to a document that then makes it ne= cessary to add
additional text to clarify that the previously added text is out of scope i= n
the document.

=A0 =A0 =A0 =A0Perhaps you can suggest wording that makes the fact that RF= C 6370 does
not limit identifiers to the bi-directional case clearer, without making it=
necessary to then add that this document is limited in this respect?

--
Eric
_____________________________________________

From: =A0 =A0Gregory Mirsky
Sent: =A0 Thursday, November 10, 2011 2:03 PM
To: =A0 =A0 rolf.winter@neclab.eu<= /a>; Eric Gray; huub.van.he= lvoort@huawei.com;
=A0 =A0 =A0 =A0 =A0malcolm.bet= ts@zte.com.cn; mpls@ietf.org
Subject: =A0 =A0 =A0 =A0Comments to draft-ietf-mpls-tp-it= u-t-identifiers-02
Importance: =A0 =A0 High

Dear Authors, et al.,

I have a question about the scope of the document. Introduction references = only
bi-directional LSPs in "RFC 6370 [RFC6370] defines a set of MPLS-TP tr= ansport
and management entity identifiers to support bidirectional (co-routed and
associated) point-to-point MPLS-TP LSPs ..." I think that RFC 63= 70 implicitly
defines ID for p2p unidirectional L= SP as well in the following format:

A1-Node_ID::A1-Tunnel_Num::Z9-LSP_Num::Z9-Node_ID

or if globally unique LSP ID required

A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::Tunnel_Num}::L= SP_Num

=A0 =A0 =A0 =A0Regards,

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

--20cf307d000a16c5c604b1bc9ea9-- From nabil.n.bitar@verizon.com Mon Nov 14 02:00:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6419011E80A1 for ; Mon, 14 Nov 2011 01:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LITqOYVCgXvj for ; Mon, 14 Nov 2011 01:59:14 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6BA1F0C8D for ; Mon, 14 Nov 2011 01:51:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 14 Nov 2011 09:50:23 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.69,508,1315180800"; d="scan'208";a="179297314" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi02.verizon.com with ESMTP; 14 Nov 2011 09:50:22 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Mon, 14 Nov 2011 04:50:22 -0500 To: Sriganesh Kini , "draft-bitar-mpls-isis-explicit-null-label@tools.ietf.org" Date: Mon, 14 Nov 2011 04:50:19 -0500 Thread-Topic: Comment on draft-bitar-mpls-isis-explicit-null-label Thread-Index: AcyistNxd0VrqpXhSZyh1axDCY7siA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 14 Nov 2011 18:38:02 -0800 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 10:01:05 -0000 Sri, I think the draft you referred to is in the context of carrying different protocols over PWs. In addition you talk about IP/GRE encap for multi-protcols. One can think about variations. What we are proposing is a simple way of carrying ISIS (more generically CLNS packets, as was pointed out by some) and enable the multiplexing of these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW). Overhead is smaller that for the GRE encap+PW with less config, and it is closer to existing implementations. One label that signifies ISIS as the carried protocol is automatically added upon sending the ISIS packet on the tunnel and used on Receive to recognize the type of the carried packet being an ISIS packet. Current methods of forwarding IPv4/IPv6 and MPLS packets over an MPLS tunnel, from enacp viewpoint, remain as they are. These packets can be multiplexed with ISIS packets on the same tunnel using this proposal. Thanks, Nabil On 11/13/11 10:37 PM, "Sriganesh Kini" wrote: >Guys, > >I would encourage you to look at draft- kini-pwe3-encap-efficient-ip- >that uses GRE to send Isis. This does not require an extra label. > > > >- Sri > >Sent from my iPad From Rolf.Winter@neclab.eu Mon Nov 14 18:54:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8521F0D3D for ; Mon, 14 Nov 2011 18:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2vEWfsZTBno for ; Mon, 14 Nov 2011 18:54:50 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E4A191F0C90 for ; Mon, 14 Nov 2011 18:54:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4707B28000085; Tue, 15 Nov 2011 03:54:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y6oceJz+5fD; Tue, 15 Nov 2011 03:54:49 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 26C2128000080; Tue, 15 Nov 2011 03:54:34 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 03:54:34 +0100 From: Rolf Winter To: Lou Berger , "huubatwork@gmail.com" Thread-Topic: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" Thread-Index: AQHMonBC3957CH2sBUK8B0HxQ/4KFZWrloOAgAALfICAAXCrAIAAKYzg Date: Tue, 15 Nov 2011 02:54:33 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D24F7F4EC@Polydeuces.office.hd> References: <4EC07E73.8050901@labn.net> <4EC08815.8010107@gmail.com> <4EC1BD58.2020007@labn.net> In-Reply-To: <4EC1BD58.2020007@labn.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:54:51 -0000 Hi, the ITU-T ID draft does that this already, although well hidden. That is wh= at I referred to as "formula" during my presentation. At the end of section= 3 is says: "The same substitution procedure applies to all identifiers specified in RFC 6370 [RFC6370] except for the other alternatives mentioned in this document." But as announced, we'll spell this out in the next version of the document.= =20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Dienstag, 15. November 2011 02:16 > To: huubatwork@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] FW: FW: New Liaison Statement, "LS331 - Corrigendum > 1 to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" >=20 > Huub, > I guess I didn't make my self sufficiently clear. Let me try > again. If I understood the comments made in the meeting correctly, the > statement made is that the usage of CC:ICC (ICC_GLOBAL_ID) is defined > by the ITU-T and that the liaison referenced by Scott identifies the > reference for this definition. Is this correct? >=20 > Assuming this is correct, the referenced ITU-T document only covers > usage of CC:ICC within the scope of a MEG_ID. So this raises the > question of where is the ITU-T definition for usage of CC:ICC for MPLS > LSPs & tunnels. I surmised that such a definition does not exist, and > therefor postulated that draft-ietf-mpls-tp-itu-t-identifiers will > provide an LSP/Tunnel definition based on the ITU-T MEG_ID. >=20 > So, is this conclusion correct? >=20 > Much thanks, > Lou >=20 >=20 > On 11/14/2011 11:16 AM, Huub van Helvoort wrote: > > Hello Lou, > > > > You wrote: > > > >> As the scope of this document (ITU-T G.8013/Y.1731) is just MEG IDs, > >> I guess this means that draft-ietf-mpls-tp-itu-t-identifiers will > >> need to explicitly define how to go from ICC-based MEG IDs to > >> ICC_based LSPs&Tunnels, right? > > > > The draft-ietf-mpls-tp-itu-t-identifiers described how the Global_ID > > can be based on CC and ICC. > > RFC6370 defines how LSPs&Tunnels use the Global_ID to provide a > global > > unique number. > > > > Regards, huub. > > > > > > > >> On 11/14/2011 9:52 AM, Scott Mansfield wrote: > >>> Greg and Huub, > >>> > >>> Looking at the text of liaison, the actual text of the corrigendum > 1 > >>> is not attached to the liaison. Currently the document is only > >>> available to ITU-T TIES members since the document is still > >>> "pre-published". > >>> > >>> Can you please provide the document? > >>> > >>> Regards, > >>> -scott. > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>> Behalf Of Scott Mansfield > >>>> Sent: Sunday, November 13, 2011 8:36 PM > >>>> To: mpls@ietf.org > >>>> Subject: [mpls] FW: New Liaison Statement, "LS331 - Corrigendum 1 > >>>> to Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" > >>>> > >>>> This is the liaison from the ITU-T that includes information about > >>>> the Global MEG ID. Uses the Country Code and the ICC to make the > >>>> MEG ID globally unique. > >>>> > >>>> Regards, > >>>> -scott. > >>>> > >>>>> -----Original Message----- > >>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > >>>>> Sent: Thursday, October 06, 2011 4:52 PM > >>>>> To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > >>>>> Cc: yoichi.maeda@ttc.or.jp; > >>>>> Steve.Trowbridge@alcatel-lucent.com; mpls@ietf.org; > >>>>> lear@cisco.com; Scott Mansfield; huub.van.helvoort@huawei.com; > >>>>> tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > >>>>> Subject: New Liaison Statement, "LS331 - Corrigendum 1 to > >>>>> Recommendation ITU-T G.8013/Y.1731: Global MEG_ID" > >>>>> > >>>>> Title: LS331 - Corrigendum 1 to Recommendation ITU-T > >>>>> G.8013/Y.1731: Global MEG_ID Submission Date: 2011-10-06 URL of > >>>>> the IETF Web page: /liaison/1100/ > >>>>> > >>>>> From: ITU-T SG 15 (Greg Jones) > >>>>> To: Multiprotocol Label Switching (rcallon@juniper.net, > >>>>> swallow@cisco.com, loa@pi.nu) > >>>>> Cc: > >>>>> yoichi.maeda@ttc.or.jp,Steve.Trowbridge@alcatel-lucent.com,mpl > >>>>> s@ietf.org,lear@cisco.com,scott.mansfield@ericsson.com > >>>>> Reponse Contact: > >>>>> tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > >>>>> Technical Contact: huub.van.helvoort@huawei.com > >>>>> Purpose: For information > >>>>> > >>>>> Body: The experts of Q10/15 would like to inform you that they > >>>>> have agreed to a corrigendum for Recommendation ITU-T > >>>>> G.8013/Y.1731 "OAM functions and mechanisms for Ethernet based > >>>>> networks." > >>>>> This corrigendum provides the definition of a globally > >>>> unique MEG-ID > >>>>> by using the Country Code (CC) and ITU-T Carrier Code (ICC). > >>>>> Attach: TD477/PLEN, "Corrigendum 1 to Recommendation ITU-T > >>>>> G.8013/Y.1731". > >>>>> Attachment(s): > >>>>> > >>>>> LS331 - Corrigendum 1 to Recommendation ITU-T > >>>>> G.8013/Y.1731: Global MEG_ID - pdf body > >>>>> https://datatracker.ietf.org/documents/LIAISON/file1279.pdf > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> 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 cts@etri.re.kr Mon Nov 14 21:49:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08121F8E3F for ; Mon, 14 Nov 2011 21:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.89 X-Spam-Level: X-Spam-Status: No, score=-99.89 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQQLPAyv-viz for ; Mon, 14 Nov 2011 21:49:33 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 530F421F8E27 for ; Mon, 14 Nov 2011 21:49:33 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 15 Nov 2011 14:49:31 +0900 Priority: normal thread-index: AcyjWliMEJQLtTOvTfeqGQQKRo44dg== Thread-Topic: Re: [mpls] Request WG input on a Mesh Protection Question From: "Taesik Cheung" To: "Pablo Frank" Date: Tue, 15 Nov 2011 14:49:31 +0900 Comment: ??, ?, Message-ID: <70AAE2D726374937B640C9A75585506A@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8899_01CCA3A5.C87601D0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 15 Nov 2011 05:49:31.0704 (UTC) FILETIME=[58AD5380:01CCA35A] Cc: mpls@ietf.org Subject: Re: [mpls] Request WG input on a Mesh Protection Question X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Taesik Cheung List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:49:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_8899_01CCA3A5.C87601D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_8899_01CCA3A5.C87601D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgV09SRC1CUkVBSzog YnJlYWstYWxsIj4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBGT05U LVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIFBhYmxvLDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+VGhhbmsgeW91IGZvciB0aGUgY29tbWVudC48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPlllcywgb3VyIGludGVudGlvbiBpcyB0byByZS11c2UgZXhpc3RpbmcgbGluZWFyIHByb3Rl Y3Rpb24gYXMgaW4gb3VyIGRyYWZ0IGFuZCBub3QgdG8gY2hhbmdlIGl0LjwvRk9OVD48L0RJVj4N CjxESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+VGhlIHJlYXNvbiB3aHkgSSBhc2tlZCB0aGUg cXVlc3Rpb24gd2FzIHRvIGdldCBvcGluaW9ucyBvciBzdXBwb3J0cyBvZiBXRyBleHBlcnRzIG9u IHRoaXMgYXBwcm9hY2guPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9O VD4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5BIGtleSBpc3N1ZSBv ZiBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uIGlzIGhvdyB0byBjb29yZGluYXRlIHRoZSB1c2Ugb2Yg c2hhcmVkIHByb3RlY3Rpb24gcmVzb3VyY2VzIGFuZCBvdXIgc29sdXRpb24gb25seSBmb2N1c2Vz IG9uIGl0LiBXZSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGRldmVsb3AgYSBuZXcgbWVjaGFuaXNt IGZyb20gdGhlIGJvdHRvbSwgc3VjaCBhcyBwcmlvcml0eSB2YWx1ZXMgZm9yIGRpZmZlcmVudCBy ZXF1ZXN0cywgc3RhdGUgdHJhbnNpdGlvbiB0YWJsZXMsIGV0Yy48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPlRoZSZuYnNwO2Z1bmN0aW9ucyB5b3UgbWVudGlvbmVkIChMb2Nrb3V0IHJlcXVlc3QsIFNQ TUcgSUQsIC4uLikgYXJlIHJlcXVpcmVkIGZvciBvdXIgc29sdXRpb24sIGJ1dCZuYnNwO3dlIGJl bGlldmUgdGhhdCBpdCB3b24ndCBjaGFuZ2UmbmJzcDt0aGUgZXhpc3RpbmcmbmJzcDtsaW5lYXIg cHJvdGVjdGlvbiZuYnNwO3Byb3RvY29sIGl0c2VsZi4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPkFueSBmdXJ0aGVyIGNvbW1lbnRzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5UaGFuayB5b3UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5SZWdhcmRzLDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5UYWVzaWs8L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPjwvRElWPjwvRElWPjwvRElWPjxCUj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxCUj48Qj5Gcm9tOjwvQj4gIlBhYmxvIEZyYW5rIiAmbHQ7cGFibG9pc25vdEBnbWFpbC5j b20mZ3Q7PEJSPjxCPkZyb20gRGF0ZTo8L0I+IDIwMTEtMTEtMTUgQU0gMToyNjozNjxCUj48Qj5U bzo8L0I+ICJUYWVzaWsgQ2hldW5nIiAmbHQ7Y3RzQGV0cmkucmUua3ImZ3Q7PEJSPjxCPkNjOjwv Qj4gIm1wbHNAaWV0Zi5vcmciICZsdDttcGxzQGlldGYub3JnJmd0OzxCUj48Qj5TdWJqZWN0Ojwv Qj4gUmU6IFttcGxzXSBSZXF1ZXN0IFdHIGlucHV0IG9uIGEgTWVzaCBQcm90ZWN0aW9uIFF1ZXN0 aW9uPEJSPjxCUj5IaSBUYWVzaWssIA0KPERJVj48QlI+PC9ESVY+DQo8RElWPkkgc3VwcG9zZSBp dCBkZXBlbmRzIG9uIHdoYXQgeW91IG1lYW4gYnkgeW91ciBxdWVzdGlvbi4gP1lvdXIgY3VycmVu dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbHJlYWR5IHJlbGllcyBvbiB0aGUgUFNDIGFzIGEga2lu ZCBvZiBzbGF2ZSBwcm90b2NvbCB0byBhIG5ldyBtZXNoLXByb3RlY3Rpb24gcHJvdG9jb2wgdGhh dCBjb29yZGluYXRlcyB0aGVpciBhY3Rpdml0aWVzLiA/SW4gYSBzZW5zZSwgeW91ciBwcm9wb3Nh bCBpcyBhbHJlYWR5IGJ1aWx0IG9uIHRoZSBleGlzdGluZyBsaW5lYXIgcHJvdGVjdGlvbiBzb2x1 dGlvbi48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPERJVj5BcmUgeW91IGFza2luZyB0aGUgV0cg dG8gZW5kb3JzZSB0aGlzIGlkZWEgb3IgZG8geW91IGhhdmUgc29tZXRoaW5nIGVsc2UgaW4gbWlu ZD8gP09uZSBwb3NzaWJpbGl0eSBpcyB0aGF0IHlvdSBtZWFuIHRvIGVuaGFuY2UgdGhlIGV4aXN0 aW5nIFBTQyBwcm90b2NvbCB0byBpbmNsdWRlIGZlYXR1cmVzIHRoYXQgeW91IG5lZWQgZm9yIG1l c2ggcHJvdGVjdGlvbiAocGVyaGFwcyBhIGxvY2tvdXQgbWVjaGFuaXNtIG9yIHNoYXJlZC1tZXNo LXByb3RlY3Rpb24tZ3JvdXAgSURzLCBldGMpLiA/SSB0aGluayB0aGlzIGlzIGEgd29ydGh5IGVm Zm9ydCBidXQgSSBjYW4gc2VlIGhvdyBpdCB3b3VsZCBiZSBkaWZmaWN1bHQuPC9ESVY+DQo8RElW PjxCUj48L0RJVj4NCjxESVY+V2hhdCBkaWQgdGhlIGF1dGhvcnMgaGF2ZSBpbiBtaW5kIHdoZW4g YXNraW5nIHRoaXMgcXVlc3Rpb24/PC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVY+cmVnYXJk cyw8L0RJVj4NCjxESVY+UGFibG88QlI+PEJSPg0KPERJViBjbGFzcz1nbWFpbF9xdW90ZT5PbiBX ZWQsIE5vdiAyLCAyMDExIGF0IDU6NDIgQU0sIFRhZXNpayBDaGV1bmcgPFNQQU4gZGlyPWx0cj4m bHQ7PEEgaHJlZj0ibWFpbHRvOmN0c0BldHJpLnJlLmtyIiB0YXJnZXQ9X2JsYW5rPmN0c0BldHJp LnJlLmtyPC9BPiZndDs8L1NQQU4+IHdyb3RlOjxCUj4NCjxCTE9DS1FVT1RFIHN0eWxlPSJCT1JE RVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJ TkctTEVGVDogMWV4IiBjbGFzcz1nbWFpbF9xdW90ZT4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZ OiBBcmlhbDsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlM WTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCI+DQo8RElWPjxTUEFOIGxhbmc9RU4tVVM+DQo8UCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz5EZWFyIE1QTFMgV0cs PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO LVVTPjxVPjwvVT48VT48L1U+PzxVPjwvVT48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+QXMgeW91IG1heSBoYXZlIHJlY2VudGx5IG5v dGljZWQsIHdlIHJlY2VudGx5IHBvc3RlZCBhbiB1cGRhdGVkIHZlcnNpb24gZHJhZnQtY2hldW5n LW1wbHMtdHAtbWVzaC1wcm90ZWN0aW9uLTA0LiA8L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+VGhlIGF1dGhvcnMgb2YgdGhlIHNvbHV0 aW9uIHdvdWxkIGxpa2UgdG8gaGVhciB0aGUgV0cgb3BpbmlvbiBmb3IgYSBzcGVjaWZpYyBxdWVz dGlvbi4gPC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs YW5nPUVOLVVTPlNob3VsZCB0aGUgTWVzaCBQcm90ZWN0aW9uIHNvbHV0aW9uIGJlIGJ1aWx0IG9u IHRoZSBleGlzdGluZyBMaW5lYXIgUHJvdGVjdGlvbiBzb2x1dGlvbj88L1NQQU4+PC9QPg0KPFAg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PFU+PC9VPj88VT48 L1U+PC9TUEFOPjwvUD4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0IiBsYW5nPUVOLVVTPlRoYW5rIHlvdS48L1NQQU4+PC9GT05UPjwvRElWPjxGT05U IGZhY2U9QXJpYWw+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz48L1NQ QU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNl PUFyaWFsPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PC9TUEFOPg0K PERJVj4/PC9ESVY+DQo8RElWPlJlZ2FyZHMsPC9ESVY+DQo8RElWPlRhZXNpazxGT05UIGNvbG9y PSM4ODg4ODg+PEJSPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvRElWPjwvRElW PjwvRElWPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj5tcGxzIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIg dGFyZ2V0PV9ibGFuaz5tcGxzQGlldGYub3JnPC9BPjxCUj48QSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9BPjxCUj48QlI+PC9CTE9DS1FVT1RFPjwv RElWPjxCUj48L0RJVj48L0RJVj48L0RJVj4= ------=_NextPart_000_8899_01CCA3A5.C87601D0-- From sriganesh.kini@ericsson.com Tue Nov 15 00:22:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493DD11E8174 for ; Tue, 15 Nov 2011 00:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNCvLp291U6p for ; Tue, 15 Nov 2011 00:22:05 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1B311E808C for ; Tue, 15 Nov 2011 00:22:05 -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 pAF8M0QR025108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 02:22:02 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 15 Nov 2011 03:22:00 -0500 From: Sriganesh Kini To: "Bitar, Nabil N" Date: Tue, 15 Nov 2011 03:21:59 -0500 Thread-Topic: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label Thread-Index: Acyjb6UYhA30qjZ/SHi4CVQcsRs0Jg== Message-ID: <7CC5505F-BED4-4437-8C05-03337BC299D1@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-bitar-mpls-isis-explicit-null-label@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 08:22:06 -0000 Hi Nabil, See inline=20 - Sri Sent from my iPad On Nov 14, 2011, at 5:50 PM, "Bitar, Nabil N" w= rote: > Sri, > I think the draft you referred to is in the context of carrying different > protocols over PWs. In addition you talk about IP/GRE encap for > multi-protcols. One can think about variations. > What we are proposing is a simple way of carrying ISIS (more generically > CLNS packets, as was pointed out by some) and enable the multiplexing of > these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW). [sri] One of the issues I see with using a fixed Label to indicate protocol= type (clns) is that it goes against the mpls arch principles of keeping la= bel value independent of protocol type.=20 Another issue is that two network layer protocols (ip and clns) of the same= interface are sent with different label stack depths (clns label depth is = one more than ip). That strikes me as odd. The other instance where somethi= ng similar occurs is the alert label, but it doesn't seem like you are defi= ning another alert label. Also, packets on an interface such as LLDP, how would they be sent ? Also, why did the "network layer transport" encapsulation not meet your nee= ds ? > Overhead is smaller that for the GRE encap+PW with less config, and it is > closer to existing implementations. One label that signifies ISIS as the > carried protocol is automatically added upon sending the ISIS packet on > the tunnel and used on Receive to recognize the type of the carried packe= t > being an ISIS packet. Current methods of forwarding IPv4/IPv6 and MPLS > packets over an MPLS tunnel, from enacp viewpoint, remain as they are. > These packets can be multiplexed with ISIS packets on the same tunnel > using this proposal. >=20 > Thanks, > Nabil >=20 > On 11/13/11 10:37 PM, "Sriganesh Kini" wrot= e: >=20 >> Guys, >>=20 >> I would encourage you to look at draft- kini-pwe3-encap-efficient-ip- >> that uses GRE to send Isis. This does not require an extra label. >>=20 >>=20 >>=20 >> - Sri >>=20 >> Sent from my iPad >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Tue Nov 15 01:43:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47A21F8F3B for ; Tue, 15 Nov 2011 01:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.602 X-Spam-Level: X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrxAfJYz1yKT for ; Tue, 15 Nov 2011 01:43:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC9021F8F21 for ; Tue, 15 Nov 2011 01:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=8201; q=dns/txt; s=iport; t=1321350202; x=1322559802; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=sKZ19u1pX6Bv+iWMMcrjg9AfBs9i0QcD1+r/dyC2rp0=; b=IYAhFQXJzz2rWSoN9zT6WfV9SyaMntE3IyKeF5OUDCPVqmkN9K31gzaf YNhqGL2FeeC1RcEsr00yIxVrFvsYgVffWZ46Bkg9BmAnJn5MGIr7vUV7h N6M6KvwKq9QyoSlWXt0sw/8wp4YZ4fQmqmQ1ftZBe6ohU851OA0dtUCeX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAPczwk6tJV2c/2dsb2JhbABDgk2mJHmBBYFyAQEBAwEBAQEPASoqBwsFDQEIGFUwAQEEDgUih2AInCABnwEEigQEh2AxjB+FRIxU X-IronPort-AV: E=Sophos;i="4.69,514,1315180800"; d="scan'208,217";a="36068472" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2011 09:43:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAF9hLum001798; Tue, 15 Nov 2011 09:43:21 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 03:43:21 -0600 Received: from 10.70.230.27 ([10.70.230.27]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Nov 2011 09:43:20 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 15 Nov 2011 04:43:20 -0500 From: George Swallow To: Sriganesh Kini , "Bitar, Nabil N" Message-ID: Thread-Topic: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label Thread-Index: Acyjb6UYhA30qjZ/SHi4CVQcsRs0JgAC10bt In-Reply-To: <7CC5505F-BED4-4437-8C05-03337BC299D1@ericsson.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3404177000_7870771" X-OriginalArrivalTime: 15 Nov 2011 09:43:21.0470 (UTC) FILETIME=[0311B9E0:01CCA37B] Cc: draft-bitar-mpls-isis-explicit-null-label@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 09:43:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3404177000_7870771 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sri - See in-line: On 11/15/11 3:21 AM, "Sriganesh Kini" wrote: > Hi Nabil, >=20 > See inline >=20 > - Sri >=20 > Sent from my iPad >=20 > On Nov 14, 2011, at 5:50 PM, "Bitar, Nabil N" > wrote: >=20 >> > Sri, >> > I think the draft you referred to is in the context of carrying differ= ent >> > protocols over PWs. In addition you talk about IP/GRE encap for >> > multi-protcols. One can think about variations. >> > What we are proposing is a simple way of carrying ISIS (more generical= ly >> > CLNS packets, as was pointed out by some) and enable the multiplexing = of >> > these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW= ). >=20 > [sri] One of the issues I see with using a fixed Label to indicate protoc= ol > type (clns) is that it goes against the mpls arch principles of keeping l= abel > value independent of protocol type. >=20 We have both IPv4 and IPv6 Explicit Null labels. This would be a CLNS Explicit Null. I don=B9t view that as an architectural change. >=20 > Another issue is that two network layer protocols (ip and clns) of the sa= me > interface are sent with different label stack depths (clns label depth is= one > more than ip). That strikes me as odd. The other instance where something > similar occurs is the alert label, but it doesn't seem like you are defin= ing > another alert label. >=20 It is fairly common to send IPv6 on IPv4 TE tunnels by using an IPv6 explicit null. =20 >=20 > Also, packets on an interface such as LLDP, how would they be sent ? >=20 These are not ethernet links. How odes LLDP apply? ...George >=20 > Also, why did the "network layer transport" encapsulation not meet your n= eeds > ? >=20 >> > Overhead is smaller that for the GRE encap+PW with less config, and it= is >> > closer to existing implementations. One label that signifies ISIS as t= he >> > carried protocol is automatically added upon sending the ISIS packet o= n >> > the tunnel and used on Receive to recognize the type of the carried pa= cket >> > being an ISIS packet. Current methods of forwarding IPv4/IPv6 and MPLS >> > packets over an MPLS tunnel, from enacp viewpoint, remain as they are. >> > These packets can be multiplexed with ISIS packets on the same tunnel >> > using this proposal. >> > >> > Thanks, >> > Nabil >> > >> > On 11/13/11 10:37 PM, "Sriganesh Kini" w= rote: >> > >>> >> Guys, >>> >> >>> >> I would encourage you to look at draft- kini-pwe3-encap-efficient-ip= - >>> >> that uses GRE to send Isis. This does not require an extra label. >>> >> >>> >> >>> >> >>> >> - Sri >>> >> >>> >> Sent from my iPad >> > >> > _______________________________________________ >> > 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 >=20 --B_3404177000_7870771 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt= '>Sri -<BR> <BR> See in-line:<BR> <BR> <BR> On 11/15/11 3:21 AM, "Sriganesh Kini" <<a href=3D"sriganesh.kini= @ericsson.com">sriganesh.kini@ericsson.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:10pt'>Hi Nabil,<BR> <BR> See inline<BR> <BR> - Sri<BR> <BR> Sent from my iPad<BR> <BR> On Nov 14, 2011, at 5:50 PM, "Bitar, Nabil N" <<a href=3D"nabil.= n.bitar@verizon.com">nabil.n.bitar@verizon.com</a>> wrote:<BR> <BR> > Sri,<BR> > I think the draft you referred to is in the context of carrying differ= ent<BR> > protocols over PWs. In addition you talk about IP/GRE encap for<BR> > multi-protcols. One can think about variations.<BR> > What we are proposing is a simple way of carrying ISIS (more generical= ly<BR> > CLNS packets, as was pointed out by some) and enable the multiplexing = of<BR> > these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW= ).<BR> <BR> [sri] One of the issues I see with using a fixed Label to indicate protocol= type (clns) is that it goes against the mpls arch principles of keeping lab= el value independent of protocol type.<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:10pt'>We have both IPv4 and IPv6 Explicit Null labels= .  This would be a CLNS Explicit Null.  I don’t view that as= an architectural change.  <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:10pt'><BR> Another issue is that two network layer protocols (ip and clns) of the same= interface are sent with different label stack depths (clns label depth is o= ne more than ip). That strikes me as odd. The other instance where something= similar occurs is the alert label, but it doesn't seem like you are definin= g another alert label.<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:10pt'>It is fairly common to send IPv6 on IPv4 TE tun= nels by using an IPv6 explicit null.  <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:10pt'><BR> Also, packets on an interface such as LLDP, how would they be sent ?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:10pt'>These are not ethernet links.  How odes LL= DP apply?<BR> <BR> ...George<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:10pt'><BR> Also, why did the "network layer transport" encapsulation not mee= t your needs ?<BR> <BR> > Overhead is smaller that for the GRE encap+PW with less config, and it= is<BR> > closer to existing implementations. One label that signifies ISIS as t= he<BR> > carried protocol is automatically added upon sending the ISIS packet o= n<BR> > the tunnel and used on Receive to recognize the type of the carried pa= cket<BR> > being an ISIS packet. Current methods of forwarding IPv4/IPv6 and MPLS= <BR> > packets over an MPLS tunnel, from enacp viewpoint, remain as they are.= <BR> > These packets can be multiplexed with ISIS packets on the same tunnel<= BR> > using this proposal.<BR> ><BR> > Thanks,<BR> > Nabil<BR> ><BR> > On 11/13/11 10:37 PM, "Sriganesh Kini" <<a href=3D"sriganes= h.kini@ericsson.com">sriganesh.kini@ericsson.com</a>> wrote:<BR> ><BR> >> Guys,<BR> >><BR> >> I would encourage you to look at draft- kini-pwe3-encap-efficient-= ip-<BR> >> that uses GRE to send Isis. This does not require an extra label.<= BR> >><BR> >><BR> >><BR> >> - Sri<BR> >><BR> >> Sent from my iPad<BR> ><BR> > _______________________________________________<BR> > mpls mailing list<BR> > <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.= org/mailman/listinfo/mpls</a><BR> _______________________________________________<BR> mpls mailing list<BR> <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3404177000_7870771-- From zhang.fei3@zte.com.cn Tue Nov 15 04:30:25 2011 Return-Path: <zhang.fei3@zte.com.cn> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A761A11E80D2; Tue, 15 Nov 2011 04:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.999 X-Spam-Level: X-Spam-Status: No, score=-97.999 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJicLnUD-VmU; Tue, 15 Nov 2011 04:30:25 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E681B1F0C51; Tue, 15 Nov 2011 04:30:22 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901279682118; Tue, 15 Nov 2011 20:18:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 91000.1279682118; Tue, 15 Nov 2011 20:30:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAFCU0kd020424; Tue, 15 Nov 2011 20:30:00 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <20111114043335.8397.79549.idtracker@ietfa.amsl.com> To: "ccamp@ietf.org" <ccamp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org> MIME-Version: 1.0 X-KeepSent: 0BFF2B07:F4D9FF08-48257949:0042D5E6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: <OF0BFF2B07.F4D9FF08-ON48257949.0042D5E6-48257949.0044A9D1@zte.com.cn> From: zhang.fei3@zte.com.cn Date: Tue, 15 Nov 2011 20:30:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-15 20:30:03, Serialize complete at 2011-11-15 20:30:03 Content-Type: multipart/alternative; boundary="=_alternative 0044A9CE48257949_=" X-MAIL: mse02.zte.com.cn pAFCU0kd020424 Subject: Re: [mpls] New Version Notification for draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 12:30:25 -0000 This is a multipart message in MIME format. --=_alternative 0044A9CE48257949_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkFjY29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZ2xpc3Qs IHdlIGhhdmUgdXBkYXRlZCB0aGlzIGRyYWZ0IA0KYW5kIHByZXNlbnRlZCB0aGVzZSBjaGFuZ2Vz IG9uIHRoZSBDQ0FNUCBzZXNzaW9uDQoNCkJlbG93IGlzIHRoZSBkcmFmdCBsaW5rDQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bS0wMQ0KDQpXZSBkZWZpbmVkIGEgYml0IGluIHRoZSBMU1AgQXR0cmlidXRlIEZs YWdzIFRMViB0byBpbmRpY2F0ZSBjYXJyeWluZyB0aGUgDQpMU1AgaWRlbnRpZmVyLiAgVHdvIG5l dyBUTFZzIGFyZSBhbHNvIGRlZmluZWQgaW4gdGhlIExTUCBBVFRSSUJVVEVTIA0Kb2JqZWN0LCBv bmUgaXMgdGhlIENvbm5lY3Rpb24gVExWIHdoaWNoIGlzIHVzZWQgdG8gY2FycnkgdGhlIGxvY2Fs IHR1bm5lbCANCm51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlIChvbmx5IHVzZWQgZm9yIGNvcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQKTsgdGhlIA0Kb3RoZXIgaXMgdGhlIEdsb2JhbF9JRCBUTFYs IHVzZWQgdG8gY2FycnkgdGhlIGdsb2JhbCBJRCAoYXBwbHlpbmcgdG8gdGhlIA0KY29yb3V0ZWQg YW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzKS4NCg0KWW91IGNhbiBhbHNvIGZpbmQg dGhlIHByZXNlbnRhdGlvbiBtYXRlcmlhbCBpbiB0aGUgZm9sbG93aW5nIGxpbmsNCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL3dnL2NjYW1wL2FnZW5kYSwgdGhlIDExIG9uZS4NCg0KQW55IGNvbW1l bnRzIG9yIGNvbnRyaWJ1dGlvbnMgYXJlIHdlbGNvbWUNCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2Fy ZHMNCg0KRmVpDQoNCg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQoyMDExLTExLTE0IDEy OjMzDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQp6aGFuZy5mZWkzQHp0 ZS5jb20uY24NCtb3zOINCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16aGFu Zy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMS50eHQNCg0KDQoNCg0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCANCmRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC10dW5uZWwtbnVtLTAxLnR4dCBoYXMgYmVlbiANCnN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgRmVpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6ICAgICAgICAgICAgICAgICBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bQ0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJTVlAtVEUgRXh0ZW5zaW9ucyB0byBFeGNoYW5nZSBNUExTLVRQ IA0KTFNQIElkZW50aWZpZXJzDQpDcmVhdGlvbiBkYXRlOiAgICAgICAgICAgIDIwMTEtMTEtMTMN CldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogOA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBNUExTIFRyYW5zcG9ydCBQ cm9maWxlIChNUExTLVRQKSBpZGVudGlmaWVycyBkb2N1bWVudCBbUkZDNjM3MF0NCiAgIHNwZWNp ZmllcyBhIGluaXRpYWwgc2V0IG9mIGlkZW50aWZpZXJzLCBzdWNoIGFzIGxvY2FsIGFzc2lnbmVk IHR1bm5lbA0KICAgbnVtYmVyIGFuZCBHbG9iYWxfSUQsIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGZv cm0gTWFpbnRlbmFuY2UgRW50aXR5DQogICBQb2ludCBJZGVudGlmaWVyIChNRVBfSUQpLiAgQXMg dG8gc29tZSBPcGVyYXRpb24sIEFkbWluaXN0cmF0aW9uIGFuZA0KICAgTWFpbnRlbmFuY2UgKE9B TSkgZnVuY3Rpb25zLCBzdWNoIGFzIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24gKENWKQ0KICAg W0ktRC5pZXRmLW1wbHMtdHAtY2MtY3YtcmRpXSwgc291cmNlIE1FUF9JRCBtdXN0IGJlIGluc2Vy dGVkIGluIHRoZQ0KICAgT0FNIHBhY2tldHMsIHNvIHRoYXQgdGhlIHBlZXIgZW5kcG9pbnQgY2Fu IGNvbXBhcmUgdGhlIHJlY2VpdmVkIGFuZA0KICAgZXhwZWN0ZWQgTUVQX0lEcyB0byBqdWRnZSB3 aGV0aGVyIHRoZXJlIGlzIGEgbWlzbWF0Y2ggW1JGQzYzNzFdLA0KICAgd2hpY2ggbWVhbnMgdGhh dCB0aGUgdHdvIE1FUCBub2RlcyBuZWVkIHRvIHByZS1zdG9yZSBlYWNoIG90aGVyJiMzOTtzDQog ICBNRVBfSURzLg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHNpZ25hbGluZyBleHRl bnNpb25zIHRvIGV4Y2hhbmdlIHRoZSBMYWJlbA0KICAgU3dpdGNoZWQgUGF0aCAoTFNQKSBpZGVu dGlmaWVycy4NCg0KICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K --=_alternative 0044A9CE48257949_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIHRoZSBkaXNj dXNzaW9uIG9uIHRoZSBtYWlsaW5nbGlzdCwNCndlIGhhdmUgdXBkYXRlZCB0aGlzIGRyYWZ0IGFu ZCBwcmVzZW50ZWQgdGhlc2UgY2hhbmdlcyBvbiB0aGUgQ0NBTVAgc2Vzc2lvbjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVsb3cgaXMgdGhlIGRyYWZ0 IGxpbms8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10 dW5uZWwtbnVtLTAxPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5XZSBkZWZpbmVkIGEgYml0IGluIHRoZSBMU1AgQXR0cmlidXRlDQpGbGFncyBUTFYgdG8g aW5kaWNhdGUgY2FycnlpbmcgdGhlIExTUCBpZGVudGlmZXIuICZuYnNwO1R3byBuZXcgVExWcyBh cmUNCmFsc28gZGVmaW5lZCBpbiB0aGUgTFNQIEFUVFJJQlVURVMgb2JqZWN0LCBvbmUgaXMgdGhl IENvbm5lY3Rpb24gVExWIHdoaWNoDQppcyB1c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwg bnVtYmVyIGFzc2lnbmVkIGF0IFo5IG5vZGUgKG9ubHkgdXNlZA0KZm9yIGNvcm91dGVkIGJpZGly ZWN0aW9uYWwgTFNQKTsgdGhlIG90aGVyIGlzIHRoZSBHbG9iYWxfSUQgVExWLCB1c2VkIHRvDQpj YXJyeSB0aGUgZ2xvYmFsIElEIChhcHBseWluZyB0byB0aGUgY29yb3V0ZWQgYW5kIGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbA0KTFNQcykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5Zb3UgY2FuIGFsc28gZmluZCB0aGUgcHJlc2VudGF0aW9uIG1hdGVy aWFsDQppbiB0aGUgZm9sbG93aW5nIGxpbms8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jY2FtcC9hZ2VuZGEs DQp0aGUgMTEgb25lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QW55IGNvbW1lbnRzIG9yIGNvbnRyaWJ1dGlvbnMgYXJlIHdlbGNvbWU8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBhbmQgYmVzdCBy ZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5G ZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTEtMTEtMTQgMTI6MzM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw O2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxLnR4dDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC10dW5uZWwtbnVtLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBG ZWkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCkZp bGVuYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDtkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVs LW51bTxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMTxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUlNWUC1URSBF eHRlbnNpb25zIHRvIEV4Y2hhbmdlIE1QTFMtVFAgTFNQIElkZW50aWZpZXJzPGJyPg0KQ3JlYXRp b24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7MjAxMS0xMS0xMzxicj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KSW5kaXZpZHVhbCBT dWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA4PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJy Pg0KICZuYnNwOyBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgaWRlbnRpZmll cnMgZG9jdW1lbnQgW1JGQzYzNzBdPGJyPg0KICZuYnNwOyBzcGVjaWZpZXMgYSBpbml0aWFsIHNl dCBvZiBpZGVudGlmaWVycywgc3VjaCBhcyBsb2NhbCBhc3NpZ25lZA0KdHVubmVsPGJyPg0KICZu YnNwOyBudW1iZXIgYW5kIEdsb2JhbF9JRCwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gZm9ybSBNYWlu dGVuYW5jZSBFbnRpdHk8YnI+DQogJm5ic3A7IFBvaW50IElkZW50aWZpZXIgKE1FUF9JRCkuICZu YnNwO0FzIHRvIHNvbWUgT3BlcmF0aW9uLCBBZG1pbmlzdHJhdGlvbg0KYW5kPGJyPg0KICZuYnNw OyBNYWludGVuYW5jZSAoT0FNKSBmdW5jdGlvbnMsIHN1Y2ggYXMgQ29ubmVjdGl2aXR5IFZlcmlm aWNhdGlvbg0KKENWKTxicj4NCiAmbmJzcDsgW0ktRC5pZXRmLW1wbHMtdHAtY2MtY3YtcmRpXSwg c291cmNlIE1FUF9JRCBtdXN0IGJlIGluc2VydGVkIGluDQp0aGU8YnI+DQogJm5ic3A7IE9BTSBw YWNrZXRzLCBzbyB0aGF0IHRoZSBwZWVyIGVuZHBvaW50IGNhbiBjb21wYXJlIHRoZSByZWNlaXZl ZA0KYW5kPGJyPg0KICZuYnNwOyBleHBlY3RlZCBNRVBfSURzIHRvIGp1ZGdlIHdoZXRoZXIgdGhl cmUgaXMgYSBtaXNtYXRjaCBbUkZDNjM3MV0sPGJyPg0KICZuYnNwOyB3aGljaCBtZWFucyB0aGF0 IHRoZSB0d28gTUVQIG5vZGVzIG5lZWQgdG8gcHJlLXN0b3JlIGVhY2ggb3RoZXImYW1wOyMzOTtz PGJyPg0KICZuYnNwOyBNRVBfSURzLjxicj4NCjxicj4NCiAmbmJzcDsgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIHRoZSBzaWduYWxpbmcgZXh0ZW5zaW9ucyB0byBleGNoYW5nZSB0aGUNCkxhYmVsPGJy Pg0KICZuYnNwOyBTd2l0Y2hlZCBQYXRoIChMU1ApIGlkZW50aWZpZXJzLjxicj4NCjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCg== --=_alternative 0044A9CE48257949_=-- From huaimo.chen@huawei.com Tue Nov 15 08:00:17 2011 Return-Path: <huaimo.chen@huawei.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BAE21F8AE9 for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 08:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEJqgRZ3JY-Z for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 08:00:15 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 680461F0C43 for <mpls@ietf.org>; Tue, 15 Nov 2011 08:00:11 -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 <0LUP00HCLLRX7Q@usaga02-in.huawei.com> for mpls@ietf.org; Tue, 15 Nov 2011 09:59:57 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUP0012YLRX50@usaga02-in.huawei.com> for mpls@ietf.org; Tue, 15 Nov 2011 09:59:57 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 07:59:54 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 07:59:19 -0800 Date: Tue, 15 Nov 2011 15:59:49 +0000 From: Huaimo Chen <huaimo.chen@huawei.com> In-reply-to: <FE60A4E52763E84B935532D7D9294FF12EE15F0690@EUSAACMS0715.eamcs.ericsson.se> X-Originating-IP: [10.47.116.248] To: Gregory Mirsky <gregory.mirsky@ericsson.com> Message-id: <5316A0AB3C851246A7CA5758973207D41189D6F4@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hhbadQxjy6q31YlNjbKmVQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Thread-index: Acyian5b+IJtfGT4QvW8Dx67gFMv+wBRHL4g X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" <mpls@ietf.org>, "Ning.So@verizonbusiness.com" <Ning.So@verizonbusiness.com> Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 16:00:17 -0000 --Boundary_(ID_hhbadQxjy6q31YlNjbKmVQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Greg, Thanks for your comments! My answers to your questions are inline below. Best Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Sunday, November 13, 2011 8:13 PM To: Huaimo Chen; Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Dear Authors, et al., Please consider my comments to the document: * Section 4.1 Not clear how Reference model in Figure 1 positioned relative to CE-PE demarcation. Is Node S a CE node and nodes R1, Ra - PEs? If S is CE, then, in my view, this is PWE3 redundancy scenario. If S is part of MPLS PSN, then what is sourced by S node? Is S a head-end of e2e PWE3? [[Chen,Huaimo]] Node S in Figure 1 is more general. It is not limited to CE. LSP and PW are at different levels. PW is above LSP. Our ingress protection provides protection for LSP against ingress failures. PW (egress) redundancy provides protection for PW against (egress) failure. An LSP can be used as a transport for a PW; it can also be used as a transport for other traffic. Thus our ingress protection for LSP can provide protection for the traffic transported over the LSP, which include PW and other traffic against ingress failures. * Section 4.4 suggests using very unnatural OAM configuration to detect failure of immediate link and/or node. [[Chen,Huaimo]] Can you give a little bit more details about this (very unnatural OAM configuration)? Regards, Greg --Boundary_(ID_hhbadQxjy6q31YlNjbKmVQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:offic= e:smarttags" name=3D"PersonName" /><!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--><style> <!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Times New Roman";} p.emailquote, li.emailquote, div.emailquote {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:1.0pt; border:none; padding:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle19 {mso-style-type:personal-reply; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style><!-- converted from rtf --><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Hi Greg,<o:= p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy"><o:p> = </o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-indent:12.0pt"><font size=3D"3" color= =3D"navy" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-size:= 12.0pt;color:navy">Thanks for your comments!<o:p></o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-indent:12.0pt"><font size=3D"3" color= =3D"navy" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-size:= 12.0pt;color:navy">My answers to your questions are inline below.<o:p></o:p= ></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy"><o:p> = </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Best Regard= s,<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Huaimo<o:p>= </o:p></span></font></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><font= size=3D"3" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-siz= e:12.0pt"> <hr size=3D"2" width=3D"100%" align=3D"center" tabindex=3D"-1"> </span></font></div> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN= -US" style=3D"font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</= span></font></b><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US" style= =3D"font-size:10.0pt;font-family:Tahoma"> Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] <br> <b><span style=3D"font-weight:bold">Sent:</span></b> Sunday, November 13, 2= 011 8:13 PM<br> <b><span style=3D"font-weight:bold">To:</span></b> Huaimo Chen; Ning.So@ver= izonbusiness.com; <st1:PersonName w:st=3D"on">Autumn Liu</st1:PersonName>; <st1:PersonName w:= st=3D"on"> mpls@ietf.org</st1:PersonName><br> <b><span style=3D"font-weight:bold">Subject:</span></b> Comments to draft-c= hen-mpls-p2mp-ingress-protection-04</span></font><span lang=3D"EN-US"><o:p>= </o:p></span></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt"><o:p> </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt"><!--[if gte vml 1]><v:shapetype id=3D= "_x0000_t74"=20 coordsize=3D"21600,21600" o:spt=3D"74" path=3D"m10860,2187c10451,1746,9529= ,1018,9015,730,7865,152,6685,,5415,,4175,152,2995,575,1967,1305,1150,2187,5= 75,3222,242,4220,,5410,242,6560,575,7597l10860,21600,20995,7597v485,-1037,6= 05,-2187,485,-3377c21115,3222,20420,2187,19632,1305,18575,575,17425,152,162= 75,,15005,,13735,152,12705,730v-529,288,-1451,1016,-1845,1457xe"> <v:stroke joinstyle=3D"miter" /> <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" o:connectlocs=3D"10= 860,2187;2928,10800;10860,21600;18672,10800"=20 o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" /> </v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" type=3D"= #_x0000_t74"=20 alt=3D"EUR88905D5C@5G3B820BE67469E24BE508;<<U;0?CdBIDO^IT@HLN,BIHO@]= B62767!!!1@B104221135D9B60B@8Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20 style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:.= 05pt; z-index:1;visibility:hidden'> <w:anchorlock/> </v:shape><![endif]--></span></font><font size=3D"2" face=3D"Arial"><span l= ang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial">Dear Authors, et al.,<o:p></o:p></span></font></p> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">Please consider my comments to the document:<o:p>= </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.1 Not clear how Reference mo= del in Figure 1 positioned relative to CE-PE demarcation. Is Node S a CE no= de and nodes R1, Ra </span></font><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US" style= =3D"font-size:10.0pt;font-family:Tahoma">–</span></font><font size=3D= "2" face=3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-fami= ly:Arial"> PEs?  If S is CE, then, in my view, this is PWE3 redundancy scenario. If S is part of MPLS PSN, then what is sourced by S n= ode? Is S a head-end of e2e PWE3?<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]]<o:p></o:p></span></font></i></b></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic"> </span></font></i></b><font size=3D"2" face=3D"Ari= al"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial">Node S in Figure 1 is more general. It is not limited to CE. <o:p></o:p></span>= </font></p> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"><o:p> </o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= ">LSP and PW are at different levels. PW is above LSP. Our ingress protecti= on provides protection for LSP against ingress failures. PW (egress) redundancy provides protection for PW against (egres= s) failure. <o:p></o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= "><o:p> </o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= ">An LSP can be used as a transport for a PW; it can also be used as a tran= sport for other traffic. Thus our ingress protection for LSP can provide protection for the traffic transported over the LSP, w= hich include PW and other traffic against ingress failures.<o:p></o:p></spa= n></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.4 suggests using very unnatu= ral OAM configuration to detect failure of immediate link and/or node.<o:p>= </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]] <o:p></o:p></span></font></i></b></p> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">Can you give a little bit more details about this= (very unnatural OAM configuration)? <o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"> <o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">        Regard= s,<o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">        &= nbsp;       Greg<o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"> <o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"> <o:p></o:p></span></font></p> </div> </div> </body> </html> --Boundary_(ID_hhbadQxjy6q31YlNjbKmVQ)-- From huaimo.chen@huawei.com Tue Nov 15 08:05:37 2011 Return-Path: <huaimo.chen@huawei.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C019E21F8AFF for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 08:05:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOUI9JXoKDzt for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 08:05:36 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0376A21F8AFC for <mpls@ietf.org>; Tue, 15 Nov 2011 08:05:36 -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 <0LUP00HJUM1B7Q@usaga02-in.huawei.com> for mpls@ietf.org; Tue, 15 Nov 2011 10:05:35 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUP001ZGM1B50@usaga02-in.huawei.com> for mpls@ietf.org; Tue, 15 Nov 2011 10:05:35 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 08:05:31 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 08:05:24 -0800 Date: Tue, 15 Nov 2011 16:05:23 +0000 From: Huaimo Chen <huaimo.chen@huawei.com> In-reply-to: <FE60A4E52763E84B935532D7D9294FF12EE15F0691@EUSAACMS0715.eamcs.ericsson.se> X-Originating-IP: [10.47.116.248] To: Gregory Mirsky <gregory.mirsky@ericsson.com> Message-id: <5316A0AB3C851246A7CA5758973207D41189D703@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QKBcY3bEL9gPATiY4yyFzg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Comments to draft-chen-mpls-p2mp-egress-protection-04 Thread-index: Acyiap2UEvFtT0Z8TrOXLfWpm5hxyQBRQa2w X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" <mpls@ietf.org>, "Ning.So@verizonbusiness.com" <Ning.So@verizonbusiness.com> Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 16:05:37 -0000 --Boundary_(ID_QKBcY3bEL9gPATiY4yyFzg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Greg, Thanks for your comments! Please see my answers inline below. Best Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Sunday, November 13, 2011 8:13 PM To: Huaimo Chen; Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-egress-protection-04 Dear Authors, et al., Please kindly consider my comments: * Section 4.1 Figure 1 I think that presented scenario is scenario more suitable for PWE3 WG [[Chen,Huaimo]] LSP and PW are at different levels. PW is above LSP. Our egress protection provides protection for LSP against egress failures. An LSP can be used as a transport for a PW; it can also be used as a transport for other traffic. Thus our egress protection for LSP can provide protection for the traffic transported over the LSP, which include PW and other traffic against egress failures. * Section 4.1 "The backup sub LSP used to protect the primary egress node L1 is from its previous hop node R3 to the backup egress node La." I'd note that there might be situation when R3, as characterized in the document, can not be connected by sub-LSP to the particular node La. [[Chen,Huaimo]] If there is not any protection path in the network, what should we do? * Section 4.4 "Destination node" is usually referred as CE in PWE3 Reference model. * Section 4.4 I think that OAM (BFD) between CE and "previous hop" is not realistic as it crosses administration domain's border. [[Chen,Huaimo]] LSP may cross multiple domains as long as policies allow. LSP with BFD between CE and "previous hop" may be one of approaches as long as polices allow. * Section 5. IMO, protection of PE and CE-PE link is outside of scope of the MPLS WG. [[Chen,Huaimo]] It seems that Section 5 in your statement above should be Section 4.4 since Section 5 "Egress Local Protection with FRR" does not mention CE-PE link. Do you mean "protection of CE and CE-PE link is outside of scope of the MPLS WG."? It seems that PE should be CE in your statement. Regards, Greg --Boundary_(ID_QKBcY3bEL9gPATiY4yyFzg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:offic= e:smarttags" name=3D"State" /><o:SmartTagType namespaceuri=3D"urn:schemas-m= icrosoft-com:office:smarttags" name=3D"place" /><o:SmartTagType namespaceur= i=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName" /><!--= [if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--><style> <!-- /* Font Definitions */ @font-face {font-family:Courier; panose-1:2 7 4 9 2 2 5 2 4 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Times New Roman";} p.emailquote, li.emailquote, div.emailquote {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:1.0pt; border:none; padding:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle19 {mso-style-type:personal-reply; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style><!-- converted from rtf --><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Hi Greg,<o:= p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy"><o:p> = </o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-indent:12.0pt"><font size=3D"3" color= =3D"navy" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-size:= 12.0pt;color:navy">Thanks for your comments!<o:p></o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-indent:12.0pt"><font size=3D"3" color= =3D"navy" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-size:= 12.0pt;color:navy">Please see my answers inline below.<o:p></o:p></span></f= ont></p> <p class=3D"MsoNormal" style=3D"text-indent:12.0pt"><font size=3D"3" color= =3D"navy" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-size:= 12.0pt;color:navy"><o:p> </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Best Regard= s,<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" color=3D"navy" face=3D"Times New Ro= man"><span lang=3D"EN-US" style=3D"font-size:12.0pt;color:navy">Huaimo<o:p>= </o:p></span></font></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><font= size=3D"3" face=3D"Times New Roman"><span lang=3D"EN-US" style=3D"font-siz= e:12.0pt"> <hr size=3D"2" width=3D"100%" align=3D"center" tabindex=3D"-1"> </span></font></div> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN= -US" style=3D"font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</= span></font></b><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US" style= =3D"font-size:10.0pt;font-family:Tahoma"> Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] <br> <b><span style=3D"font-weight:bold">Sent:</span></b> Sunday, November 13, 2= 011 8:13 PM<br> <b><span style=3D"font-weight:bold">To:</span></b> Huaimo Chen; Ning.So@ver= izonbusiness.com; <st1:PersonName w:st=3D"on">Autumn Liu</st1:PersonName>; <st1:PersonName w:= st=3D"on"> mpls@ietf.org</st1:PersonName><br> <b><span style=3D"font-weight:bold">Subject:</span></b> Comments to draft-c= hen-mpls-p2mp-egress-protection-04</span></font><span lang=3D"EN-US"><o:p><= /o:p></span></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt"><o:p> </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt"><!--[if gte vml 1]><v:shapetype id=3D= "_x0000_t74"=20 coordsize=3D"21600,21600" o:spt=3D"74" path=3D"m10860,2187c10451,1746,9529= ,1018,9015,730,7865,152,6685,,5415,,4175,152,2995,575,1967,1305,1150,2187,5= 75,3222,242,4220,,5410,242,6560,575,7597l10860,21600,20995,7597v485,-1037,6= 05,-2187,485,-3377c21115,3222,20420,2187,19632,1305,18575,575,17425,152,162= 75,,15005,,13735,152,12705,730v-529,288,-1451,1016,-1845,1457xe"> <v:stroke joinstyle=3D"miter" /> <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" o:connectlocs=3D"10= 860,2187;2928,10800;10860,21600;18672,10800"=20 o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" /> </v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" type=3D"= #_x0000_t74"=20 alt=3D"EUR88905D5C@5G3B820BE67469E24BE508;<<U;0?CdBIDO^IT@HLN,BIHO@]= B62767!!!1@B104221135D9B60B@8Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20 style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:.= 05pt; z-index:1;visibility:hidden'> <w:anchorlock/> </v:shape><![endif]--></span></font><font size=3D"2" face=3D"Arial"><span l= ang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial">Dear Authors, et al.,<o:p></o:p></span></font></p> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">Please kindly consider my comments:<o:p></o:p></s= pan></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.1 Figure 1 I think that pres= ented scenario is scenario more suitable for PWE3 WG<o:p></o:p></span></fon= t></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]] <o:p></o:p></span></font></i></b></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= ">LSP and PW are at different levels. PW is above LSP. Our egress protectio= n provides protection for LSP against egress failures. <o:p></o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= "><o:p> </o:p></span></font></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><font size=3D"2" face= =3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial= ">An LSP can be used as a transport for a PW; it can also be used as a tran= sport for other traffic. Thus our egress protection for LSP can provide protection for the traffic transported over the LSP, w= hich include PW and other traffic against egress failures.<o:p></o:p></span= ></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic"><o:p> </o:p></span></font></i></b></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.1 “The backup sub LSP = used to protect the primary egress node L1 is from its previous hop node R3= to the backup egress node <st1:place w:st=3D"on"><st1:State w:st=3D"on">La.</st1:State></st1:place>&#= 8221; I’d note that there might be situation when R3, as characterize= d in the document, can not be connected by sub-LSP to the particular node <st1:place w:st=3D"on"><st1:State w:st=3D"on">La.</st1:State></st1:place><o= :p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]] </span></font></i></b><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" = style=3D"font-size:10.0pt;font-family:Arial">If there is not any protection= path in the network, what should we do?<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.4 “Destination node= 221; is usually referred as CE in PWE3 Reference model.<o:p></o:p></span></= font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 4.4 I think that OAM (BFD) bet= ween CE and “previous hop” is not realistic as it crosses admin= istration domain’s border.<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]] <o:p></o:p></span></font></i></b></p> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">LSP may cross multiple domains as long as policie= s allow. LSP with BFD between CE and “previous hop” may be one = of approaches as long as polices allow. <o:p></o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic"><o:p> </o:p></span></font></i></b></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Tahoma"><span lang=3D"EN-US= " style=3D"font-size: 10.0pt;font-family:Tahoma">•       </span></font><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D= "font-size:10.0pt;font-family:Arial">Section 5. IMO, protection of PE and C= E-PE link is outside of scope of the MPLS WG.<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> <p class=3D"MsoNormal"><b><i><font size=3D"2" color=3D"navy" face=3D"Arial"= ><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:nav= y;font-weight:bold; font-style:italic">[[Chen,Huaimo]] <o:p></o:p></span></font></i></b></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt">It seems that Section 5 in your state= ment above should be Section 4.4 since Section 5 “</span></font><font= face=3D"Courier"><span lang=3D"EN-US" style=3D"font-family:Courier">Egress Local Protection with FRR</span></font><span lang=3D"EN-US">” does n= ot mention </span> <font size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.= 0pt;font-family:Arial">CE-PE link.<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt"><o:p> </o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span lang= =3D"EN-US" style=3D"font-size:12.0pt">Do you mean “</span></font><fon= t size=3D"2" face=3D"Arial"><span lang=3D"EN-US" style=3D"font-size:10.0pt;= font-family:Arial">protection of CE and CE-PE link is outside of scope of the MPLS WG.”? It seems that PE should be CE in your sta= tement.<o:p></o:p></span></font></p> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span= lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"><o:= p> </o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"> <o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">        Regard= s,<o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial">        &= nbsp;       Greg<o:p></o:p></span></font></p> </div> <div> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Arial"><span lang=3D"EN-US"= style=3D"font-size: 10.0pt;font-family:Arial"> <o:p></o:p></span></font></p> </div> </div> </body> </html> --Boundary_(ID_QKBcY3bEL9gPATiY4yyFzg)-- From internet-drafts@ietf.org Tue Nov 15 10:07:30 2011 Return-Path: <internet-drafts@ietf.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B5411E80A3; Tue, 15 Nov 2011 10:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaLCyARm+p7V; Tue, 15 Nov 2011 10:07:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4589A11E809C; Tue, 15 Nov 2011 10:07:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111115180726.28435.74300.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 10:07:26 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 18:07:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-02.txt Pages : 38 Date : 2011-11-15 This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast or IP multicast over MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mcast-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mcast-02.txt From yakov@juniper.net Tue Nov 15 10:11:27 2011 Return-Path: <yakov@juniper.net> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4005121F867F for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 10:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agcFaHwokpw0 for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 10:11:23 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9521F8593 for <mpls@ietf.org>; Tue, 15 Nov 2011 10:11:22 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTsKrShNyMztx54Ih6tL8oWUfFxlc+a1N@postini.com; Tue, 15 Nov 2011 10:11:23 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Nov 2011 10:09:32 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAFI9Wh36906 for <mpls@ietf.org>; Tue, 15 Nov 2011 10:09:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201111151809.pAFI9Wh36906@magenta.juniper.net> To: <mpls@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89326.1321380572.1@juniper.net> Date: Tue, 15 Nov 2011 10:09:32 -0800 From: Yakov Rekhter <yakov@juniper.net> Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 18:11:27 -0000 Folks, The -02 version of the draft incorporates changes to reflect comments received from Eric Rosen. It also includes other editorial changes. Yakov. ------- Forwarded Message Date: Tue, 15 Nov 2011 10:07:26 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-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 o f the IETF. Title : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-02.txt Pages : 38 Date : 2011-11-15 This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast or IP multicast over MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mcast-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mcast-02.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------- End of Forwarded Message From gregory.mirsky@ericsson.com Tue Nov 15 17:11:01 2011 Return-Path: <gregory.mirsky@ericsson.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A9811E80BB for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 17:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0MC72-+bcsC for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 17:10:59 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D61BA11E80BA for <mpls@ietf.org>; Tue, 15 Nov 2011 17:10:58 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAG1AeBL022025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 19:10:40 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 15 Nov 2011 20:10:39 -0500 From: Gregory Mirsky <gregory.mirsky@ericsson.com> To: Huaimo Chen <huaimo.chen@huawei.com> Date: Tue, 15 Nov 2011 20:10:36 -0500 Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Thread-Index: Acyian5b+IJtfGT4QvW8Dx67gFMv+wBRHL4gABJyEhA= Message-ID: <FE60A4E52763E84B935532D7D9294FF12EE1659094@EUSAACMS0715.eamcs.ericsson.se> References: <FE60A4E52763E84B935532D7D9294FF12EE15F0690@EUSAACMS0715.eamcs.ericsson.se> <5316A0AB3C851246A7CA5758973207D41189D6F4@dfweml506-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D41189D6F4@dfweml506-mbx> 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_FE60A4E52763E84B935532D7D9294FF12EE1659094EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org>, "Ning.So@verizonbusiness.com" <Ning.So@verizonbusiness.com> Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 01:11:01 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE1659094EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Huaimo, thank you for your response and clarifications. Please find my notes in-lin= ed under GIM>> tag. Regards, Greg ________________________________ From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, November 15, 2011 8:00 AM To: Gregory Mirsky Cc: Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Hi Greg, Thanks for your comments! My answers to your questions are inline below. Best Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Sunday, November 13, 2011 8:13 PM To: Huaimo Chen; Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-04 Dear Authors, et al., Please consider my comments to the document: * Section 4.1 Not clear how Reference model in Figure 1 positioned re= lative to CE-PE demarcation. Is Node S a CE node and nodes R1, Ra - PEs? I= f S is CE, then, in my view, this is PWE3 redundancy scenario. If S is part= of MPLS PSN, then what is sourced by S node? Is S a head-end of e2e PWE3? [[Chen,Huaimo]] Node S in Figure 1 is more general. It is not limited to CE. LSP and PW are at different levels. PW is above LSP. Our ingress protection= provides protection for LSP against ingress failures. PW (egress) redundan= cy provides protection for PW against (egress) failure. An LSP can be used as a transport for a PW; it can also be used as a transp= ort for other traffic. Thus our ingress protection for LSP can provide prot= ection for the traffic transported over the LSP, which include PW and other= traffic against ingress failures. GIM>> Can I assume that the reference model describes IP/MPLS traffic over = MPLS p2mp tunnel? IMHO, in case of IP, the S node still might be viewed as = CE with redundant connection to a tunnel. If the scenario is MPLS over p2mp= MPLS tunnel, then the reference model, IMHO, is the case of MPLS-TE local = protection described in RFC 4875. * Section 4.4 suggests using very unnatural OAM configuration to dete= ct failure of immediate link and/or node. [[Chen,Huaimo]] Can you give a little bit more details about this (very unnatural OAM confi= guration)? GIM>> I'll note that what can be "detected through a BFD session between t= he ingress node and the backup ingress node" is not only availability of pr= imary ingress node R1 but of path between R1 and Ra as well. As result, one= can receive positive negatives when the path fails and interpret them as R= 1 failure. Similar applies to monitoring of link between S and R1 since the= monitoring is done by Ra. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE1659094EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18510" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--><o:SmartTagType name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagTyp= e><!--[if !mso]> <STYLE>st1\:* { BEHAVIOR: url(#default#ieooui) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: SimSun; } @font-face { font-family: Tahoma; } @font-face { font-family: SimSun; } @page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt;= } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } P.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } LI.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } DIV.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } SPAN.EmailStyle19 { COLOR: navy; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!-- converted from rtf --><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DZH-CN vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D920144300-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Dear Huaimo,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D920144300-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>thank you for your response and clarifications. Pl= ease find=20 my notes in-lined under GIM>> tag.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D920144300-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D920144300-16112011>  &n= bsp; <FONT=20 face=3DArial color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D920144300-16112011>        <FONT= =20 face=3DArial color=3D#0000ff size=3D2>Greg</FONT></SPAN></DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Huaimo Chen=20 [mailto:huaimo.chen@huawei.com] <BR><B>Sent:</B> Tuesday, November 15, 2011= 8:00=20 AM<BR><B>To:</B> Gregory Mirsky<BR><B>Cc:</B> Ning.So@verizonbusiness.com;= =20 Autumn Liu; mpls@ietf.org<BR><B>Subject:</B> RE: Comments to=20 draft-chen-mpls-p2mp-ingress-protection-04<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: navy">Hi=20 Greg,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal style=3D"TEXT-INDENT: 12pt"><FONT face=3D"Times New Ro= man"=20 color=3Dnavy size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: n= avy">Thanks=20 for your comments!<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal style=3D"TEXT-INDENT: 12pt"><FONT face=3D"Times New Ro= man"=20 color=3Dnavy size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: n= avy">My=20 answers to your questions are inline below.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: navy">Best=20 Regards,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy">Huaimo<o:p></o:p></SPAN></FONT></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12= pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SP= AN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Gregory Mirsky=20 [mailto:gregory.mirsky@ericsson.com] <BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday, November 13, 2011 8:13= =20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Huaimo Chen;=20 Ning.So@verizonbusiness.com; <st1:PersonName w:st=3D"on">Autumn=20 Liu</st1:PersonName>; <st1:PersonName=20 w:st=3D"on">mpls@ietf.org</st1:PersonName><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Comments to=20 draft-chen-mpls-p2mp-ingress-protection-04</SPAN></FONT><SPAN=20 lang=3DEN-US><o:p></o:p></SPAN></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt"><!--[if gte vml 1]><v:shapetype id=3D"_x0000_t74"= =20 coordsize=3D"21600,21600" o:spt=3D"74" path=3D"m10860,2187c10451,1746,9529= ,1018,9015,730,7865,152,6685,,5415,,4175,152,2995,575,1967,1305,1150,2187,5= 75,3222,242,4220,,5410,242,6560,575,7597l10860,21600,20995,7597v485,-1037,6= 05,-2187,485,-3377c21115,3222,20420,2187,19632,1305,18575,575,17425,152,162= 75,,15005,,13735,152,12705,730v-529,288,-1451,1016,-1845,1457xe"> <v:stroke joinstyle=3D"miter" /> <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" o:connectlocs=3D"10= 860,2187;2928,10800;10860,21600;18672,10800"=20 o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" /> </v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" type=3D"= #_x0000_t74"=20 alt=3D"EUR88905D5C@5G3B820BE67469E24BE508;<<U;0?CdBIDO^IT@HLN,BIHO@]= B62767!!!1@B104221135D9B60B@8Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20 style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:.= 05pt; z-index:1;visibility:hidden'> <w:anchorlock/> </v:shape><![endif]--></SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang= =3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dear Authors, et=20 al.,<o:p></o:p></SPAN></FONT></P> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please consider my comments t= o the=20 document:<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.1 Not clear how Ref= erence=20 model in Figure 1 positioned relative to CE-PE demarcation. Is Node S a CE = node=20 and nodes R1, Ra </SPAN></FONT><FONT face=3DTahoma size=3D2><SPAN lang=3DEN= -US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">–</SPAN></FONT><FONT f= ace=3DArial=20 size=3D2><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> = PEs? =20 If S is CE, then, in my view, this is PWE3 redundancy scenario. If S is par= t of=20 MPLS PSN, then what is sourced by S node? Is S a head-end of e2e=20 PWE3?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]<o:p></o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial"> </SPAN></FONT></I></B><FONT=20 face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Node S in Figure 1 is more ge= neral.=20 It is not limited to CE. <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FON= T></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">LSP and PW are at different l= evels.=20 PW is above LSP. Our ingress protection provides protection for LSP against= =20 ingress failures. PW (egress) redundancy provides protection for PW against= =20 (egress) failure. <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FON= T></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">An LSP can be used as a trans= port=20 for a PW; it can also be used as a transport for other traffic. Thus our in= gress=20 protection for LSP can provide protection for the traffic transported over = the=20 LSP, which include PW and other traffic against ingress failures.<FONT=20 color=3D#0000ff><SPAN class=3D920144300-16112011> </SPAN></FONT></SPAN= ></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT color=3D#0000ff><SPAN=20 class=3D920144300-16112011></SPAN></FONT></SPAN> </P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT color=3D#0000ff><SPAN=20 class=3D920144300-16112011>GIM>> Can I assume that the reference mode= l=20 describes IP/MPLS traffic over MPLS p2mp tunnel? IMHO, in case of IP, the S= node=20 still might be viewed as CE with redundant connection to a tunnel. If the=20 scenario is MPLS over p2mp MPLS tunnel, then the reference model, IMHO, is = the=20 case of MPLS-TE local protection described in RFC 4875.</SPAN></FONT></SPAN= ></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.4 suggests using ve= ry=20 unnatural OAM configuration to detect failure of immediate link and/or=20 node.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]=20 <o:p></o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Can you give a little bit mor= e=20 details about this (very unnatural OAM configuration)?=20 <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <SPAN=20 class=3D920144300-16112011>GIM>> I'll note that what can=20 be "detected through a BFD session between the ingress node and the ba= ckup=20 ingress node" is not only availability of primary ingress node R1 but of pa= th=20 between R1 and Ra as well. As result, one can receive positive negatives wh= en=20 the path fails and interpret them as R1 failure. Similar applies to monitor= ing=20 of link between S and R1 since the monitoring is done by Ra.</SPAN></SPAN><= /P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20 class=3D920144300-16112011> </P></SPAN></SPAN></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">     = ;  =20 Regards,<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">     = ;          =20 Greg<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FON= T></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FON= T></P></DIV></DIV></BODY></HTML> --_000_FE60A4E52763E84B935532D7D9294FF12EE1659094EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Tue Nov 15 17:27:35 2011 Return-Path: <gregory.mirsky@ericsson.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548C21F0C61 for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 17:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGHlqDNGDxlZ for <mpls@ietfa.amsl.com>; Tue, 15 Nov 2011 17:27:33 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 242051F0C84 for <mpls@ietf.org>; Tue, 15 Nov 2011 17:27:33 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG1RNE5017074; Tue, 15 Nov 2011 19:27:25 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.18]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 15 Nov 2011 20:27:23 -0500 From: Gregory Mirsky <gregory.mirsky@ericsson.com> To: Huaimo Chen <huaimo.chen@huawei.com> Date: Tue, 15 Nov 2011 20:27:20 -0500 Thread-Topic: Comments to draft-chen-mpls-p2mp-egress-protection-04 Thread-Index: Acyiap2UEvFtT0Z8TrOXLfWpm5hxyQBRQa2wABM8C3A= Message-ID: <FE60A4E52763E84B935532D7D9294FF12EE1659099@EUSAACMS0715.eamcs.ericsson.se> References: <FE60A4E52763E84B935532D7D9294FF12EE15F0691@EUSAACMS0715.eamcs.ericsson.se> <5316A0AB3C851246A7CA5758973207D41189D703@dfweml506-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D41189D703@dfweml506-mbx> 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_FE60A4E52763E84B935532D7D9294FF12EE1659099EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org>, "Ning.So@verizonbusiness.com" <Ning.So@verizonbusiness.com> Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 01:27:35 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EE1659099EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Huaimo, thank you for your response and clarifications you've provided. Please find= my notes in-lened under GIM>> tag. Regards, Greg ________________________________ From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, November 15, 2011 8:05 AM To: Gregory Mirsky Cc: Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-egress-protection-04 Hi Greg, Thanks for your comments! Please see my answers inline below. Best Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Sunday, November 13, 2011 8:13 PM To: Huaimo Chen; Ning.So@verizonbusiness.com; Autumn Liu; mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-egress-protection-04 Dear Authors, et al., Please kindly consider my comments: * Section 4.1 Figure 1 I think that presented scenario is scenario mo= re suitable for PWE3 WG [[Chen,Huaimo]] LSP and PW are at different levels. PW is above LSP. Our egress protection = provides protection for LSP against egress failures. An LSP can be used as a transport for a PW; it can also be used as a transp= ort for other traffic. Thus our egress protection for LSP can provide prote= ction for the traffic transported over the LSP, which include PW and other = traffic against egress failures. GIM>> As mentioned earlier, it might be IP or MPLS payload over MPLS p2mp = tunnel. If former, IMHO, model of CE CE still applies as in l3vpn. If the l= atter, this is MPLS-TE local protection. * Section 4.1 "The backup sub LSP used to protect the primary egress = node L1 is from its previous hop node R3 to the backup egress node La." I'd= note that there might be situation when R3, as characterized in the docume= nt, can not be connected by sub-LSP to the particular node La. [[Chen,Huaimo]] If there is not any protection path in the network, what sh= ould we do? * Section 4.4 "Destination node" is usually referred as CE in PWE3 Re= ference model. * Section 4.4 I think that OAM (BFD) between CE and "previous hop" is= not realistic as it crosses administration domain's border. [[Chen,Huaimo]] LSP may cross multiple domains as long as policies allow. LSP with BFD betw= een CE and "previous hop" may be one of approaches as long as polices allow= . GIM>> I'd add that CC/CV monitoring between, e.g. R3 and CE1 makes CC/CV se= ssion between R3 and L1 unneccessary. * Section 5. IMO, protection of PE and CE-PE link is outside of scope= of the MPLS WG. [[Chen,Huaimo]] It seems that Section 5 in your statement above should be Section 4.4 since= Section 5 "Egress Local Protection with FRR" does not mention CE-PE link. Do you mean "protection of CE and CE-PE link is outside of scope of the MPL= S WG."? It seems that PE should be CE in your statement. GIM>> I think that reference to Section 5 was correct. The egress node is t= he PE in case of IP payload. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EE1659099EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18510" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--><o:SmartTagType name=3D"State"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagTyp= e><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagTyp= e><o:SmartTagType=20 name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagTyp= e><!--[if !mso]> <STYLE>st1\:* { BEHAVIOR: url(#default#ieooui) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Courier; } @font-face { font-family: SimSun; } @font-face { font-family: Tahoma; } @font-face { font-family: SimSun; } @page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt;= } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoAcetate { FONT-SIZE: 8pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } P.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } LI.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } DIV.emailquote { BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PA= DDING-LEFT: 0cm; FONT-SIZE: 12pt; PADDING-BOTTOM: 0cm; MARGIN-LEFT: 1pt; BO= RDER-LEFT: medium none; MARGIN-RIGHT: 0cm; PADDING-TOP: 0cm; BORDER-BOTTOM:= medium none; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso= -margin-bottom-alt: auto } SPAN.EmailStyle19 { COLOR: navy; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> <!-- converted from rtf --><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DZH-CN vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D474501001-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Dear Huaimo,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D474501001-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>thank you for your response and clarifications you= 've=20 provided. Please find my notes in-lened under GIM>>=20 tag.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D474501001-16112011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D474501001-16112011>  &n= bsp; <FONT=20 face=3DArial color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D474501001-16112011>        <FONT= =20 face=3DArial color=3D#0000ff size=3D2>Greg</FONT></SPAN></DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Huaimo Chen=20 [mailto:huaimo.chen@huawei.com] <BR><B>Sent:</B> Tuesday, November 15, 2011= 8:05=20 AM<BR><B>To:</B> Gregory Mirsky<BR><B>Cc:</B> Ning.So@verizonbusiness.com;= =20 Autumn Liu; mpls@ietf.org<BR><B>Subject:</B> RE: Comments to=20 draft-chen-mpls-p2mp-egress-protection-04<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: navy">Hi=20 Greg,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal style=3D"TEXT-INDENT: 12pt"><FONT face=3D"Times New Ro= man"=20 color=3Dnavy size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: n= avy">Thanks=20 for your comments!<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal style=3D"TEXT-INDENT: 12pt"><FONT face=3D"Times New Ro= man"=20 color=3Dnavy size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: n= avy">Please=20 see my answers inline below.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal style=3D"TEXT-INDENT: 12pt"><FONT face=3D"Times New Ro= man"=20 color=3Dnavy size=3D3><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: navy">Best=20 Regards,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy size=3D3><= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy">Huaimo<o:p></o:p></SPAN></FONT></P> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN lang=3DEN-US style=3D"FONT-SIZE: 12= pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SP= AN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Gregory Mirsky=20 [mailto:gregory.mirsky@ericsson.com] <BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Sunday, November 13, 2011 8:13= =20 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Huaimo Chen;=20 Ning.So@verizonbusiness.com; <st1:PersonName w:st=3D"on">Autumn=20 Liu</st1:PersonName>; <st1:PersonName=20 w:st=3D"on">mpls@ietf.org</st1:PersonName><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Comments to=20 draft-chen-mpls-p2mp-egress-protection-04</SPAN></FONT><SPAN=20 lang=3DEN-US><o:p></o:p></SPAN></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt"><!--[if gte vml 1]><v:shapetype id=3D"_x0000_t74"= =20 coordsize=3D"21600,21600" o:spt=3D"74" path=3D"m10860,2187c10451,1746,9529= ,1018,9015,730,7865,152,6685,,5415,,4175,152,2995,575,1967,1305,1150,2187,5= 75,3222,242,4220,,5410,242,6560,575,7597l10860,21600,20995,7597v485,-1037,6= 05,-2187,485,-3377c21115,3222,20420,2187,19632,1305,18575,575,17425,152,162= 75,,15005,,13735,152,12705,730v-529,288,-1451,1016,-1845,1457xe"> <v:stroke joinstyle=3D"miter" /> <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" o:connectlocs=3D"10= 860,2187;2928,10800;10860,21600;18672,10800"=20 o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" /> </v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" type=3D"= #_x0000_t74"=20 alt=3D"EUR88905D5C@5G3B820BE67469E24BE508;<<U;0?CdBIDO^IT@HLN,BIHO@]= B62767!!!1@B104221135D9B60B@8Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20 style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:.= 05pt; z-index:1;visibility:hidden'> <w:anchorlock/> </v:shape><![endif]--></SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang= =3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dear Authors, et=20 al.,<o:p></o:p></SPAN></FONT></P> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please kindly consider my=20 comments:<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.1 Figure 1 I think = that=20 presented scenario is scenario more suitable for PWE3=20 WG<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]=20 <o:p></o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">LSP and PW are at different l= evels.=20 PW is above LSP. Our egress protection provides protection for LSP against= =20 egress failures. <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FON= T></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">An LSP can be used as a trans= port=20 for a PW; it can also be used as a transport for other traffic. Thus our eg= ress=20 protection for LSP can provide protection for the traffic transported over = the=20 LSP, which include PW and other traffic against egress=20 failures.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <SPAN= =20 class=3D474501001-16112011><FONT color=3D#0000ff>GIM>> As mentioned e= arlier,=20 it might be IP or MPLS payload over MPLS p2mp tunnel. If former, IMHO, mode= l of=20 CE CE still applies as in l3vpn. If the latter, this is MPLS-TE local=20 protection.</FONT></SPAN></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT color=3D#0000ff><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN=20 class=3D474501001-16112011></SPAN></o:p></SPAN></FONT> </P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.1 “The backup= sub LSP used=20 to protect the primary egress node L1 is from its previous hop node R3 to t= he=20 backup egress node <st1:place w:st=3D"on"><st1:State=20 w:st=3D"on">La.</st1:State></st1:place>” I’d note that there mi= ght be situation=20 when R3, as characterized in the document, can not be connected by sub-LSP = to=20 the particular node <st1:place w:st=3D"on"><st1:State=20 w:st=3D"on">La.</st1:State></st1:place><o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]=20 </SPAN></FONT></I></B><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">If there is not any protectio= n path=20 in the network, what should we do?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.4 “Destinatio= n node” is=20 usually referred as CE in PWE3 Reference=20 model.<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 4.4 I think that OAM = (BFD)=20 between CE and “previous hop” is not realistic as it crosses ad= ministration=20 domain’s border.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]=20 <o:p></o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">LSP may cross multiple domain= s as=20 long as policies allow. LSP with BFD between CE and “previous hopR= 21; may be one of=20 approaches as long as polices allow. <o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN=20 class=3D474501001-16112011><FONT color=3D#0000ff>GIM>> I'd add that C= C/CV=20 monitoring between, e.g. R3 and CE1 makes CC/CV session between R3 and L1=20 unneccessary.</FONT></SPAN> </o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">•   &nb= sp;  =20 </SPAN></FONT><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Section 5. IMO, protection of= PE and=20 CE-PE link is outside of scope of the MPLS WG.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P> <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy size=3D2><SPAN l= ang=3DEN-US=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: itali= c; FONT-FAMILY: Arial">[[Chen,Huaimo]]=20 <o:p></o:p></SPAN></FONT></I></B></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt">It seems that Section 5 in your statement above s= hould=20 be Section 4.4 since Section 5 “</SPAN></FONT><FONT face=3DCourier><S= PAN=20 lang=3DEN-US style=3D"FONT-FAMILY: Courier">Egress Local Protection with=20 FRR</SPAN></FONT><SPAN lang=3DEN-US>” does not mention </SPAN><FONT f= ace=3DArial=20 size=3D2><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">C= E-PE=20 link.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN lang=3DE= N-US=20 style=3D"FONT-SIZE: 12pt">Do you mean “</SPAN></FONT><SPAN lang=3DEN-= US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">protection of CE and CE-PE li= nk is=20 outside of scope of the MPLS WG.”? It seems that PE should be CE in y= our=20 statement.<FONT color=3D#0000ff><SPAN=20 class=3D474501001-16112011> </SPAN></FONT></SPAN></P> <P class=3DMsoNormal><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><FONT color=3D#0000ff><SPAN=20 class=3D474501001-16112011>GIM>> I think that reference to Section 5 = was=20 correct. The egress node is the PE in case of IP=20 payload. </SPAN><o:p></o:p></FONT></SPAN></P> <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN lang=3D= EN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p= ></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FON= T></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">     = ;  =20 Regards,<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">     = ;          =20 Greg<o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></FON= T></P></DIV></DIV></BODY></HTML> --_000_FE60A4E52763E84B935532D7D9294FF12EE1659099EUSAACMS0715e_-- From wwwrun@rfc-editor.org Wed Nov 16 01:41:48 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBFD21F9579; Wed, 16 Nov 2011 01:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B9GR8QO+sWm; Wed, 16 Nov 2011 01:41:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9621F9563; Wed, 16 Nov 2011 01:41:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D4885B1E00D; Wed, 16 Nov 2011 01:36:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111116093634.D4885B1E00D@rfc-editor.org> Date: Wed, 16 Nov 2011 01:36:34 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6425 on Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 09:41:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6425 Title: Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping Author: S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau Status: Standards Track Stream: IETF Date: November 2011 Mailbox: ssaxena@cisco.com, swallow@cisco.com, zali@cisco.com, adrian@olddog.co.uk, yasukawa.seisho@lab.ntt.co.jp, thomas.nadeau@ca.com Pages: 28 Characters: 68437 Updates: RFC4379 I-D Tag: draft-ietf-mpls-p2mp-lsp-ping-18.txt URL: http://www.rfc-editor.org/rfc/rfc6425.txt Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment. This document updates RFC 4379. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Nov 16 01:42:09 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AE21F959B; Wed, 16 Nov 2011 01:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.659 X-Spam-Level: X-Spam-Status: No, score=-104.659 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bya4mOdEf3gn; Wed, 16 Nov 2011 01:42:09 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9821F959C; Wed, 16 Nov 2011 01:42:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 03BCAB1E008; Wed, 16 Nov 2011 01:36:56 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111116093656.03BCAB1E008@rfc-editor.org> Date: Wed, 16 Nov 2011 01:36:56 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6426 on MPLS On-Demand Connectivity Verification and Route Tracing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 09:42:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6426 Title: MPLS On-Demand Connectivity Verification and Route Tracing Author: E. Gray, N. Bahadur, S. Boutros, R. Aggarwal Status: Standards Track Stream: IETF Date: November 2011 Mailbox: eric.gray@ericsson.com, nitinb@juniper.net, sboutros@cisco.com, raggarwa_1@yahoo.com Pages: 22 Characters: 46539 Updates: RFC4379 I-D Tag: draft-ietf-mpls-tp-on-demand-cv-07.txt URL: http://www.rfc-editor.org/rfc/rfc6426.txt Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. 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. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Nov 16 01:42:41 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EB321F95B8; Wed, 16 Nov 2011 01:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhimrk7PIe5M; Wed, 16 Nov 2011 01:42:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5D21F95AC; Wed, 16 Nov 2011 01:42:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 06582B1E00E; Wed, 16 Nov 2011 01:37:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111116093727.06582B1E00E@rfc-editor.org> Date: Wed, 16 Nov 2011 01:37:27 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6445 on Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 09:42:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6445 Title: Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author: T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed. Status: Standards Track Stream: IETF Date: November 2011 Mailbox: thomas.nadeau@ca.com, kkoushik@cisco.com, riza.cetin@alcatel.be Pages: 53 Characters: 101627 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-fastreroute-mib-21.txt URL: http://www.rfc-editor.org/rfc/rfc6445.txt This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Wed Nov 16 17:23:05 2011 Return-Path: <loa@pi.nu> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50DC1F0C58 for <mpls@ietfa.amsl.com>; Wed, 16 Nov 2011 17:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW72euMdXHG7 for <mpls@ietfa.amsl.com>; Wed, 16 Nov 2011 17:23:05 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 118401F0C4A for <mpls@ietf.org>; Wed, 16 Nov 2011 17:23:05 -0800 (PST) Received: from [130.129.17.40] (dhcp-1128.meeting.ietf.org [130.129.17.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id E199D2A8004; Thu, 17 Nov 2011 02:23:01 +0100 (CET) Message-ID: <4EC461F1.2070501@pi.nu> Date: Thu, 17 Nov 2011 09:22:57 +0800 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, "mpls-ads@tools.ietf.org" <mpls-ads@tools.ietf.org>, George Swallow <swallow@cisco.com>, Ross Callon <rcallon@juniper.net> References: <4EB02DBD.5060305@pi.nu> In-Reply-To: <4EB02DBD.5060305@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] poll on draft-fang-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 01:23:05 -0000 Working Group, this poll has ended and we have a new working group document. Could the authors please publish draft-ietf-mpls-tp-use-cases-and-design-00 Without any other changes than file name and dates relative to the draft that we polled! /Loa On 2011-11-02 01:34, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-fang-mpls-tp-use-cases-and-design an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Tue Nov 15. > > /Loa > for the mpls wg 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 loa@pi.nu Wed Nov 16 17:54:09 2011 Return-Path: <loa@pi.nu> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCE1F0C88; Wed, 16 Nov 2011 17:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD9PZl558EGP; Wed, 16 Nov 2011 17:54:03 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5C07D21F85AE; Wed, 16 Nov 2011 17:53:11 -0800 (PST) Received: from [130.129.17.40] (dhcp-1128.meeting.ietf.org [130.129.17.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id EA9382A8004; Thu, 17 Nov 2011 02:52:58 +0100 (CET) Message-ID: <4EC468F6.7030904@pi.nu> Date: Thu, 17 Nov 2011 09:52:54 +0800 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" <mpls@ietf.org> References: <4EB2C05C.5070809@pi.nu> In-Reply-To: <4EB2C05C.5070809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP <ccamp@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, pwe3@ietf.org Subject: Re: [mpls] [CCAMP] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 01:54:09 -0000 Working Group, this last call has ended. There has been comments. Can the authors work with the commenters to resolve the comments and send a mail to the mpls wg mailing list detailing how the comments has been addressed. /Loa for the mpls wg co-chairs On 2011-11-04 00:25, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-security-framework-02.txt. > > Please review the document and send comments to the mpls working > group mailing list (mpls@ietf.org). > > This working group last call ends on November 16th. > > /Loa > for the mpls wg co-charis > > -- 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 fu.xihua@zte.com.cn Wed Nov 16 18:21:26 2011 Return-Path: <fu.xihua@zte.com.cn> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471C111E80A3 for <mpls@ietfa.amsl.com>; Wed, 16 Nov 2011 18:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.86 X-Spam-Level: X-Spam-Status: No, score=-98.86 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb59snGpkygI for <mpls@ietfa.amsl.com>; Wed, 16 Nov 2011 18:21:25 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4914811E8081 for <mpls@ietf.org>; Wed, 16 Nov 2011 18:21:25 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690806486374; Thu, 17 Nov 2011 10:09:42 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 24024.806486374; Thu, 17 Nov 2011 10:21:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAH2L3PJ047682 for <mpls@ietf.org>; Thu, 17 Nov 2011 10:21:03 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: <OF7BC5A98E.49FA8918-ON4825794B.00066935-4825794B.000CEB3C@zte.com.cn> From: fu.xihua@zte.com.cn Date: Thu, 17 Nov 2011 10:21:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-17 10:21:05, Serialize complete at 2011-11-17 10:21:05 Content-Type: multipart/alternative; boundary="=_alternative 000CEB3C4825794B_=" X-MAIL: mse02.zte.com.cn pAH2L3PJ047682 Subject: [mpls] Open Issues in draft-fuxh-mpls-delay-loss-te-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 02:21:26 -0000 This is a multipart message in MIME format. --=_alternative 000CEB3C4825794B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgV29ya2luZyBHcm91cCwNCg0KV2Ugd291bGQgbGlrZSB0byBnZXQgY29tbWVudHMgZm9yIHRo ZSBmb2xsb3dpbmcgb3BlbiBpc3N1ZXMuDQoNCjEuIExhdGVuY3kgYW5kIGppdHRlciBvZiBOb2Rl DQpBZHZlcnRpc2luZyBub2RlIGxhdGVuY3kgbWF5IHJlc3VsdCBpbiBvc2NpbGxhdGlvbiByaXNr IGJlY2F1c2Ugb2YgcXVldWUgDQpkZWxheS4NCkF1dGhvcnMgb2YgdGhpcyBkcmFmdHMgaGF2ZSBl dmVyIGRpc2N1c3NlZCB0aGlzIGlzc3Vlcy4gV2UgZGVzY2lkZWQgZHJhZnRzIA0KaWdub3JlIHRo ZSBxdWV1aW5nIGRlbGF5IGZvciB0aGUgYmVuZWZpdCBvZiBzaW1wbGljaXR5LiANCk5vZGUgbGF0 ZW5jeSAoZS5nLiwgYSBmaXhlZCBvciBhdmVyYWdlL2FwcHJveGltYXRlIGxhdGVuY3kgKSBjYW4g YmUgDQppbmNsdWRlZCBpbiB0aGUgYWR2ZXJ0aXNlZCBsaW5rIGRlbGF5Lg0KDQoyLk9uZSBtYXhp bXVtIHRocmVzaG9sZCBjb3VsZCBiZSBjb25maWd1cmVkIHRvIGxpbmsuIElmIHRoZSBsaW5rIA0K cGVyZm9ybWFuY2UgZXhjZWVkcyB0aGUgdGhyZXNob2xkLCB0aGUgSUdQIHNob3VsZCBnZXQgdGhl IGFub21hbG91cyBzdGF0ZSANCm9mIHRoaXMgbGluay4NCkl0IG1heSByZXN1bHQgaW4gaGVhdnkg Y29uZmlndXJhdGlvbiB3b3JrLg0KDQozLkNvbXBvc2l0ZSBMaW5rIFBlcmZvcm1hbmNlIEFkdmVy dGlzZW1lbnQNCk9wdGlvbiAxOiBPbmx5IFRMViBmb3IgQ29tcG9zaXRlIExpbmsuIFRoZSBwZXJm b3JtYW5jZSBtYXkgYmUgdGhlIHJhbmdlLCANCmF2ZXJhZ2Ugb3IgbWF4aW11bSBsYXRlbmN5L2xv c3Mgb2YgYWxsIGNvbXBvbmVudCBsaW5rcy4NCk9wdGlvbiAyOiBCb3RoIGEgVExWIGZvciBlYWNo IGNvbXBvbmVudCBsaW5rLCBwbHVzIG9uZSBmb3IgdGhlIGJ1bmRsZSB3aXRoIA0KdGhlIGF2ZXJh Z2UuDQoNCjQuIEUyRSBsb3NzIGNvbXB1dGF0aW9uOiANClRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0 aGlzIGRyYWZ0IHNheSB0aGUgZW5kLXRvLWVuZCBwYXRoIGxvc3Mgc2hvdWxkIGJlIA0Kc3VtIG9m IGVhY2ggbGluay4gSXQgaXNuJ3QgY29ycmVjdC4gDQpXZSB3aWxsIGdpdmUgYSBsaXR0bGUgY2hh bmdlIGluIG5leHQgdmVyc2lvbiB0byBjbGFyaWZ5IHRoZSBlMmUgbG9zcyANCmNvbXB1dGF0aW9u IGlzIG11bHRpcGxpY2F0aW9uIG9mIGVhY2ggbGluayByYXRoZXIgdGhhbiBzdW0uDQppLmUuIHBh Y2tldCBsb3NzIG9mIGUyZSBwYXRoID0gMS0oMS1sb3NzcmF0ZV9MaW5rMSkqKDEtbG9zc3JhdGVf TGluazIpKqGtDQoqKDEtbG9zc3JhdGVfTGlua24pDQpBc3N1bWUgcGFja2V0IGxvc3MgaXMgMTAl IGZvciB0d28gaG9wcyBvZiBhIGxpbmsuIFRoZSBtZWFzdXJlbWVudHMgd2lsbCANCmNvbWUgdG8g MTklIHRvdGFsIHBhY2tldCBsb3NzLiBCZWNhdXNlIG9mIDEwJSBsb3NzIG9uIHRoZSBmaXJzdCBs aW5rIG9ubHkgDQo5MCUgcGFja2V0IHJlYWNoIHRoZSBzZWNvbmQgbGluayB3aGVyZSBhbm90aGVy IDEwJSBvZiA5MCUgYXJlIGxvc3QsIHdoaWNoIA0KaXMgOSUgb2YgdG90YWwgcGFja2V0cy4NCllv dSBtYXkgcmVmZXIgdG8gSVRVLVQgWS4xNTQxIDguMiBzZWN0aW9uLg0KDQpCZXN0IFJlZ2FyZHMs DQoNCkF1dGhvcnMNCg== --=_alternative 000CEB3C4825794B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFdvcmtpbmcgR3JvdXAsPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSB3b3VsZCBs aWtlIHRvIGdldCBjb21tZW50cyBmb3IgdGhlDQpmb2xsb3dpbmcgb3BlbiBpc3N1ZXMuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBMYXRlbmN5IGFu ZCBqaXR0ZXIgb2YgTm9kZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QWR2ZXJ0aXNpbmcgbm9kZSBsYXRlbmN5IG1heSByZXN1bHQNCmluIG9zY2lsbGF0aW9uIHJp c2sgYmVjYXVzZSBvZiBxdWV1ZSBkZWxheS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkF1dGhvcnMgb2YgdGhpcyBkcmFmdHMgaGF2ZSBldmVyIGRpc2N1c3NlZA0K dGhpcyBpc3N1ZXMuIFdlIGRlc2NpZGVkIGRyYWZ0cyBpZ25vcmUgdGhlIHF1ZXVpbmcgZGVsYXkg Zm9yIHRoZSBiZW5lZml0DQpvZiBzaW1wbGljaXR5LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPk5vZGUgbGF0ZW5jeSAoZS5nLiwgYSBmaXhlZCBvciBhdmVyYWdl L2FwcHJveGltYXRlDQpsYXRlbmN5ICkgY2FuIGJlIGluY2x1ZGVkIGluIHRoZSBhZHZlcnRpc2Vk IGxpbmsgZGVsYXkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4yLk9uZSBtYXhpbXVtIHRocmVzaG9sZCBjb3VsZCBiZSBjb25maWd1cmVkDQp0byBsaW5r LiBJZiB0aGUgbGluayBwZXJmb3JtYW5jZSBleGNlZWRzIHRoZSB0aHJlc2hvbGQsIHRoZSBJR1Ag c2hvdWxkDQpnZXQgdGhlIGFub21hbG91cyBzdGF0ZSBvZiB0aGlzIGxpbmsuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBtYXkgcmVzdWx0IGluIGhlYXZ5IGNv bmZpZ3VyYXRpb24NCndvcmsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4zLkNvbXBvc2l0ZSBMaW5rIFBlcmZvcm1hbmNlIEFkdmVydGlzZW1lbnQ8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9wdGlvbiAxOiBPbmx5IFRM ViBmb3IgQ29tcG9zaXRlIExpbmsuDQpUaGUgcGVyZm9ybWFuY2UgbWF5IGJlIHRoZSByYW5nZSwg YXZlcmFnZSBvciBtYXhpbXVtIGxhdGVuY3kvbG9zcyBvZiBhbGwNCmNvbXBvbmVudCBsaW5rcy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9wdGlvbiAyOiBCb3Ro IGEgVExWIGZvciBlYWNoIGNvbXBvbmVudA0KbGluaywgcGx1cyBvbmUgZm9yIHRoZSBidW5kbGUg d2l0aCB0aGUgYXZlcmFnZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjQuIEUyRSBsb3NzIGNvbXB1dGF0aW9uOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHNh eQ0KdGhlIGVuZC10by1lbmQgcGF0aCBsb3NzIHNob3VsZCBiZSBzdW0gb2YgZWFjaCBsaW5rLiBJ dCBpc24ndCBjb3JyZWN0Lg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5XZSB3aWxsIGdpdmUgYSBsaXR0bGUgY2hhbmdlIGluIG5leHQNCnZlcnNpb24gdG8gY2xh cmlmeSB0aGUgZTJlIGxvc3MgY29tcHV0YXRpb24gaXMgbXVsdGlwbGljYXRpb24gb2YgZWFjaCBs aW5rDQpyYXRoZXIgdGhhbiBzdW0uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5pLmUuIHBhY2tldCBsb3NzIG9mIGUyZSBwYXRoID0gMS0oMS1sb3NzcmF0ZV9MaW5r MSkqKDEtbG9zc3JhdGVfTGluazIpKqGtKigxLWxvc3NyYXRlX0xpbmtuKTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXNzdW1lIHBhY2tldCBsb3NzIGlzIDEwJSBm b3IgdHdvIGhvcHMNCm9mIGEgbGluay4gVGhlIG1lYXN1cmVtZW50cyB3aWxsIGNvbWUgdG8gMTkl IHRvdGFsIHBhY2tldCBsb3NzLiBCZWNhdXNlDQpvZiAxMCUgbG9zcyBvbiB0aGUgZmlyc3QgbGlu ayBvbmx5IDkwJSBwYWNrZXQgcmVhY2ggdGhlIHNlY29uZCBsaW5rIHdoZXJlDQphbm90aGVyIDEw JSBvZiA5MCUgYXJlIGxvc3QsIHdoaWNoIGlzIDklIG9mIHRvdGFsIHBhY2tldHMuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3UgbWF5IHJlZmVyIHRvIElUVS1U IFkuMTU0MSA4LjIgc2VjdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkJlc3QgUmVnYXJkcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkF1dGhvcnM8L2ZvbnQ+DQo= --=_alternative 000CEB3C4825794B_=-- From wwwrun@rfc-editor.org Wed Nov 16 23:18:15 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F3221F96C9; Wed, 16 Nov 2011 23:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIfpV5uhnUuy; Wed, 16 Nov 2011 23:18:15 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 021E821F96C8; Wed, 16 Nov 2011 23:18:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9FA84B1E002; Wed, 16 Nov 2011 23:12:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111117071258.9FA84B1E002@rfc-editor.org> Date: Wed, 16 Nov 2011 23:12:58 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6427 on MPLS Fault Management Operations, Administration, and Maintenance (OAM) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 07:18:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6427 Title: MPLS Fault Management Operations, Administration, and Maintenance (OAM) Author: G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward Status: Standards Track Stream: IETF Date: November 2011 Mailbox: swallow@cisco.com, annamaria.fulignoli@ericsson.com, martin.vigoureux@alcatel-lucent.com, sboutros@cisco.com, dward@juniper.net Pages: 17 Characters: 34069 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-fault-07.txt URL: http://www.rfc-editor.org/rfc/rfc6427.txt This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Nov 16 23:18:33 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8B1F0CAE; Wed, 16 Nov 2011 23:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWh+pm-1vG1c; Wed, 16 Nov 2011 23:18:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E06DA1F0CA3; Wed, 16 Nov 2011 23:18:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 81A00B1E005; Wed, 16 Nov 2011 23:13:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111117071316.81A00B1E005@rfc-editor.org> Date: Wed, 16 Nov 2011 23:13:16 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6428 on Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 07:18:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6428 Title: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile Author: D. Allan, Ed., G. Swallow Ed., J. Drake Ed. Status: Standards Track Stream: IETF Date: November 2011 Mailbox: david.i.allan@ericsson.com, swallow@cisco.com, jdrake@juniper.net Pages: 21 Characters: 44293 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-cc-cv-rdi-06.txt URL: http://www.rfc-editor.org/rfc/rfc6428.txt Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section. This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Nov 16 23:19:14 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804D41F0CC3; Wed, 16 Nov 2011 23:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.713 X-Spam-Level: X-Spam-Status: No, score=-104.713 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgFXiZuz-iUg; Wed, 16 Nov 2011 23:19:14 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id EEE521F0CBE; Wed, 16 Nov 2011 23:19:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 97D0EB1E002; Wed, 16 Nov 2011 23:13:57 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111117071357.97D0EB1E002@rfc-editor.org> Date: Wed, 16 Nov 2011 23:13:57 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6435 on MPLS Transport Profile Lock Instruct and Loopback Functions X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 07:19:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6435 Title: MPLS Transport Profile Lock Instruct and Loopback Functions Author: S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed. Status: Standards Track Stream: IETF Date: November 2011 Mailbox: sboutros@cisco.com, msiva@cisco.com, raggarwa_1@yahoo.com, martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn Pages: 12 Characters: 23862 Updates: RFC6371 I-D Tag: draft-ietf-mpls-tp-li-lb-08.txt URL: http://www.rfc-editor.org/rfc/rfc6435.txt Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Thu Nov 17 01:34:10 2011 Return-Path: <loa@pi.nu> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD321F9938 for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 01:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGJ8an3SdlW1 for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 01:34:09 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEA821F9935 for <mpls@ietf.org>; Thu, 17 Nov 2011 01:34:09 -0800 (PST) Received: from [130.129.17.40] (dhcp-1128.meeting.ietf.org [130.129.17.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 034742A8004; Thu, 17 Nov 2011 10:34:04 +0100 (CET) Message-ID: <4EC4D506.4040203@pi.nu> Date: Thu, 17 Nov 2011 17:33:58 +0800 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: RFC Editor <rfc-editor@rfc-editor.org>, Pearl Liang via RT <iana-questions@iana.org>, Michelle Cotton <michelle.cotton@icann.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "mpls-ads@tools.ietf.org" <mpls-ads@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] 16 new RFCs since Quebac X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 09:34:10 -0000 Working Group, we have now published all the RFCs that the working group (chairs) promised to deliver as RFCs (first set of MPLS-TP RFCs) before the of the SG15 meeting in December. We had 10 new RFCs when we came into meeting, in the week we have cleared 6 more RFCs (not all of them MPLS-TP), in total 16 new RFCs: RFC 6425 Title: Detecting Data-Plane Failures in Point- to-Multipoint MPLS - Extensions to LSP Ping RFC 6426 Title: MPLS On-Demand Connectivity Verification and Route Tracing RFC 6427 Title: MPLS Fault Management Operations, Administration, and Maintenance (OAM) RFC 6428 Title: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile RFC 6435 Title: MPLS Transport Profile Lock Instruct and Loopback Functions RFC 6445 Title: Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute The working group chairs would like to thank the RFC Editor, the IANA, all the co-authors and our ADs for their consistent, hard and useful work! Loa George and Ross mpls wg 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 stephane.litkowski@orange.com Thu Nov 17 06:38:14 2011 Return-Path: <stephane.litkowski@orange.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D5921F99AD for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 06:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KR8ydCGLdTi for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 06:38:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EF04121F99B6 for <mpls@ietf.org>; Thu, 17 Nov 2011 06:38:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 130DC3B497C for <mpls@ietf.org>; Thu, 17 Nov 2011 15:38:12 +0100 (CET) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8EA704C024 for <mpls@ietf.org>; Thu, 17 Nov 2011 15:38:11 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Nov 2011 15:38:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA536.87C5BD81" Date: Thu, 17 Nov 2011 15:38:05 +0100 Message-ID: <31895_1321540691_4EC51C53_31895_8302_2_4FC3556A36EE3646A09DAA60429F5335074DF38F@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about RFC4090 : Merging Detours using the Path-Specific Method Thread-Index: AcylNiuoNH3ly4F3Q++N9D+eMf0snQ== From: <stephane.litkowski@orange.com> To: <mpls@ietf.org> X-OriginalArrivalTime: 17 Nov 2011 14:38:11.0480 (UTC) FILETIME=[87F68980:01CCA536] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.17.131516 Subject: [mpls] Question about RFC4090 : Merging Detours using the Path-Specific Method X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 14:38:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA536.87C5BD81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have few questions about the Merge Point behavior when detour object is used. If we consider the following LSP : R1 - R2 - R3 - R4 protected using FRR one to one, node protection, detour object used. R1 computes a detour path : R1 - R5 - R6 - R3 - R4 R2 computes a detour path : R2 - R1 - R5 - R6 - R7 - R4=20 =20 We can see that there is a potential issue as R1 detour is using R3 which need to be avoided by R2 detour. =20 RFC says that :=20 " 2. From the remaining set of Detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid. =20 " =20 In this case, we except that detour be signaled by R1 as merge point should be : R1 - R5 - R6 - R7 - R4 instead of the one computed. But I can be clear exactly on what's happening if : R1 detour is operational first, so R1 signals his detour along the path he computed, and then R1 receives path msg from R2 with detour object to avoid R3. Need R1 to break the detour signaled and signal the new one as the path signaled doesn't fit the condition ? "eliminate from consideration those that traverse nodes that others want to avoid." =20 After some tests on one vendor equipment, we saw some non deterministic behavior : - if R1 signals detour first, R2 receives a path Err from R1 when it tries to signal his own : path can't be merged - if R2 signals detour first, R1 merge his own with R2 detour already signaled. =20 =20 Why not always using the condition 3 as if there was no remaining path ? : "3. If several still remain, which one to forward is a local decision. If none remain, then the MP MAY try to find a new route that avoids all nodes that merging Detour Paths want to avoid; it will forward a Path message with that ERO. ", this would permit to always have a detour available with optimal protection. =20 Can someone clarify for me the expected behavior ? =20 =20 Thanks, =20 =20 ---- Stephane =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorization. If you have received this email in error,= please notify the sender and delete this message and its attachments. As e= mails may be altered, France Telecom - Orange shall not be liable if this m= essage was modified, changed or falsified. Thank you. ------_=_NextPart_001_01CCA536.87C5BD81 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.21264" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D616442314-17112011>Hi=20 all,</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D616442314-17112011></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D616442314-17112011>I have fe= w questions=20 about the Merge Point behavior when detour object is used.</SPAN></FONT></D= IV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D616442314-17112011>If we con= sider the=20 following LSP : R1 - R2 - R3 - R4 protected using FRR one to one, node=20 protection, detour object used.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D616442314-17112011>R1 comput= es a detour=20 path : R1 - R5 - R6 - R3 - R4</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D616442314-17112011>R2 comput= es a detour=20 path : R2 - R1 - R5 - R6 - R7 - R4 </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>We can se= e that=20 there is a potential issue as R1 detour is using R3 which need to be avoide= d by=20 R2 detour.</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>RFC says = that :=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2>"</FONT></SPAN></DIV>     2. From the remainin= g set=20 of Detour Path messages, eliminate=20 from<BR>        consideration those that= =20 traverse nodes that others want to<BR>      &= nbsp;=20 avoid.<BR> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2>"</FONT></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>In this c= ase, we=20 except that detour be signaled by R1 as merge point should be : R1 - R5 - R= 6 -=20 R7 - R4 instead of the one computed.</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>But I can= be clear=20 exactly on what's happening if : R1 detour is operational first, so R1 sign= als=20 his detour along the path he computed, and then R1 receives path msg from R= 2=20 with detour object to avoid R3. Need R1 to break the detour signaled and si= gnal=20 the new one as the path signaled doesn't fit the condition ? "<FONT=20 face=3D"Times New Roman" size=3D3>eliminate from consideration those that t= raverse=20 nodes that others want to avoid.</FONT>"</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>After som= e tests on=20 one vendor equipment, we saw some non deterministic behavior=20 :</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>- if R1 s= ignals=20 detour first, R2 receives a path Err from R1 when it tries to signal his ow= n :=20 path can't be merged</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>- if R2 s= ignals=20 detour first, R1 merge his own with R2 detour already=20 signaled.</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>Why not a= lways using=20 the condition 3 as if there was no remaining path ? : "<FONT size=3D3>= 3. If=20 several still remain, which one to forward is a=20 local<BR>        decision.  If none= =20 remain, then the MP MAY try to find a=20 new<BR>        route that avoids all nod= es=20 that merging Detour Paths want to<BR>      &n= bsp;=20 avoid; it will forward a Path message with that ERO.<BR>",</FONT><FONT size= =3D2>=20 this would permit to always have a detour available with optimal=20 protection.</FONT></FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial></FONT></SPAN>&nbs= p;</DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial size=3D2>Can someo= ne clarify=20 for me the expected behavior ?</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2>Thanks,</FONT></SPAN></DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2>----</FONT></SPAN></DIV> <DIV align=3Dleft><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2>Stephane</FONT></SPAN></DIV> <DIV align=3Dleft><SPAN class=3D616442314-17112011><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV><PRE>___________________________________= ___________________________________________________________________________= ___________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorization. If you have received this email in error,= please notify the sender and delete this message and its attachments. As e= mails may be altered, France Telecom - Orange shall not be liable if this m= essage was modified, changed or falsified. Thank you. </PRE></BODY></HTML> ------_=_NextPart_001_01CCA536.87C5BD81-- From ice@cisco.com Thu Nov 17 07:34:54 2011 Return-Path: <ice@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A021F9A67 for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 07:34:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d9+DzyNJeTE for <mpls@ietfa.amsl.com>; Thu, 17 Nov 2011 07:34:53 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 814DC21F95F0 for <mpls@ietf.org>; Thu, 17 Nov 2011 07:34:53 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-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 pAHFYqc6009294 for <mpls@ietf.org>; Thu, 17 Nov 2011 16:34:52 +0100 (CET) Received: from ams3-vpn-dhcp4889.cisco.com (ams3-vpn-dhcp4889.cisco.com [10.61.83.24]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAHFYjEX006135; Thu, 17 Nov 2011 16:34:47 +0100 (CET) From: IJsbrand Wijnands <ice@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 23:34:50 +0800 Message-Id: <CB27A6F3-E74A-4FD3-92AA-35C03C39B4D9@cisco.com> To: Quintin Zhao <quintin.zhao@huawei.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org Subject: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Nov 2011 15:34:54 -0000 Dear Quintin, During the MPLS WG presentation you asked for feedback on the different = options to signal the MT-ID. See below; I've worked on this with Kamran Raza and we came to the conclusion there = is really only one good option to signal the MT-ID, and that is within = the FEC. This is true for LDP, and very much true for mLDP. We = documented the preferred solution for mLDP, which would also apply to = LDP. See;=20 draft-iwijnand-mpls-mldp-multi-topology-00.txt Below is a summary of the reasons; - The LDP spec allows for multiple FEC's to be signaled in a single = label mapping. If you don't add the MT-ID into the FEC its becomes = difficult to match the MT-ID the right FEC, so you can't mix and match = FEC elements, for example for IPv4 and IPv6. For the same reason Address = Family is part of the FEC. - The MT-ID is something that is directly related to the Prefix/Root = address encoded in the FEC, so it makes sense to combine them. - LDP messages and specifications that use FEC (e.g. Typed Wildcard, End-of-LIB) will automatically be extended for MT. There is no need to = specify for which messages (map, withdraw, release etc..) the MT-ID = applies. - If you are doing mLDP Live-Live using MTR (or MRT) and the 2 LSPs = merge/overlap for some reason, you potentially duplicate the traffic and = prevent live-live from working. For that reason the MT-ID MUST be in the = FEC to make sure the 2 LSPs are unique and will never accidentally = merge. - With mLDP a router may receive label mappings from multiple downstream = routers, each of them including a different MT-ID. At that point you = would need come up with some selection logic on which MT-ID you need to = select and signal upstream. If the MT-ID is part of the FEC, you don't = have that problem. Thx, Ice & Kamran From lufang@cisco.com Fri Nov 18 03:46:04 2011 Return-Path: <lufang@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C334E21F8AAC; Fri, 18 Nov 2011 03:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmQ0gM7dnchW; Fri, 18 Nov 2011 03:46:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE521F8AAA; Fri, 18 Nov 2011 03:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1437; q=dns/txt; s=iport; t=1321616761; x=1322826361; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=rUKAEFh4jIpFvy8KpGrnZZbuabwpEL+30U2n3583CwU=; b=mj4/1KyDwAURtiovhTjjTsoFiwVxQhWCgKg7X+iXpHup84+06a4mbZlx vHaVYPo13PLB3dG7iYOFsz7LjxfvkoObCtSPU7F3ikF6ezrBwKiOjlK9o m4EgoYIKyNrYgOAx74zAX8wNRnrP/Sny8MK3GmYPdnWxUCj8XQ9cPat8c 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYAALxExk6tJV2c/2dsb2JhbABCmhGQFIEFgXIBAQEEAQEBDwEdPgsMAgQBCBEEAQEBCgYXAQcaDAEeCQgBAQQBEggah2mYCAGeUwQCiTJjBIdmMYoDh2WMWg X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; d="scan'208";a="37219326" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 18 Nov 2011 11:46:00 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAIBk0en008661; Fri, 18 Nov 2011 11:46:00 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 05:46:00 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 05:45:59 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25AE430E@XMB-RCD-201.cisco.com> In-Reply-To: <4EC468F6.7030904@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] mpls wg last call ondraft-ietf-mpls-tp-security-framework Thread-Index: Acyky9CNdb3Csm4kRSmbE1oEU/1xhABG9NOR From: "Luyuan Fang (lufang)" <lufang@cisco.com> To: <loa@pi.nu>, <mpls@ietf.org> X-OriginalArrivalTime: 18 Nov 2011 11:46:00.0144 (UTC) FILETIME=[A46B8500:01CCA5E7] Cc: ccamp@ietf.org, ahmpls-tp@lists.itu.int, pwe3@ietf.org Subject: Re: [mpls] [CCAMP] mpls wg last call ondraft-ietf-mpls-tp-security-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Nov 2011 11:46:04 -0000 Loa, Will do.=20 Thx, Luyuan ----- Original Message ----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, November 16, 2011 07:52 PM To: mpls@ietf.org <mpls@ietf.org> Cc: CCAMP <ccamp@ietf.org>; MPLS-TP ad hoc team = <ahmpls-tp@lists.itu.int>; pwe3@ietf.org <pwe3@ietf.org> Subject: Re: [mpls] [CCAMP] mpls wg last call = ondraft-ietf-mpls-tp-security-framework Working Group, this last call has ended. There has been comments. Can the authors work with the commenters to resolve the comments and send a mail to the mpls wg mailing list detailing how the comments has been addressed. /Loa for the mpls wg co-chairs On 2011-11-04 00:25, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-security-framework-02.txt. > > Please review the document and send comments to the mpls working > group mailing list (mpls@ietf.org). > > This working group last call ends on November 16th. > > /Loa > for the mpls wg co-charis > > --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lizho.jin@gmail.com Fri Nov 18 07:24:49 2011 Return-Path: <lizho.jin@gmail.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418521F8922 for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 07:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSG8K9WeZvLu for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 07:24:48 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8621F89B8 for <mpls@ietf.org>; Fri, 18 Nov 2011 07:24:47 -0800 (PST) Received: by ghrr14 with SMTP id r14so841773ghr.31 for <mpls@ietf.org>; Fri, 18 Nov 2011 07:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=9sq/YQj612PINaYSIqE5o3kkX2QEck3gw6NxBMQ+sOg=; b=aVkbAe8KDcfL5i+mjX2TqRDgG9MF9LmMLEhAKLywRAFYk9BBDMLVff2TCESWMdeN/C Xta/pfQwFd8NA1/JGcOjrgRukhuiPDfP09zRVaMhXSDQjAiQxiHZ8i/4QRytMfJmKzSE myLc3liKx4VuKc+MYgoF6X4/7HDIl/wkiRbcE= MIME-Version: 1.0 Received: by 10.229.3.133 with SMTP id 5mr375871qcn.212.1321629887264; Fri, 18 Nov 2011 07:24:47 -0800 (PST) Received: by 10.224.67.81 with HTTP; Fri, 18 Nov 2011 07:24:47 -0800 (PST) Date: Fri, 18 Nov 2011 23:24:47 +0800 Message-ID: <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com> From: Lizhong Jin <lizho.jin@gmail.com> To: ice@cisco.com, quintin.zhao@huawei.com Content-Type: multipart/alternative; boundary=001636833ee8f4778204b203ef4e Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Nov 2011 15:24:49 -0000 --001636833ee8f4778204b203ef4e Content-Type: text/plain; charset=ISO-8859-1 Hi, I agree with Ice's summary. I don't think it is very difficult to choose the option of signaling MT-ID within FEC. Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 17 Nov 2011 23:34:50 +0800 > From: IJsbrand Wijnands <ice@cisco.com> > To: Quintin Zhao <quintin.zhao@huawei.com> > Cc: mpls@ietf.org > Subject: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 > Message-ID: <CB27A6F3-E74A-4FD3-92AA-35C03C39B4D9@cisco.com> > Content-Type: text/plain; charset=us-ascii > > Dear Quintin, > > During the MPLS WG presentation you asked for feedback on the different > options to signal the MT-ID. See below; > > I've worked on this with Kamran Raza and we came to the conclusion there > is really only one good option to signal the MT-ID, and that is within the > FEC. This is true for LDP, and very much true for mLDP. We documented the > preferred solution for mLDP, which would also apply to LDP. See; > > draft-iwijnand-mpls-mldp-multi-topology-00.txt > > Below is a summary of the reasons; > > - The LDP spec allows for multiple FEC's to be signaled in a single label > mapping. If you don't add the MT-ID into the FEC its becomes difficult to > match the MT-ID the right FEC, so you can't mix and match FEC elements, for > example for IPv4 and IPv6. For the same reason Address Family is part of > the FEC. > > - The MT-ID is something that is directly related to the Prefix/Root > address encoded in the FEC, so it makes sense to combine them. > > - LDP messages and specifications that use FEC (e.g. Typed Wildcard, > End-of-LIB) will automatically be extended for MT. There is no need to > specify for which messages (map, withdraw, release etc..) the MT-ID applies. > > - If you are doing mLDP Live-Live using MTR (or MRT) and the 2 LSPs > merge/overlap for some reason, you potentially duplicate the traffic and > prevent live-live from working. For that reason the MT-ID MUST be in the > FEC to make sure the 2 LSPs are unique and will never accidentally merge. > > - With mLDP a router may receive label mappings from multiple downstream > routers, each of them including a different MT-ID. At that point you would > need come up with some selection logic on which MT-ID you need to select > and signal upstream. If the MT-ID is part of the FEC, you don't have that > problem. > > > Thx, > > Ice & Kamran > > > ------------------------------ > > _______________________________________________ --001636833ee8f4778204b203ef4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi,</div> <div>I agree with Ice's summary. I don't think it is very difficult= to choose the option of signaling MT-ID within FEC.</div> <div>=A0</div> <div>Thanks</div> <div>Lizhong</div> <div>=A0</div> <div><br>=A0</div> <div class=3D"gmail_quote"> <blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex= ; PADDING-LEFT: 1ex" class=3D"gmail_quote">------------------------------<b= r><br>Message: 2<br>Date: Thu, 17 Nov 2011 23:34:50 +0800<br>From: IJsbrand= Wijnands <<a href=3D"mailto:ice@cisco.com">ice@cisco.com</a>><br> To: Quintin Zhao <<a href=3D"mailto:quintin.zhao@huawei.com">quintin.zha= o@huawei.com</a>><br>Cc: <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org<= /a><br>Subject: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01<br= > Message-ID: <<a href=3D"mailto:CB27A6F3-E74A-4FD3-92AA-35C03C39B4D9@cisc= o.com">CB27A6F3-E74A-4FD3-92AA-35C03C39B4D9@cisco.com</a>><br>Content-Ty= pe: text/plain; charset=3Dus-ascii<br><br>Dear Quintin,<br><br>During the M= PLS WG presentation you asked for feedback on the different options to sign= al the MT-ID. See below;<br> <br>I've worked on this with Kamran Raza and we came to the conclusion = there is really only one good option to signal the MT-ID, and that is withi= n the FEC. This is true for LDP, and very much true for mLDP. We documented= the preferred solution for mLDP, which would also apply to LDP. See;<br> <br>draft-iwijnand-mpls-mldp-multi-topology-00.txt<br><br>Below is a summar= y of the reasons;<br><br>- The LDP spec allows for multiple FEC's to be= signaled in a single label mapping. If you don't add the MT-ID into th= e FEC its becomes difficult to match the MT-ID the right FEC, so you can= 9;t mix and match FEC elements, for example for IPv4 and IPv6. For the same= reason Address Family is part of the FEC.<br> <br>- The MT-ID is something that is directly related to the Prefix/Root ad= dress encoded in the FEC, so it makes sense to combine them.<br><br>- LDP m= essages and specifications that use FEC (e.g. Typed Wildcard,<br>End-of-LIB= ) will automatically be extended for MT. There is no need to specify for wh= ich messages (map, withdraw, release etc..) the MT-ID applies.<br> <br>- If you are doing mLDP Live-Live using MTR (or MRT) and the 2 LSPs mer= ge/overlap for some reason, you potentially duplicate the traffic and preve= nt live-live from working. For that reason the MT-ID MUST be in the FEC to = make sure the 2 LSPs are unique and will never accidentally merge.<br> <br>- With mLDP a router may receive label mappings from multiple downstrea= m routers, each of them including a different MT-ID. At that point you woul= d need come up with some selection logic on which MT-ID you need to select = and signal upstream. If the MT-ID is part of the FEC, you don't have th= at problem.<br> <br><br>Thx,<br><br>Ice & Kamran<br><br><br>---------------------------= ---<br><br>_______________________________________________</blockquote></di= v> --001636833ee8f4778204b203ef4e-- From vishwas.ietf@gmail.com Fri Nov 18 13:21:45 2011 Return-Path: <vishwas.ietf@gmail.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037191F0C64 for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 13:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.97 X-Spam-Level: X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-pKXPuSltR2 for <mpls@ietfa.amsl.com>; Fri, 18 Nov 2011 13:21:44 -0800 (PST) Received: from mail-dy0-f44.google.com (mail-dy0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFC11F0C38 for <mpls@ietf.org>; Fri, 18 Nov 2011 13:21:43 -0800 (PST) Received: by dyl37 with SMTP id 37so353853dyl.31 for <mpls@ietf.org>; Fri, 18 Nov 2011 13:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a4TJTpG0/hrFXqYdHDFZIMJ1WSNqXxhMhpXCWBc8RmI=; b=pkze0i3d+OfUC0IOS6zx0pQfpIVgdeztHYMWADjRaK9WRJyy605ESWAqlQwEFH5bll XgejqpHRxgf+Kd+hNmIqgMWD7g6Gn0hKZNn9WMx9HR4zBhz53iYOQPFNguHDnhTESYG7 UAexnUHnRzWFYxtiHXgxVJ8Ah8elPYJVABEf8= MIME-Version: 1.0 Received: by 10.182.41.100 with SMTP id e4mr1078101obl.63.1321651302590; Fri, 18 Nov 2011 13:21:42 -0800 (PST) Received: by 10.182.150.73 with HTTP; Fri, 18 Nov 2011 13:21:42 -0800 (PST) In-Reply-To: <OF7BC5A98E.49FA8918-ON4825794B.00066935-4825794B.000CEB3C@zte.com.cn> References: <OF7BC5A98E.49FA8918-ON4825794B.00066935-4825794B.000CEB3C@zte.com.cn> Date: Fri, 18 Nov 2011 13:21:42 -0800 Message-ID: <CAOyVPHR_XhOfAeErseCEXscXrEJv9xo0pJ0ENZzp22k7G4twxw@mail.gmail.com> From: Vishwas Manral <vishwas.ietf@gmail.com> To: fu.xihua@zte.com.cn Content-Type: multipart/alternative; boundary=f46d0444eb9568695304b208ec0c Cc: mpls@ietf.org Subject: Re: [mpls] Open Issues in draft-fuxh-mpls-delay-loss-te-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Nov 2011 21:21:45 -0000 --f46d0444eb9568695304b208ec0c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Fu, 3.Composite Link Performance Advertisement > Option 1: Only TLV for Composite Link. The performance may be the range, > average or maximum latency/loss of all component links. > Option 2: Both a TLV for each component link, plus one for the bundle wit= h > the average. > If we are sending for each component why do we need to send the average at all. Any device can easily calculate the average. Though in my view Average is of no use at all. > > 4. E2E loss computation: > The latest version of this draft say the end-to-end path loss should be > sum of each link. It isn't correct. > We will give a little change in next version to clarify the e2e loss > computation is multiplication of each link rather than sum. > i.e. packet loss of e2e path =3D > 1-(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossrate_Linkn) > Assume packet loss is 10% for two hops of a link. The measurements will > come to 19% total packet loss. Because of 10% loss on the first link only > 90% packet reach the second link where another 10% of 90% are lost, which > is 9% of total packets. > You may refer to ITU-T Y.1541 8.2 section. > Yes if it is percentge or ratio, we need to use the mechanism as defined in ITU draft. If its actual packets, then we can directly use the sum. Thanks, Vishwas --f46d0444eb9568695304b208ec0c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Fu,<br><br> <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><font face=3D"sans-serif" size= =3D"2">3.Composite Link Performance Advertisement</font> <br><font face=3D"= sans-serif" size=3D"2">Option 1: Only TLV for Composite Link. The performan= ce may be the range, average or maximum latency/loss of all component links= .</font> <br> <font face=3D"sans-serif" size=3D"2">Option 2: Both a TLV for each componen= t link, plus one for the bundle with the average.</font> <br></blockquote> <div>If we are sending for each component why do we need to send the averag= e at all. Any device can easily calculate the average. Though in my view Av= erage is of no use at all.</div> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><font face=3D"sans-serif" si= ze=3D"2">4. E2E loss computation: </font><br><font face=3D"sans-serif" size= =3D"2">The latest version of this draft say the end-to-end path loss should= be sum of each link. It isn't correct. </font><br> <font face=3D"sans-serif" size=3D"2">We will give a little change in next v= ersion to clarify the e2e loss computation is multiplication of each link r= ather than sum.</font> <br><font face=3D"sans-serif" size=3D"2">i.e. packet= loss of e2e path =3D 1-(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossra= te_Linkn)</font> <br> <font face=3D"sans-serif" size=3D"2">Assume packet loss is 10% for two hops= of a link. The measurements will come to 19% total packet loss. Because of= 10% loss on the first link only 90% packet reach the second link where ano= ther 10% of 90% are lost, which is 9% of total packets.</font> <br> <font face=3D"sans-serif" size=3D"2">You may refer to ITU-T Y.1541 8.2 sect= ion.</font> <br></blockquote> <div>Yes if it is percentge or ratio, we need to use the mechanism as defin= ed in ITU draft. If its actual packets, then we can directly use the sum.</= div> <div>=A0</div> <div>Thanks,</div> <div>Vishwas</div></div> --f46d0444eb9568695304b208ec0c-- From erosen@cisco.com Mon Nov 21 08:54:41 2011 Return-Path: <erosen@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5980F21F8C67 for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 08:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TORU-VqsWpnA for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 08:54:37 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D5E3F21F8C65 for <mpls@ietf.org>; Mon, 21 Nov 2011 08:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1959; q=dns/txt; s=iport; t=1321894477; x=1323104077; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=1xcZPkvfG/HZKeheMISAy2eV+y+UxEbE1XihoUBJDmY=; b=I5UeL2DKGDqDvcEP4zp3oB+VHtfJroBDEugDoJd69UIQ86JDrkuDV8O0 B8EjPfdUl/34T/TMrSt7hNg6Ppz/66LBgojF2zRDpcnehVkF42YgSTWp+ cdSNqnuu9HdsAoI3wDBjvDqSoB9kYaSihE13OsI/DG5PwTCJBBIs0VO0N o=; X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="60161694" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Nov 2011 16:54:35 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pALGsZmv001463; Mon, 21 Nov 2011 16:54:35 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id pALGsYCn024621; Mon, 21 Nov 2011 11:54:34 -0500 To: Lizhong Jin <lizho.jin@gmail.com> In-reply-to: Your message of Fri, 18 Nov 2011 23:24:47 +0800. <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com> Date: Mon, 21 Nov 2011 11:54:34 -0500 Message-ID: <24620.1321894474@erosen-linux> From: Eric Rosen <erosen@cisco.com> Cc: mpls@ietf.org, ice@cisco.com, quintin.zhao@huawei.com Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 16:54:41 -0000 I also prefer the encoding where the MT-ID is encoded as part of each FEC element. In LDP, a Label Mapping Message creates a mapping from each of the included FEC elements to a label. In a single topology, the FEC element is an address prefix, and the mapping is from a prefix to a label. In a multitopology network, the mapping is not from a prefix to a label, it's from a <prefix, MT-ID> ordered pair to a label. So if we want to maintain the idea that LDP sets up mappings from FEC elements to label, we have to treat the <prefix, MT-ID> ordered pair as a FEC element. In general, extensions to LDP have retained the concept that one should be able to map from FEC element to label, and we should try not to depart from that paradigm. Many LDP features are specified in terms of FEC elements, and most of the LDP specs (and implementations) assume that you can look up a FEC element to find the corresponding LSP. The only argument I've heard in favor of the other options is the following: An LDP message may contain multiple FEC elements. But there is no need to have a single LDP message that contains FEC elements from different topologies. Therefore the most efficient way of encoding the message is to include the MTid just once per message, in its own TLV. This is a much more efficient encoding than you get by repeating the MT-ID in every FEC element. This argument does point out a disadvantage of this option; it isn't the option that results in the shortest messages. But I don't think this factor outweighs the advantages of maintaining the ability to map from a FEC element to a label. Maintaining the proper semantics is more important than shortening the message size. (One could also argue that there may well be cases where it is convenient to assign the same label to prefixes from different topologies; think of cases where the label assigned is explicit null.) From akatlas@gmail.com Mon Nov 21 09:11:13 2011 Return-Path: <akatlas@gmail.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AD21F8BB5 for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 09:11:13 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oxnI7FntPez for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 09:11:08 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4721F8BA7 for <mpls@ietf.org>; Mon, 21 Nov 2011 09:11:08 -0800 (PST) Received: by ggnp4 with SMTP id p4so204315ggn.31 for <mpls@ietf.org>; Mon, 21 Nov 2011 09:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xmI6diZaHiJ8jmyv8/tZaYgOnG6mNiVgjeZ5ejXGzHw=; b=h5+iIuF3TfoSD0WnESc5x23DuKXYDk+DPmiopLJpTvr7RHkHmKE827tob5+2FaGM6j fBS5gV0rEqoB91KExHPLZEnt/PuXfoIqQd1RPNbyNNcJpCIYBoXUDiH7whiN9fCpo6rG v56KCK8QxWrigT6GPT2oDLZN7LKyCTMLnt2v8= MIME-Version: 1.0 Received: by 10.50.135.40 with SMTP id pp8mr15609999igb.1.1321895465647; Mon, 21 Nov 2011 09:11:05 -0800 (PST) Received: by 10.50.184.229 with HTTP; Mon, 21 Nov 2011 09:11:05 -0800 (PST) In-Reply-To: <24620.1321894474@erosen-linux> References: <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com> <24620.1321894474@erosen-linux> Date: Mon, 21 Nov 2011 12:11:05 -0500 Message-ID: <CAG4d1re_2E98NYch=f6YxoCQRw3nieoJ5xj6AOaNg1mKsHmZNw@mail.gmail.com> From: Alia Atlas <akatlas@gmail.com> To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ice@cisco.com, quintin.zhao@huawei.com, Lizhong Jin <lizho.jin@gmail.com> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 17:11:13 -0000 I am also strongly in favor of having the MT-ID encoded as part of each FEC element. The idea of specifying address families that include MT-ID seems a particularly functional way of doing so. I also have a case where it makes perfect sense to include multiple FEC/Label bindings in a single message where each FEC refers to a different MT-ID. This is for MRT fast-reroute, where one may want to send a FEC for the loopback address with the default topology as well as FECs for the loopback address on the blue MRT topology and on the red MRT topology. Alia On Mon, Nov 21, 2011 at 11:54 AM, Eric Rosen <erosen@cisco.com> wrote: > > I also prefer the encoding where the MT-ID is encoded as part of each FEC > element. =A0In LDP, a Label Mapping Message creates a mapping from each o= f the > included FEC elements to a label. =A0In a single topology, the FEC elemen= t is > an address prefix, and the mapping is from a prefix to a label. =A0In a > multitopology network, the mapping is not from a prefix to a label, it's > from a <prefix, MT-ID> ordered pair to a label. =A0So if we want to maint= ain > the idea that LDP sets up mappings from FEC elements to label, we have to > treat the <prefix, MT-ID> ordered pair as a FEC element. > > In general, extensions to LDP have retained the concept that one should b= e > able to map from FEC element to label, and we should try not to depart fr= om > that paradigm. =A0Many LDP features are specified in terms of FEC element= s, > and most of the LDP specs (and implementations) assume that you can look = up > a FEC element to find the corresponding LSP. > > The only argument I've heard in favor of the other options is the followi= ng: > > =A0 =A0An LDP message may contain multiple FEC elements. =A0But there is = no need > =A0 =A0to have a single LDP message that contains FEC elements from diffe= rent > =A0 =A0topologies. =A0Therefore the most efficient way of encoding the me= ssage is > =A0 =A0to include the MTid just once per message, in its own TLV. =A0This= is a > =A0 =A0much more efficient encoding than you get by repeating the MT-ID i= n > =A0 =A0every FEC element. > > This argument does point out a disadvantage of this option; it isn't the > option that results in the shortest messages. =A0But I don't think this f= actor > outweighs the advantages of maintaining the ability to map from a FEC > element to a label. =A0Maintaining the proper semantics is more important= than > shortening the message size. > > (One could also argue that there may well be cases where it is convenient= to > assign the same label to prefixes from different topologies; think of cas= es > where the label assigned is explicit null.) > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From internet-drafts@ietf.org Mon Nov 21 09:41:39 2011 Return-Path: <internet-drafts@ietf.org> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5A711E80D4; Mon, 21 Nov 2011 09:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcLHSW+YVa3n; Mon, 21 Nov 2011 09:41:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4494311E80AA; Mon, 21 Nov 2011 09:41:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111121174135.31593.61611.idtracker@ietfa.amsl.com> Date: Mon, 21 Nov 2011 09:41:35 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 17:41:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuang Fang Chao Zhou Lianyuan Li Ning So Raveendra Torvi Filename : draft-ietf-mpls-ldp-multi-topology-02.txt Pages : 18 Date : 2011-11-21 Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. It would be advantageous to extend Multiprotocol Label Switching (MPLS), using Label Distribution Protocol (LDP), to support multiple topologies. These LDP extensions, known as Multiple Topology Label Distribution Protocol (MT LDP), would allow the configuration of multiple topologies within an MPLS LDP enabled network. This document describes the protocol extensions required to extend the existing MPLS LDP signalling protocol for creating and maintaining LSPs in an MT environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-02.txt From quintin.zhao@huawei.com Mon Nov 21 10:08:06 2011 Return-Path: <quintin.zhao@huawei.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6128D21F8B74 for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T59fvqTysgkV for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:08:03 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5914721F8B76 for <mpls@ietf.org>; Mon, 21 Nov 2011 10:08:03 -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 <0LV0009BOVPE7P@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 21 Nov 2011 12:08:02 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV000K36VP01Z@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 21 Nov 2011 12:08:02 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Nov 2011 10:08:00 -0800 Received: from QZHAO (10.47.136.224) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server id 14.1.270.1; Mon, 21 Nov 2011 10:07:51 -0800 Date: Tue, 22 Nov 2011 02:07:46 +0800 From: Quintin Zhao <quintin.zhao@huawei.com> In-reply-to: <CAG4d1re_2E98NYch=f6YxoCQRw3nieoJ5xj6AOaNg1mKsHmZNw@mail.gmail.com> X-Originating-IP: [10.47.136.224] To: erosen@cisco.com, ice@cisco.com, 'Alia Atlas' <akatlas@gmail.com>, 'Lizhong Jin' <lizho.jin@gmail.com> Message-id: <003201cca878$7966bda0$6c3438e0$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyocJU1JyMihpPnScao1IvphhU0xQABdP+w References: <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com> <24620.1321894474@erosen-linux> <CAG4d1re_2E98NYch=f6YxoCQRw3nieoJ5xj6AOaNg1mKsHmZNw@mail.gmail.com> Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 18:08:06 -0000 Hello Eric, Ice, Alia, Lizhong, Thanks for your detailed reasoning points on why we should chose the = option3, which puts MPLS-MT ID inside FEC element, of the three choices = we have presented last Monday in the IETF = meeting=EF=BC=8Chttp://www.ietf.org/proceedings/82/slides/mpls-3.ppt=EF=BC= =89. After Monday's presentation, we had discussions among co-authors and we = also had the consensus that option3 is a more flexible and scalable = choice. I agree with Eric=E2=80=99s point that one of the main reason for = choosing option3 is that maintaining the proper semantics is more = important than shortening the message size. For Alia's point using multiple FEC elements with different MT-ID for = the protections, it is a very good idea! We have the similar scenario = for mLDP=E2=80=99s protections (see the page6-9 of the presentation we = gave on RTG=E2=80=99s meeting last week, = http://www.ietf.org/proceedings/82/slides/rtgwg-6.ppt ).=20 Regarding to Ice's email, I'd like to get a clarification for the = following in your reasoning points=EF=BC=9A (1) For first reasoning point, what is the scenario where IPv4 FEC = element and IPv6 FEC element are mixed together in a message to share a = same label TLV? (2) For the fourth reasoning point, when do we have the accident merge = here using MRT or MTR? If the two messages are for different topologies, = why do you merge them? (3) For the 5th reasoning point, why do we need to merge the label = mappings if these labels map to address belong to different topology? = Label aggregation? =20 We have updated LDP MT extension draft = (draft-ietf-mpls-ldp-multi-topology-02.txt) to reflect this choice of = encoding the MPLS-MT ID inside the FEC element. =20 Again, thanks for your time and your comments and suggestions have made = our draft a better document. Quintin From ice@cisco.com Mon Nov 21 10:37:12 2011 Return-Path: <ice@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0C1F0C76 for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZqmWXLaS3gA for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:37:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E13241F0C73 for <mpls@ietf.org>; Mon, 21 Nov 2011 10:37:11 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-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 pALISMpr022072 for <mpls@ietf.org>; Mon, 21 Nov 2011 19:28:22 +0100 (CET) Received: from ams-iwijnand-8714.cisco.com (ams-iwijnand-8714.cisco.com [10.55.191.149]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pALISE9U001307; Mon, 21 Nov 2011 19:28:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: IJsbrand Wijnands <ice@cisco.com> In-Reply-To: <003201cca878$7966bda0$6c3438e0$%zhao@huawei.com> Date: Mon, 21 Nov 2011 19:28:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <BC0C7CDA-EE05-4AE3-BC42-2455CE0F041F@cisco.com> References: <CAH==cJxFr5Nhd3HpHK8M_HpsKVxvs1tDgentyo9OuUW=J7QXFA@mail.gmail.com> <24620.1321894474@erosen-linux> <CAG4d1re_2E98NYch=f6YxoCQRw3nieoJ5xj6AOaNg1mKsHmZNw@mail.gmail.com> <003201cca878$7966bda0$6c3438e0$%zhao@huawei.com> To: Quintin Zhao <quintin.zhao@huawei.com> X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, 'Lizhong Jin' <lizho.jin@gmail.com> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 18:37:12 -0000 Quintin, > After Monday's presentation, we had discussions among co-authors and = we also had the consensus that option3 is a more flexible and scalable = choice. Great. > Regarding to Ice's email, I'd like to get a clarification for the = following in your reasoning points=EF=BC=9A > (1) For first reasoning point, what is the scenario where IPv4 FEC = element and IPv6 FEC element are mixed together in a message to share a = same label TLV? It is an example, if rfc5036 allows for it, you don't want to break it = just because of MT-ID, right? > (2) For the fourth reasoning point, when do we have the accident merge = here using MRT or MTR? If the two messages are for different topologies, = why do you merge them? It is not about the messages, it is about the mLDP state. MRT or MTR may = have a router that is shared between 2 topologies (maybe accidental or = just because there is no dual topology). > (3) For the 5th reasoning point, why do we need to merge the label = mappings if these labels map to address belong to different topology? = Label aggregation? These are label mappings from 2 different downstream routers. Thx, Ice. From skraza@cisco.com Mon Nov 21 10:53:28 2011 Return-Path: <skraza@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C68821F8AED for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai9qdWfPW1Yk for <mpls@ietfa.amsl.com>; Mon, 21 Nov 2011 10:53:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD121F8AEC for <mpls@ietf.org>; Mon, 21 Nov 2011 10:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2990; q=dns/txt; s=iport; t=1321901603; x=1323111203; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=skqcaP7lHQE9rxIPCvAg8zEuuzGEXW45dWhMzHK6xMw=; b=Z7mV7lHUzki4dsxJY4RVm9KbYIxG6/8FaWwCb7m9fl0WXgbs5Sclyy5g fUUTkwZWmGO74dJHQBbam2TOXI+LaNHcHz5vporXKdnttueY1z3a08V6v URrLSruvKKTFNHSD6jeSsFQ8VRlOfB+yLv4nchADIvRMqGM4r+pWQq9mo c=; X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208,217";a="37939145" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 21 Nov 2011 18:53:23 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pALIrNWS026053; Mon, 21 Nov 2011 18:53:23 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 12:53:23 -0600 Received: from 10.86.244.196 ([10.86.244.196]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Nov 2011 18:53:22 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 21 Nov 2011 13:53:38 -0500 From: Kamran Raza <skraza@cisco.com> To: IJsbrand Wijnands <ice@cisco.com>, Quintin Zhao <quintin.zhao@huawei.com> Message-ID: <CAF00862.23915%skraza@cisco.com> Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 Thread-Index: AcyofuDup1DbYeMz1kGnD8lUMQywzg== In-Reply-To: <BC0C7CDA-EE05-4AE3-BC42-2455CE0F041F@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3404728418_6003940" X-OriginalArrivalTime: 21 Nov 2011 18:53:23.0388 (UTC) FILETIME=[D83947C0:01CCA87E] Cc: mpls@ietf.org, 'Lizhong Jin' <lizho.jin@gmail.com> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2011 18:53:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3404728418_6003940 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > what is the scenario where IPv4 FEC element and IPv6 FEC element are mixed > together in a message to share a same label TLV? One such example is the advertisement/withdrawal/change of a null label (implicit null or explicit null) associated with one/more prefixes potentially across different IP Address families. -- e.g. an LSR can advertise/withdraw implicit-null label for a (mixed) set of IPv4 and IPv6 prefixes and hence have a single FEC TLV with mixed (IPv4 and IPv6) Prefix FEC elements associated with a single label specified in single Label TLV in a given Label Mapping msg. Rgds, -- Kamran _______________________________________________ mpls > mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3404728418_6003940 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01
> what is the scenario where IPv4 FEC element and = IPv6 FEC element are mixed
> together in a message to share a same label TLV?
One such example is the advertisement/withdrawal/change of a null label (im= plicit null or explicit null) associated with one/more prefixes potentially = across different IP Address families. -- e.g. an LSR can advertise/withdraw = implicit-null label for a (mixed) set of IPv4 and IPv6 prefixes and hence ha= ve a single FEC TLV with mixed (IPv4 and IPv6) Prefix FEC elements associate= d with a single label specified in single Label TLV in a given Label Mapping= msg.

Rgds, -- Kamran
_______________________________________________ mpls
> mailing list mpls@ietf.org https://www.ietf.org/m= ailman/listinfo/mpls

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3404728418_6003940-- From gregimirsky@gmail.com Mon Nov 21 15:04:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693211E80D5 for ; Mon, 21 Nov 2011 15:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es756jr3mRkd for ; Mon, 21 Nov 2011 15:04:00 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAF7811E811A for ; Mon, 21 Nov 2011 15:03:59 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so3621322vbb.31 for ; Mon, 21 Nov 2011 15:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5T/EEWTdWkkgDD41ASyFKhgue6Di1JITKLjrAzjXUs=; b=Bs0yxpl5Omb8i8DqMaOivMcSrT10II+UlER9s94CtGg5KNQAQD82zr/76cjjdpB4o0 CIWWG7WyQu2Dpc7ZExC7evRCr+zticiSi9cPd2Unf+mtnaQMah2Cqh3W5Ao76tHGbHjl anZzKhz94pdKuPsbTsb+ofYsBTLt/k2esfSTg= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr17616709vdb.72.1321916639201; Mon, 21 Nov 2011 15:03:59 -0800 (PST) Received: by 10.220.63.212 with HTTP; Mon, 21 Nov 2011 15:03:59 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Nov 2011 15:03:59 -0800 Message-ID: From: Greg Mirsky To: fu.xihua@zte.com.cn Content-Type: multipart/alternative; boundary=20cf307f336ab3c76e04b246b3d1 Cc: mpls@ietf.org Subject: Re: [mpls] Open Issues in draft-fuxh-mpls-delay-loss-te-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 23:04:04 -0000 --20cf307f336ab3c76e04b246b3d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Fu and Authors, two notes to make: - it is important to maintain consistent terminology during the discussion and in document itself. I believe that latency and jitter are characteristics of links, not of a node. And that specific levels of jit= ter and latency are function of PHB and CoS. - I think that queuing latency is an important if not dominant portion especially as link usage gets to BW saturation. And since links even at some PHB can be oversubscribed ignoring queuing latency might make stati= c latency/jitter metric irrelevant. Regards, Greg 2011/11/16 > > Hi Working Group, > > We would like to get comments for the following open issues. > > 1. Latency and jitter of Node > Advertising node latency may result in oscillation risk because of queue > delay. > Authors of this drafts have ever discussed this issues. We descided draft= s > ignore the queuing delay for the benefit of simplicity. > Node latency (e.g., a fixed or average/approximate latency ) can be > included in the advertised link delay. > > 2.One maximum threshold could be configured to link. If the link > performance exceeds the threshold, the IGP should get the anomalous state > of this link. > It may result in heavy configuration work. > > 3.Composite Link Performance Advertisement > Option 1: Only TLV for Composite Link. The performance may be the range, > average or maximum latency/loss of all component links. > Option 2: Both a TLV for each component link, plus one for the bundle wit= h > the average. > > 4. E2E loss computation: > The latest version of this draft say the end-to-end path loss should be > sum of each link. It isn't correct. > We will give a little change in next version to clarify the e2e loss > computation is multiplication of each link rather than sum. > i.e. packet loss of e2e path =3D > 1-(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossrate_Linkn) > Assume packet loss is 10% for two hops of a link. The measurements will > come to 19% total packet loss. Because of 10% loss on the first link only > 90% packet reach the second link where another 10% of 90% are lost, which > is 9% of total packets. > You may refer to ITU-T Y.1541 8.2 section. > > Best Regards, > > Authors > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf307f336ab3c76e04b246b3d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Fu and Authors,
two notes to make:
  • it is important to ma= intain consistent terminology during the discussion and in document itself.= I believe that latency and jitter are characteristics of links, not of a n= ode. And that specific levels of jitter and latency are function of PHB and= CoS.
  • I think that queuing latency is an important if not dominant portion es= pecially as link usage gets to BW saturation. And since links even at some = PHB can be oversubscribed ignoring queuing latency might make static latenc= y/jitter metric irrelevant.
Regards,
Greg

2011/11/16 <fu.xihua@zte.com.cn>

Hi Working Group,

We would like to get comments for = the following open issues.

1. Latency and jitter of Node
Advertising node latency may resul= t in oscillation risk because of queue delay.
Authors of this drafts have ever d= iscussed this issues. We descided drafts ignore the queuing delay for the benefit of simplicity.
Node latency (e.g., a fixed or ave= rage/approximate latency ) can be included in the advertised link delay.

2.One maximum threshold could be c= onfigured to link. If the link performance exceeds the threshold, the IGP should get the anomalous state of this link.
It may result in heavy configurati= on work.

3.Composite Link Performance Adver= tisement
Option 1: Only TLV for Composite L= ink. The performance may be the range, average or maximum latency/loss of all component links.
Option 2: Both a TLV for each comp= onent link, plus one for the bundle with the average.

4. E2E loss computation:
The latest version of this draft s= ay the end-to-end path loss should be sum of each link. It isn't correct.
We will give a little change in ne= xt version to clarify the e2e loss computation is multiplication of each link rather than sum.
i.e. packet loss of e2e path =3D 1= -(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossrate_Linkn)
Assume packet loss is 10% for two = hops of a link. The measurements will come to 19% total packet loss. Because of 10% loss on the first link only 90% packet reach the second link where another 10% of 90% are lost, which is 9% of total packets.
You may refer to ITU-T Y.1541 8.2 = section.

Best Regards,

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


--20cf307f336ab3c76e04b246b3d1-- From vishwas.ietf@gmail.com Mon Nov 21 15:15:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9E11E80D5 for ; Mon, 21 Nov 2011 15:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.929 X-Spam-Level: X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b0rrX9rAywR for ; Mon, 21 Nov 2011 15:15:00 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9BB011E8140 for ; Mon, 21 Nov 2011 15:15:00 -0800 (PST) Received: by qadb14 with SMTP id b14so741465qad.10 for ; Mon, 21 Nov 2011 15:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i3OHkZV9LrHtzGrHR2y0Hzc7TViV6v4Yx+jYT3zpq1k=; b=Iwsd0G9eIMTJ3hEdNCHpQL1F38Fd9yw5GhPsL+lVqouw4xGYRXwLTN3R4TjXw2FTF2 HO6xqfGPtoqZlNnEODGgUbBX3SDoJeQ1jMRMFuG3RPpuXwhbf3bEpH4WcQ7w1AWIbTLJ Rw2PIpWxnZm7mv1I4LWIIwZEuhyuUbJ/Xjcic= MIME-Version: 1.0 Received: by 10.182.45.6 with SMTP id i6mr3439270obm.3.1321917300010; Mon, 21 Nov 2011 15:15:00 -0800 (PST) Received: by 10.182.150.73 with HTTP; Mon, 21 Nov 2011 15:14:59 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Nov 2011 15:14:59 -0800 Message-ID: From: Vishwas Manral To: Greg Mirsky Content-Type: multipart/alternative; boundary=f46d0444ea0f16ef3c04b246dbf1 Cc: mpls@ietf.org Subject: Re: [mpls] Open Issues in draft-fuxh-mpls-delay-loss-te-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 23:15:05 -0000 --f46d0444ea0f16ef3c04b246dbf1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Greg, I agree queuing latencies can be an issue. However as mentioned in the draft because of the fact that the latencies are going high we can go into the "unusable state" for the latency parameter, which means any latency sensitive LSP's that need to be placed will not use the link. The idea is to go for simplicity instead of absolute optimization. Thanks, Vishwas On Mon, Nov 21, 2011 at 3:03 PM, Greg Mirsky wrote: > Dear Fu and Authors, > two notes to make: > > - it is important to maintain consistent terminology during the > discussion and in document itself. I believe that latency and jitter a= re > characteristics of links, not of a node. And that specific levels of j= itter > and latency are function of PHB and CoS. > - I think that queuing latency is an important if not dominant portion > especially as link usage gets to BW saturation. And since links even a= t > some PHB can be oversubscribed ignoring queuing latency might make sta= tic > latency/jitter metric irrelevant. > > Regards, > Greg > > 2011/11/16 > >> >> Hi Working Group, >> >> We would like to get comments for the following open issues. >> >> 1. Latency and jitter of Node >> Advertising node latency may result in oscillation risk because of queue >> delay. >> Authors of this drafts have ever discussed this issues. We descided >> drafts ignore the queuing delay for the benefit of simplicity. >> Node latency (e.g., a fixed or average/approximate latency ) can be >> included in the advertised link delay. >> >> 2.One maximum threshold could be configured to link. If the link >> performance exceeds the threshold, the IGP should get the anomalous stat= e >> of this link. >> It may result in heavy configuration work. >> >> 3.Composite Link Performance Advertisement >> Option 1: Only TLV for Composite Link. The performance may be the range, >> average or maximum latency/loss of all component links. >> Option 2: Both a TLV for each component link, plus one for the bundle >> with the average. >> >> 4. E2E loss computation: >> The latest version of this draft say the end-to-end path loss should be >> sum of each link. It isn't correct. >> We will give a little change in next version to clarify the e2e loss >> computation is multiplication of each link rather than sum. >> i.e. packet loss of e2e path =3D >> 1-(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossrate_Linkn) >> Assume packet loss is 10% for two hops of a link. The measurements will >> come to 19% total packet loss. Because of 10% loss on the first link onl= y >> 90% packet reach the second link where another 10% of 90% are lost, whic= h >> is 9% of total packets. >> You may refer to ITU-T Y.1541 8.2 section. >> >> Best Regards, >> >> Authors >> _______________________________________________ >> 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 > > --f46d0444ea0f16ef3c04b246dbf1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Greg,
=A0
I agree queuing latencies can be an issue.
=A0
However as mentioned in the draft because of the fact that the latenci= es are going high we can go into the "unusable state" for the lat= ency parameter, which means any latency sensitive LSP's that need to be= placed will not use the link. The idea is to go for simplicity instead of = absolute optimization.
=A0
Thanks,
Vishwas
On Mon, Nov 21, 2011 at 3:03 PM, Greg Mirsky <gregimirsky@gma= il.com> wrote:
Dear Fu and Authors,
two note= s to make:
  • it is important to maintain consistent terminology during the discussio= n and in document itself. I believe that latency and jitter are characteris= tics of links, not of a node. And that specific levels of jitter and latenc= y are function of PHB and CoS.
  • I think that queuing latency is an important if not dominant portion es= pecially as link usage gets to BW saturation. And since links even at some = PHB can be oversubscribed ignoring queuing latency might make static latenc= y/jitter metric irrelevant.
Regards,
Greg

2011/11/16 <fu.xihua@zte.com.cn>

Hi Working Group= ,

We would like to get = comments for the following open issues.

1. Latency and jitter of Node
Advertising node latency may result in= oscillation risk because of queue delay.
Authors of this drafts have ever discussed this issues. We d= escided drafts ignore the queuing delay for the benefit of simplicity.
Node latency (e.g., a fixed or average= /approximate latency ) can be included in the advertised link delay.=

2.One maximum threshold could= be configured to link. If the link performance exceeds the threshold, the = IGP should get the anomalous state of this link.
It may result in heavy configuration w= ork.

3.Composite Link P= erformance Advertisement
Op= tion 1: Only TLV for Composite Link. The performance may be the range, aver= age or maximum latency/loss of all component links.
Option 2: Both a TLV for each componen= t link, plus one for the bundle with the average.

4. E2E loss computation:
The latest version of this draft say the end-to-= end path loss should be sum of each link. It isn't correct.
We will give a little change in next v= ersion to clarify the e2e loss computation is multiplication of each link r= ather than sum.
i.e. packet= loss of e2e path =3D 1-(1-lossrate_Link1)*(1-lossrate_Link2)*=85*(1-lossra= te_Linkn)
Assume packet loss is 10% for two hops= of a link. The measurements will come to 19% total packet loss. Because of= 10% loss on the first link only 90% packet reach the second link where ano= ther 10% of 90% are lost, which is 9% of total packets.
You may refer to ITU-T Y.1541 8.2 sect= ion.

Best Regards,

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



_______________________________________________
mpls maili= ng list
mpls@ietf.org
https://www.= ietf.org/mailman/listinfo/mpls


--f46d0444ea0f16ef3c04b246dbf1-- From lufang@cisco.com Mon Nov 21 18:02:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471A31F0C7E for ; Mon, 21 Nov 2011 18:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27btGufmF2Ku for ; Mon, 21 Nov 2011 18:01:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C88311F0C48 for ; Mon, 21 Nov 2011 18:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=4058; q=dns/txt; s=iport; t=1321927316; x=1323136916; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mmVSt9tWCeKIvRVZgKpqv4j8fgn8k0lqDC39Sq0Dxio=; b=bJgWbrEfP9W/j3WbwUg+fIPjRB8alW0efAft47l0SpBkDfMxmYWlJP9b d/3XxVVpX5iy9QW4ZpmsLGIolO7kER9VAlAbTIup1J3b/tD0FETQvxrA0 LYbg5FZTt4Q4/OqdeXorCF/fSTx4wX1zAxY+HBn7XOugiv04F9j1XJwgg U=; X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; d="scan'208";a="38022121" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Nov 2011 02:01:56 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAM21uHE010144; Tue, 22 Nov 2011 02:01:56 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 20:01:56 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 20:01:52 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25075BA060@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 Thread-Index: AcyocJUVqKYuofrDRlG+zdYmRnqi8wARkV9Q References: <24620.1321894474@erosen-linux> From: "Luyuan Fang (lufang)" To: "Alia Atlas" , X-OriginalArrivalTime: 22 Nov 2011 02:01:56.0303 (UTC) FILETIME=[B650BDF0:01CCA8BA] Cc: ice@cisco.com, quintin.zhao@huawei.com, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:02:01 -0000 Same here, much prefer MT-ID is encoded as part of each FEC element, = treat the ordered pair as a FEC element. This way we = maintain the consistent semantics in handling the LDP set up mappings = from FEC elements to label, as Eric described. Thanks to Eric for the = clear reasoning, and Alia for the MRT FRR use case. Discussed with Ice and Quintin separately last week in Taipei on using = FEC as the preferred encoding option as well, we were very much in synch = on this. Thanks, Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Alia Atlas > Sent: Monday, November 21, 2011 12:11 PM > To: mpls@ietf.org > Cc: ice@cisco.com; quintin.zhao@huawei.com; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 >=20 > I am also strongly in favor of having the MT-ID encoded as part of > each FEC element. The idea of specifying address families that > include MT-ID seems a particularly functional way of doing so. >=20 > I also have a case where it makes perfect sense to include multiple > FEC/Label bindings in a single message where each FEC refers to a > different MT-ID. This is for MRT fast-reroute, where one may want to > send a FEC for the loopback address with the default topology as well > as FECs for the loopback address on the blue MRT topology and on the > red MRT topology. >=20 > Alia >=20 > On Mon, Nov 21, 2011 at 11:54 AM, Eric Rosen wrote: > > > > I also prefer the encoding where the MT-ID is encoded as part of = each > FEC > > element. =A0In LDP, a Label Mapping Message creates a mapping from = each > of the > > included FEC elements to a label. =A0In a single topology, the FEC > element is > > an address prefix, and the mapping is from a prefix to a label. = =A0In a > > multitopology network, the mapping is not from a prefix to a label, > it's > > from a ordered pair to a label. =A0So if we want to > maintain > > the idea that LDP sets up mappings from FEC elements to label, we > have to > > treat the ordered pair as a FEC element. > > > > In general, extensions to LDP have retained the concept that one > should be > > able to map from FEC element to label, and we should try not to > depart from > > that paradigm. =A0Many LDP features are specified in terms of FEC > elements, > > and most of the LDP specs (and implementations) assume that you can > look up > > a FEC element to find the corresponding LSP. > > > > The only argument I've heard in favor of the other options is the > following: > > > > =A0 =A0An LDP message may contain multiple FEC elements. =A0But = there is no > need > > =A0 =A0to have a single LDP message that contains FEC elements from > different > > =A0 =A0topologies. =A0Therefore the most efficient way of encoding = the > message is > > =A0 =A0to include the MTid just once per message, in its own TLV. = =A0This > is a > > =A0 =A0much more efficient encoding than you get by repeating the = MT-ID > in > > =A0 =A0every FEC element. > > > > This argument does point out a disadvantage of this option; it isn't > the > > option that results in the shortest messages. =A0But I don't think = this > factor > > outweighs the advantages of maintaining the ability to map from a = FEC > > element to a label. =A0Maintaining the proper semantics is more > important than > > shortening the message size. > > > > (One could also argue that there may well be cases where it is > convenient to > > assign the same label to prefixes from different topologies; think = of > cases > > where the label assigned is explicit null.) > > > > > > > > > > _______________________________________________ > > 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 czhou@cisco.com Mon Nov 21 19:10:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2936321F84B4 for ; Mon, 21 Nov 2011 19:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0UdI-y70oCf for ; Mon, 21 Nov 2011 19:10:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AE75E21F8672 for ; Mon, 21 Nov 2011 19:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=czhou@cisco.com; l=4706; q=dns/txt; s=iport; t=1321931423; x=1323141023; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tRtpbhWw1J8AU0tLh0m7TxQPZz4ZHLsoE5LRdWk2nTg=; b=B2MV8yShJ15+N8bsUJfj3J2m8dYWR9b4UavjJvijz1GbGjW0V9vE+313 yAd6sVI0bG85hlKlvUkubHEp1vxYbuCMtf24yvTtUSzJR9+1sjlby0l1N StZ8bm/HgksgigoA7r2UIXYEJbHa4fZ/GAE3PAdflIQPktoLN1nngbNto 4=; X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; d="scan'208";a="38047348" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 22 Nov 2011 03:10:19 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAM3AJ0c000725; Tue, 22 Nov 2011 03:10:19 GMT Received: from xmb-rcd-208.cisco.com ([72.163.62.215]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 21:10:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 21:10:17 -0600 Message-ID: <01A021EBB03D534AB5CE4B620B5F82D1048EBDBD@XMB-RCD-208.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25075BA060@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 Thread-Index: AcyocJUVqKYuofrDRlG+zdYmRnqi8wARkV9QAANDP4A= References: <24620.1321894474@erosen-linux> <238542D917511A45B6B8AA806E875E25075BA060@XMB-RCD-201.cisco.com> From: "Chao Zhou (czhou)" To: "Luyuan Fang (lufang)" , "Alia Atlas" , X-OriginalArrivalTime: 22 Nov 2011 03:10:19.0418 (UTC) FILETIME=[43F667A0:01CCA8C4] Cc: ice@cisco.com, quintin.zhao@huawei.com, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 03:10:31 -0000 Quintin has submitted a new version based on our discussion and feedback = from various sources. Please review the new version and if possible, = move to the next step. Thanks. -Chao -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Luyuan Fang (lufang) Sent: Tuesday, November 22, 2011 10:02 AM To: Alia Atlas; mpls@ietf.org Cc: ice@cisco.com; quintin.zhao@huawei.com; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 Same here, much prefer MT-ID is encoded as part of each FEC element, = treat the ordered pair as a FEC element. This way we = maintain the consistent semantics in handling the LDP set up mappings = from FEC elements to label, as Eric described. Thanks to Eric for the = clear reasoning, and Alia for the MRT FRR use case. Discussed with Ice and Quintin separately last week in Taipei on using = FEC as the preferred encoding option as well, we were very much in synch = on this. Thanks, Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Alia Atlas > Sent: Monday, November 21, 2011 12:11 PM > To: mpls@ietf.org > Cc: ice@cisco.com; quintin.zhao@huawei.com; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-multi-topology-01 >=20 > I am also strongly in favor of having the MT-ID encoded as part of > each FEC element. The idea of specifying address families that > include MT-ID seems a particularly functional way of doing so. >=20 > I also have a case where it makes perfect sense to include multiple > FEC/Label bindings in a single message where each FEC refers to a > different MT-ID. This is for MRT fast-reroute, where one may want to > send a FEC for the loopback address with the default topology as well > as FECs for the loopback address on the blue MRT topology and on the > red MRT topology. >=20 > Alia >=20 > On Mon, Nov 21, 2011 at 11:54 AM, Eric Rosen wrote: > > > > I also prefer the encoding where the MT-ID is encoded as part of = each > FEC > > element. =A0In LDP, a Label Mapping Message creates a mapping from = each > of the > > included FEC elements to a label. =A0In a single topology, the FEC > element is > > an address prefix, and the mapping is from a prefix to a label. = =A0In a > > multitopology network, the mapping is not from a prefix to a label, > it's > > from a ordered pair to a label. =A0So if we want to > maintain > > the idea that LDP sets up mappings from FEC elements to label, we > have to > > treat the ordered pair as a FEC element. > > > > In general, extensions to LDP have retained the concept that one > should be > > able to map from FEC element to label, and we should try not to > depart from > > that paradigm. =A0Many LDP features are specified in terms of FEC > elements, > > and most of the LDP specs (and implementations) assume that you can > look up > > a FEC element to find the corresponding LSP. > > > > The only argument I've heard in favor of the other options is the > following: > > > > =A0 =A0An LDP message may contain multiple FEC elements. =A0But = there is no > need > > =A0 =A0to have a single LDP message that contains FEC elements from > different > > =A0 =A0topologies. =A0Therefore the most efficient way of encoding = the > message is > > =A0 =A0to include the MTid just once per message, in its own TLV. = =A0This > is a > > =A0 =A0much more efficient encoding than you get by repeating the = MT-ID > in > > =A0 =A0every FEC element. > > > > This argument does point out a disadvantage of this option; it isn't > the > > option that results in the shortest messages. =A0But I don't think = this > factor > > outweighs the advantages of maintaining the ability to map from a = FEC > > element to a label. =A0Maintaining the proper semantics is more > important than > > shortening the message size. > > > > (One could also argue that there may well be cases where it is > convenient to > > assign the same label to prefixes from different topologies; think = of > cases > > where the label assigned is explicit null.) > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Wed Nov 23 18:47:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8F11E80BE; Wed, 23 Nov 2011 18:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=3.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ketSNwAd2ZZD; Wed, 23 Nov 2011 18:47:37 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4711E8098; Wed, 23 Nov 2011 18:47:37 -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 <0LV5008FP92H96@szxga04-in.huawei.com>; Thu, 24 Nov 2011 10:47:05 +0800 (CST) Received: from szxrg01-dlp.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 <0LV5006OK92H8H@szxga04-in.huawei.com>; Thu, 24 Nov 2011 10:47:05 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFG96117; Thu, 24 Nov 2011 10:47:05 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 Nov 2011 10:47:00 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0270.001; Thu, 24 Nov 2011 10:46:56 +0800 Date: Thu, 24 Nov 2011 02:46:55 +0000 From: Mach Chen X-Originating-IP: [10.108.4.60] To: "mpls@ietf.org" Message-id: 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: Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-index: AcyqU1Nai2fKVCNrQGGbwyzFXbI2GQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 02:47:38 -0000 Hi, We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and did not receive technical comments there. Although the authors think that the draft is quite straightforward and stable, we'd like that you could spend some time to read the draft and give your comments. Any comments and feedbacks are appreciated! Here is the pointer: http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . Many thanks, Mach From Spike.Curtis@metaswitch.com Thu Nov 24 04:22:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFAD21F8B47; Thu, 24 Nov 2011 04:22:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lOgOvCVoOVp; Thu, 24 Nov 2011 04:22:09 -0800 (PST) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7B21F8B43; Thu, 24 Nov 2011 04:22:09 -0800 (PST) Received: from ENFICSMBX1.datcon.co.uk (172.18.10.94) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 24 Nov 2011 12:22:09 +0000 Received: from ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715]) by ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19%19]) with mapi id 14.01.0339.001; Thu, 24 Nov 2011 12:22:03 +0000 From: Spike Curtis To: Mach Chen , "mpls@ietf.org" Thread-Topic: Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-Index: AcyqU1Nai2fKVCNrQGGbwyzFXbI2GQAUAyOw Date: Thu, 24 Nov 2011 12:22:02 +0000 Message-ID: <86C289CC63A2544A932C48E05AC49582210CB9AF@ENFIRHMBX1.datcon.co.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 12:22:10 -0000 Hi Mach, I agree that the draft is straightforward, so I only have comments intended= to improve the clarity, rather than the technical details. In the introduction and abstract you state that there is ambiguity in the c= urrently defined sub-TLVs that is resolved by looking at the sub-TLV length= . Really, it isn't the sub-TLV length itself that determines this, but the= length of the address fields. I think what you are getting at would be mo= re clearly stated with something like the following. "Although the sub-TLVs defined for pseudowires in RFC 4379 are not explicit= ly restricted to IPv4 LDP sessions, this restriction is clearly inferred by= examining the lengths of the Sender/Remote PE Address fields. These sub-T= LVs cannot be used for pseudowires signalled in IPv6 LDP sessions since the= addresses will not fit." Cheers, Spike -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mac= h Chen Sent: Thursday, November 24, 2011 2:47 AM To: mpls@ietf.org Cc: pwe3@ietf.org Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Hi, We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and d= id not receive technical comments there. Although the authors think that th= e draft is quite straightforward and stable, we'd like that you could spend= some time to read the draft and give your comments.=20 Any comments and feedbacks are appreciated! Here is the pointer: http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp= -ping-02 . Many thanks, Mach _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Thu Nov 24 05:54:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B574821F8C1C; Thu, 24 Nov 2011 05:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK2gH1u9P0XX; Thu, 24 Nov 2011 05:54:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E686D21F8C18; Thu, 24 Nov 2011 05:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=2200; q=dns/txt; s=iport; t=1322142897; x=1323352497; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iRUtpuIGPl6VpQB8mYtKhIu2rmjvgE+RVEeDvh0OIKg=; b=nCSBkO2AgY1IqtkspHo/yvMqk1FwGNluT1GYaa7aRU6MsZY0xyRCoGJW K0L2RZcr3vmRJg4nu8SEmX2ysCZhaHC/YNM+8ipzO3/fXWELFqefIW9dh g4aKsbiLuEypg9rFrPN2pYQxUj7mnyFucziyjuRrZxNJN/8rJm6ACFGl7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAKhLzk6tJV2d/2dsb2JhbABDmk2QJYEFgXIBAQEEAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHa5YjAZ5OiX9jBIghnlM X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; d="scan'208";a="38740171" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 24 Nov 2011 13:54:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAODsupf005648; Thu, 24 Nov 2011 13:54:56 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 07:54:56 -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: Thu, 24 Nov 2011 07:54:54 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D86306EC751C@XMB-RCD-206.cisco.com> In-Reply-To: <86C289CC63A2544A932C48E05AC49582210CB9AF@ENFIRHMBX1.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-Index: AcyqU1Nai2fKVCNrQGGbwyzFXbI2GQAUAyOwAANPcyA= References: <86C289CC63A2544A932C48E05AC49582210CB9AF@ENFIRHMBX1.datcon.co.uk> From: "Carlos Pignataro (cpignata)" To: "Spike Curtis" , "Mach Chen" , X-OriginalArrivalTime: 24 Nov 2011 13:54:56.0206 (UTC) FILETIME=[A5F366E0:01CCAAB0] Cc: pwe3@ietf.org Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 13:54:57 -0000 Spike, I think this clarification sounds reasonable. Thank you. -- Carlos. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spike Curtis Sent: Thursday, November 24, 2011 7:22 AM To: Mach Chen; mpls@ietf.org Cc: pwe3@ietf.org Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Hi Mach, I agree that the draft is straightforward, so I only have comments intended to improve the clarity, rather than the technical details. In the introduction and abstract you state that there is ambiguity in the currently defined sub-TLVs that is resolved by looking at the sub-TLV length. Really, it isn't the sub-TLV length itself that determines this, but the length of the address fields. I think what you are getting at would be more clearly stated with something like the following. "Although the sub-TLVs defined for pseudowires in RFC 4379 are not explicitly restricted to IPv4 LDP sessions, this restriction is clearly inferred by examining the lengths of the Sender/Remote PE Address fields. These sub-TLVs cannot be used for pseudowires signalled in IPv6 LDP sessions since the addresses will not fit." Cheers, Spike -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen Sent: Thursday, November 24, 2011 2:47 AM To: mpls@ietf.org Cc: pwe3@ietf.org Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Hi, We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and did not receive technical comments there. Although the authors think that the draft is quite straightforward and stable, we'd like that you could spend some time to read the draft and give your comments.=20 Any comments and feedbacks are appreciated! Here is the pointer: http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . Many thanks, Mach _______________________________________________ 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 ilya@nobulus.com Thu Nov 24 07:58:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7E421F84B0; Thu, 24 Nov 2011 07:58:08 -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, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kuqWyb7fl5Q; Thu, 24 Nov 2011 07:58:07 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id B9DF721F8492; Thu, 24 Nov 2011 07:58:07 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 0A8881717E; Thu, 24 Nov 2011 16:58:06 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wnt501zkD5Qx; Thu, 24 Nov 2011 16:58:02 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:dd55:57ed:7072:e255]) by nobulus.com (Postfix) with ESMTPA id 26B4617141; Thu, 24 Nov 2011 16:58:00 +0100 (CET) Message-ID: <71D87D6111F94757A7B7D6002CAEEC12@hnivarlas1> From: "iLya" To: "Mach Chen" , References: In-Reply-To: Date: Thu, 24 Nov 2011 16:57:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: pwe3@ietf.org Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 15:58:08 -0000 Mach, I wonder if v6 lsp ping specs could be ammended to specify that if intermediate node needs to return "TTL expired" and do not have route back to the source they SHOULD send "TTL expired" along the same path as original packet would have taken. I know v4 lsp ping specs doesn't have such point, but since that creates problem in Inter-AS MPLS Option C environment while plain IP traceroute doesn't have such problem (due to above described ICMP tunneling) it would be nice if v6 lsp ping could fix the issue. Cheers, iLya -------------------------------------------------- From: "Mach Chen" Sent: Thursday, November 24, 2011 3:46 AM To: Cc: Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > Hi, > > We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and > did not receive technical comments there. Although the authors think that > the draft is quite straightforward and stable, we'd like that you could > spend some time to read the draft and give your comments. > > Any comments and feedbacks are appreciated! > > Here is the pointer: > http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . > > Many thanks, > Mach > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From cpignata@cisco.com Thu Nov 24 09:13:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DF21F85FF; Thu, 24 Nov 2011 09:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.988 X-Spam-Level: X-Spam-Status: No, score=-105.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw7WRP05HR0x; Thu, 24 Nov 2011 09:13:13 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5121F85F2; Thu, 24 Nov 2011 09:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=2317; q=dns/txt; s=iport; t=1322154793; x=1323364393; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bm+O/xryhAhbfzGmMa6m18nZXAkAh6ohFOFzYM3njYo=; b=IF5R3a09CUcMIUeyAZVp+tfmRQ3XofuYM4FoAxibtR/JvBL6Bt1PBda/ EXXe2w00NDucmsGZk0XU8SeuRzaQPOQmXlRdDXb/L3R7bm1ixslbVZSOb AJs2p1Y/ct08slFj3+u82WnRRACE1Pj5FOR15EegOqm8ekEgysOPNll3u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAANB6zk6tJXHA/2dsb2JhbABDmk2QJoEFgXIBAQEDAQEBAQ8BHQo0CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIEweHYwiWOQGePIl/YwSIIZ5T X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; d="scan'208";a="38788120" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 24 Nov 2011 17:13:13 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAOHDD2Q024578; Thu, 24 Nov 2011 17:13:13 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 11:13:12 -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: Thu, 24 Nov 2011 11:13:10 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D86306EC752A@XMB-RCD-206.cisco.com> In-Reply-To: <71D87D6111F94757A7B7D6002CAEEC12@hnivarlas1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-Index: AcyqwefP6PYm5F1lTVyfTGqnuQy9qgABONfg References: <71D87D6111F94757A7B7D6002CAEEC12@hnivarlas1> From: "Carlos Pignataro (cpignata)" To: "iLya" , "Mach Chen" , X-OriginalArrivalTime: 24 Nov 2011 17:13:12.0960 (UTC) FILETIME=[58F80000:01CCAACC] Cc: pwe3@ietf.org Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 17:13:14 -0000 iLya, I would thing that such an provision is not specific to the Target FEC Sub-TLVs for IPv6 PWs, and consequently out of scope of this document. Note also that this is not a "v6 LSP Ping" spec as it does not cover 'LDP|VPN|BGP labeled|Generic IPv6 prefix' or 'RSVP IPv6 LSPs'. There's also potentially the use of Reply Modes in RFC4379, as well as other more generic solutions to that, which should be applicable to v4 and v6 LSP Traceroute. Thanks, -- Carlos. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of iLya Sent: Thursday, November 24, 2011 10:58 AM To: Mach Chen; mpls@ietf.org Cc: pwe3@ietf.org Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Mach, I wonder if v6 lsp ping specs could be ammended to specify that if intermediate node needs to return "TTL expired" and do not have route back to the source they SHOULD send "TTL expired" along the same path as original packet would have taken. I know v4 lsp ping specs doesn't have such point, but since that creates problem in Inter-AS MPLS Option C environment while plain IP traceroute doesn't have such problem (due to above described ICMP tunneling) it would be nice if v6 lsp ping could fix the issue. Cheers, iLya -------------------------------------------------- From: "Mach Chen" Sent: Thursday, November 24, 2011 3:46 AM To: Cc: Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > Hi, > > We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG)=20 > and did not receive technical comments there. Although the authors=20 > think that the draft is quite straightforward and stable, we'd like=20 > that you could spend some time to read the draft and give your comments. > > Any comments and feedbacks are appreciated! > > Here is the pointer:=20 > http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . > > Many thanks, > Mach > _______________________________________________ > 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 mach.chen@huawei.com Thu Nov 24 17:22:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C011E80B7; Thu, 24 Nov 2011 17:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=2.789, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjnV4EcWxsnA; Thu, 24 Nov 2011 17:22:20 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16911E80BB; Thu, 24 Nov 2011 17:22:20 -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 <0LV600948ZT0PJ@szxga04-in.huawei.com>; Fri, 25 Nov 2011 09:22:12 +0800 (CST) Received: from szxrg02-dlp.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 <0LV6004PIZT02U@szxga04-in.huawei.com>; Fri, 25 Nov 2011 09:22:12 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFG20153; Fri, 25 Nov 2011 09:22:11 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 Nov 2011 09:22:03 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 25 Nov 2011 09:21:58 +0800 Date: Fri, 25 Nov 2011 01:21:57 +0000 From: Mach Chen In-reply-to: <86C289CC63A2544A932C48E05AC49582210CB9AF@ENFIRHMBX1.datcon.co.uk> X-Originating-IP: [10.108.4.60] To: Spike Curtis , "mpls@ietf.org" Message-id: 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: Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-index: AcyqU1Nai2fKVCNrQGGbwyzFXbI2GQAUAyOwABsXH8A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <86C289CC63A2544A932C48E05AC49582210CB9AF@ENFIRHMBX1.datcon.co.uk> Cc: "pwe3@ietf.org" Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 01:22:21 -0000 Hi Spike, Many thanks for your comments! I thinks your text is great and we will incorporate it into the next version. Best regards, Mach > -----Original Message----- > From: Spike Curtis [mailto:Spike.Curtis@metaswitch.com] > Sent: Thursday, November 24, 2011 8:22 PM > To: Mach Chen; mpls@ietf.org > Cc: pwe3@ietf.org > Subject: RE: Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > > Hi Mach, > > I agree that the draft is straightforward, so I only have comments intended to > improve the clarity, rather than the technical details. > > In the introduction and abstract you state that there is ambiguity in the > currently defined sub-TLVs that is resolved by looking at the sub-TLV length. > Really, it isn't the sub-TLV length itself that determines this, but the length of > the address fields. I think what you are getting at would be more clearly > stated with something like the following. > > "Although the sub-TLVs defined for pseudowires in RFC 4379 are not explicitly > restricted to IPv4 LDP sessions, this restriction is clearly inferred by examining > the lengths of the Sender/Remote PE Address fields. These sub-TLVs cannot > be used for pseudowires signalled in IPv6 LDP sessions since the addresses will > not fit." > > Cheers, > Spike > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Mach Chen > Sent: Thursday, November 24, 2011 2:47 AM > To: mpls@ietf.org > Cc: pwe3@ietf.org > Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > > Hi, > > We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and > did not receive technical comments there. Although the authors think that the > draft is quite straightforward and stable, we'd like that you could spend some > time to read the draft and give your comments. > > Any comments and feedbacks are appreciated! > > Here is the pointer: > http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . > > Many thanks, > Mach > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Thu Nov 24 19:06:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB811E8089; Thu, 24 Nov 2011 19:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[AWL=2.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-mqiiHLFjAx; Thu, 24 Nov 2011 19:06:14 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A40DA11E8073; Thu, 24 Nov 2011 19:06:14 -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 <0LV7009414K7V3@szxga04-in.huawei.com>; Fri, 25 Nov 2011 11:04:55 +0800 (CST) Received: from szxrg02-dlp.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 <0LV7005U04K7YV@szxga04-in.huawei.com>; Fri, 25 Nov 2011 11:04:55 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFG29576; Fri, 25 Nov 2011 11:04:55 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 Nov 2011 11:04:43 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 25 Nov 2011 11:04:47 +0800 Date: Fri, 25 Nov 2011 03:04:46 +0000 From: Mach Chen In-reply-to: <71D87D6111F94757A7B7D6002CAEEC12@hnivarlas1> X-Originating-IP: [10.108.4.60] To: iLya , "mpls@ietf.org" Message-id: 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] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping Thread-index: AcyqU1Nai2fKVCNrQGGbwyzFXbI2GQAK3PCAACeTqZA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <71D87D6111F94757A7B7D6002CAEEC12@hnivarlas1> Cc: "pwe3@ietf.org" Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 03:06:16 -0000 Hi iLya, Thanks for the comments! Since this draft mainly focuses on IPv6 PW FEC sub-TLVs, as Carlos said, your suggestion should be out of the scope of this draft. IMHO, there should another generic LSP Ping update draft to solve the issue you pointed out. Best regards, Mach > -----Original Message----- > From: iLya [mailto:ilya@nobulus.com] > Sent: Thursday, November 24, 2011 11:58 PM > To: Mach Chen; mpls@ietf.org > Cc: pwe3@ietf.org > Subject: Re: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > > Mach, > > I wonder if v6 lsp ping specs could be ammended to specify that if > intermediate node needs to return "TTL expired" and do not have route back > to the source they SHOULD send "TTL expired" along the same path as original > packet would have taken. I know v4 lsp ping specs doesn't have such point, > but since that creates problem in Inter-AS MPLS Option C environment while > plain IP traceroute doesn't have such problem (due to above described ICMP > tunneling) it would be nice if v6 lsp ping could fix the issue. > > Cheers, > iLya > > -------------------------------------------------- > From: "Mach Chen" > Sent: Thursday, November 24, 2011 3:46 AM > To: > Cc: > Subject: [mpls] Solicit comments on draft-chen-mpls-ipv6-pw-lsp-ping > > > Hi, > > > > We presented the draft in IETF 82th meeting (both in MPLS and PW3 WG) and > > did not receive technical comments there. Although the authors think that > > the draft is quite straightforward and stable, we'd like that you could > > spend some time to read the draft and give your comments. > > > > Any comments and feedbacks are appreciated! > > > > Here is the pointer: > > http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02 . > > > > Many thanks, > > Mach > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > From iesg-secretary@ietf.org Mon Nov 28 07:06:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2521F8C88; Mon, 28 Nov 2011 07:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7kvYzQu6z9E; Mon, 28 Nov 2011 07:06:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8121F8BF4; Mon, 28 Nov 2011 07:06:38 -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.64 Message-ID: <20111128150638.24732.93054.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2011 07:06:38 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:06:39 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overview/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overview/ No IPR declarations have been submitted directly on this I-D. From david.i.allan@ericsson.com Mon Nov 28 09:52:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BB621F8AC3 for ; Mon, 28 Nov 2011 09:52:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4RHJ-jC6nxF for ; Mon, 28 Nov 2011 09:52:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 632B621F899D for ; Mon, 28 Nov 2011 09:52:46 -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 pASHqZYB021750 for ; Mon, 28 Nov 2011 11:52:45 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.43]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 28 Nov 2011 12:52:34 -0500 From: David Allan I To: "mpls@ietf.org" Date: Mon, 28 Nov 2011 12:52:29 -0500 Thread-Topic: Draft on Shared Mesh Protection Thread-Index: Acyt9n8JxvH+JkChTlyjrdYA0d9A6A== Message-ID: <60C093A41B5E45409A19D42CF7786DFD5228A7EB60@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5228A7EB60EUSAACMS0703e_" MIME-Version: 1.0 Subject: [mpls] Draft on Shared Mesh Protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 17:52:47 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5228A7EB60EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to draw the WGs attention to "A framework for the use of SPMEs for= shared mesh protection" http://datatracker.ietf.org/doc/draft-allan-spme-smp-fmwk/ This differs from other proposals in this space in that it focuses on imple= menting business policy via packet level preemption vs. path level preempti= on. We believe there are a lot of operational and implementation complexities t= hat can be avoided with such an approach as it merely becomes a planning ex= ercise combined with existing kit. The actual behavior is to degrade pre-empted services vs. completely blocki= ng them as the selector is the SPME TC bits, and not a protocol. However th= e implication is there is no explicit notification to the endpoints of pree= mpted services that the degredation is happening. They would have to infer = this from PM or CC failure... The authors would seek operator feedback on whether explicit notification i= s a real requirement, noting that this goes hand in hand with "your service= has been completely preempted...". We would be similarly interested if the= re is room for the WG to consider both approaches... Much thanks Dave & Greg --_000_60C093A41B5E45409A19D42CF7786DFD5228A7EB60EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'd like to draw the WGs attention to "A framework for the use of= SPMEs for shared mesh protection"
 
 
This differs from other proposals in this space in that it focuses on = implementing business policy via packet level preemption vs. path level pre= emption.
 
We believe there are a lot of operational and implementation complexit= ies that can be avoided with such an approach as it merely becomes a planni= ng exercise combined with existing kit.
 
The actual behavior is to degrade pre-empted services vs. completely b= locking them as the selector is the SPME TC bits, and not a protocol. Howev= er the implication is there is no explicit notification to the endpoints of= preempted services that the degredation is happening. They would have to infer this from PM or CC failure...
 
The authors would seek operator feedback on whether explicit notificat= ion is a real requirement, noting that this goes hand in hand with "yo= ur service has been completely preempted…". We would be similarl= y interested if there is room for the WG to consider both approaches...
 
Much thanks
Dave & Greg
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD5228A7EB60EUSAACMS0703e_-- From gregory.mirsky@ericsson.com Mon Nov 28 11:29:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9B921F8B42; Mon, 28 Nov 2011 11:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq9cmh2ohN6g; Mon, 28 Nov 2011 11:28:59 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83321F8B2F; Mon, 28 Nov 2011 11:28:59 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pASJSd7F029962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Nov 2011 13:28:57 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.103]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 28 Nov 2011 14:28:55 -0500 From: Gregory Mirsky To: Shahram Davari , "'stbryant@cisco.com'" , "'yaakov_s@rad.com'" Date: Mon, 28 Nov 2011 14:28:52 -0500 Thread-Topic: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Thread-Index: AcysmVwcfQ0Tjw/xS9apvb81elccigAFiL6EAFTTYBA= Message-ID: References: <4ED1808C.8080901@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1CEA@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1CEA@SJEXCHCCR02.corp.ad.broadcom.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 Cc: "mpls@ietf.org" , "'tictoc@ietf.org'" Subject: Re: [mpls] [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 19:29:00 -0000 Dear Shahram, et al., I think that adding MPLS WG to the discussion is helpful. Thus I'll take th= e liberty to copy to the list. And I don't agree that combination of TC transport over MPLS domain with cl= ock distribution within it inherently creates layer violation. As I've ment= ioned, PTP can be distributed over PSN that interconnects 1588-capable node= s if IP encapsulation used or as MS-PW if Ethernet encapsulation used. Regards, Greg -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Shahram Davari Sent: Saturday, November 26, 2011 6:52 PM To: 'stbryant@cisco.com'; 'yaakov_s@rad.com' Cc: 'tictoc@ietf.org' Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Hi Stewart, Your proposal also does layer violation. TC by nature does layer violation.= Advantage of our approach is that it uses existing PW encapsulation, and d= oesn't require new protocol.=20 Your solution can be further explored in a new draft as a more generic solu= tion, noting that requires new protocol and new parsing. =20 Thx Shahram. ----- Original Message ----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Saturday, November 26, 2011 04:13 PM To: Yaakov Stein Cc: Shahram Davari; 'tictoc@ietf.org' Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Yaakov I was not thinking of a particularly radical packet type. A label stack, a 64 bit delay field, and then any timing payload you like (= specific details out of scope for the draft). The P routers then just add and subtract the current time from the delay fi= eld to update it with the dwell time. The Edge will know what the timing payload type is and can make the TC corr= ection based on the delay field. The important point is that this works for any packet type that needs to kn= ow delay, be that a timing payload such as 1588v2, 1588v3, NTPv4, NTPv5 etc= etc. It also as Yaakov notes works for any other payload type such as a pa= yload that needs to perform synchronous delivery at multiple disjoint endpo= ints, or a 1+1 protection system that is required to provide synchronied st= reams etc etc. - Stewart On 26/11/2011 20:24, Yaakov Stein wrote: > Shahram and Stewart > > If we need intermediate MPLS nodes to perform special processing on=20 > 1588oMPLS packets there are several methods to lower the processing requi= rements. > Of course, DPI could be performed to go below the MPLS and IP headers=20 > as Shahram said, but as Stewart pointed out this would be prohibitively e= xpensive. > > Two methods have been proposed. > The method of the present draft is to use the standard encapsulations=20 > (after ensuring that 1588 is supported) and to inform the intermediate=20 > nodes that the particular label value being used is special. > For this special label value the node has been informed of what to do,=20 > e.g., has the offset of a TC. > Any use of TC is necessarily a layer violation (after all, the=20 > timestamp is a layer-0 entity and we are placing it in a layer 2 or=20 > higher field), but correcting a field inside 1588 in UDP in IP in MPLS=20 > is not really that much worse than correcting on in 1588 in UDP in IP in = Ethernet. > > The alternative method that I proposed is to invent a completely new time= stamping mechanism. > This has the advantage of being applicable to all MPLS packets (and=20 > thus can solve other problems), but requires inventing yet another=20 > timing distribution protocol. > I know that Stewart succeeded in inventing a new packet loss and delay=20 > measurement protocol for TP, but I didn't gauge support in TICTOC for som= ething new here. > > Y(J)S > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, November 24, 2011 19:30 > To: Shahram Davari > Cc: 'tictoc-chairs@tools.ietf.org'; 'tictoc@ietf.org' > Subject: Re: [TICTOC] FW: I-D Action:=20 > draft-ietf-tictoc-1588overmpls-02.txt > > Shahram > > I will ponder the answer to this question, but will note that you have=20 > not addressed my second question which relates to whether there is=20 > MPLS WG buy-in for this proposal. > > - Stewart > > > > On 24/11/2011 16:34, Shahram Davari wrote: >> Hi Stewart, >> >> The parsing required by the draft is not complex and almost all MPLS rou= ters have support it already. The idea was to reuse existing data plane mec= hanisms and not invent a new one. This I believe is in the spirit of IETF t= o reuse existing mechanisms. >> >> I don't believe adding a shim makes the design simpler. You still need t= o detect that such shim exists and for that you need parsing that doesn't e= ven exist today. >> >> >> This draft has been implemented by vendors, so we have a working code an= d I believe we also have rough consensus. >> >> Thanks >> Shahram >> >> >> >> ----- Original Message ----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Thursday, November 24, 2011 07:58 AM >> To: stbryant@cisco.com >> Cc: tictoc-chairs@tools.ietf.org;=20 >> tictoc@ietf.org >> Subject: Re: [TICTOC] FW: I-D Action:=20 >> draft-ietf-tictoc-1588overmpls-02.txt >> >> Can we wind back to my original points here which have not addressed. >> >> Why are is the WG proposing a design that needs such complex parsing,=20 >> against the ethos of MPLS, when a simpler design would be more=20 >> universally applicable? >> >> Does the WG have any input to suggest that the design will survive a=20 >> review by MPLS/PWE3 WG and then by IESG? >> >> - Stewart >> >> >> On 22/11/2011 09:12, Stewart Bryant wrote: >>> Speaking as an individual here, I really have a hard time=20 >>> understanding why it is necessary to have quite the egregious layer=20 >>> violation that this draft uses. >>> >>> The idea of having an LSP type that is dedicated to tracking the=20 >>> time of passage through the network is a good idea. However MPLS is=20 >>> completely geared to the concept that only the LSP endpoints know=20 >>> how to resolve the payload type. >>> >>> The function that you require could be achieved by including a shim=20 >>> that contains the time compensation information and adjust the=20 >>> payload on egress from the LSP. That would be rather more consistent=20 >>> with the MPLS architecture. >>> >>> I have not seen a request for review by the MPLS or PWE3 WGs and I=20 >>> would suggest that you request that sooner rather than later since=20 >>> it is inevitable that the draft will be sent there later in it's=20 >>> life, and if they do not subscribe to your mode of operation the=20 >>> draft is unlikely to progress. >>> >>> I would also suggest that you discuss the extent of layer violation=20 >>> with your AD to make sure he is confident that this draft will pass=20 >>> IESG review. >>> >>> - Stewart >>> >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >>> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From sriganeshkini@gmail.com Mon Nov 28 15:35:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624221F8CE5 for ; Mon, 28 Nov 2011 15:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svAi0H8lQUCn for ; Mon, 28 Nov 2011 15:35:23 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3142C21F8CE0 for ; Mon, 28 Nov 2011 15:35:23 -0800 (PST) Received: by eabm6 with SMTP id m6so2700284eab.31 for ; Mon, 28 Nov 2011 15:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=f1qbREMeh5HZ6x7yKppkKCqNwmWIO408IoiLAVitSk4=; b=EnmWgeFB3N+IpIHbPdIek4nUfM3Kc5JH0+3atk8xb6tT56aeFJRsViY18v+KQDNCvR D57S5yh4qgw/q8Q8Bg3cS54JPaTXu1QEv/KiT51qy9/1bcR9O4O7jMYxuDUPd+L5XQuy DdPuqs63aWtblkKL55Jtn0mz7O9RJZtisCO1g= Received: by 10.180.18.10 with SMTP id s10mr1562303wid.21.1322523322317; Mon, 28 Nov 2011 15:35:22 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.4.84 with HTTP; Mon, 28 Nov 2011 15:34:51 -0800 (PST) From: Sriganesh Kini Date: Mon, 28 Nov 2011 15:34:51 -0800 X-Google-Sender-Auth: ZpUZV1v42veEhtDMeLDfFV5PIA4 Message-ID: To: mpls@ietf.org, draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2011 23:35:24 -0000 Hi, Some comments - First of all I don't buy this argument that it "MAY" be applicable to MPLS-TP (as stated by Mach in another email thread). Either it is, or it is not, it should be stated clearly. I don't see a strong reason why this should not be applicable. sec 3.3 - What if tunnel is static and not signaled ? sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID from the Tunnel ID as defined in RFC 6370. That should handle the static case as well. sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present but echo-response is being sent over a LSP (i.e. an LSP chosen by egress but not explicitly requested by ingress). sec 4.2 - What does a LSR do when it sees the new reply-mode (and understands it) but is not the egress of the LSP. Does it reply with an error code ? Or does it silently drop the packet ? sec 4.3 - If a routable IP network is not present how is source address chosen ? sec 4.3 - Value to be set for MPLS TTL must be specified. sec 5 - The security attack by "proxying" still seems possible when the label on the last hop is NULL. Verifying return path solely using an address would not avoid all possible attacks. Strict authentication would still be needed. sec 6.2.1 - Is explicitly identifying the setup protocol RSVP required ? If we remove that, the static case could be wrapped in. Generic comment - What if tunnel is P2MP ? Editorial nits - sec 6.2.2 - "from the" is repeated twice -- - Sri From mach.chen@huawei.com Tue Nov 29 01:32:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8366D21F8BDC for ; Tue, 29 Nov 2011 01:32:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+SdrTQgH7U2 for ; Tue, 29 Nov 2011 01:32:22 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3021F8BBE for ; Tue, 29 Nov 2011 01:32:21 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF00KHV13XEP@szxga04-in.huawei.com> for mpls@ietf.org; Tue, 29 Nov 2011 17:31:09 +0800 (CST) Received: from szxrg02-dlp.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 <0LVF00D8G13X4O@szxga04-in.huawei.com> for mpls@ietf.org; Tue, 29 Nov 2011 17:31:09 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFI22216; Tue, 29 Nov 2011 17:31:07 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 Nov 2011 17:31:02 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 17:30:57 +0800 Date: Tue, 29 Nov 2011 09:30:55 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.108.4.60] To: Sriganesh Kini , "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Message-id: 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] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 Thread-index: AQHMriZuA4y+7qvjMkCazCM5vyh08pXDKAFw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 09:32:23 -0000 Hi Sri, Many thanks for your comments! Please see my reply inline... > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Sriganesh Kini > Sent: Tuesday, November 29, 2011 7:35 AM > To: mpls@ietf.org; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 > > Hi, > > Some comments - > > First of all I don't buy this argument that it "MAY" be applicable to > MPLS-TP (as stated by Mach in another email thread). Either it is, or > it is not, it should be stated clearly. I don't see a strong reason > why this should not be applicable. The draft is originally designed for IP/MPLS network, and theoretically, as you said, the idea can apply to MPLS-TP as well, but some extensions and updates are needed to cover MPLS-TP scenarios. That's the main reason why I said "MAY". I am OK to extend the draft to cover MPLS-TP if there is no objection from the WG. > sec 3.3 - What if tunnel is static and not signaled ? Then the sub-TLVs defined in RFC6426 will be used, which are designed for static LSP and PW. > sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID > from the Tunnel ID as defined in RFC 6370. That should handle the > static case as well. If MPLS-TP is in scope, then it should be as you suggested. > sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present but > echo-response is being sent over a LSP (i.e. an LSP chosen by egress > but not explicitly requested by ingress). RP TC sub-TLV is carried in RP TLV, and if the "reply via specified path" mode is used, RP TLV must be carried in either echo request or echo reply. If the RP TLV is not present, there will be no RP TC sub-TLV, so the RP TC sub-TLV can not apply to the scenario your described. > sec 4.2 - What does a LSR do when it sees the new reply-mode (and > understands it) but is not the egress of the LSP. Does it reply with > an error code ? Or does it silently drop the packet ? This should be a typical CV error, and there will be an error code(e.g., return code 3 - Replying router is an egress for the FEC at stack-depth ) returned if there is a return path, the related procedures defined in RFC4379 will be inherited here. If there is no return path, it should drop the packet. > sec 4.3 - If a routable IP network is not present how is source address chosen ? This is also related to MPLS-TP scenario, the current text does not cover this. And also, if MPLS-TP is in scope, some Non-IP-based encapsulation should be defined. > sec 4.3 - Value to be set for MPLS TTL must be specified. Why does it need to specify the TLL? Could you please elaborate the scenario? > sec 5 - The security attack by "proxying" still seems possible when > the label on the last hop is NULL. Verifying return path solely using > an address would not avoid all possible attacks. Strict authentication > would still be needed. Yes, there are also some other comments about the security consideration, the authors will think over the comments and improve it in the next revision > sec 6.2.1 - Is explicitly identifying the setup protocol RSVP required > ? If we remove that, the static case could be wrapped in. Yes, if MPLS-TP is in scope. > Generic comment - What if tunnel is P2MP ? The P2MP is out of scope :-) > > Editorial nits - > sec 6.2.2 - "from the" is repeated twice Good catch! Will fix it in next revision. Many thanks, Mach > > -- > - Sri > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From sriganeshkini@gmail.com Tue Nov 29 11:29:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B48E1F0C94 for ; Tue, 29 Nov 2011 11:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCIeASyHcE5g for ; Tue, 29 Nov 2011 11:29:35 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB11F1F0C8D for ; Tue, 29 Nov 2011 11:29:34 -0800 (PST) Received: by eabm6 with SMTP id m6so3986502eab.31 for ; Tue, 29 Nov 2011 11:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cVwllVZw6eiy88/tbUQcDoY/ht9Vicjjf2daXY4trlc=; b=H/FyQVbg8CTYD2ItPr5iMiVsiPOfBGlCoGznpecLYgqbUonh6l43JqYH4iPSz6fSn7 AburFWEZjN1hfM8uWUT/a5S1XOe8LEXakHAov+CcWVRbHlN7wbk0ALS1ZldHtel8qevi dQgVC/2dWRDanfHity7BS8c7RCY9gKjSsHoxI= MIME-Version: 1.0 Received: by 10.227.197.71 with SMTP id ej7mr31272887wbb.15.1322594974071; Tue, 29 Nov 2011 11:29:34 -0800 (PST) Sender: sriganeshkini@gmail.com Received: by 10.216.4.84 with HTTP; Tue, 29 Nov 2011 11:29:33 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Nov 2011 11:29:33 -0800 X-Google-Sender-Auth: aMPmGCpqcXlRKRkM2LqVZGPO7-M Message-ID: From: Sriganesh Kini To: Mach Chen Content-Type: multipart/alternative; boundary=0015174c45b09c7c1e04b2e4a324 Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 19:29:36 -0000 --0015174c45b09c7c1e04b2e4a324 Content-Type: text/plain; charset=UTF-8 Mach, see inline. On Tuesday, November 29, 2011, Mach Chen wrote: > Hi Sri, > > Many thanks for your comments! > > Please see my reply inline... >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Sriganesh Kini >> Sent: Tuesday, November 29, 2011 7:35 AM >> To: mpls@ietf.org; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org >> Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 >> >> Hi, >> >> Some comments - >> >> First of all I don't buy this argument that it "MAY" be applicable to >> MPLS-TP (as stated by Mach in another email thread). Either it is, or >> it is not, it should be stated clearly. I don't see a strong reason >> why this should not be applicable. > > The draft is originally designed for IP/MPLS network, and theoretically, as you said, the idea can apply to MPLS-TP as well, but some extensions and updates are needed to cover MPLS-TP scenarios. That's the main reason why I said "MAY". IMO it must include TP since lsp ping is a tool used in TP. > > I am OK to extend the draft to cover MPLS-TP if there is no objection from the WG. > >> sec 3.3 - What if tunnel is static and not signaled ? > > Then the sub-TLVs defined in RFC6426 will be used, which are designed for static LSP and PW. Pls update the draft. When will static pw sub TLV be used ? > >> sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID >> from the Tunnel ID as defined in RFC 6370. That should handle the >> static case as well. > > If MPLS-TP is in scope, then it should be as you suggested. Ok. > >> sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present but >> echo-response is being sent over a LSP (i.e. an LSP chosen by egress >> but not explicitly requested by ingress). > > RP TC sub-TLV is carried in RP TLV, and if the "reply via specified path" mode is used, RP TLV must be carried in either echo request or echo reply. > If the RP TLV is not present, there will be no RP TC sub-TLV, so the RP TC sub-TLV can not apply to the scenario your described. My point was whether RP TC sub TLV should be made a TLV instead. It's value seems to be useful whenever the reply path is a LSP independent of whether the ping originator has requested the reply via a specific tunnel. > >> sec 4.2 - What does a LSR do when it sees the new reply-mode (and >> understands it) but is not the egress of the LSP. Does it reply with >> an error code ? Or does it silently drop the packet ? > > This should be a typical CV error, and there will be an error code(e.g., return code 3 - Replying router is an egress for the FEC at stack-depth ) returned if there is a return path, the related procedures defined in RFC4379 will be inherited here. If there is no return path, it should drop the packet. Thinking some more on this is it really necessary to special case this ? If the trace route mode of rfc 4379 is used as-is and the RP TLV applies to the node at which TTL expired shouldn't it work ? > >> sec 4.3 - If a routable IP network is not present how is source address chosen ? > > This is also related to MPLS-TP scenario, the current text does not cover this. And also, if MPLS-TP is in scope, some Non-IP-based encapsulation should be defined. > >> sec 4.3 - Value to be set for MPLS TTL must be specified. > > Why does it need to specify the TLL? Could you please elaborate the scenario? We don't want implementations to guess the value of TTL. It should be 255 but the draft should explicitly state it. Similar to rfc 4379 specifying IP TTL value when using IP for echo reply. > >> sec 5 - The security attack by "proxying" still seems possible when >> the label on the last hop is NULL. Verifying return path solely using >> an address would not avoid all possible attacks. Strict authentication >> would still be needed. > > Yes, there are also some other comments about the security consideration, the authors will think over the comments and improve it in the next revision > >> sec 6.2.1 - Is explicitly identifying the setup protocol RSVP required >> ? If we remove that, the static case could be wrapped in. > > Yes, if MPLS-TP is in scope. Independent of whether TP is in scope this should be addressed. > >> Generic comment - What if tunnel is P2MP ? > > The P2MP is out of scope :-) > P2MP lsp ping is an RFC. Why would that be out of scope ? >> >> Editorial nits - >> sec 6.2.2 - "from the" is repeated twice > > Good catch! Will fix it in next revision. > > Many thanks, > Mach > >> >> -- >> - Sri >> _______________________________________________ >> 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 > -- Sriganesh Kini (Sri) --0015174c45b09c7c1e04b2e4a324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mach, see inline.

On Tuesday, November 29, 2011, Mach Chen <mach.chen@huawei.com> wrote:
&= gt; Hi Sri,
>
> Many thanks for your comments!
>
> = Please see my reply inline...
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>> Sri= ganesh Kini
>> Sent: Tuesday, November 29, 2011 7:35 AM
>> To: mpls@ietf.org; draft-ietf-mpls-return-p= ath-specified-lsp-ping@tools.ietf.org
>> Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-l= sp-ping-04
>>
>> Hi,
>>
>> Some comment= s -
>>
>> First of all I don't buy this argument that= it "MAY" be applicable to
>> MPLS-TP (as stated by Mach in another email thread). Either it is,= or
>> it is not, it should be stated clearly. I don't see a s= trong reason
>> why this should not be applicable.
>
> The draft is originally designed for IP/MPLS network, and theoreticall= y, as you said, the idea can apply to MPLS-TP as well, but some extensions = and updates are needed to cover MPLS-TP scenarios. That's the main reas= on why I said "MAY".

IMO it must include TP since lsp ping is a tool used in TP.

>=
> I am OK to extend the draft to cover MPLS-TP if there is no object= ion from the WG.
>
>> sec 3.3 - What if tunnel is static and= not signaled ?
>
> Then the sub-TLVs defined in RFC6426 will be used, which are d= esigned for static LSP and PW.

Pls update the draft. When will stati= c pw sub TLV be used ?

>
>> sec 3.3.1, 3.3.2 - I would s= uggest that we derive the RP tunnel ID
>> from the Tunnel ID as defined in RFC 6370. That should handle the<= br>>> static case as well.
>
> If MPLS-TP is in scope, th= en it should be as you suggested.

Ok.

>
>> sec 3.= 3.3 - Is RP TC sub-TLV applicable when RP TLV is not present but
>> echo-response is being sent over a LSP (i.e. an LSP chosen by egre= ss
>> but not explicitly requested by ingress).
>
> RP= TC sub-TLV is carried in RP TLV, and if the "reply via specified path= " mode is used, RP TLV must be carried in either echo request or echo = reply.
> If the RP TLV is not present, there will be no RP TC sub-TLV, so the R= P TC sub-TLV can not apply to the scenario your described.

My point = was whether RP TC sub TLV should be made a TLV instead. It's value seem= s to be useful whenever the reply path is a LSP independent of whether the = ping originator has requested the reply via a specific tunnel.

>
>> sec 4.2 - What does a LSR do when it sees the new repl= y-mode (and
>> understands it) but is not the egress of the LSP. D= oes it reply with
>> an error code ? Or does it silently drop the = packet ?
>
> This should be a typical CV error, and there will be an error = code(e.g., return code 3 - Replying router is an egress for the FEC at stac= k-depth <RSC>) returned if there is a return path, the related proced= ures defined in RFC4379 will be inherited here. If there is no return path,= it should drop the packet.

Thinking some more on this is it really necessary to special case this = ? If the trace route mode of rfc 4379 is used as-is and the RP TLV applies = to the node at which TTL expired shouldn't it work ?

>
>> sec 4.3 - If a routable IP network is not present how is source ad= dress chosen ?
>
> This is also related to MPLS-TP scenario, th= e current text does not cover this. And also, if MPLS-TP is in scope, some = Non-IP-based encapsulation should be defined.
>
>> sec 4.3 - Value to be set for MPLS TTL must be specified.<= br>>
> Why does it need to specify the TLL? Could you please elabo= rate the scenario?

We don't want implementations to guess the va= lue of TTL. It should be 255 but the draft should explicitly state it. Simi= lar to rfc 4379 specifying IP TTL value when using IP for echo reply.

>
>> sec 5 - The security attack by "proxying" st= ill seems possible when
>> the label on the last hop is NULL. Veri= fying return path solely using
>> an address would not avoid all p= ossible attacks. Strict authentication
>> would still be needed.
>
> Yes, there are also some ot= her comments about the security consideration, the authors will think over = the comments and improve it in the next revision
>
>> sec 6.= 2.1 - Is explicitly identifying the setup protocol RSVP required
>> ? If we remove that, the static case could be wrapped in.
><= br>> Yes, if MPLS-TP is in scope.

Independent of whether TP is in= scope this should be addressed.

>
>> Generic comment - = What if tunnel is P2MP ?
>
> The P2MP is out of scope :-)
>

P2MP lsp ping is a= n RFC. Why would that be out of scope ?

>>
>> Editori= al nits -
>> sec 6.2.2 - "from the" is repeated twice >
> Good catch! Will fix it in next revision.
>
> Many= thanks,
> Mach
>
>>
>> --
>> - Sri<= br>>> _______________________________________________
>> mpl= s mailing list
>> mpls@ietf.org
>> https://www.ietf.org/ma= ilman/listinfo/mpls
> ___________________________________________= ____
> mpls mailing list
> mpls@ietf.o= rg
> https= ://www.ietf.org/mailman/listinfo/mpls
>

--
Sriganesh K= ini (Sri)
--0015174c45b09c7c1e04b2e4a324-- From mach.chen@huawei.com Tue Nov 29 19:18:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED52E11E8091 for ; Tue, 29 Nov 2011 19:18:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEovIqqvKdef for ; Tue, 29 Nov 2011 19:18:06 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0A2D11E808D for ; Tue, 29 Nov 2011 19:18:05 -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 <0LVG00D24EGQ1I@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 30 Nov 2011 11:17:14 +0800 (CST) Received: from szxrg01-dlp.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 <0LVG002JIEGQ8A@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 30 Nov 2011 11:17:14 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFK76473; Wed, 30 Nov 2011 11:15:34 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 11:15:30 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 30 Nov 2011 11:15:23 +0800 Date: Wed, 30 Nov 2011 03:15:21 +0000 From: Mach Chen X-Originating-IP: [10.108.4.60] To: Sriganesh Kini Message-id: 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: Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 Thread-index: Acyu/Aq5p6fWoB4uR2axu1LqAOs3OQAEc/MQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 03:18:07 -0000 Hi Sri, Please see inline. > -----Original Message----- > From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On > Behalf Of Sriganesh Kini > Sent: Wednesday, November 30, 2011 3:30 AM > To: Mach Chen > Cc: Sriganesh Kini; mpls@ietf.org; > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Subject: Re: Comment on > draft-ietf-mpls-return-path-specified-lsp-ping-04 > > Mach, see inline. > > On Tuesday, November 29, 2011, Mach Chen > wrote: > > Hi Sri, > > > > Many thanks for your comments! > > > > Please see my reply inline... > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf Of Sriganesh Kini > >> Sent: Tuesday, November 29, 2011 7:35 AM > >> To: mpls@ietf.org; > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > >> Subject: [mpls] Comment on > draft-ietf-mpls-return-path-specified-lsp-ping-04 > >> > >> Hi, > >> > >> Some comments - > >> > >> First of all I don't buy this argument that it "MAY" be applicable > >> to MPLS-TP (as stated by Mach in another email thread). Either it > >> is, or it is not, it should be stated clearly. I don't see a strong > >> reason why this should not be applicable. > > > > The draft is originally designed for IP/MPLS network, and > > theoretically, as you > said, the idea can apply to MPLS-TP as well, but some extensions and > updates are needed to cover MPLS-TP scenarios. That's the main reason > why I said "MAY". > > IMO it must include TP since lsp ping is a tool used in TP. I am OK with that. > > > > > I am OK to extend the draft to cover MPLS-TP if there is no > > objection from the > WG. > > > >> sec 3.3 - What if tunnel is static and not signaled ? > > > > Then the sub-TLVs defined in RFC6426 will be used, which are > > designed for > static LSP and PW. > > Pls update the draft. When will static pw sub TLV be used ? Actually, the current draft has already included this, the RP TLV can carry any sub-TLV (including the static case) defined for the Target FEC stack TLV. Regarding to static PW, in theory, there is no difference between static and dynamic, or between LSP and PW, if you want to specify the reply path, it could be used. > > > > >> sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID > >> from the Tunnel ID as defined in RFC 6370. That should handle the > >> static case as well. > > > > If MPLS-TP is in scope, then it should be as you suggested. > > Ok. > > > > >> sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present > >> but echo-response is being sent over a LSP (i.e. an LSP chosen by > >> egress but not explicitly requested by ingress). > > > > RP TC sub-TLV is carried in RP TLV, and if the "reply via specified > > path" mode is > used, RP TLV must be carried in either echo request or echo reply. > > If the RP TLV is not present, there will be no RP TC sub-TLV, so the > > RP TC > sub-TLV can not apply to the scenario your described. > > My point was whether RP TC sub TLV should be made a TLV instead. It's > value seems to be useful whenever the reply path is a LSP independent > of whether the ping originator has requested the reply via a specific tunnel. Seems a good idea, we will consider it more and then decide how to deal with it. > > > > >> sec 4.2 - What does a LSR do when it sees the new reply-mode (and > >> understands it) but is not the egress of the LSP. Does it reply > >> with an error code ? Or does it silently drop the packet ? > > > > This should be a typical CV error, and there will be an error > > code(e.g., return > code 3 - Replying router is an egress for the FEC at stack-depth > ) returned if there is a return path, the related procedures > defined in RFC4379 will be inherited here. If there is no return path, it should drop the packet. > > Thinking some more on this is it really necessary to special case this > ? If the trace route mode of rfc 4379 is used as-is and the RP TLV > applies to the node at which TTL expired shouldn't it work ? This draft is only intended to ping mode, trace mode is out of scope, which is explicitly stated in Section 4. > > > > >> sec 4.3 - If a routable IP network is not present how is source > >> address > chosen ? > > > > This is also related to MPLS-TP scenario, the current text does not cover this. > And also, if MPLS-TP is in scope, some Non-IP-based encapsulation > should be defined. > > > >> sec 4.3 - Value to be set for MPLS TTL must be specified. > > > > Why does it need to specify the TLL? Could you please elaborate the > scenario? > > We don't want implementations to guess the value of TTL. It should be > 255 but the draft should explicitly state it. Similar to rfc 4379 > specifying IP TTL value when using IP for echo reply. OK, will state this in the revision. > > > > >> sec 5 - The security attack by "proxying" still seems possible when > >> the label on the last hop is NULL. Verifying return path solely > >> using an address would not avoid all possible attacks. Strict > >> authentication would still be needed. > > > > Yes, there are also some other comments about the security > > consideration, > the authors will think over the comments and improve it in the next > revision > > > >> sec 6.2.1 - Is explicitly identifying the setup protocol RSVP > >> required ? If we remove that, the static case could be wrapped in. > > > > Yes, if MPLS-TP is in scope. > > Independent of whether TP is in scope this should be addressed. OK. > > > > >> Generic comment - What if tunnel is P2MP ? > > > > The P2MP is out of scope :-) > > > > P2MP lsp ping is an RFC. Why would that be out of scope ? For P2MP, it is more complicate that P2P case, there are more things need to be considered. For example, how to specify the return paths? Just specify one for a leaf, or specify all the return paths for all leaves (may not scale). In addition, if the return path is also a P2MP tunnel, the echo reply will reach to the nodes that are not the originator of the echo request, this may cause some potential problems. So, the current draft is scoped to P2P scenario and leave the P2MP case for future study. Best regards, Mach > > >> > >> Editorial nits - > >> sec 6.2.2 - "from the" is repeated twice > > > > Good catch! Will fix it in next revision. > > > > Many thanks, > > Mach > > > >> > >> -- > >> - Sri > >> _______________________________________________ > >> 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 > > > > -- > Sriganesh Kini (Sri)