From gregory.mirsky@ericsson.com Fri Feb 3 12:38:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6650921F85E9 for ; Fri, 3 Feb 2012 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 SaHfkvG3L3Yn for ; Fri, 3 Feb 2012 12:38:23 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9972A21F85EC for ; Fri, 3 Feb 2012 12:38:23 -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 q13KcKF1030221; Fri, 3 Feb 2012 14:38:21 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 3 Feb 2012 15:38:19 -0500 From: Gregory Mirsky To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Fri, 3 Feb 2012 15:38:18 -0500 Thread-Topic: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: AczaDF1k8qDP9h4GQIuy8sT4XETymQImRiNw 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_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:38:24 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, do not support. Several reasons: * I think that problem of MAC withdrawal is out of scope of the PWE3 WG. I th= ink that this problem is in scope of the L2VPN. IMHO, before any MPLS-TP sp= ecific mechanisms for L2VPN are adopted we need to discuss applicability of= L2VPN and L3VPN, in particular when dynamic control plane is not used. * MAC Withrawal, MAC management in general, is not part of PW OAM and should = not re-use PW OAM G-ACh. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Monday, January 23, 2012 12:19 PM To: pwe3@ietf.org Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-ma= c-wd-02 This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/htm= l/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond = with your approval, disapproval, and other comments to the PWE3 list. If yo= u don't support the adoption, providing a reason would be useful to the aut= hors and the working group, but is not required. Of course, the reason why = you support the draft is also welcome, but also optional. This request will= be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew --_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
do not support.
Several reasons:
  • I think that problem of MAC withdrawal is out of scope of the PW= E3 WG.=20 I think that this problem is in scope of the L2VPN. IMHO, before any= =20 MPLS-TP specific mechanisms for L2VPN are adopted we need to discuss=20 applicability of L2VPN and L3VPN, in particular when dynamic control plan= e is=20 not used.
  • MAC Withrawal, MAC management in general, is not part of PW OAM = and=20 should not re-use PW OAM G-ACh.
 
  &n= bsp; Regards,
        Greg

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G.=20 Malis
Sent: Monday, January 23, 2012 12:19 PM
To:=20 pwe3@ietf.org
Subject: [PWE3] Starting WG adoption call for=20 draft-boutros-pwe3-mpls-tp-mac-wd-02

This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-= wd-02=20 , ending February 6. Please respond with your approval, disapproval, and ot= her=20 comments to the PWE3 list. If you don't support the adoption, providing a r= eason=20 would be useful to the authors and the working group, but is not required. = Of=20 course, the reason why you support the draft is also welcome, but also opti= onal.=20 This request will be a part of PWE3 WG adoption calls going=20 forward.

Thanks,
Andy and Matthew

--_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_-- From sriganeshkini@gmail.com Mon Feb 6 15:55:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3604F11E80BB for ; Mon, 6 Feb 2012 15:55:55 -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 rC42evUel+d7 for ; Mon, 6 Feb 2012 15:55:54 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99911E8075 for ; Mon, 6 Feb 2012 15:55:54 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so4953005wgb.13 for ; Mon, 06 Feb 2012 15:55:53 -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:cc:content-type; bh=lFusWG+OfO/i2NwkIPvAYyLi2716tCp19WioPNAxxL8=; b=C/Xboja2SFdQCAxXcOEIcL0M44sbci1tj3MSP/h4xoR/R0r/A2zJYQ099yhgITL6cK ZSVfMB6RpP+EHsDC3jG8TJECZ6qKkjpwJ4os8yQDx4+AlEdyacPokMH9hXWmb0iEkNBM USaBtQaemyj/wAJuDODBMbYOfK7XPu8X7ImHY= Received: by 10.180.109.77 with SMTP id hq13mr16132922wib.7.1328572553307; Mon, 06 Feb 2012 15:55:53 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.54.7 with HTTP; Mon, 6 Feb 2012 15:55:23 -0800 (PST) From: Sriganesh Kini Date: Mon, 6 Feb 2012 15:55:23 -0800 X-Google-Sender-Auth: w_wxdWzwyyGamKdkOAPzDqBc4Z8 Message-ID: To: "Andrew G. Malis" Content-Type: multipart/alternative; boundary=e89a8f3ba44519264404b85467ca Cc: pwe3@ietf.org Subject: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 23:55:55 -0000 --e89a8f3ba44519264404b85467ca Content-Type: text/plain; charset=UTF-8 Hi Sami and other authors, A few comments 1. Does the sequence numbers have any rollover procedures or other requirements ? 2. You mention that there are no security considerations. What if this packet is spoofed by say a man-in-the-middle attack ? On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis wrote: > This begins a two-week PWE3 WG adoption call for > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > February 6. Please respond with your approval, disapproval, and other > comments to the PWE3 list. If you don't support the adoption, providing a > reason would be useful to the authors and the working group, but is not > required. Of course, the reason why you support the draft is also welcome, > but also optional. This request will be a part of PWE3 WG adoption calls > going forward. > > Thanks, > Andy and Matthew > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > -- - Sri --e89a8f3ba44519264404b85467ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sami and other authors,

A few comments
1. D= oes the sequence numbers have any rollover procedures or other requirements= ?
2. You mention that there are no security considerations. What= if this packet is spoofed by say a man-in-the-middle attack ?

On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. = Malis <amalis@gmai= l.com> wrote:
This begins a two-week PWE3 WG adoption call for https:= //tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending Feb= ruary 6. Please respond with your approval, disapproval, and other comments= to the PWE3 list. If you don't support the adoption, providing a reaso= n would be useful to the authors and the working group, but is not required= . Of course, the reason why you support the draft is also welcome, but also= optional. This request will be a part of PWE3 WG adoption calls going forw= ard.

Thanks,
Andy and Matthew


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




--
- Sri
--e89a8f3ba44519264404b85467ca-- From sboutros@cisco.com Mon Feb 6 18:55:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8011E80BB for ; Mon, 6 Feb 2012 18:55:46 -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 LmzmqQTUNbWd for ; Mon, 6 Feb 2012 18:55:45 -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 C1EC211E809D for ; Mon, 6 Feb 2012 18:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=4049; q=dns/txt; s=iport; t=1328583345; x=1329792945; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=HSIpaUhoHbMbyJ9zPqNVbHwj97bMVwTWmDuJFEssNAc=; b=DXCtwvZGb47VkdTqpubgyVhMFXMOygy4tAsbeQ+PTsCjFMOGQM2vlnS/ kAXjhLwMr6m7yy99XxODZmBXgtUSFt45wB5mCTuE82J8PtI22iQedyOb6 LfM1iX6aLKWclu6gsrg/Lh24eAKtSJ7Etla72lWYSbtM2mNwc+vbAruvw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADCSME+rRDoJ/2dsb2JhbABCiCKnKYEFgXIBAQEEAQEBDwEKUQsQBwQEFCcHGQgGHxEGARIih2OaHQGXJwSIFYNDEwEIBQMDCSQBgw0FAxIdCiwFIYNYBIhEl26Hcg X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208,217";a="27358856" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 07 Feb 2012 02:55:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q172tjAA019714; Tue, 7 Feb 2012 02:55:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 18:55:45 -0800 Received: from sboutros-wxp01.ciswco.com ([10.21.168.234]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 18:55:45 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Feb 2012 18:55:41 -0800 To: Sriganesh Kini , "Andrew G. Malis" From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_295983281==.ALT" Message-ID: X-OriginalArrivalTime: 07 Feb 2012 02:55:45.0162 (UTC) FILETIME=[FCAC46A0:01CCE543] Cc: pwe3@ietf.org Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:55:46 -0000 --=====================_295983281==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Sri, At 03:55 PM 2/6/2012, Sriganesh Kini wrote: >Hi Sami and other authors, > >A few comments >1. Does the sequence numbers have any rollover procedures or other >requirements ? Sami: This is one of the comments that we need to address for sure as we progress the draft.. >2. You mention that there are no security considerations. What if >this packet is spoofed by say a man-in-the-middle attack ? Sami: The reason here is that we will be using static PW-OAM and our security will be no better or no worse that what this mechanism provide. Thanks, Sami >On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis ><amalis@gmail.com> wrote: >This begins a two-week PWE3 WG adoption call for >https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 >, ending February 6. Please respond with your approval, disapproval, >and other comments to the PWE3 list. If you don't support the >adoption, providing a reason would be useful to the authors and the >working group, but is not required. Of course, the reason why you >support the draft is also welcome, but also optional. This request >will be a part of PWE3 WG adoption calls going forward. > >Thanks, >Andy and Matthew > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 > > > > >-- >- Sri >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 --=====================_295983281==.ALT Content-Type: text/html; charset="us-ascii" Hi Sri,

At 03:55 PM 2/6/2012, Sriganesh Kini wrote:
Hi Sami and other authors,

A few comments
1. Does the sequence numbers have any rollover procedures or other requirements ?

Sami: This is one of the comments that we need to address for sure as we progress the draft..

2. You mention that there are no security considerations. What if this packet is spoofed by say a man-in-the-middle attack ?

Sami: The reason here is that we will be using static PW-OAM and our security will be no better or no worse that what this mechanism provide.

Thanks,

Sami

On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis <amalis@gmail.com> wrote:
This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward.

Thanks,
Andy and Matthew


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




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

--=====================_295983281==.ALT-- From sboutros@cisco.com Mon Feb 6 18:55:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2511E809D for ; Mon, 6 Feb 2012 18:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 EEo+ZAEoG63V for ; Mon, 6 Feb 2012 18:55:45 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C926211E80BA for ; Mon, 6 Feb 2012 18:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=5063; q=dns/txt; s=iport; t=1328583345; x=1329792945; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=9lY2uN9A4BnsAeam+AbO2Eey/zddCctVilfnUDglK3k=; b=M5Ak3R8H6cdTvtNmzBaH3aUi7d3oOwKCxxC5ntQLGaGB+3N47S+hdOiD 7/0pBzzfbgskbkforW2uiwxs04ggEIZzBsLFycVKLWbCEFLLGpMsSyjI9 OekcgxdQOCovGCEK0D3XIgy/Z9siHAVcIkxOw2KBgFO4CP0r6K5PTkl5w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGSSME+rRDoJ/2dsb2JhbABDiB6nKYEFgXIBAQEDAQEBAQ8BClEQCwcEBA0EAQEBJwcZDh8JCAYBEiKHWgmaBgGfDwSLWBMBCAUDAwkkAYMNBQMSJzEhg1gEiESfYA X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208,217";a="29081528" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Feb 2012 02:55:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q172tjA8019714; Tue, 7 Feb 2012 02:55:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 18:55:45 -0800 Received: from sboutros-wxp01.ciswco.com ([10.21.168.234]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 18:55:44 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Feb 2012 18:54:10 -0800 To: Gregory Mirsky , "Andrew G. Malis" , "pwe3@ietf.org" From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_295983156==.ALT" Message-ID: X-OriginalArrivalTime: 07 Feb 2012 02:55:44.0850 (UTC) FILETIME=[FC7CAB20:01CCE543] Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:55:46 -0000 --=====================_295983156==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Greg, Please see comments inline.. At 12:38 PM 2/3/2012, Gregory Mirsky wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_" > >Dear All, >do not support. >Several reasons: >I think that problem of MAC withdrawal is out of scope of the PWE3 >WG. I think that this problem is in scope of the L2VPN. IMHO, before >any MPLS-TP specific mechanisms for L2VPN are adopted we need to >discuss applicability of L2VPN and L3VPN, in particular when dynamic >control plane is not used. Sami: This is a requirement when deploying static PWs in an H-VPLS scenario along with PW-redundancy. I don't think this can be ignored.. >MAC Withrawal, MAC management in general, is not part of PW OAM and >should not re-use PW OAM G-ACh. > Sami: So, how do you propose achieving this function for static PWs if we don't use PW-OAM? Thanks, Sami > Regards, > Greg > > >---------- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf >Of Andrew G. Malis >Sent: Monday, January 23, 2012 12:19 PM >To: pwe3@ietf.org >Subject: [PWE3] Starting WG adoption call for >draft-boutros-pwe3-mpls-tp-mac-wd-02 > >This begins a two-week PWE3 WG adoption call for >https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 >, ending February 6. Please respond with your approval, disapproval, >and other comments to the PWE3 list. If you don't support the >adoption, providing a reason would be useful to the authors and the >working group, but is not required. Of course, the reason why you >support the draft is also welcome, but also optional. This request >will be a part of PWE3 WG adoption calls going forward. > >Thanks, >Andy and Matthew > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 --=====================_295983156==.ALT Content-Type: text/html; charset="us-ascii" Hi Greg,

Please see comments inline..

At 12:38 PM 2/3/2012, Gregory Mirsky wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_"

Dear All,
do not support.
Several reasons:
    I think that problem of MAC withdrawal is out of scope of the PWE3 WG. I think that this problem is in scope of the L2VPN. IMHO, before any MPLS-TP specific mechanisms for L2VPN are adopted we need to discuss applicability of L2VPN and L3VPN, in particular when dynamic control plane is not used.

Sami: This is a requirement when deploying static PWs in an H-VPLS scenario along with PW-redundancy. I don't think this can be ignored..

    MAC Withrawal, MAC management in general, is not part of PW OAM and should not re-use PW OAM G-ACh.
 

Sami: So, how do you propose achieving this function for static PWs if we don't use PW-OAM?

Thanks,

Sami

    Regards,
        Greg

From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Monday, January 23, 2012 12:19 PM
To: pwe3@ietf.org
Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02

This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward.

Thanks,
Andy and Matthew

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

--=====================_295983156==.ALT-- From internet-drafts@ietf.org Mon Feb 6 20:27:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C369411E80DE; Mon, 6 Feb 2012 20:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Hr5EaiqujCoo; Mon, 6 Feb 2012 20:27:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3A11E8086; Mon, 6 Feb 2012 20:27: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.64p1 Message-ID: <20120207042726.28578.34160.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 20:27:26 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 04:27:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : LDP Typed Wildcard FEC for PWid and Generalized PWid FEC= Elements Author(s) : Kamran Raza Sami Boutros Carlos Pignataro Filename : draft-ietf-pwe3-pw-typed-wc-fec-03.txt Pages : 9 Date : 2012-02-06 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-03.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-pwe3-pw-typed-wc-fec-03.txt From skraza@cisco.com Mon Feb 6 20:39:02 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9611E80E0; Mon, 6 Feb 2012 20:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.202 X-Spam-Level: X-Spam-Status: No, score=-7.202 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 f8-Mn4q1dZZZ; Mon, 6 Feb 2012 20:39:01 -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 499FF11E8086; Mon, 6 Feb 2012 20:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2503; q=dns/txt; s=iport; t=1328589541; x=1329799141; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=aos4+hkz+5uDo24+5umEo1RzsU67AdTyEdGc1OqhjWw=; b=gC3m8ERz75HPJG0mqk2JrlEFrLTpcZ59aeGzOLPYvKX4aAdCFTO1yUvJ gxznaaXNAy0RT7Ay7QVLCGGJaAEVArGO4dMAZfsmcnVegMzyA5QQpxW6+ vMkjsO71AHOOx9iEP2WLNIITXOeNCj8/0RlWjqrsWarwHbyP7pA+WmmZL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEKqME+tJXG8/2dsb2JhbAA/A65kZ4EFgXIBAQEDAQEBAQ8BKQEYEQgLEgF1MAEBBA4FCRmHWgmZUwGXI4stKxMBCAUDAwkHAQcHAoQtJgEQBYMcBIgRM4xkknk X-IronPort-AV: E=Sophos;i="4.73,374,1325462400"; d="scan'208";a="56863064" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 07 Feb 2012 04:39:01 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q174d0Zn016185; Tue, 7 Feb 2012 04:39:00 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 22:39:00 -0600 Received: from 10.86.255.42 ([10.86.255.42]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Feb 2012 04:39:00 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 06 Feb 2012 23:39:27 -0500 From: Kamran Raza To: Message-ID: Thread-Topic: Summary of changes [Re: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-03.txt] Thread-Index: AczlUnkt+lXc9ScklEePEb0O9TxKBw== In-Reply-To: <20120207042726.28578.34160.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 07 Feb 2012 04:39:00.0752 (UTC) FILETIME=[69884900:01CCE552] Cc: l2vpn@ietf.org, "Carlos Pignataro \(cpignata\)" , "Malis, Andrew G \(Andy\)" Subject: [PWE3] Summary of changes [Re: I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-03.txt] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 04:39:02 -0000 The changes from rev -02 to -03 mainly incorporates comments received durin= g WG LC: 1- Clarifies that PW Typed WC FEC can be used in any LDP message that allow= s FEC element - i.e. Label messages, Address Withdraw [ for VPLS], and Notification. 2 - New Section 4.4: Applicability of PW Typed WC FEC in VPLS MAC Withdrawal to allow a PE node to =B3wildcard=B2 withdraw **all** MAC addresses for: =20 o all VPLS instances; or o all VPLS instances corresponding to a given PW type. =20 [ Ack Daniel Cohn for his input ] 3- Mandates that VPLS MAC Wdw (Address Withdrawal) MUST contain an =B3empty=B2 list if PW Typed WC specified in FEC TLV. Rgds, -- Kamran On 12-02-06 11:27 PM, "internet-drafts@ietf.org" wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Pseudowire Emulation Edge t= o > Edge Working Group of the IETF. >=20 > Title : LDP Typed Wildcard FEC for PWid and Generalized PWid FE= C > Elements > Author(s) : Kamran Raza > Sami Boutros > Carlos Pignataro > Filename : draft-ietf-pwe3-pw-typed-wc-fec-03.txt > Pages : 9 > Date : 2012-02-06 >=20 > The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" > defines an extension to the Label Distribution Protocol (LDP) that > can be used when it is desired to request or withdraw or release all > label bindings for a given FEC Element type. However, a typed > wildcard FEC element must be individually defined for each FEC > element type. This specification defines the typed wildcard FEC > elements for the PWid (0x80) and Generalized PWid (0x81) FEC element > types. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-03.tx= t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-03.txt >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --=20 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 From gregory.mirsky@ericsson.com Mon Feb 6 21:47:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CD121F8596 for ; Mon, 6 Feb 2012 21:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 7uPnHBLtpTXi for ; Mon, 6 Feb 2012 21:47:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4DECB21F858E for ; Mon, 6 Feb 2012 21:47:56 -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 q175lrxD016510; Mon, 6 Feb 2012 23:47:54 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 7 Feb 2012 00:47:47 -0500 From: Gregory Mirsky To: Sami Boutros , "Andrew G. Malis" , "pwe3@ietf.org" Date: Tue, 7 Feb 2012 00:47:42 -0500 Thread-Topic: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: AczlRAIke17oQAJ7QN61ww239i3abwAFrTqA 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_FE60A4E52763E84B935532D7D9294FF1322B3173A3EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:47:57 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322B3173A3EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sami, thank you for interest in my comments. Please find my notes in-lined tagged= GIM>>. Regards, Greg ________________________________ From: Sami Boutros [mailto:sboutros@cisco.com] Sent: Monday, February 06, 2012 6:54 PM To: Gregory Mirsky; Andrew G. Malis; pwe3@ietf.org Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-t= p-mac-wd-02 Hi Greg, Please see comments inline.. At 12:38 PM 2/3/2012, Gregory Mirsky wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary=3D"_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACM= S0715e_" Dear All, do not support. Several reasons: I think that problem of MAC withdrawal is out of scope of the PWE3 WG. I th= ink that this problem is in scope of the L2VPN. IMHO, before any MPLS-TP sp= ecific mechanisms for L2VPN are adopted we need to discuss applicability of= L2VPN and L3VPN, in particular when dynamic control plane is not used. Sami: This is a requirement when deploying static PWs in an H-VPLS scenario= along with PW-redundancy. I don't think this can be ignored.. GIM>> H-VPLS is not PWE3 but L2VPN construct. And MAC management is not pa= rt of TDM PW or ATM PW. I'm not suggesting to "ignore" MAC Management but t= o address it in appropriate IETF WG. MAC Withrawal, MAC management in general, is not part of PW OAM and should = not re-use PW OAM G-ACh. Sami: So, how do you propose achieving this function for static PWs if we d= on't use PW-OAM? GIM>> I suggest request MAC Management VCCV PW ACH code point from IANA. I= believe that MAC management is not element of PW OAM, unlike Continuity Ch= eck, Connectivity Verification, Loss and Delay Measurement that are common = to all types of PWs. Thanks, Sami Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On Behalf Of An= drew G. Malis Sent: Monday, January 23, 2012 12:19 PM To: pwe3@ietf.org Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-ma= c-wd-02 This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/htm= l/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond = with your approval, disapproval, and other comments to the PWE3 list. If yo= u don't support the adoption, providing a reason would be useful to the aut= hors and the working group, but is not required. Of course, the reason why = you support the draft is also welcome, but also optional. This request will= be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF1322B3173A3EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sami,
thank you for interest in my comments. Please find= my notes=20 in-lined tagged GIM>>.
 
  &n= bsp; Regards,
        Greg

From: Sami Boutros [mailto:sboutros@cis= co.com]=20
Sent: Monday, February 06, 2012 6:54 PM
To: Gregory Mi= rsky;=20 Andrew G. Malis; pwe3@ietf.org
Subject: Re: [PWE3] Starting WG=20 adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02

Hi Greg,

Please see comments inline..

At 12:38 PM= =20 2/3/2012, Gregory Mirsky wrote:
Content-Language:=20 en-US
Content-Type:=20 multipart/alternative;
      &nbs= p; =20 boundary=3D"_000_FE60A4E52763E84B935532D7D9294FF1322B316C3AEUSAACMS0715e_= "

Dear All,
do not support.
Several reasons:= =20
    I think that problem of MAC withdrawal is out of scope of the PWE3 WG= . I=20 think that this problem is in scope of the L2VPN. IMHO, before any MPLS= -TP=20 specific mechanisms for L2VPN are adopted we need to discuss applicabil= ity=20 of L2VPN and L3VPN, in particular when dynamic control plane is not=20 used.

    Sami: This is a requirement when deploying static PWs in an H-= VPLS=20 scenario along with PW-redundancy. I don't think this can be ignored..
    <= SPAN=20 class=3D922263805-07022012>&nbs= p;GIM>> H-VPLS is not PWE3 but L2VPN construct. And MAC= =20 management is not part of TDM PW or ATM PW. I'm not suggesting to "ignore" = MAC=20 Management but to address it in appropriate IETF=20 WG.
      MAC Withrawal, MAC management in gener= al, is=20 not part of PW OAM and should not re-use PW OAM G-ACh.=20
     

    Sami: So, how do you propose achieving this function for static PW= s if=20 we don't use PW-OAM?
     GIM>> I sug= gest=20 request MAC Management VCCV PW ACH code point from IANA. I believe that MAC= =20 management is not element of PW OAM, unlike Continuity Check, Connectivity= =20 Verification, Loss and Delay Measurement that are common to all types of=20 PWs.

    Thanks,

    Sami

        Regards,
            Greg

    From: pwe3-bounces@ietf.org [=20 mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G.=20 Malis
    Sent: Monday, January 23, 2012 12:19 PM
    To:=20 pwe3@ietf.org
    Subject: [PWE3] Starting WG adoption call for=20 draft-boutros-pwe3-mpls-tp-mac-wd-02

    This begins a two-week= PWE3=20 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02=20 , ending February 6. Please respond with your approval, disapproval, and = other=20 comments to the PWE3 list. If you don't support the adoption, providing a= =20 reason would be useful to the authors and the working group, but is not=20 required. Of course, the reason why you support the draft is also welcome= , but=20 also optional. This request will be a part of PWE3 WG adoption calls goin= g=20 forward.

    Thanks,
    Andy and=20 Matthew

    _______________________________________________
    pwe3 ma= iling=20 list
    pwe3@ietf.org
    https://www.ietf.org/mailman/listinfo/pwe3
    --_000_FE60A4E52763E84B935532D7D9294FF1322B3173A3EUSAACMS0715e_-- From amalis@gmail.com Mon Feb 6 22:04:44 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0021F8739; Mon, 6 Feb 2012 22:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 bDSCTOiso1j9; Mon, 6 Feb 2012 22:04: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 9E28421F8726; Mon, 6 Feb 2012 22:04:43 -0800 (PST) Received: by iagf6 with SMTP id f6so11509895iag.31 for ; Mon, 06 Feb 2012 22:04:43 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=uKd0Uml+mkYvQDqUOMX/mbCM8+u6L1CaUh86zPeNFuQ=; b=lOwGZn5AZbYxtuwnUuETZrStVZcDEhWukmaO+Xg5OZ129Z044WzMm+Gm+hVLot3my4 BiL5jVNK4nX5jcs/aGtt9wsqlANwdOihHZdxreb3OM5s/VQoiLk+3VpCRwFZYNrONhps D8FyJCCEEv0Y7uYKv+zSM4d1R6PBlip5FlYHg= Received: by 10.50.89.197 with SMTP id bq5mr24723072igb.24.1328594683268; Mon, 06 Feb 2012 22:04:43 -0800 (PST) MIME-Version: 1.0 Sender: amalis@gmail.com Received: by 10.50.100.198 with HTTP; Mon, 6 Feb 2012 22:04:23 -0800 (PST) In-Reply-To: References: <20120207042726.28578.34160.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Tue, 7 Feb 2012 07:04:23 +0100 X-Google-Sender-Auth: T_ntBDip6tY0PXWiJIyTGdwLLeM Message-ID: To: Kamran Raza Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, "Carlos Pignataro \(cpignata\)" , pwe3@ietf.org Subject: Re: [PWE3] Summary of changes [Re: I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-03.txt] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 06:04:44 -0000 Kamran, Thanks to you and the other authors. I'll leave this open for a couple of more days to give WG participants a chance to review the changes, and assuming there aren't any further comments, I'll forward it to the IESG. I would like to remind the WG that you can easily generate a diff by going to https://tools.ietf.org/html/draft-ietf-pwe3-pw-typed-wc-fec-03 and clicking on "Diff1" and "Diff2" to get two types of diffs. Cheers, Andy On Tue, Feb 7, 2012 at 5:39 AM, Kamran Raza wrote: > > The changes from rev -02 to -03 mainly incorporates comments received dur= ing > WG LC: > > 1- Clarifies that PW Typed WC FEC can be used in any LDP message that all= ows > FEC element - i.e. Label messages, Address Withdraw [ for VPLS], and > Notification. > > =A02 - New Section 4.4: Applicability of PW Typed WC FEC in VPLS MAC > Withdrawal to allow a PE node to =B3wildcard=B2 withdraw **all** MAC addr= esses > for: > =A0 =A0 o =A0all VPLS instances; or > =A0 =A0 o =A0all VPLS instances corresponding to a given PW type. > > =A0[ Ack Daniel Cohn for his input ] > > 3- Mandates that VPLS MAC Wdw (Address Withdrawal) MUST contain an =B3emp= ty=B2 > list if PW Typed WC specified in FEC TLV. > > Rgds, > -- Kamran > > On 12-02-06 11:27 PM, "internet-drafts@ietf.org" > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Pseudowire Emulation Edge = to >> Edge Working Group of the IETF. >> >> Title =A0 =A0 =A0 =A0 =A0 : LDP Typed Wildcard FEC for PWid and Generali= zed PWid FEC >> Elements >> Author(s) =A0 =A0 =A0 : Kamran Raza >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sami Boutros >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Carlos Pignataro >> Filename =A0 =A0 =A0 =A0: draft-ietf-pwe3-pw-typed-wc-fec-03.txt >> Pages =A0 =A0 =A0 =A0 =A0 : 9 >> Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-06 >> >> =A0 =A0The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" >> =A0 =A0defines an extension to the Label Distribution Protocol (LDP) tha= t >> =A0 =A0can be used when it is desired to request or withdraw or release = all >> =A0 =A0label bindings for a given FEC Element type. =A0However, a typed >> =A0 =A0wildcard FEC element must be individually defined for each FEC >> =A0 =A0element type. =A0This specification defines the typed wildcard FE= C >> =A0 =A0elements for the PWid (0x80) and Generalized PWid (0x81) FEC elem= ent >> =A0 =A0types. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-03.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-pwe3-pw-typed-wc-fec-03.tx= t >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > > -- > 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 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From internet-drafts@ietf.org Tue Feb 7 10:03:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F372521F8844; Tue, 7 Feb 2012 10:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 sNBF7RWFLsxZ; Tue, 7 Feb 2012 10:03:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84E21F883A; Tue, 7 Feb 2012 10:03:05 -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.64p1 Message-ID: <20120207180305.12922.32417.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 10:03:05 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-iccp-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:03:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Inter-Chassis Communication Protocol for L2VPN PE Redund= ancy Author(s) : Luca Martini Samer Salam Ali Sajassi Satoru Matsushima Filename : draft-ietf-pwe3-iccp-07.txt Pages : 78 Date : 2012-02-07 This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iccp-07.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-pwe3-iccp-07.txt From sriganeshkini@gmail.com Tue Feb 7 11:40:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB0511E8072 for ; Tue, 7 Feb 2012 11:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 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 I3tGPcqKs40t for ; Tue, 7 Feb 2012 11:40:39 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20B2421F88E2 for ; Tue, 7 Feb 2012 11:40:30 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5598431wgb.13 for ; Tue, 07 Feb 2012 11:40:30 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=qQOqZeM7VWrMlmZP6YE/sbudGkEdG0WhHQVJZLeE19c=; b=pTviNS2/9KjMQtJYCEph9ZTCGGNX+8JGX5dwRwYB3VDO6mYKn7Q3ofEeY39t61orpz lzPv6lrXaRTtNdSVBSdKB8vNdemRQPQd4hxZ8SQZU1OgnpWQKRCic3vl8Rq/rmq8po1K 2Eed2ui1akFRCFLLG6epJgC7eZKOEoargXGKw= Received: by 10.216.135.167 with SMTP id u39mr5440731wei.51.1328643630302; Tue, 07 Feb 2012 11:40:30 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.54.7 with HTTP; Tue, 7 Feb 2012 11:40:00 -0800 (PST) In-Reply-To: References: From: Sriganesh Kini Date: Tue, 7 Feb 2012 11:40:00 -0800 X-Google-Sender-Auth: pOfoILiqBZd82ELpJHwyF31Kfpc Message-ID: To: Sami Boutros Content-Type: multipart/alternative; boundary=0016e6de04be9e073804b864f38a Cc: pwe3@ietf.org Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:40:40 -0000 --0016e6de04be9e073804b864f38a Content-Type: text/plain; charset=UTF-8 Sami, See inline. On Mon, Feb 6, 2012 at 6:55 PM, Sami Boutros wrote: > Hi Sri, > > > At 03:55 PM 2/6/2012, Sriganesh Kini wrote: > > Hi Sami and other authors, > > A few comments > 1. Does the sequence numbers have any rollover procedures or other > requirements ? > > > Sami: This is one of the comments that we need to address for sure as we > progress the draft.. > This is a basic issue and it needs to be addressed before considering this to be a WG draft. > > > 2. You mention that there are no security considerations. What if this > packet is spoofed by say a man-in-the-middle attack ? > > > Sami: The reason here is that we will be using static PW-OAM and our > security will be no better or no worse that what this mechanism provide. > MAC flush can be forwarded beyond the receiving PE. So the problem gets progressively worse. IMO we need to add security to PW-OAM (the alternative being to use a mechanism other than PW-OAM). > > Thanks, > > Sami > > > On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis > wrote: > This begins a two-week PWE3 WG adoption call for > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > February 6. Please respond with your approval, disapproval, and other > comments to the PWE3 list. If you don't support the adoption, providing a > reason would be useful to the authors and the working group, but is not > required. Of course, the reason why you support the draft is also welcome, > but also optional. This request will be a part of PWE3 WG adoption calls > going forward. > > Thanks, > Andy and Matthew > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > -- > - Sri > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > -- - Sri --0016e6de04be9e073804b864f38a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sami,

    See inline.

    On M= on, Feb 6, 2012 at 6:55 PM, Sami Boutros <sboutros@cisco.com> wrote:
    Hi Sri,


    At 03:55 PM 2/6/2012, Sriganesh Kini wrote:
    Hi Sami and other authors,

    A few comments
    1. Does the sequence numbers have any rollover procedures or other requirements ?

    Sami: This is one of the comments that we need to address for sure as we progress the draft..

    This is a basic = issue and it needs to be addressed before considering this to be a WG draft= .
    =C2=A0


    2. You mention that there are no security considerations. What if this packet is spoofed by say a man-in-the-middle attack ?

    Sami: The reason here is that we will be using static PW-OAM and our security will be no better or no worse that what this mechanism provide.

    MAC flush can be forward= ed beyond the receiving PE. So the problem gets progressively worse. IMO we= need to add security to PW-OAM (the alternative being to use a mechanism o= ther than PW-OAM).
    =C2=A0

    Thanks,

    Sami


    On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis <amalis@gmail.com<= /a>> wrote:
    This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward.

    Thanks,
    Andy and Matthew


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




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


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




    --
    - Sri --0016e6de04be9e073804b864f38a-- From nmcgill@cisco.com Tue Feb 7 12:02:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD9E21F8771 for ; Tue, 7 Feb 2012 12:02:20 -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 qXQUv66likUB for ; Tue, 7 Feb 2012 12:02:20 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03B21F86FE for ; Tue, 7 Feb 2012 12:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2676; q=dns/txt; s=iport; t=1328644940; x=1329854540; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=0UQ9UJ9LK9DkoNGbNjqGrzwWUndJLNIroFI4kpkJEVI=; b=a/ZPi8NPiTEz9n+NXbyIF4UoSsKejH5thRH5U1D65xihKP0F8EmswYKO LWmSu9FxoA1bvmuZH1/AvW+VgFfpcG8CT5kvi7uHeTxDXzMl0NjFn+oJ4 WCqmCNQErWWPQNf/R0O3j0S3ffgxmMlBGhUQmTdXLkIHu4K4fhCg8H3GY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFyCMU+tJV2Y/2dsb2JhbABDr1uBBoFyAQEBAwEBAQEPAQodLQcLEAsYLiEGMAYTIodaCZsDAZcIBIgagyQCCQIBFAQBDgEIBQMDCYRFg1kEiEaXcody X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="54459332" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2012 20:02:19 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17K2Jlq015756; Tue, 7 Feb 2012 20:02:19 GMT Received: from xmb-rcd-110.cisco.com ([72.163.62.152]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 14:02:19 -0600 Received: from sjc-lds-319 ([171.70.173.95]) by xmb-rcd-110.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 14:02:19 -0600 Date: Tue, 7 Feb 2012 12:02:18 -0800 (PST) From: Neil McGill X-X-Sender: nmcgill@sjc-lds-319 To: Sriganesh Kini In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Feb 2012 20:02:19.0478 (UTC) FILETIME=[65BF0760:01CCE5D3] Cc: pwe3@ietf.org Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:02:21 -0000 > > Sami: This is one of the comments that we need to address for sure as we > > progress the draft.. > > > > This is a basic issue and it needs to be addressed before considering this > to be a WG draft. > > > > > > > > 2. You mention that there are no security considerations. What if this > > packet is spoofed by say a man-in-the-middle attack ? > > > > > > Sami: The reason here is that we will be using static PW-OAM and our > > security will be no better or no worse that what this mechanism provide. > > > > MAC flush can be forwarded beyond the receiving PE. So the problem gets > progressively worse. IMO we need to add security to PW-OAM (the alternative > being to use a mechanism other than PW-OAM). There is no security for the PW status bits either that are carried in this message, so one could just as easily inject a fault that would also induce the equivalent of a mac flush. Or send standby and force a redundant VPLS switchover to another instance. These problems already exist with PW OAM; adding MAC flush is not making matters any worse as you could probably emulate a brute force flush by sending ac rx/tx faults... The original intent was to keep the protocol simple, but if security is a concern then it is a base concern with the protocol and we have to look into adding some kind of digest or some other protocol all together. Thanks, Neil. > > > > > > Thanks, > > > > Sami > > > > > > On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis > > wrote: > > This begins a two-week PWE3 WG adoption call for > > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > > February 6. Please respond with your approval, disapproval, and other > > comments to the PWE3 list. If you don't support the adoption, providing a > > reason would be useful to the authors and the working group, but is not > > required. Of course, the reason why you support the draft is also welcome, > > but also optional. This request will be a part of PWE3 WG adoption calls > > going forward. > > > > Thanks, > > Andy and Matthew > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > -- > > - Sri > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > -- > - Sri > From zhang.fei3@zte.com.cn Tue Feb 7 23:02:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0D21F8588; Tue, 7 Feb 2012 23:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.173 X-Spam-Level: X-Spam-Status: No, score=-97.173 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 PokL3XUrbzfT; Tue, 7 Feb 2012 23:02:53 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5821F8585; Tue, 7 Feb 2012 23:02:52 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566903491178658; Wed, 8 Feb 2012 14:35:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 91379.8081620874; Wed, 8 Feb 2012 15:02:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1872WMT055327; Wed, 8 Feb 2012 15:02:32 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Gregory Mirsky , "Andrew G. Malis" , Sami Boutros MIME-Version: 1.0 X-KeepSent: DE301E33:3ADF710D-4825799E:0025570A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 8 Feb 2012 15:02:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 15:02:34, Serialize complete at 2012-02-08 15:02:34 Content-Type: multipart/alternative; boundary="=_alternative 0026AE914825799E_=" X-MAIL: mse02.zte.com.cn q1872WMT055327 Cc: pwe3-bounces@ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:02:55 -0000 This is a multipart message in MIME format. --=_alternative 0026AE914825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FtaSwgR3JlZw0KDQpTYW1pOiBTbywgaG93IGRvIHlvdSBwcm9wb3NlIGFjaGlldmluZyB0 aGlzIGZ1bmN0aW9uIGZvciBzdGF0aWMgUFdzIGlmIHdlIA0KZG9uJ3QgdXNlIFBXLU9BTT8NCiBH SU0+PiBJIHN1Z2dlc3QgcmVxdWVzdCBNQUMgTWFuYWdlbWVudCBWQ0NWIFBXIEFDSCBjb2RlIHBv aW50IGZyb20gSUFOQS4gDQpJIGJlbGlldmUgdGhhdCBNQUMgbWFuYWdlbWVudCBpcyBub3QgZWxl bWVudCBvZiBQVyBPQU0sIHVubGlrZSBDb250aW51aXR5IA0KQ2hlY2ssIENvbm5lY3Rpdml0eSBW ZXJpZmljYXRpb24sIExvc3MgYW5kIERlbGF5IE1lYXN1cmVtZW50IHRoYXQgYXJlIA0KY29tbW9u IHRvIGFsbCB0eXBlcyBvZiBQV3MuDQoNCkZlaTogQWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlv biBpbiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1nYWNoLWFk di0wMA0KDQoiVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcHJvY2VkdXJlcyBmb3IgYW4gTVBMUyBM YWJlbCBTd2l0Y2hpbmcgUm91dGVyIA0KKExTUikgdG8gYWR2ZXJ0aXNlIGl0cyBjYXBhYmlsaXRp ZXMgYW5kIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycywgb3INCiAgIG90aGVyIGFwcGxpY2F0aW9u LXNwZWNpZmljIGluZm9ybWF0aW9uLCB0byBpdHMgcGVlcnMgb3ZlciBMU1BzLCANCnBzZXVkb3dp cmVzLCBhbmQgc2VjdGlvbnMuICBSZWNlaXZlcnMgY2FuIHRoZW4gbWFrZSB1c2Ugb2YgdGhpcw0K ICAgaW5mb3JtYXRpb24gdG8gdmFsaWRhdGUgb3IgYWRqdXN0IHRoZWlyIG93biBjb25maWd1cmF0 aW9ucywgYW5kIG5ldHdvcmsgDQpvcGVyYXRvcnMgY2FuIG1ha2UgdXNlIG9mIGl0IHRvIGRpYWdu b3NlIGZhdWx0cyBhbmQNCiAgIGNvbmZpZ3VyYXRpb24gaW5jb25zaXN0ZW5jaWVzIGJldHdlZW4g ZW5kcG9pbnRzLiINCg0KTWF5YmUgdGhlIEdBUCBwcm90b2NvbCBpcyBhIGJldHRlciBjaG9pY2Ug aWYgdGhlIEFjayBtZXNzYWdlIGlzIG5vdCANCm5lY2Vzc2FyeT8NCg0KDQoNCg0KR3JlZ29yeSBN aXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4gDQq3orz+yMs6ICBwd2UzLWJvdW5j ZXNAaWV0Zi5vcmcNCjIwMTItMDItMDcgMTM6NDcNCg0KytW8/sjLDQpTYW1pIEJvdXRyb3MgPHNi b3V0cm9zQGNpc2NvLmNvbT4sICJBbmRyZXcgRy4gTWFsaXMiIDxhbWFsaXNAZ21haWwuY29tPiwg DQoicHdlM0BpZXRmLm9yZyIgPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbUFdF M10gU3RhcnRpbmcgV0cgYWRvcHRpb24gY2FsbCAgICBmb3IgDQpkcmFmdC1ib3V0cm9zLXB3ZTMt bXBscy10cC1tYWMtd2QtMDINCg0KDQoNCg0KDQoNCkhpIFNhbWksDQp0aGFuayB5b3UgZm9yIGlu dGVyZXN0IGluIG15IGNvbW1lbnRzLiBQbGVhc2UgZmluZCBteSBub3RlcyBpbi1saW5lZCANCnRh Z2dlZCBHSU0+Pi4NCiANCiAgICBSZWdhcmRzLA0KICAgICAgICBHcmVnDQoNCkZyb206IFNhbWkg Qm91dHJvcyBbbWFpbHRvOnNib3V0cm9zQGNpc2NvLmNvbV0gDQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDA2LCAyMDEyIDY6NTQgUE0NClRvOiBHcmVnb3J5IE1pcnNreTsgQW5kcmV3IEcuIE1hbGlz OyBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BXRTNdIFN0YXJ0aW5nIFdHIGFkb3B0aW9u IGNhbGwgZm9yIA0KZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAtbWFjLXdkLTAyDQoNCkhpIEdy ZWcsDQoNClBsZWFzZSBzZWUgY29tbWVudHMgaW5saW5lLi4NCg0KQXQgMTI6MzggUE0gMi8zLzIw MTIsIEdyZWdvcnkgTWlyc2t5IHdyb3RlOg0KQ29udGVudC1MYW5ndWFnZTogZW4tVVMNCkNvbnRl bnQtVHlwZTogbXVsdGlwYXJ0L2FsdGVybmF0aXZlOw0KIGJvdW5kYXJ5PSJfMDAwX0ZFNjBBNEU1 Mjc2M0U4NEI5MzU1MzJEN0Q5Mjk0RkYxMzIyQjMxNkMzQUVVU0FBQ01TMDcxNWVfIg0KDQpEZWFy IEFsbCwNCmRvIG5vdCBzdXBwb3J0Lg0KU2V2ZXJhbCByZWFzb25zOiANCkkgdGhpbmsgdGhhdCBw cm9ibGVtIG9mIE1BQyB3aXRoZHJhd2FsIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgUFdFMyBXRy4g SSANCnRoaW5rIHRoYXQgdGhpcyBwcm9ibGVtIGlzIGluIHNjb3BlIG9mIHRoZSBMMlZQTi4gSU1I TywgYmVmb3JlIGFueSBNUExTLVRQIA0Kc3BlY2lmaWMgbWVjaGFuaXNtcyBmb3IgTDJWUE4gYXJl IGFkb3B0ZWQgd2UgbmVlZCB0byBkaXNjdXNzIGFwcGxpY2FiaWxpdHkgDQpvZiBMMlZQTiBhbmQg TDNWUE4sIGluIHBhcnRpY3VsYXIgd2hlbiBkeW5hbWljIGNvbnRyb2wgcGxhbmUgaXMgbm90IHVz ZWQuDQoNClNhbWk6IFRoaXMgaXMgYSByZXF1aXJlbWVudCB3aGVuIGRlcGxveWluZyBzdGF0aWMg UFdzIGluIGFuIEgtVlBMUyANCnNjZW5hcmlvIGFsb25nIHdpdGggUFctcmVkdW5kYW5jeS4gSSBk b24ndCB0aGluayB0aGlzIGNhbiBiZSBpZ25vcmVkLi4NCiBHSU0+PiBILVZQTFMgaXMgbm90IFBX RTMgYnV0IEwyVlBOIGNvbnN0cnVjdC4gQW5kIE1BQyBtYW5hZ2VtZW50IGlzIG5vdCANCnBhcnQg b2YgVERNIFBXIG9yIEFUTSBQVy4gSSdtIG5vdCBzdWdnZXN0aW5nIHRvICJpZ25vcmUiIE1BQyBN YW5hZ2VtZW50IA0KYnV0IHRvIGFkZHJlc3MgaXQgaW4gYXBwcm9wcmlhdGUgSUVURiBXRy4NCk1B QyBXaXRocmF3YWwsIE1BQyBtYW5hZ2VtZW50IGluIGdlbmVyYWwsIGlzIG5vdCBwYXJ0IG9mIFBX IE9BTSBhbmQgc2hvdWxkIA0Kbm90IHJlLXVzZSBQVyBPQU0gRy1BQ2guIA0KIA0KDQpTYW1pOiBT bywgaG93IGRvIHlvdSBwcm9wb3NlIGFjaGlldmluZyB0aGlzIGZ1bmN0aW9uIGZvciBzdGF0aWMg UFdzIGlmIHdlIA0KZG9uJ3QgdXNlIFBXLU9BTT8NCiBHSU0+PiBJIHN1Z2dlc3QgcmVxdWVzdCBN QUMgTWFuYWdlbWVudCBWQ0NWIFBXIEFDSCBjb2RlIHBvaW50IGZyb20gSUFOQS4gDQpJIGJlbGll dmUgdGhhdCBNQUMgbWFuYWdlbWVudCBpcyBub3QgZWxlbWVudCBvZiBQVyBPQU0sIHVubGlrZSBD b250aW51aXR5IA0KQ2hlY2ssIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24sIExvc3MgYW5kIERl bGF5IE1lYXN1cmVtZW50IHRoYXQgYXJlIA0KY29tbW9uIHRvIGFsbCB0eXBlcyBvZiBQV3MuDQoN ClRoYW5rcywNCg0KU2FtaQ0KDQogICAgUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQpGcm9tOiBw d2UzLWJvdW5jZXNAaWV0Zi5vcmcgWyBtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgDQpBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyMywgMjAx MiAxMjoxOSBQTQ0KVG86IHB3ZTNAaWV0Zi5vcmcNClN1YmplY3Q6IFtQV0UzXSBTdGFydGluZyBX RyBhZG9wdGlvbiBjYWxsIGZvciANCmRyYWZ0LWJvdXRyb3MtcHdlMy1tcGxzLXRwLW1hYy13ZC0w Mg0KDQpUaGlzIGJlZ2lucyBhIHR3by13ZWVrIFBXRTMgV0cgYWRvcHRpb24gY2FsbCBmb3IgDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAtbWFj LXdkLTAyICwgZW5kaW5nIA0KRmVicnVhcnkgNi4gUGxlYXNlIHJlc3BvbmQgd2l0aCB5b3VyIGFw cHJvdmFsLCBkaXNhcHByb3ZhbCwgYW5kIG90aGVyIA0KY29tbWVudHMgdG8gdGhlIFBXRTMgbGlz dC4gSWYgeW91IGRvbid0IHN1cHBvcnQgdGhlIGFkb3B0aW9uLCBwcm92aWRpbmcgYSANCnJlYXNv biB3b3VsZCBiZSB1c2VmdWwgdG8gdGhlIGF1dGhvcnMgYW5kIHRoZSB3b3JraW5nIGdyb3VwLCBi dXQgaXMgbm90IA0KcmVxdWlyZWQuIE9mIGNvdXJzZSwgdGhlIHJlYXNvbiB3aHkgeW91IHN1cHBv cnQgdGhlIGRyYWZ0IGlzIGFsc28gd2VsY29tZSwgDQpidXQgYWxzbyBvcHRpb25hbC4gVGhpcyBy ZXF1ZXN0IHdpbGwgYmUgYSBwYXJ0IG9mIFBXRTMgV0cgYWRvcHRpb24gY2FsbHMgDQpnb2luZyBm b3J3YXJkLg0KDQpUaGFua3MsDQpBbmR5IGFuZCBNYXR0aGV3DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5n IGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcHdlMw0KDQoNCg== --=_alternative 0026AE914825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zPkhpIFNhbWksIEdyZWc8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zPlNhbWk6IFNvLCBob3cgZG8geW91IHByb3Bvc2UgYWNoaWV2aW5nIHRoaXMgZnVuY3Rp b24gZm9yDQpzdGF0aWMgUFdzIGlmIHdlIGRvbid0IHVzZSBQVy1PQU0/PC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jODA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQogR0lNJmd0OyZndDsgSSBzdWdn ZXN0IHJlcXVlc3QgTUFDIE1hbmFnZW1lbnQgVkNDViBQVyBBQ0ggY29kZSBwb2ludCBmcm9tDQpJ QU5BLiBJIGJlbGlldmUgdGhhdCBNQUMgbWFuYWdlbWVudCBpcyBub3QgZWxlbWVudCBvZiBQVyBP QU0sIHVubGlrZSBDb250aW51aXR5DQpDaGVjaywgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiwg TG9zcyBhbmQgRGVsYXkgTWVhc3VyZW1lbnQgdGhhdCBhcmUgY29tbW9uDQp0byBhbGwgdHlwZXMg b2YgUFdzPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj4uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPkZl aTogQWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbg0KaW4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWdhY2gtYWR2LTAwPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O1RoaXMgZG9jdW1lbnQg c3BlY2lmaWVzDQpwcm9jZWR1cmVzIGZvciBhbiBNUExTIExhYmVsIFN3aXRjaGluZyBSb3V0ZXIg KExTUikgdG8gYWR2ZXJ0aXNlIGl0cyBjYXBhYmlsaXRpZXMNCmFuZCBjb25maWd1cmF0aW9uIHBh cmFtZXRlcnMsIG9yPGJyPg0KICZuYnNwOyBvdGhlciBhcHBsaWNhdGlvbi1zcGVjaWZpYyBpbmZv cm1hdGlvbiwgdG8gaXRzIHBlZXJzIG92ZXIgTFNQcywNCnBzZXVkb3dpcmVzLCBhbmQgc2VjdGlv bnMuICZuYnNwO1JlY2VpdmVycyBjYW4gdGhlbiBtYWtlIHVzZSBvZiB0aGlzPGJyPg0KICZuYnNw OyBpbmZvcm1hdGlvbiB0byB2YWxpZGF0ZSBvciBhZGp1c3QgdGhlaXIgb3duIGNvbmZpZ3VyYXRp b25zLCBhbmQNCm5ldHdvcmsgb3BlcmF0b3JzIGNhbiBtYWtlIHVzZSBvZiBpdCB0byBkaWFnbm9z ZSBmYXVsdHMgYW5kPGJyPg0KICZuYnNwOyBjb25maWd1cmF0aW9uIGluY29uc2lzdGVuY2llcyBi ZXR3ZWVuIGVuZHBvaW50cy4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+TWF5YmUgdGhlIEdBUCBwcm90b2NvbCBpcw0KYSBi ZXR0ZXIgY2hvaWNlIGlmIHRoZSBBY2sgbWVzc2FnZSBpcyBub3QgbmVjZXNzYXJ5PzwvZm9udD48 dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdyZWdvcnkgTWlyc2t5ICZsdDtncmVnb3J5Lm1pcnNr eUBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3B3ZTMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAyLTA3IDEzOjQ3PC9mb250Pg0K PHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNhbWkgQm91 dHJvcyAmbHQ7c2JvdXRyb3NAY2lzY28uY29tJmd0OywNCiZxdW90O0FuZHJldyBHLiBNYWxpcyZx dW90OyAmbHQ7YW1hbGlzQGdtYWlsLmNvbSZndDssICZxdW90O3B3ZTNAaWV0Zi5vcmcmcXVvdDsN CiZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQV0UzXSBTdGFydGluZyBXRyBhZG9wdGlvbiBj YWxsDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAtbWFjLXdkLTAyPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPkhpIFNhbWksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj50aGFuayB5b3UgZm9yIGludGVyZXN0IGluIG15IGNvbW1lbnRzLg0KUGxlYXNlIGZp bmQgbXkgbm90ZXMgaW4tbGluZWQgdGFnZ2VkIEdJTSZndDsmZ3Q7LjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7IDwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+UmVnYXJkcyw8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkdyZWc8L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IFNhbWkgQm91dHJv cyBbbWFpbHRvOnNib3V0cm9zQGNpc2NvLmNvbV0NCjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXks IEZlYnJ1YXJ5IDA2LCAyMDEyIDY6NTQgUE08Yj48YnI+DQpUbzo8L2I+IEdyZWdvcnkgTWlyc2t5 OyBBbmRyZXcgRy4gTWFsaXM7IHB3ZTNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6 IFtQV0UzXSBTdGFydGluZyBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1ib3V0cm9zLXB3ZTMt bXBscy10cC1tYWMtd2QtMDI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+SGkgR3JlZyw8YnI+DQo8YnI+DQpQbGVhc2Ugc2VlIGNvbW1lbnRzIGlubGlu ZS4uPGJyPg0KPGJyPg0KQXQgMTI6MzggUE0gMi8zLzIwMTIsIEdyZWdvcnkgTWlyc2t5IHdyb3Rl OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Q29udGVudC1MYW5ndWFnZTogZW4tVVM8YnI+DQpD b250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTs8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGJvdW5kYXJ5PSZxdW90O18wMDBfRkU2MEE0RTUyNzYzRTg0QjkzNTUzMkQ3 RDkyOTRGRjEzMjJCMzE2QzNBRVVTQUFDTVMwNzE1ZV8mcXVvdDs8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWU+PGJyPg0KRGVhciBBbGwsPGJyPg0KZG8gbm90IHN1cHBvcnQuPGJy Pg0KU2V2ZXJhbCByZWFzb25zOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+ SSB0aGluayB0aGF0IHByb2JsZW0gb2YgTUFDIHdpdGhkcmF3YWwgaXMgb3V0DQpvZiBzY29wZSBv ZiB0aGUgUFdFMyBXRy4gSSB0aGluayB0aGF0IHRoaXMgcHJvYmxlbSBpcyBpbiBzY29wZSBvZiB0 aGUgTDJWUE4uDQpJTUhPLCBiZWZvcmUgYW55IE1QTFMtVFAgc3BlY2lmaWMgbWVjaGFuaXNtcyBm b3IgTDJWUE4gYXJlIGFkb3B0ZWQgd2UgbmVlZA0KdG8gZGlzY3VzcyBhcHBsaWNhYmlsaXR5IG9m IEwyVlBOIGFuZCBMM1ZQTiwgaW4gcGFydGljdWxhciB3aGVuIGR5bmFtaWMNCmNvbnRyb2wgcGxh bmUgaXMgbm90IHVzZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQpTYW1pOiBUaGlz IGlzIGEgcmVxdWlyZW1lbnQgd2hlbiBkZXBsb3lpbmcgc3RhdGljIFBXcyBpbiBhbiBILVZQTFMg c2NlbmFyaW8NCmFsb25nIHdpdGggUFctcmVkdW5kYW5jeS4gSSBkb24ndCB0aGluayB0aGlzIGNh biBiZSBpZ25vcmVkLi48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwi Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDgwMDAgZmFjZT0iQXJpYWwiPkdJ TSZndDsmZ3Q7IEgtVlBMUyBpcyBub3QNClBXRTMgYnV0IEwyVlBOIGNvbnN0cnVjdC4gQW5kIE1B QyBtYW5hZ2VtZW50IGlzIG5vdCBwYXJ0IG9mIFRETSBQVyBvciBBVE0NClBXLiBJJ20gbm90IHN1 Z2dlc3RpbmcgdG8gJnF1b3Q7aWdub3JlJnF1b3Q7IE1BQyBNYW5hZ2VtZW50IGJ1dCB0byBhZGRy ZXNzDQppdCBpbiBhcHByb3ByaWF0ZSBJRVRGIFdHLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZT5NQUMgV2l0aHJhd2FsLCBNQUMgbWFuYWdlbWVudCBpbiBnZW5lcmFsLCBpcw0K bm90IHBhcnQgb2YgUFcgT0FNIGFuZCBzaG91bGQgbm90IHJlLXVzZSBQVyBPQU0gRy1BQ2guPC9m b250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQpTYW1pOiBTbywgaG93IGRvIHlvdSBwcm9wb3NlIGFj aGlldmluZyB0aGlzIGZ1bmN0aW9uIGZvciBzdGF0aWMgUFdzIGlmDQp3ZSBkb24ndCB1c2UgUFct T0FNPzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzgwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0K IEdJTSZndDsmZ3Q7IEkgc3VnZ2VzdCByZXF1ZXN0IE1BQyBNYW5hZ2VtZW50IFZDQ1YgUFcgQUNI IGNvZGUgcG9pbnQgZnJvbQ0KSUFOQS4gSSBiZWxpZXZlIHRoYXQgTUFDIG1hbmFnZW1lbnQgaXMg bm90IGVsZW1lbnQgb2YgUFcgT0FNLCB1bmxpa2UgQ29udGludWl0eQ0KQ2hlY2ssIENvbm5lY3Rp dml0eSBWZXJpZmljYXRpb24sIExvc3MgYW5kIERlbGF5IE1lYXN1cmVtZW50IHRoYXQgYXJlIGNv bW1vbg0KdG8gYWxsIHR5cGVzIG9mIFBXczwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KVGhhbmtzLDxicj4N Cjxicj4NClNhbWk8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsg PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPlJlZ2FyZHMsPC9mb250Pjxmb250IHNpemU9 Mz48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlPkdyZWc8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD4NCjxo cj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gcHdlMy1ib3VuY2VzQGll dGYub3JnIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZyI+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT4NCm1haWx0bzpwd2UzLWJvdW5j ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJldyBHLiBNYWxpczxiPjxicj4NClNlbnQ6PC9iPiBNb25k YXksIEphbnVhcnkgMjMsIDIwMTIgMTI6MTkgUE08Yj48YnI+DQpUbzo8L2I+IHB3ZTNAaWV0Zi5v cmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gW1BXRTNdIFN0YXJ0aW5nIFdHIGFkb3B0aW9uIGNhbGwg Zm9yIGRyYWZ0LWJvdXRyb3MtcHdlMy1tcGxzLXRwLW1hYy13ZC0wMjwvZm9udD48Zm9udCBzaXpl PTM+PGJyPg0KPGJyPg0KVGhpcyBiZWdpbnMgYSB0d28td2VlayBQV0UzIFdHIGFkb3B0aW9uIGNh bGwgZm9yIDwvZm9udD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Ym91dHJvcy1wd2UzLW1wbHMtdHAtbWFjLXdkLTAyIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48 dT5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAt bWFjLXdkLTAyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KLCBlbmRpbmcgRmVicnVhcnkg Ni4gUGxlYXNlIHJlc3BvbmQgd2l0aCB5b3VyIGFwcHJvdmFsLCBkaXNhcHByb3ZhbCwgYW5kDQpv dGhlciBjb21tZW50cyB0byB0aGUgUFdFMyBsaXN0LiBJZiB5b3UgZG9uJ3Qgc3VwcG9ydCB0aGUg YWRvcHRpb24sIHByb3ZpZGluZw0KYSByZWFzb24gd291bGQgYmUgdXNlZnVsIHRvIHRoZSBhdXRo b3JzIGFuZCB0aGUgd29ya2luZyBncm91cCwgYnV0IGlzIG5vdA0KcmVxdWlyZWQuIE9mIGNvdXJz ZSwgdGhlIHJlYXNvbiB3aHkgeW91IHN1cHBvcnQgdGhlIGRyYWZ0IGlzIGFsc28gd2VsY29tZSwN CmJ1dCBhbHNvIG9wdGlvbmFsLiBUaGlzIHJlcXVlc3Qgd2lsbCBiZSBhIHBhcnQgb2YgUFdFMyBX RyBhZG9wdGlvbiBjYWxscw0KZ29pbmcgZm9yd2FyZC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K QW5keSBhbmQgTWF0dGhldzxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2UzQGlldGYu b3JnPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEg aHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w d2UzPC91PjwvZm9udD48L2E+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJy Pg0KcHdlM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcHdlMzxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0026AE914825799E_=-- From sriganeshkini@gmail.com Wed Feb 8 12:30:03 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C160621F8573 for ; Wed, 8 Feb 2012 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 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 JCUZHFlsawhT for ; Wed, 8 Feb 2012 12:30:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6122221F8537 for ; Wed, 8 Feb 2012 12:30:02 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so728540wgb.13 for ; Wed, 08 Feb 2012 12:30:01 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=23D8QYrDjVy6Z5QYHk5fIkRHJWegqjYJy82W0cQEWGc=; b=dLVCynt37Z8aSsm6Z28zczrZ3c9a/a8JNOZd1u7bs++UOUSruOm5DkcUmKDf8suUA9 lpdqzA1tDG6ET6zGul4rN9uWA6x1XNu9hKjMU52WhWBRElRRSvMgajYGOEaoMPflCf57 QNQjja4IQ28KzSR62d18/xlbXRzCHfAY+uERw= Received: by 10.180.103.68 with SMTP id fu4mr39931164wib.7.1328733001438; Wed, 08 Feb 2012 12:30:01 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.54.7 with HTTP; Wed, 8 Feb 2012 12:29:31 -0800 (PST) In-Reply-To: References: From: Sriganesh Kini Date: Wed, 8 Feb 2012 12:29:31 -0800 X-Google-Sender-Auth: zs0vmVzaQi63YpMxhb0Mj8cDnvM Message-ID: To: Neil McGill Content-Type: multipart/alternative; boundary=f46d044282528d563504b879c24d Cc: pwe3@ietf.org Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:30:03 -0000 --f46d044282528d563504b879c24d Content-Type: text/plain; charset=UTF-8 The status bits effects are limited to PW (or a few PWs like primary/standby). So while the problem exists and needs to be solved, it gets worse with MAC withdrawal since an empty MAC list can flush many MACs in the whole network. A PE even though it handles optimized MAC withdrawal could still treat a empty MAC list as per RFC4762 and open up a DoS attack vector on the whole VPLS network. Since there is no authenticated signaling channel as is used in signaled VPLS, this opens up a large security hole that needs to be addressed. IMO the simplicity argument is not overriding in this case. On Tue, Feb 7, 2012 at 12:02 PM, Neil McGill wrote: > > > Sami: This is one of the comments that we need to address for sure as > we > > > progress the draft.. > > > > > > > This is a basic issue and it needs to be addressed before considering > this > > to be a WG draft. > > > > > > > > > > > > > 2. You mention that there are no security considerations. What if this > > > packet is spoofed by say a man-in-the-middle attack ? > > > > > > > > > Sami: The reason here is that we will be using static PW-OAM and our > > > security will be no better or no worse that what this mechanism > provide. > > > > > > > MAC flush can be forwarded beyond the receiving PE. So the problem gets > > progressively worse. IMO we need to add security to PW-OAM (the > alternative > > being to use a mechanism other than PW-OAM). > > There is no security for the PW status bits either that are carried in this > message, so one could just as easily inject a fault that would also induce > the > equivalent of a mac flush. Or send standby and force a redundant VPLS > switchover > to another instance. These problems already exist with PW OAM; adding MAC > flush > is not making matters any worse as you could probably emulate a brute > force flush > by sending ac rx/tx faults... > > The original intent was to keep the protocol simple, but if security is > a concern then it is a base concern with the protocol and we have to > look into adding some kind of digest or some other protocol all > together. > > Thanks, > > Neil. > > > > > > > > > > > > Thanks, > > > > > > Sami > > > > > > > > > On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis > > > wrote: > > > This begins a two-week PWE3 WG adoption call for > > > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , > ending > > > February 6. Please respond with your approval, disapproval, and other > > > comments to the PWE3 list. If you don't support the adoption, > providing a > > > reason would be useful to the authors and the working group, but is not > > > required. Of course, the reason why you support the draft is also > welcome, > > > but also optional. This request will be a part of PWE3 WG adoption > calls > > > going forward. > > > > > > Thanks, > > > Andy and Matthew > > > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > -- > > > - Sri > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > -- > > - Sri > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- - Sri --f46d044282528d563504b879c24d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The status bits effects are limited to PW (or a few PWs like primary/standb= y). So while the problem exists and needs to be solved, it gets worse with = MAC withdrawal since an empty MAC list can flush many MACs in the whole net= work. A PE even though it handles optimized MAC withdrawal could still trea= t a empty MAC list as per RFC4762 and open up a DoS attack vector on the wh= ole VPLS network. Since there is no authenticated signaling channel as is u= sed in signaled VPLS, this opens up a large security hole that needs to be = addressed. IMO the simplicity argument is not overriding in this case.

    On Tue, Feb 7, 2012 at 12:02 PM, Neil McGill= <nmcgill@cisco.c= om> wrote:
    > > Sami: This is one of the comments that we need = to address for sure as we
    > > progress the draft..
    > >
    >
    > This is a basic issue and it needs to be addressed before considering = this
    > to be a WG draft.
    >
    >
    > >
    > >
    > > 2. You mention that there are no security considerations. What if= this
    > > packet is spoofed by say a man-in-the-middle attack ?
    > >
    > >
    > > Sami: The reason here is that we will be using static PW-OAM and = our
    > > security will be no better or no worse that what this mechanism p= rovide.
    > >
    >
    > MAC flush can be forwarded beyond the receiving PE. So the problem get= s
    > progressively worse. IMO we need to add security to PW-OAM (the altern= ative
    > being to use a mechanism other than PW-OAM).

    There is no security for the PW status bits either that are carried i= n this
    message, so one could just as easily inject a fault that would also induce = the
    equivalent of a mac flush. Or send standby and force a redundant VPLS switc= hover
    to another instance. These problems already exist with PW OAM; adding MAC f= lush
    is not making matters any worse as you could probably emulate a brute force= flush
    by sending ac rx/tx faults...

    The original intent was to keep the protocol simple, but if security is
    a concern then it is a base concern with the protocol and we have to
    look into adding some kind of digest or some other protocol all
    together.

    Thanks,

    Neil.


    >
    >
    > >
    > > Thanks,
    > >
    > > Sami
    > >
    > >
    > > On Mon, Jan 23, 2012 at 12:19 PM, Andrew G. Malis <amalis@gmail.com>
    > > wrote:
    > > =C2=A0This begins a two-week PWE3 WG adoption call for
    > > https://tools.ietf.org/html/draft-boutros-pwe= 3-mpls-tp-mac-wd-02 , ending
    > > February 6. Please respond with your approval, disapproval, and o= ther
    > > comments to the PWE3 list. If you don't support the adoption,= providing a
    > > reason would be useful to the authors and the working group, but = is not
    > > required. Of course, the reason why you support the draft is also= welcome,
    > > but also optional. This request will be a part of PWE3 WG adoptio= n calls
    > > going forward.
    > >
    > > Thanks,
    > > Andy and Matthew
    > >
    > >
    > > _______________________________________________
    > > pwe3 mailing list
    > > pwe3@ietf.org
    > > =C2=A0https://www.ietf.org/mailman/listinfo/pwe3
    > >
    > >
    > >
    > >
    > > --
    > > - Sri
    > > _______________________________________________
    > > pwe3 mailing list
    > > pwe3@ietf.org
    > > =C2=A0https://www.ietf.org/mailman/listinfo/pwe3
    > >
    > >
    > >
    > > _______________________________________________
    > > pwe3 mailing list
    > > pwe3@ietf.org
    > > https://www.ietf.org/mailman/listinfo/pwe3
    > >
    > >
    >
    >
    > --
    > - Sri
    >

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



    --
    = - Sri
    --f46d044282528d563504b879c24d-- From sboutros@cisco.com Wed Feb 8 13:50:29 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E1121F8525 for ; Wed, 8 Feb 2012 13:50:29 -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 PCGLKByvxXCs for ; Wed, 8 Feb 2012 13:50:28 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB51921F8522 for ; Wed, 8 Feb 2012 13:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=5475; q=dns/txt; s=iport; t=1328737828; x=1329947428; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=zyBXEXwcVrTOKxIpFyXXGTqJMRcIu3QtWtYW393kkqI=; b=GYX3iio/j7oBijtne9W4lZizVjWhEuPCAwP/cm3va38bNcgrd3oZi5Uj otKWDQ+4gw2nl94rnTbh3mpMYharYMDEU0VsAnTIZWnFLvZ7TC12rL4AB Y6Li8yYtntNDiJHrqMt2AfLRz57KPJOJsrQ0XzodeiFUiJ9jPauUa29lP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPPtMk+rRDoG/2dsb2JhbABDiCCmaoEHgXIBAQEEAQEBDwEKURsHBAQNBAEBKAcZDh8JCAYBEiKHY5pOAZ5JBIt1EwEIBQMDCSQBgw0FAxInMSGDWQSIRp9l X-IronPort-AV: E=Sophos;i="4.73,386,1325462400"; d="scan'208,217";a="29381031" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Feb 2012 21:50:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q18LoJrA019313; Wed, 8 Feb 2012 21:50:19 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 13:50:19 -0800 Received: from sboutros-wxp01.ciswco.com ([10.21.168.208]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 13:50:18 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Feb 2012 13:50:14 -0800 To: Gregory Mirsky , "Andrew G. Malis" , "pwe3@ietf.org" From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_60486125==.ALT" Message-ID: X-OriginalArrivalTime: 08 Feb 2012 21:50:18.0643 (UTC) FILETIME=[A60AE630:01CCE6AB] Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:50:29 -0000 --=====================_60486125==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Greg, >Sami: This is a requirement when deploying static PWs in an H-VPLS >scenario along with PW-redundancy. I don't think this can be ignored.. > GIM>> H-VPLS is not PWE3 but L2VPN construct. And MAC management > is not part of TDM PW or ATM PW. I'm not suggesting to "ignore" MAC > Management but to address it in appropriate IETF WG. Sami: Good that we agree that this is needed. >>MAC Withrawal, MAC management in general, is not part of PW OAM and >>should not re-use PW OAM G-ACh. >> > >Sami: So, how do you propose achieving this function for static PWs >if we don't use PW-OAM? > GIM>> I suggest request MAC Management VCCV PW ACH code point from > IANA. I believe that MAC management is not element of PW OAM, > unlike Continuity Check, Connectivity Verification, Loss and Delay > Measurement that are common to all types of PWs. Sami: The reason we are using the static PW-OAM status, is that we want to use a very similar procedure here to the one we use to send static PW status. Thanks, Sami >Thanks, > >Sami > >> Regards, >> Greg >> >> >>---------- >>From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On >>Behalf Of Andrew G. Malis >>Sent: Monday, January 23, 2012 12:19 PM >>To: pwe3@ietf.org >>Subject: [PWE3] Starting WG adoption call for >>draft-boutros-pwe3-mpls-tp-mac-wd-02 >> >>This begins a two-week PWE3 WG adoption call for >>https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 >>, ending February 6. Please respond with your approval, >>disapproval, and other comments to the PWE3 list. If you don't >>support the adoption, providing a reason would be useful to the >>authors and the working group, but is not required. Of course, the >>reason why you support the draft is also welcome, but also >>optional. This request will be a part of PWE3 WG adoption calls going forward. >> >>Thanks, >>Andy and Matthew >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www.ietf.org/mailman/listinfo/pwe3 --=====================_60486125==.ALT Content-Type: text/html; charset="us-ascii" Hi Greg,


    Sami: This is a requirement when deploying static PWs in an H-VPLS scenario along with PW-redundancy. I don't think this can be ignored..
      GIM>> H-VPLS is not PWE3 but L2VPN construct. And MAC management is not part of TDM PW or ATM PW. I'm not suggesting to "ignore" MAC Management but to address it in appropriate IETF WG.

    Sami: Good that we agree that this is needed.

      MAC Withrawal, MAC management in general, is not part of PW OAM and should not re-use PW OAM G-ACh.
     

    Sami: So, how do you propose achieving this function for static PWs if we don't use PW-OAM?
     GIM>> I suggest request MAC Management VCCV PW ACH code point from IANA. I believe that MAC management is not element of PW OAM, unlike Continuity Check, Connectivity Verification, Loss and Delay Measurement that are common to all types of PWs.

    Sami: The reason we are using the static PW-OAM status, is that we want to use a very similar procedure here to the one we use to send static PW status.

    Thanks,

    Sami

    Thanks,

    Sami

        Regards,
            Greg

    From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
    Sent: Monday, January 23, 2012 12:19 PM
    To: pwe3@ietf.org
    Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02

    This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward.

    Thanks,
    Andy and Matthew

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

    --=====================_60486125==.ALT-- From gregory.mirsky@ericsson.com Wed Feb 8 14:03:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F088121F855D for ; Wed, 8 Feb 2012 14:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 qShOPlWtvc6Y for ; Wed, 8 Feb 2012 14:03:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 011EA21F84EA for ; Wed, 8 Feb 2012 14:03:53 -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 q18M3nol006413; Wed, 8 Feb 2012 16:03:51 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 8 Feb 2012 17:03:44 -0500 From: Gregory Mirsky To: Sami Boutros , "Andrew G. Malis" , "pwe3@ietf.org" Date: Wed, 8 Feb 2012 17:03:42 -0500 Thread-Topic: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: Aczmq67g8JjCpa0cS3+B8k6q4mDC9AAAR7/Q 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_FE60A4E52763E84B935532D7D9294FF1322B37F923EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:03:55 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322B37F923EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sami, thank you for your response. We are converging. I've snipped part of discus= sion and kept issue of PW OAM code point re-use. ________________________________ MAC Withrawal, MAC management in general, is not part of PW OAM and should = not re-use PW OAM G-ACh. Sami: So, how do you propose achieving this function for static PWs if we d= on't use PW-OAM? GIM>> I suggest request MAC Management VCCV PW ACH code point from IANA. I= believe that MAC management is not element of PW OAM, unlike Continuity Ch= eck, Connectivity Verification, Loss and Delay Measurement that are common = to all types of PWs. Sami: The reason we are using the static PW-OAM status, is that we want to = use a very similar procedure here to the one we use to send static PW statu= s. GIM>> I am not convinced that such re-use is justified and introduction of= new ACH code point would cause a problem. Regards, Greg Thanks, Sami Thanks, Sami Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On Behalf Of An= drew G. Malis Sent: Monday, January 23, 2012 12:19 PM To: pwe3@ietf.org Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-ma= c-wd-02 This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/htm= l/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond = with your approval, disapproval, and other comments to the PWE3 list. If yo= u don't support the adoption, providing a reason would be useful to the aut= hors and the working group, but is not required. Of course, the reason why = you support the draft is also welcome, but also optional. This request will= be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF1322B37F923EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hi Sami,
    thank you for your response. We are converging. I'= ve=20 snipped part of discussion and kept issue of PW OAM code point re-use.=20

    MAC Withrawal, MAC management in general, is= not part=20 of PW OAM and should not re-use PW OAM G-ACh.
    Sami: So, how do you propose achieving this function for static PWs = if we=20 don't use PW-OAM?
     GIM>> I s= uggest=20 request MAC Management VCCV PW ACH code point from IANA. I believe that M= AC=20 management is not element of PW OAM, unlike Continuity Check, Connectivit= y=20 Verification, Loss and Delay Measurement that are common to all types of= =20 PWs.

    Sami: The reason= we are=20 using the static PW-OAM status, is that we want to use a very similar=20 procedure here to the one we use to send static PW status.
     GIM>> I am not convinced that such re-use is justifi= ed and=20 introduction of new ACH code point would cause a problem.
     Regards,
        Greg 
    Thanks,

    Sami

    Thanks,

    Sami
        Regards,
            = Greg

    From: pwe3-bounces@ietf.org [ mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Andrew G. Malis
    Sent: Monday, January 23, 2012 12:19=20 PM
    To: pwe3@ietf.org
    Subject: [PWE3] Starting WG=20 adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02

    Th= is=20 begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02=20 , ending February 6. Please respond with your approval, disapproval, an= d=20 other comments to the PWE3 list. If you don't support the adoption,=20 providing a reason would be useful to the authors and the working group= , but=20 is not required. Of course, the reason why you support the draft is als= o=20 welcome, but also optional. This request will be a part of PWE3 WG adop= tion=20 calls going forward.

    Thanks,
    Andy and=20 Matthew

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

    --_000_FE60A4E52763E84B935532D7D9294FF1322B37F923EUSAACMS0715e_-- From sboutros@cisco.com Wed Feb 8 14:13:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947B121F85C0 for ; Wed, 8 Feb 2012 14:13:54 -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=[AWL=-0.000, 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 APz9LeiBkdJO for ; Wed, 8 Feb 2012 14:13:53 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 12AE521F85BE for ; Wed, 8 Feb 2012 14:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=3182; q=dns/txt; s=iport; t=1328739232; x=1329948832; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=IrSxv/RATlbNqLIG9i6HwxtZv8bNrAD2HVk2Ap5cIB0=; b=I3JT6/Fl16L+r8Tj2umuuCb/pJWJgnHaBb35Knf0rP86i0Xs9ZLA2gsf B52HRW9Blx600YFJnaJedt+G4mNPyvop2yJ2zzqzVfwA9dwNTClBN0SFi UmR/9J80luVm0pRRCXzfSRUg7OxP6KlmO6lUoAZwLs+KvoR8L6JMvZ8He Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI/yMk+rRDoJ/2dsb2JhbABDiCCmaoEHgXMBAQQSAQpcEAcEBAFBGT4GNaIoAZ5Mi3UTAQgFAwMJJAGDDQUDEhFog1kEiBMzn2U X-IronPort-AV: E=Sophos;i="4.73,386,1325462400"; d="scan'208,217";a="29385397" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Feb 2012 22:13:50 +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 q18MDoqO025437; Wed, 8 Feb 2012 22:13:50 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); Wed, 8 Feb 2012 14:13:50 -0800 Received: from sboutros-wxp01.ciswco.com ([10.21.168.208]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:13:49 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Feb 2012 14:13:46 -0800 To: Sriganesh Kini From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_61898031==.ALT" Message-ID: X-OriginalArrivalTime: 08 Feb 2012 22:13:49.0873 (UTC) FILETIME=[EF338210:01CCE6AE] Cc: pwe3@ietf.org, "Siva Sivabalan \(msiva\)" Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:13:54 -0000 --=====================_61898031==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Sri, >>A few comments >>1. Does the sequence numbers have any rollover=20 >>procedures or other requirements ? > >Sami: This is one of the comments that we need=20 >to address for sure as we progress the draft.. > > >This is a basic issue and it needs to be=20 >addressed before considering this to be a WG draft. >=C2 Sami: Neil suggested to use the half seq-id=20 space, and use mod arith to work out if old. As=20 well we will handled sequence 0 differently to=20 force a Flush and reset the sequence #, will add=20 this to the draft before becoming WG. >>2. You mention that there are no security=20 >>considerations. What if this packet is spoofed=20 >>by say a man-in-the-middle attack ? > >Sami: The reason here is that we will be using=20 >static PW-OAM and our security will be no better=20 >or no worse that what this mechanism provide. > > >MAC flush can be forwarded beyond the receiving=20 >PE. So the problem gets progressively worse. IMO=20 >we need to add security to PW-OAM (the=20 >alternative being to use a mechanism other than PW-OAM). >=C2 Sami: Are you talking about the MS-PW case? why=20 is that different than regular static PW-OAM Status? Thanks, Sami --=====================_61898031==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sri,


    A few comments
    1. Does the sequence numbers have any rollover procedures or other requirements ?

    Sami: This is one of the comments that we need to address for sure as we progress the draft..


    This is a basic issue and it needs to be addressed before considering this to be a WG draft.
    =C2

    Sami: Neil suggested to use the half seq-id space, and use mod arith to work out if old. As well we will handled sequence 0 differently to force a Flush and reset the sequence #, will add this to the draft before becoming WG.


    2. You mention that there are no security considerations. What if this packet is spoofed by say a man-in-the-middle attack ?

    Sami: The reason here is that we will be using static PW-OAM and our security will be no better or no worse that what this mechanism provide.


    MAC flush can be forwarded beyond the receiving PE. So the problem gets progressively worse. IMO we need to add security to PW-OAM (the alternative being to use a mechanism other than PW-OAM).
    =C2

    Sami: Are you talking about the MS-PW case? why is that different than regular static PW-OAM Status?

    Thanks,

    Sami


    --=====================_61898031==.ALT-- From sriganeshkini@gmail.com Thu Feb 9 00:02:18 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4377421F851B for ; Thu, 9 Feb 2012 00:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 LUsR2pOPRu5T for ; Thu, 9 Feb 2012 00:02:17 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3537921F8518 for ; Thu, 9 Feb 2012 00:02:17 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1315473wib.31 for ; Thu, 09 Feb 2012 00:02:16 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=PRE2MH7Jguwz/RSdLyX69wK7NIJ/LCJDHZJCYAGLBNE=; b=pHs/wILIq72HnBhqxRpPCwhtwHcBQXvRhRaA8cmvoa+uBv8dzmqiEREf4zX4QcmLlc bJGSLT4b2H3DcY3tYmjpwUiPFH0NzIdcn3BsfcTPj5RHjjHbNSYTUwO5mr/yXPONbAjb vCkMEdEWQIRmECgCuhP0aBy0MbXeczEDNLh7Q= Received: by 10.180.101.165 with SMTP id fh5mr1089317wib.10.1328774536267; Thu, 09 Feb 2012 00:02:16 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.54.7 with HTTP; Thu, 9 Feb 2012 00:01:46 -0800 (PST) In-Reply-To: References: From: Sriganesh Kini Date: Thu, 9 Feb 2012 00:01:46 -0800 X-Google-Sender-Auth: Q1wY3snvAJwLeHRI0H69exsPb90 Message-ID: To: Sami Boutros Content-Type: multipart/alternative; boundary=f46d04426e0c38868604b8836e33 Cc: pwe3@ietf.org, "Siva Sivabalan \(msiva\)" Subject: Re: [PWE3] Comment on Re: Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:02:18 -0000 --f46d04426e0c38868604b8836e33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sami, On Wed, Feb 8, 2012 at 2:13 PM, Sami Boutros wrote: > Hi Sri, > > > A few comments > 1. Does the sequence numbers have any rollover procedures or other > requirements ? > > > Sami: This is one of the comments that we need to address for sure as we > progress the draft.. > > > This is a basic issue and it needs to be addressed before considering thi= s > to be a WG draft. > =C3=82 > > > Sami: Neil suggested to use the half seq-id space, and use mod arith to > work out if old. As well we will handled sequence 0 differently to force = a > Flush and reset the sequence #, will add this to the draft before becomin= g > WG. > > > 2. You mention that there are no security considerations. What if this > packet is spoofed by say a man-in-the-middle attack ? > > > Sami: The reason here is that we will be using static PW-OAM and our > security will be no better or no worse that what this mechanism provide. > > > MAC flush can be forwarded beyond the receiving PE. So the problem gets > progressively worse. IMO we need to add security to PW-OAM (the alternati= ve > being to use a mechanism other than PW-OAM). > =C3=82 > > > Sami: Are you talking about the MS-PW case? why is that different than > regular static PW-OAM Status? > I am referring to the VPLS case (H-VPLS). See earlier email response to Neil. > Thanks, > > Sami > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --=20 - Sri --f46d04426e0c38868604b8836e33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sami,

    On Wed, Feb 8, 2012 at 2:13 PM,= Sami Boutros <s= boutros@cisco.com> wrote:
    Hi Sri,


    A few comments
    1. Does the sequence numbers have any rollover procedures or other requirements ?

    Sami: This is one of the comments that we need = to address for sure as we progress the draft..


    This is a basic issue and it needs to be addressed before considering this to be a WG draft.
    =C3=82

    Sami: Neil suggested to use the half seq-id space, and use mod arith to work out if old. As well we will handled sequence 0 differently to force a Flush and reset the sequence #, will add this to the draft before becoming WG.


    2. You mention that there are no security considerations. What if this packet is spoofed by say a man-in-the-middle attack ?

    Sami: The reason here is that we will be using = static PW-OAM and our security will be no better or no worse that what this mechanism provide.


    MAC flush can be forwarded beyond the receiving PE. So the problem gets progressively worse. IMO we need to add security to PW-OAM (the alternative being to use a mechanism other than PW-OAM).
    =C3=82

    Sami: Are you talking about the MS-PW case? why is that different than regular static PW-OAM Status?

    I a= m referring to the VPLS case (H-VPLS). See earlier email response to Neil.<= /div>


    Thanks,

    Sami



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




    --
    - Sri
    --f46d04426e0c38868604b8836e33-- From matthew.bocci@alcatel-lucent.com Fri Feb 10 08:39:03 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50521F8606; Fri, 10 Feb 2012 08:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.791 X-Spam-Level: X-Spam-Status: No, score=-108.791 tagged_above=-999 required=5 tests=[AWL=1.456, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 2rZFcy6w9hUD; Fri, 10 Feb 2012 08:39:01 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA721F85FF; Fri, 10 Feb 2012 08:39:00 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1AGcu2c026116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Feb 2012 17:38:56 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 10 Feb 2012 17:38:56 +0100 From: "Bocci, Matthew (Matthew)" To: The IESG Date: Fri, 10 Feb 2012 17:38:54 +0100 Thread-Topic: Updated proto statement for draft-ietf-pwe3-packet-pw-03.txt Thread-Index: AczoEnsrFRRIalBQSPyamtJHuO2k6A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB5ABED72339Bmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "pwe3@ietf.org" , "pwe3-chairs@tools.ietf.org" , Stewart Bryant Subject: [PWE3] Updated proto statement for draft-ietf-pwe3-packet-pw-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:39:03 -0000 --_000_CB5ABED72339Bmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find below an updated document shepherd's write-up for draft-ietf-pw= e3-packet-pw-03.txt. This has been updated to reflect the change in intende= d status of the draft from BCP to Standards Track. Best regards Matthew draft-ietf-pwe3-packet-pw-03.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has received significant review by the WG and received a number of comments during WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. Although there were was an alternative proposal for a mechanism to support Packet PWs presented at a number of IETFs, that proposal has not been adopted by the working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are a couple of minor I-D nits related to a copyright dat= e and a missing reference. These should be fixed before publication. There are no formal review criteria. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. This document is a product of the PWE3 working group. This document is Standards Track. Working Group Summary This draft presents a number of alternative encapsulations for a generic= packet PW that were investigated by the authors and discussed in the WG over a per= iod of time (these are documented in the appendix), and reaches a conclusion about wh= ich one to use. However, an alternative approach was also proposed to the PWE3 work= ing group by a different set of authors in a separate draft, and progressed over a pe= riod of a number of IETFs. A consensus call was conducted by the chairs to tr= y to reach agreement on how to proceed. This resulted in the Ethernet PW encapsulat= ion approach, specified in draft-ietf-pwe3-packet-pw-03, being adopted. WG c= onsensus could not be reached on the alternative approach at that time. Since this draft documents a new way to use an existing encapsulation, the dra= ft was originally progressed as a BCP rather than standards track. However, it = was subsequently noted in AD review that the document makes IANA requests an= d therefore version 3, which is the subject of this proto write up, has been promote= d to a standards track draft. Document Quality The draft uses an existing Ethernet PW type that is widely deployed. As well as being used for interconnecting Ethernet attachment circuits, the= re are implementations that directly terminate the Ethernet PW on an IP interfa= ce e.g. on a VRF, which represents a subset of the proposal in the draft. Howeve= r, direct termination on an LSR, as shown in the draft, is not known to be widely = implemented/ deployed yet, although such as model has been requested by service provi= ders. There are no further concerns with document quality. The document does not specify any MIB changes or additions which would n= eed review. --_000_CB5ABED72339Bmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Please find below an upd= ated document shepherd's write-up for draft-ietf-pwe3-packet-pw-03.txt. Thi= s has been updated to reflect the change in intended status of the draft fr= om BCP to Standards Track.

    Best regards
    =
    Matthew

    draft-ietf-pwe3-packet= -pw-03.txt

    Document Shepard Write-Up

        (1.a) Who is the Document Shepherd= for this document? Has the 
            &nb= sp; Document Shepherd personally reviewed this version of the 
              document and, in particular, does he = or she believe this 
              vers= ion is ready for forwarding to the IESG for publication? 
            Yes,= I have reviewed the document and I believe it is ready for 
            forwarding to the IESG.


        (1.b) Has the document had adequate review = both from key WG members 
             = and from key non-WG members? Does the Document Shepherd have 
              any concerns about the depth or bread= th of the reviews that 
              h= ave been performed? 

          &nb= sp; Yes, the document has received adequate review. The document has
    <= div>        received significant review by the WG and r= eceived a number 
            of comments du= ring WG last call.


        (1= .c) Does the Document Shepherd have concerns that the document 
    <= div>          needs more review from a particular = or broader perspective, 
              = e.g., security, operational complexity, someone familiar with 
              AAA, internationalization or XML?&nbs= p;

           No.


        (1.d) Does the Document Shepherd have= any specific concerns or 
             = ; issues with this document that the Responsible Area Director 
    <= div>          and/or the IESG should be aware of? = For example, perhaps he 
              = or she is uncomfortable with certain parts of the document, or 
    <= div>          has concerns whether there really is= a need for it. In any 
              e= vent, if the WG has discussed those issues and has indicated 
              that it still wishes to advance the do= cument, detail those 
              con= cerns here. Has an IPR disclosure related to this document 
    =           been filed? If so, please include a refe= rence to the 
              disclosure = and summarize the WG discussion and conclusion on 
      &n= bsp;       this issue. 

     =      No specific concerns. 

    <= br>
        (1.e) How solid is the WG consensus behind this= document? Does it 
              repre= sent the strong concurrence of a few individuals, with 
    &nbs= p;         others being silent, or does the WG as a who= le understand and 
              agree = with it? 

          I am comfortab= le that the document represents WG consensus and has
       = ;   been reviewed by a reasonable number of active WG participants.&nb= sp;
          Although there were was an alternative p= roposal for a mechanism to 
          support Pac= ket PWs presented at a number of IETFs, that proposal has
      =     not been adopted by the working group. 
     =

        (1.f) Has anyone threatened an appe= al or otherwise indicated extreme 
          &nbs= p;   discontent? If so, please summarise the areas of conflict in = ;
              separate email messages to t= he Responsible Area Director. (It 
          &nbs= p;   should be in a separate email because this questionnaire is =
              entered into the ID Tracker.)=  

           None indicated.<= /div>


        (1.g) Has the Documen= t Shepherd personally verified that the 
         = ;     document satisfies all ID nits? (See 
      &n= bsp;       h= ttp://tools.ietf.org/tools/idnits/). Boilerplate checks are 
    =
              not enough; this check needs to be = thorough. Has the document 
            &nbs= p; met all formal review criteria it needs to, such as the MIB 
    <= div>          Doctor, media type and URI type revi= ews? 


          &nb= sp;Yes. There are a couple of minor I-D nits related to a copyright date&nb= sp;
           and a missing reference. These sho= uld be fixed before publication.
           There= are no formal review criteria.

        (1.h= ) Has the document split its references into normative and 
    =           informative? Are there normative referen= ces to documents that 
              ar= e not ready for advancement or are otherwise in an unclear 
    =           state? If such normative references exis= t, what is the 
              strategy = for their completion? Are there normative references 
     =         that are downward references, as described in = [RFC3967]? If 
              so, list t= hese downward references to support the Area 
        =       Director in the Last Call procedure for them [RFC3967]= . 

          Yes, the references a= re split appropriately. 



    <= /div>
        (1.i) Has the Document Shepherd verified that the d= ocument IANA 
              considerati= on section exists and is consistent with the body 
      &n= bsp;       of the document? If the document specifies protoc= ol 
              extensions, are reser= vations requested in appropriate IANA 
          =     registries? Are the IANA registries clearly identified? If&nb= sp;
              the document creates a new= registry, does it define the 
            &= nbsp; proposed initial contents of the registry and an allocation 
              procedure for future registration= s? Does it suggest a 
              rea= sonable name for the new registry? See [RFC5226]. If the 
    &n= bsp;         document describes an Expert Review proces= s has Shepherd 
              conferred= with the Responsible Area Director so that the IESG 
     =         can appoint the needed Expert during the IESG = Evaluation? 

          The IANA co= nsiderations section exists and seems reasonable.

    =
        (1.j) Has the Document Shepherd verified that = sections of the 
              document= that are written in a formal language, such as XML 
      =         code, BNF rules, MIB definitions, etc., validat= e correctly in 
              an automa= ted checker? 

          There are = no sections that use a formal language.


    =
        (1.k) The IESG approval announcement includes a Document=  
              Announcement Write-Up. = Please provide such a Document 
            =   Announcement Write-Up? Recent examples can be found in the
              "Action" announcements for approved doc= uments. The approval 
              ann= ouncement contains the following sections: 

    T= echnical Summary

       This document descri= bes a pseudowire mechanism that is used to
       transport= a packet service over an MPLS PSN is the case where the
      &= nbsp;client LSR and the server PE are co-resident in the same equipment.
       This pseudowire mechanism may be used to carry all of = the required
       layer 2 and layer 3 protocols between t= he pair of client LSRs.

       This document= is a product of the PWE3 working group.

      &n= bsp;This document is Standards Track.

    Working Grou= p Summary

       This draft presents a numbe= r of alternative encapsulations for a generic packet PW
      &n= bsp;that were investigated by the authors and discussed in the WG over a pe= riod of time
      (these are documented in the appendix), and r= eaches a conclusion about which one to
       use. However,= an alternative approach was also proposed to the PWE3 working group by&nbs= p;
       a different set of authors in a separate draft, a= nd progressed over a period
       of a number of IETFs. A = consensus call was conducted by the chairs to try to reach
     =  agreement on how to proceed. This resulted in the Ethernet PW encaps= ulation
       approach, specified in draft-ietf-pwe3-packe= t-pw-03, being adopted. WG consensus 
       could not= be reached on the alternative approach at that time. Since
     = ;  this draft documents a new way to use an existing encapsulation, th= e draft was
       originally progressed as a BCP rather th= an standards track. However, it was 
       subsequent= ly noted in AD review that the document makes IANA requests and therefore
       version 3, which is the subject of this proto write u= p, has been promoted to a
       standards track draft.

    Document Quality

      &nbs= p;The draft uses an existing Ethernet PW type that is widely deployed. As
       well as being used for interconnecting Ethernet attac= hment circuits, there are
       implementations that direc= tly terminate the Ethernet PW on an IP interface e.g.
      &nbs= p;on a VRF, which represents a subset of the proposal in the draft. However= , direct
       termination on an LSR, as shown in the draf= t, is not known to be widely implemented/
       deployed y= et, although such as model has been requested by service providers. 

       There are no further concerns with doc= ument quality.

       The document does not = specify any MIB changes or additions which would need review.
       


    --_000_CB5ABED72339Bmatthewboccialcatellucentcom_-- From matthew.bocci@alcatel-lucent.com Wed Feb 15 07:09:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6421F869A; Wed, 15 Feb 2012 07:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.795 X-Spam-Level: X-Spam-Status: No, score=-107.795 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8, 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 gUfJx55fgyTN; Wed, 15 Feb 2012 07:09:53 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0321F866C; Wed, 15 Feb 2012 07:09:53 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1FF9jwX032427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Feb 2012 16:09:48 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 15 Feb 2012 16:09:34 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" , "ietf@ietf.org" Date: Wed, 15 Feb 2012 16:09:31 +0100 Thread-Topic: Auth48 comments on draft-ietf-pwe3-static-pw-status-10 Thread-Index: Aczr89KtIVI7SxkNRWultcFx3Ew+Sw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB617B2B23929matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "pwe3-chairs@tools.ietf.org" , Stewart Bryant Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:09:54 -0000 --_000_CB617B2B23929matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some = issues with the acknowledgement procedures in Section 5.3 of the draft that= we feel should be addressed before publication. Since the draft has alread= y been through WG and IETF last call, we would like to highlight the propos= ed changes to the working group and solicit feedback. Best regards, Matthew Section 5.3, 3rd paragraph: Reason for change: The current suggested default refresh timer value is too short to allow sca= ling to very large numbers of PWs while minimising the overhead. It is also inco= nsistent with the suggested default requested in an ACK packet. Therefore we suggest= increasing the default to 600secs. OLD: The suggested default value for the refresh timer is 30 seconds. NEW: The suggested default value for the refresh timer is 600 seconds. Section 5.3, 4th paragraph: Reason for change: The current text requires that a receiving PE must acknowledge a PW status = message of 'clear all faults' in order to force a transmitter to stop sending PW st= atus messages at 1 second intervals. We are concerned that a mandatory acknowle= dgement adds an unnecessary complexity to the protocol which is inconsistent with the use of the acknowledgement as per the following section (5.3.1). Additi= onally, we are also concerned that this may cause problems if a transmitter is flapping between 'clear all faults' and a non-zero value, and if the acknowledgement is lost. We therefore suggest that the acknowledgement to 'clear all faults' be made optional, and that the transmitter behavior be = changed so that it sends up to 3 status messages of zero in a row, and then goes silen= t. OLD: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, it MUST be acknowledged with a packet with a timer value of zero. This will cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Section 5.3.1, 1st paragraph: Reason for change: The procedures currently defined in this paragraph can lead to a receiver of the static status message timing out if it requests, throught the use of= the ACK mechanism, a longer refresh timer from the transmitter. This is because= the current text implies that the transmitter change its referesh timer immedia= tely on receipt of the ack packet from the receiver. The new text clarifies that the refresh timer be updated at the end of the current refresh interval, as well as making some other editorial clarifications. OLD: The PE receiving a PW OAM message containing a PW status message can acknowledge the PW status message by simply building an almost identical reply packet with the A bit set, and transmitting it on the PW ACH back to the source of the PW status message. The timer value set in the reply packet SHOULD then be used by the PE as the new transmit interval. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent. The receiving PE MUST NOT retry to set the timer value more than once per timer value. NEW: A PE receiving a PW OAM message containing a PW status message MAY acknowledge the PW status message by simply building a reply packet with the same format and status code as the received PW OAM message, but with the A bit set, and transmitting it on the PW ACh back to the source of the PW OAM message. The receiving PE MAY use the refresh timer field in the acknowledgement packet to request a new refresh interval from the originator of the PW OAM message. The timer value set in the reply packet SHOULD then be used by the originator of the PW OAM message as the new transmit interval. If the requested refresh timer value is used, the PW OAM message transmission interval is only set to the new value and the new value sent in the next PW OAM message, when the current timer expires. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the new refresh timer value that is in the packet received, regardless of what timer value it requested. The receiving PE MUST NOT request a new refresh timer value more than once per refresh interval. --_000_CB617B2B23929matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    During Auth 48= , the authors of draft-ietf-pwe3-static-pw-status found some issues with th= e acknowledgement procedures in Section 5.3 of the draft that we feel shoul= d be addressed before publication. Since the draft has already been through= WG and IETF last call, we would like to highlight the proposed changes to = the working group and solicit feedback.

    Best = regards,

    Matthew

    <= div>Section 5.3, 3rd paragraph:
    Reason for change:
    The = current suggested default refresh timer value is too short to allow scaling=  
    to very large numbers of PWs while minimising the overhead= . It is also inconsistent
    with the suggested default requested in= an ACK packet. Therefore we suggest increasing
    the default to 60= 0secs.

    OLD: The suggested default value for the re= fresh timer is 30 seconds.

    NEW: The suggested defa= ult value for the refresh timer is 600 seconds.


    Section 5.3, 4th paragraph:
    Reason fo= r change:
    The current text requires that a receiving PE must ackn= owledge a PW status message
    of 'clear all faults' in order to for= ce a transmitter to stop sending PW status
    messages at 1 second i= ntervals.  We are concerned that a mandatory acknowledgement
    adds an unnecessary complexity to the protocol which is inconsistent with<= /div>
    the use of the acknowledgement as per the following section (5.3.= 1). Additionally,
    we are also concerned that this may cause probl= ems if a transmitter 
    is flapping between 'clear all faults'= and a non-zero value, and if the 
    acknowledgement is lost. = We therefore suggest that the acknowledgement to 
    'clea= r all faults' be made optional, and that  the transmitter behavior be = changed so 
    that it sends up to 3 status messages of ze= ro in a row, and then goes silent.

    OLD: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW statu= s
    code is zero, the PW OAM message will be sent like any other PW= OAM
    status message using the procedures described above; however= , it MUST be
    acknowledged with a packet with a timer value of zer= o.  This will cause
    the PE sending the PW status notificatio= n message with a PW status code
    equal to zero to stop sending and= to continue normal operation.


    NEW:=  
    To clear a particular status fault, the PE need only send = an
    updated message with the corresponding bit cleared.  If t= he PW status
    code is zero, the PW OAM message will be sent like a= ny other PW OAM
    status message using the procedures described abo= ve; however,
    transmission will cease after 3 PW status messages h= ave been sent. A PW
    status message of zero MAY be acknowledged as= per the procedures described 
    in Section 5.3.1. If it is ac= knowledged, then a timer
    value of zero MUST be used.  This S= HOULD cause the PE sending the PW status
    notification message wit= h a PW status code equal to zero to stop sending
     and to con= tinue normal operation.


    Section 5.3= .1, 1st paragraph:
    Reason for change:
    The procedures cu= rrently defined in this paragraph can lead to a receiver
    of the s= tatic status message timing out if it requests, throught the use of the
    ACK mechanism, a longer refresh timer from the transmitter. This is = because the
    current text implies that the transmitter change its = referesh timer immediately
    on receipt of the ack packet from the = receiver. The new text clarifies that 
    the refresh timer be = updated at the end of the current refresh interval, as 
    well= as making some other editorial clarifications.

    OL= D: 
    The PE receiving a PW OAM message containing a PW status= message
    can acknowledge the PW status message by simply building= an almost
    identical reply packet with the A bit set, and transmi= tting it on the PW
    ACH back to the source of the PW status messag= e.  The timer value set in
    the reply packet SHOULD then be u= sed by the PE as the new transmit
    interval.  If the transmit= ting PE does not want to use the new timer
    value (for local polic= y reasons, or because it simply cannot support
    it), it MUST refre= sh the PW OAM message with the timer value it desires.
    The receiv= ing PE will then set its timeout timer according to the timer
    val= ue that is in the packet received, regardless of what timer value it
    <= div>sent.  The receiving PE MUST NOT retry to set the timer value more= than
    once per timer value.

    NEW: 
    A PE receiving a PW OAM message containing a PW status message MAY=
    acknowledge the PW status message by simply building a reply pac= ket 
    with the same format and status code as the received PW= OAM message,
    but with the A bit set, and transmitting it on the = PW ACh back
    to the source of the PW OAM message.  The receiv= ing PE MAY use the
    refresh timer field in the acknowledgement pac= ket to request a new
    refresh interval from the originator of the = PW OAM message. The timer
    value set in the reply packet SHOULD th= en be used by the originator of
    the PW OAM message as the new tra= nsmit interval.  If the requested
    refresh timer value is use= d, the PW OAM message transmission interval is
    only set to the ne= w value and the new value sent in the next PW OAM
    message, when t= he current timer expires. If the transmitting PE does not
    want to= use the new timer value (for local policy reasons, or because it
    simply cannot support it), it MUST refresh the PW OAM message with the
    timer value it desires. The receiving PE will then set its timeout t= imer
    according to the new refresh timer value that is in the pack= et received,
    regardless of what timer value it requested.  T= he receiving PE MUST NOT
    request a new refresh timer value more t= han once per refresh interval.

    --_000_CB617B2B23929matthewboccialcatellucentcom_-- From gregory.mirsky@ericsson.com Wed Feb 15 14:14:26 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521D021F85C4; Wed, 15 Feb 2012 14:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 dKwr1tiW1N71; Wed, 15 Feb 2012 14:14:24 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A08F921F84D6; Wed, 15 Feb 2012 14:14:24 -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 q1FMEADV022038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Feb 2012 16:14:15 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 15 Feb 2012 17:14:11 -0500 From: Gregory Mirsky To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" , "ietf@ietf.org" Date: Wed, 15 Feb 2012 17:14:10 -0500 Thread-Topic: Auth48 comments on draft-ietf-pwe3-static-pw-status-10 Thread-Index: Aczr89KtIVI7SxkNRWultcFx3Ew+SwAOetDg 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_FE60A4E52763E84B935532D7D9294FF1322B42FE15EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3-chairs@tools.ietf.org" , Stewart Bryant Subject: Re: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:14:26 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322B42FE15EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Matthew, Authors, et al., I think that new text of fourth para in Section 5.3 adds some confusion. If= intension is to stop sending 'all clear' after three one-second intervals = went unacknowledged but before refresh timer expires then perhpas new text = can be more explicit: NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent at one se= cond intervals and before refresh timer expires. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Wednesday, February 15, 2012 7:10 AM To: pwe3@ietf.org; ietf@ietf.org Cc: pwe3-chairs@tools.ietf.org; Stewart Bryant Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some = issues with the acknowledgement procedures in Section 5.3 of the draft that= we feel should be addressed before publication. Since the draft has alread= y been through WG and IETF last call, we would like to highlight the propos= ed changes to the working group and solicit feedback. Best regards, Matthew Section 5.3, 3rd paragraph: Reason for change: The current suggested default refresh timer value is too short to allow sca= ling to very large numbers of PWs while minimising the overhead. It is also inco= nsistent with the suggested default requested in an ACK packet. Therefore we suggest= increasing the default to 600secs. OLD: The suggested default value for the refresh timer is 30 seconds. NEW: The suggested default value for the refresh timer is 600 seconds. Section 5.3, 4th paragraph: Reason for change: The current text requires that a receiving PE must acknowledge a PW status = message of 'clear all faults' in order to force a transmitter to stop sending PW st= atus messages at 1 second intervals. We are concerned that a mandatory acknowle= dgement adds an unnecessary complexity to the protocol which is inconsistent with the use of the acknowledgement as per the following section (5.3.1). Additi= onally, we are also concerned that this may cause problems if a transmitter is flapping between 'clear all faults' and a non-zero value, and if the acknowledgement is lost. We therefore suggest that the acknowledgement to 'clear all faults' be made optional, and that the transmitter behavior be = changed so that it sends up to 3 status messages of zero in a row, and then goes silen= t. OLD: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, it MUST be acknowledged with a packet with a timer value of zero. This will cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Section 5.3.1, 1st paragraph: Reason for change: The procedures currently defined in this paragraph can lead to a receiver of the static status message timing out if it requests, throught the use of= the ACK mechanism, a longer refresh timer from the transmitter. This is because= the current text implies that the transmitter change its referesh timer immedia= tely on receipt of the ack packet from the receiver. The new text clarifies that the refresh timer be updated at the end of the current refresh interval, as well as making some other editorial clarifications. OLD: The PE receiving a PW OAM message containing a PW status message can acknowledge the PW status message by simply building an almost identical reply packet with the A bit set, and transmitting it on the PW ACH back to the source of the PW status message. The timer value set in the reply packet SHOULD then be used by the PE as the new transmit interval. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent. The receiving PE MUST NOT retry to set the timer value more than once per timer value. NEW: A PE receiving a PW OAM message containing a PW status message MAY acknowledge the PW status message by simply building a reply packet with the same format and status code as the received PW OAM message, but with the A bit set, and transmitting it on the PW ACh back to the source of the PW OAM message. The receiving PE MAY use the refresh timer field in the acknowledgement packet to request a new refresh interval from the originator of the PW OAM message. The timer value set in the reply packet SHOULD then be used by the originator of the PW OAM message as the new transmit interval. If the requested refresh timer value is used, the PW OAM message transmission interval is only set to the new value and the new value sent in the next PW OAM message, when the current timer expires. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the new refresh timer value that is in the packet received, regardless of what timer value it requested. The receiving PE MUST NOT request a new refresh timer value more than once per refresh interval. --_000_FE60A4E52763E84B935532D7D9294FF1322B42FE15EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Dear Matthew, Authors, et al.,
    I=20 think that new text of fourth para in Section 5.3 adds some confusion. If=20 intension is to stop sending 'all clear' after three one-second intervals w= ent=20 unacknowledged but before refresh timer expires then perhpas new text can b= e=20 more explicit:
    NEW: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however,
    transmission will cease after 3 PW status messages have been sent at one second intervals and before refre= sh=20 timer expires. A PW
    status message of zero MAY be acknowledged as per the procedures=20 described 
    in Section 5.3.1. If it is acknowledged, then a timer
    value of zero MUST be used.  This SHOULD cause the PE sending the= PW=20 status
    notification message with a PW status code equal to zero to stop=20 sending
     and to continue normal operation.
     
      &n= bsp; Regards,
            Greg

    From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew=20 (Matthew)
    Sent: Wednesday, February 15, 2012 7:10 AM
    To:=20 pwe3@ietf.org; ietf@ietf.org
    Cc: pwe3-chairs@tools.ietf.org; Stew= art=20 Bryant
    Subject: [PWE3] Auth48 comments on=20 draft-ietf-pwe3-static-pw-status-10

    During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found = some=20 issues with the acknowledgement procedures in Section 5.3 of the draft that= we=20 feel should be addressed before publication. Since the draft has already be= en=20 through WG and IETF last call, we would like to highlight the proposed chan= ges=20 to the working group and solicit feedback.

    Best regards,

    Matthew

    Section 5.3, 3rd paragraph:
    Reason for change:
    The current suggested default refresh timer value is too short to allo= w=20 scaling 
    to very large numbers of PWs while minimising the overhead. It is also= =20 inconsistent
    with the suggested default requested in an ACK packet. Therefore we su= ggest=20 increasing
    the default to 600secs.

    OLD: The suggested default value for the refresh timer is 30 seconds.<= /DIV>

    NEW: The suggested default value for the refresh timer is 600=20 seconds.



    Section 5.3, 4th paragraph:
    Reason for change:
    The current text requires that a receiving PE must acknowledge a PW st= atus=20 message
    of 'clear all faults' in order to force a transmitter to stop sending = PW=20 status
    messages at 1 second intervals.  We are concerned that a mandator= y=20 acknowledgement
    adds an unnecessary complexity to the protocol which is inconsistent=20 with
    the use of the acknowledgement as per the following section (5.3.1).=20 Additionally,
    we are also concerned that this may cause problems if a=20 transmitter 
    is flapping between 'clear all faults' and a non-zero value, and if=20 the 
    acknowledgement is lost. We therefore suggest that the acknowledg= ement=20 to 
    'clear all faults' be made optional, and that  the transmitter=20 behavior be changed so 
    that it sends up to 3 status messages of zero in a row, and then = goes=20 silent.

    OLD: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however, it MUST= =20 be
    acknowledged with a packet with a timer value of zero.  This will= =20 cause
    the PE sending the PW status notification message with a PW status=20 code
    equal to zero to stop sending and to continue normal operation.


    NEW: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however,
    transmission will cease after 3 PW status messages have been sent. A=20 PW
    status message of zero MAY be acknowledged as per the procedures=20 described 
    in Section 5.3.1. If it is acknowledged, then a timer
    value of zero MUST be used.  This SHOULD cause the PE sending the= PW=20 status
    notification message with a PW status code equal to zero to stop=20 sending
     and to continue normal operation.


    Section 5.3.1, 1st paragraph:
    Reason for change:
    The procedures currently defined in this paragraph can lead to a=20 receiver
    of the static status message timing out if it requests, throught the u= se of=20 the
    ACK mechanism, a longer refresh timer from the transmitter. This is be= cause=20 the
    current text implies that the transmitter change its referesh timer=20 immediately
    on receipt of the ack packet from the receiver. The new text clarifies= =20 that 
    the refresh timer be updated at the end of the current refresh interva= l,=20 as 
    well as making some other editorial clarifications.

    OLD: 
    The PE receiving a PW OAM message containing a PW status message
    can acknowledge the PW status message by simply building an almost
    identical reply packet with the A bit set, and transmitting it on the= =20 PW
    ACH back to the source of the PW status message.  The timer value= set=20 in
    the reply packet SHOULD then be used by the PE as the new transmit
    interval.  If the transmitting PE does not want to use the new=20 timer
    value (for local policy reasons, or because it simply cannot support
    it), it MUST refresh the PW OAM message with the timer value it=20 desires.
    The receiving PE will then set its timeout timer according to the=20 timer
    value that is in the packet received, regardless of what timer value=20 it
    sent.  The receiving PE MUST NOT retry to set the timer value mor= e=20 than
    once per timer value.

    NEW: 
    A PE receiving a PW OAM message containing a PW status message MAY
    acknowledge the PW status message by simply building a reply=20 packet 
    with the same format and status code as the received PW OAM message,
    but with the A bit set, and transmitting it on the PW ACh back
    to the source of the PW OAM message.  The receiving PE MAY use=20 the
    refresh timer field in the acknowledgement packet to request a new
    refresh interval from the originator of the PW OAM message. The timer<= /DIV>
    value set in the reply packet SHOULD then be used by the originator=20 of
    the PW OAM message as the new transmit interval.  If the=20 requested
    refresh timer value is used, the PW OAM message transmission interval= =20 is
    only set to the new value and the new value sent in the next PW OAM
    message, when the current timer expires. If the transmitting PE does=20 not
    want to use the new timer value (for local policy reasons, or because= =20 it
    simply cannot support it), it MUST refresh the PW OAM message with=20 the
    timer value it desires. The receiving PE will then set its timeout=20 timer
    according to the new refresh timer value that is in the packet=20 received,
    regardless of what timer value it requested.  The receiving PE MU= ST=20 NOT
    request a new refresh timer value more than once per refresh=20 interval.

    --_000_FE60A4E52763E84B935532D7D9294FF1322B42FE15EUSAACMS0715e_-- From pabloisnot@gmail.com Wed Feb 15 14:24:12 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591B221E8092; Wed, 15 Feb 2012 14:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.371, 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 39XWo0AMnZcw; Wed, 15 Feb 2012 14:24:11 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F74921E8032; Wed, 15 Feb 2012 14:24:11 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2408084obb.31 for ; Wed, 15 Feb 2012 14:24:10 -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=QW/n6P1HKzz1Y0btVy1BV1vprTJko15HKrsfVBQiut8=; b=JSimeIxtIIskc0qRuryI+7Nz7R8o0SMnwnLdoPVhT6Iic9QX6WcdGV1++iVk3Qwa3b P9rV9BP/KUqAxjIvFUl0zaiZXff+jDLRJ+JBw7kL0ubUMLdXc22IMLo0PKYA2NSTfIZo SURLqxb/I1L5J/25MYG/MfMrmpPcR7ftmpU1Y= MIME-Version: 1.0 Received: by 10.182.89.65 with SMTP id bm1mr19606310obb.52.1329344650877; Wed, 15 Feb 2012 14:24:10 -0800 (PST) Received: by 10.182.42.137 with HTTP; Wed, 15 Feb 2012 14:24:10 -0800 (PST) In-Reply-To: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Wed, 15 Feb 2012 17:24:10 -0500 Message-ID: From: Pablo Frank To: John E Drake Content-Type: multipart/alternative; boundary=f46d0447a001b31c0f04b9082b20 Cc: Kireeti Kompella , "mpls@ietf.org" , pwe3@ietf.org Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:24:12 -0000 --f46d0447a001b31c0f04b9082b20 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when flow labels are present? That seems too bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire. This puts the overhead right back in so it may be more attractive to run fat PWEs with type-1 VCCV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote: > Pablo,**** > > ** ** > > Based upon Kireeti=92s update in Taipei, we seem to going towards using a > reserved label for ELI and making it always required.**** > > ** ** > > Thanks,**** > > ** ** > > John **** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Pablo Frank > *Sent:* Wednesday, February 15, 2012 7:30 AM > *To:* mpls@ietf.org > *Subject:* [mpls] Question about Entropy labels + GAL**** > > ** ** > > I'm working on implementation for entropy labels and I have a question > about draft-ietf-mpls-entropy-label-01. Consider a scenario where I have > received the following:**** > > ** ** > > ... | LSP label x | Entropy label | IPv4 payload | ...**** > > ** ** > > Assume that I've signaled that the LSP label wants entropy and an ELI is > unnecessary. Following the procedures detailed in 4.3, the datapath woul= d > lookup label x and see that it is expecting a possible entropy label and > since x is not BOS, it pops the next label and then begins processing the > IPv4 payload. So far, so good. **** > > ** ** > > However, I believe the following is legal as well:**** > > ** ** > > ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** > > ** ** > > Alternatively, an equally vexing scenario is:**** > > ** ** > > ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | .= .. > **** > > ** ** > > There are probably other reserved labels that are applicable as well.**** > > ** ** > > In either case, the draft doesn't clearly state what's supposed to happen= . > If I follow the procedures in 4.3, the datapath would end up popping the > GAL or the explicit NULL label (thinking they are entropy labels) and wou= ld > then attempt to lookup the entropy label (which would result in erroneous > behaviour). The only additional guidance that the draft gives is in > section 6 where it suggests that GAL could be treated as an application > label. But that doesn't seem helpful since the LSP label must *also *be > an application label (to handle the non-GAL case) and will always be > encountered first during label disposition. Also, presumably I don't wan= t > all GALs to expect entropy so there's an implied scoping of GAL.**** > > ** ** > > It seems to me that when a datapath encounters an entropy-enabled > application label or an ELI, that it essentially must do a "deferred pop = of > BOS label". In other words, if the datapath encounters an entropy-enable= d > AL or an ELI, it must make a note of it and continue processing labels > until it hits the BOS label, which it must pop. While certainly possible= , > this is a lot more convoluted and difficult to implement than what is > specified in the draft. Is this really the desired behaviour?**** > > ** ** > > The same question applies to type-4 VCCV with flow labels.**** > > ** ** > > regards,**** > > Pablo**** > > ** ** > --f46d0447a001b31c0f04b9082b20 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ah, good. =A0That certainly makes things more deterministic. =A0

    I guess the question now becomes how will this affect type-4 VCCV = on fat pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mandate the use = of ELIs when flow labels are present? =A0That seems too bad since the main = advantage of type-4 VCCV seems to be to save a few bytes on the wire. =A0Th= is puts the overhead right back in so it may be more attractive to run fat = PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15,= 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:<= br>

    Pablo,

    =A0

    Based upon Kireeti=92s update in Taipei, we s= eem to going towards using a reserved label for ELI and making it always re= quired.

    =A0<= /p>

    Thanks,<= /span>

    =A0<= /p>

    John =A0=

    =A0<= /p>

    From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org
    Subject: [mpls] Question about Entropy labels + GAL

    =A0

    I'm working on implementation for entropy labels and I have a q= uestion about=A0draft-ietf-mpls-entropy-label-01. =A0Consider a scenario wh= ere I have received the following:

    =A0

    ... | LSP label x | Entropy label | IPv4 payload | ...

    =A0

    Assume that I've signaled that the LSP label wants entropy and an ELI i= s unnecessary. =A0Following the procedures detailed in 4.3, the datapath wo= uld lookup label x and see that it is expecting a possible entropy label an= d since x is not BOS, it pops the next label and then begins processing the= IPv4 payload. =A0So far, so good. =A0

    =A0

    However, I believe the following is legal as well:=

    =A0

    <= p class=3D"MsoNormal"> ... | LSP label x | GAL label | Entropy label | BFD payload | ...=

    =A0

    <= p class=3D"MsoNormal">Alternatively, an equally vexing scenario is:<= u>

    =A0

    ... | LSP label x | IPv4 explicit NULL | Entropy label |= IPv4 payload | ...

    <= /u>=A0

    There are probably other reserved labels = that are applicable as well.

    =A0

    In either case,= the draft doesn't clearly state what's supposed to happen. =A0If I= follow the procedures in 4.3, the datapath would end up popping the GAL or= the explicit NULL label (thinking they are entropy labels) and would then = attempt to lookup the entropy label (which would result in erroneous behavi= our). =A0 The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. =A0Bu= t that doesn't seem helpful since the LSP label must also be an = application label (to handle the non-GAL case) and will always be encounter= ed first during label disposition. =A0Also, presumably I don't want all= GALs to expect entropy so there's an implied scoping of GAL.=

    =A0

    It seems to me that when a datapath encounters an entro= py-enabled application label or an ELI, that it essentially must do a "= ;deferred pop of BOS label". =A0In other words, if the datapath encoun= ters an entropy-enabled AL or an ELI, it must make a note of it and continu= e processing labels until it hits the BOS label, which it must pop. =A0Whil= e certainly possible, this is a lot more convoluted and difficult to implem= ent than what is specified in the draft. =A0Is this really the desired beha= viour?

    =A0

    The same question applies to type-4 VCCV with flow labels.

    =A0

    regards,

    Pablo

    =A0=


    --f46d0447a001b31c0f04b9082b20-- From Alexander.Vainshtein@ecitele.com Wed Feb 15 22:24:27 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFE21F851C for ; Wed, 15 Feb 2012 22:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=0.684, 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 OABr2Bsrya76 for ; Wed, 15 Feb 2012 22:24:26 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id C854821F850C for ; Wed, 15 Feb 2012 22:24:22 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1329373410!54455154!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 25466 invoked from network); 16 Feb 2012 06:23:30 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-27.messagelabs.com with SMTP; 16 Feb 2012 06:23:30 -0000 X-AuditID: 93eaf2e7-b7fb46d000005f52-8c-4f3cacdcca28 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 3E.D1.24402.CDCAC3F4; Thu, 16 Feb 2012 09:14:36 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 16 Feb 2012 08:24:20 +0200 From: Alexander Vainshtein To: Pablo Frank , John E Drake Date: Thu, 16 Feb 2012 08:22:36 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AczsMFnBTnRSQc/CQ/OmxQcJJA9zewAQHM7a Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net>, 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_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUYRTl25mdHVcnJnPdLynapjKorN0euJpbYQ8Uiq0MAql0mv3amdqd HXbWyDQUoYf7o3xApT002iTLMs1eUFRGVEZZkRSSkb3MNRRMiJ4205gJ0fw6c865594Z7iWx 6KAhjhTEAPKLrIchjHh5uH8g4UVditPa2jrRfrhjsb39RK3efqDnDmHf29+EL8LTrlR2GNJC oS+6tGdFbYaVWGYhSGFF0RdgA8jiQjLnYFb6ha0sl8tYBJeDsTEWycNyyIvEgINhJQmJLmaB 0fLPk6LYBNGCRM7nEkS3g0nPcCbY7fOSEmzMgvhJtjnzjWt4QbagBC8reCxeJMusG1kUJrsJ 4y/eKCKkb+K2d3VPiUJwfH0QRJCQngsfNx3FNBwLH72sJ1QcTV8HsLbXGQRGBe8HsORat14V CNoBG093/DbF0OlwIHxHp2KMXgJfdrUYVIzTU2BfTQUeBCQ5hk6ENeUFmt0OqzvaMZWOoWfD Q73LVZqiV8FXRd2E1uoZgG2Xw0AVIhSh6P59XMVAme1zS91QKzNsf1ul02amYehq69D8Jtj9 5qde85vgi931QPP7YG/FgEFrNhreq3iLa/6x8ObJ53gJiK0cEVs5oqRyRInGW2HfwypMw9Nh zbGeITwLNgw8ACP5amA4BUyCRwps9LqttpmIEwLIg2ZyPm8j0Bap6zL4WjW5GdAkYKKoRQUp zmg9u1XO9TaDsaSOMVHOaoUatdHnyuVZmc/y53iQ3AwgiTExVPJORaNcbO525Pf9kZYqP78U i4vkfMrKioGsOVbr/18YM/WO+7gimnYri7kFIQn5/+SMI0kGUqvV9qP9yI22bRI8gb+yjoxQ x4hSxshTPZQssV5ZcGt6C5gYZ6Y8qkCrAp8jDteqJ1QwODgYBmblo8dQu1RXlHJgw9VhJVin BCd+SFaDlaMZluIKgZcoWxfqW5sDrMlY25GCTnbZd+KK6ZLwgS8z8z8aLjyZOy7+4EK9r+v8 46TQl9j+/GI5I5uROvOmb5YeRqaeO3u3dEfX7X2lry+yMUm7g/yE9183ZBV/qs0bv6e8c/HR Wxw+I2thNrqQX38pP37q6shMo2FHtr2kfllq2pnye8XdDC7zrG0a5pfZXwR+yPsdBAAA Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 06:24:27 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank= [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo 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_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
    Pablo, John and all,
    A couple of comments:
     
    1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
    2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
    3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

    Regards,

         Sasha

     

     
     
     
     
     
     
     
    From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank [pabloisnot@gmail= .com]
    Sent: Thursday, February 16, 2012 12:24 AM
    To: John E Drake
    Cc: mpls@ietf.org; pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels + GAL

    Ah, good.  That certainly makes things more deterministic.  

    I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to mandate the use of= ELIs when flow labels are present?  That seems too bad since the main= advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right back in so= it may be more attractive to run fat PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net>= wrote:

    Pablo,

     

    Based upon Kireeti=92s update in Taipei, we= seem to going towards using a reserved label for ELI and making it always r= equired.

     

    Thanks,

     

    John  

     

    From: mpls-bounces@ietf.org [mailto:<= a href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org
    Subject: [mpls] Question about Entropy labels + GAL=

     

    I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

     

    ... | LSP label x | Entropy label | IPv4 payload | ..= .

     

    Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it is expecting a possi= ble entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload. &n= bsp;So far, so good.  

     

    However, I believe the following is legal as well:=

     

    ... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

     

    Alternatively, an equally vexing scenario is:<= u>

     

    ... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

     

    There are probably other reserved labels that are app= licable as well.

     

    In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the datapath= would end up popping the GAL or the explicit NULL label (thinking they are= entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour). &n= bsp; The only additional guidance that the draft gives is in section 6 where= it suggests that GAL could be treated as an application label.  But th= at doesn't seem helpful since the LSP label must also be an application label (to handle the non-GAL case) and w= ill always be encountered first during label disposition.  Also, presum= ably I don't want all GALs to expect entropy so there's an implied scoping o= f GAL.

     

    It seems to me that when a datapath encounters an ent= ropy-enabled application label or an ELI, that it essentially must do a &quo= t;deferred pop of BOS label".  In other words, if the datapath enc= ounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS labe= l, which it must pop.  While certainly possible, this is a lot more con= voluted and difficult to implement than what is specified in the draft. &nbs= p;Is this really the desired behaviour?

     

    The same question applies to type-4 VCCV with flow la= bels.

     

    regards,

    Pablo

     


    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_A3C5DF08D38B6049839A6F553B331C76011659266622ILPTMAIL02e_-- From matthew.bocci@alcatel-lucent.com Thu Feb 16 02:05:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573F21F86F2; Thu, 16 Feb 2012 02:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.802 X-Spam-Level: X-Spam-Status: No, score=-105.802 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 Deso07Afb70X; Thu, 16 Feb 2012 02:05:23 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7F21F871D; Thu, 16 Feb 2012 02:05:10 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1G9xrAL005020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Feb 2012 11:03:20 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 16 Feb 2012 11:02:53 +0100 From: "Bocci, Matthew (Matthew)" To: Gregory Mirsky , "pwe3@ietf.org" , "ietf@ietf.org" Date: Thu, 16 Feb 2012 11:02:51 +0100 Thread-Topic: Auth48 comments on draft-ietf-pwe3-static-pw-status-10 Thread-Index: AczskiYGRqS0mn8KS3+tOKP48PqizA== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB6284AB23A4Ematthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "pwe3-chairs@tools.ietf.org" , Stewart Bryant Subject: Re: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:05:25 -0000 --_000_CB6284AB23A4Ematthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, That is fine with me. Best regards Matthew On 15/02/2012 22:14, "Gregory Mirsky" > wrote: Dear Matthew, Authors, et al., I think that new text of fourth para in Section 5.3 adds some confusion. If= intension is to stop sending 'all clear' after three one-second intervals = went unacknowledged but before refresh timer expires then perhpas new text = can be more explicit: NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent at one se= cond intervals and before refresh timer expires. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, February 15, 2012 7:10 AM To: pwe3@ietf.org; ietf@ietf.org Cc: pwe3-chairs@tools.ietf.org; Stewart = Bryant Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some = issues with the acknowledgement procedures in Section 5.3 of the draft that= we feel should be addressed before publication. Since the draft has alread= y been through WG and IETF last call, we would like to highlight the propos= ed changes to the working group and solicit feedback. Best regards, Matthew Section 5.3, 3rd paragraph: Reason for change: The current suggested default refresh timer value is too short to allow sca= ling to very large numbers of PWs while minimising the overhead. It is also inco= nsistent with the suggested default requested in an ACK packet. Therefore we suggest= increasing the default to 600secs. OLD: The suggested default value for the refresh timer is 30 seconds. NEW: The suggested default value for the refresh timer is 600 seconds. Section 5.3, 4th paragraph: Reason for change: The current text requires that a receiving PE must acknowledge a PW status = message of 'clear all faults' in order to force a transmitter to stop sending PW st= atus messages at 1 second intervals. We are concerned that a mandatory acknowle= dgement adds an unnecessary complexity to the protocol which is inconsistent with the use of the acknowledgement as per the following section (5.3.1). Additi= onally, we are also concerned that this may cause problems if a transmitter is flapping between 'clear all faults' and a non-zero value, and if the acknowledgement is lost. We therefore suggest that the acknowledgement to 'clear all faults' be made optional, and that the transmitter behavior be = changed so that it sends up to 3 status messages of zero in a row, and then goes silen= t. OLD: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, it MUST be acknowledged with a packet with a timer value of zero. This will cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Section 5.3.1, 1st paragraph: Reason for change: The procedures currently defined in this paragraph can lead to a receiver of the static status message timing out if it requests, throught the use of= the ACK mechanism, a longer refresh timer from the transmitter. This is because= the current text implies that the transmitter change its referesh timer immedia= tely on receipt of the ack packet from the receiver. The new text clarifies that the refresh timer be updated at the end of the current refresh interval, as well as making some other editorial clarifications. OLD: The PE receiving a PW OAM message containing a PW status message can acknowledge the PW status message by simply building an almost identical reply packet with the A bit set, and transmitting it on the PW ACH back to the source of the PW status message. The timer value set in the reply packet SHOULD then be used by the PE as the new transmit interval. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent. The receiving PE MUST NOT retry to set the timer value more than once per timer value. NEW: A PE receiving a PW OAM message containing a PW status message MAY acknowledge the PW status message by simply building a reply packet with the same format and status code as the received PW OAM message, but with the A bit set, and transmitting it on the PW ACh back to the source of the PW OAM message. The receiving PE MAY use the refresh timer field in the acknowledgement packet to request a new refresh interval from the originator of the PW OAM message. The timer value set in the reply packet SHOULD then be used by the originator of the PW OAM message as the new transmit interval. If the requested refresh timer value is used, the PW OAM message transmission interval is only set to the new value and the new value sent in the next PW OAM message, when the current timer expires. If the transmitting PE does not want to use the new timer value (for local policy reasons, or because it simply cannot support it), it MUST refresh the PW OAM message with the timer value it desires. The receiving PE will then set its timeout timer according to the new refresh timer value that is in the packet received, regardless of what timer value it requested. The receiving PE MUST NOT request a new refresh timer value more than once per refresh interval. --_000_CB6284AB23A4Ematthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Greg,

    That is fine with me.

    Best regards

    Matthew

    On 15/02/2012 22:14, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote:

    <= div>
    Dear Matthew, Authors, et al.,
    I=20 think that new text of fourth para in Section 5.3 adds some confusion. If=20 intension is to stop sending 'all clear' after three one-second intervals w= ent=20 unacknowledged but before refresh timer expires then perhpas new text can b= e=20 more explicit:
    NEW: 
    To clear a particular s= tatus fault, the PE need only send an
    updated message with the co= rresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any oth= er PW OAM
    status message using the procedures described above; ho= wever,
    transmission will cease after 3 PW status messages have be= en sent at one second intervals a= nd before refresh=20 timer expires. A PW
    status message of zero MAY be= acknowledged as per the procedures=20 described 
    in Section 5.3.1. If it is acknowledged, then a t= imer
    value of zero MUST be used.  This SHOULD cause the PE s= ending the PW=20 status
    notification message with a PW status code equal to zero t= o stop=20 sending
     and to continue normal operation.
     
        Regards,
            Greg

    = From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org]= On Behalf Of Bocci, Matthew=20 (Matthew)
    Sent: Wednesday, February 15, 2012 7:10 AM
    To:=20 pwe3@ietf.org; ietf@ietf.org
    Cc: pwe3-chairs@tools.ietf.org; Stewart=20 Bryant
    Subject: [PWE3] Auth48 comments on=20 draft-ietf-pwe3-static-pw-status-10

    During Auth 48, the authors of draft-ietf-pwe3-static-pw-status foun= d some=20 issues with the acknowledgement procedures in Section 5.3 of the draft that= we=20 feel should be addressed before publication. Since the draft has already be= en=20 through WG and IETF last call, we would like to highlight the proposed chan= ges=20 to the working group and solicit feedback.

    Be= st regards,

    Matthew

    Section 5.3, 3rd paragraph:
    Reason for change:
    T= he current suggested default refresh timer value is too short to allow=20 scaling 
    to very large numbers of PWs while minimising the o= verhead. It is also=20 inconsistent
    with the suggested default requested in an ACK packe= t. Therefore we suggest=20 increasing
    the default to 600secs.

    OLD: = The suggested default value for the refresh timer is 30 seconds.
    =
    NEW: The suggested default value for the refresh timer is 60= 0 seconds.



    Section 5= .3, 4th paragraph:
    Reason for change:
    The current text = requires that a receiving PE must acknowledge a PW status=20 message
    of 'clear all faults' in order to force a transmitter to = stop sending PW=20 status
    messages at 1 second intervals.  We are concerned tha= t a mandatory=20 acknowledgement
    adds an unnecessary complexity to the protocol wh= ich is inconsistent=20 with
    the use of the acknowledgement as per the following section = (5.3.1).=20 Additionally,
    we are also concerned that this may cause problems = if a=20 transmitter 
    is flapping between 'clear all faults' and a no= n-zero value, and if=20 the 
    acknowledgement is lost. We therefore suggest that= the acknowledgement=20 to 
    'clear all faults' be made optional, and that  the = transmitter=20 behavior be changed so 
    that it sends up to 3 status message= s of zero in a row, and then goes=20 silent.

    OLD: 
    To clear a particular= status fault, the PE need only send an
    updated message with the = corresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any oth= er PW OAM
    status message using the procedures described above; ho= wever, it MUST=20 be
    acknowledged with a packet with a timer value of zero.  T= his will=20 cause
    the PE sending the PW status notification message with a PW= status=20 code
    equal to zero to stop sending and to continue normal operati= on.


    NEW: 
    To clear a= particular status fault, the PE need only send an
    updated messag= e with the corresponding bit cleared.  If the PW=20 status
    code is zero, the PW OAM message will be sent like any oth= er PW OAM
    status message using the procedures described above; ho= wever,
    transmission will cease after 3 PW status messages have be= en sent. A=20 PW
    status message of zero MAY be acknowledged as per the procedur= es=20 described 
    in Section 5.3.1. If it is acknowledged, then a t= imer
    value of zero MUST be used.  This SHOULD cause the PE s= ending the PW=20 status
    notification message with a PW status code equal to zero t= o stop=20 sending
     and to continue normal operation.


    Section 5.3.1, 1st paragraph:
    Reason for c= hange:
    The procedures currently defined in this paragraph can lea= d to a=20 receiver
    of the static status message timing out if it requests, = throught the use of=20 the
    ACK mechanism, a longer refresh timer from the transmitter. T= his is because=20 the
    current text implies that the transmitter change its referesh= timer=20 immediately
    on receipt of the ack packet from the receiver. The n= ew text clarifies=20 that 
    the refresh timer be updated at the end of the current= refresh interval,=20 as 
    well as making some other editorial clarifications.

    OLD: 
    The PE receiving a PW OAM message= containing a PW status message
    can acknowledge the PW status mes= sage by simply building an almost
    identical reply packet with the= A bit set, and transmitting it on the=20 PW
    ACH back to the source of the PW status message.  The tim= er value set=20 in
    the reply packet SHOULD then be used by the PE as the new tran= smit
    interval.  If the transmitting PE does not want to use = the new=20 timer
    value (for local policy reasons, or because it simply canno= t support
    it), it MUST refresh the PW OAM message with the timer = value it=20 desires.
    The receiving PE will then set its timeout timer accordi= ng to the=20 timer
    value that is in the packet received, regardless of what ti= mer value=20 it
    sent.  The receiving PE MUST NOT retry to set the timer v= alue more=20 than
    once per timer value.

    NEW: 
    A PE receiving a PW OAM message containing a PW status message MAY<= /div>
    acknowledge the PW status message by simply building a reply=20 packet 
    with the same format and status code as the received= PW OAM message,
    but with the A bit set, and transmitting it on t= he PW ACh back
    to the source of the PW OAM message.  The rec= eiving PE MAY use=20 the
    refresh timer field in the acknowledgement packet to request = a new
    refresh interval from the originator of the PW OAM message.= The timer
    value set in the reply packet SHOULD then be used by t= he originator=20 of
    the PW OAM message as the new transmit interval.  If the = requested
    refresh timer value is used, the PW OAM message transmi= ssion interval=20 is
    only set to the new value and the new value sent in the next P= W OAM
    message, when the current timer expires. If the transmittin= g PE does=20 not
    want to use the new timer value (for local policy reasons, or= because=20 it
    simply cannot support it), it MUST refresh the PW OAM message = with=20 the
    timer value it desires. The receiving PE will then set its ti= meout=20 timer
    according to the new refresh timer value that is in the pac= ket=20 received,
    regardless of what timer value it requested.  The = receiving PE MUST=20 NOT
    request a new refresh timer value more than once per refresh = interval.

    = --_000_CB6284AB23A4Ematthewboccialcatellucentcom_-- From stbryant@cisco.com Thu Feb 16 03:48:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36C21F8574; Thu, 16 Feb 2012 03:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.448 X-Spam-Level: X-Spam-Status: No, score=-109.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8, 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 3dw6gJKsQV5J; Thu, 16 Feb 2012 03:48:36 -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 DD6E121F8557; Thu, 16 Feb 2012 03:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=25782; q=dns/txt; s=iport; t=1329392893; x=1330602493; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=G8sjRuwM3BgkAh1Fu99TmAgA4o4HWL6wXsA5Zk3Kq6s=; b=RGx/Gvcp/nrYI1kVSmNGb88ClqyRuqvNNvf6WXhmSWM8GGZyhlPaP52D kd3shHnHvSbg1LhgpXV0Wm3YLy7/7LZ36g5k3Lun3Q7D0worrSR39Zqmx z5MnE1/7jZOIZxsjzHLYKGSlg9CXFuAx4jcFa5PlY0dcy5OrgNsCJZYV4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM7sPE+Q/khN/2dsb2JhbABDglGuEoEHgXIBAQEEEgECAWIBEAsRBAEBAQkWAQcHCQMCAQIBNAkIBgEMAQUCAQEeh2afDQGDMQ8Bkx6LYgICBAMBAgECAQEDBgICAQYEAgQBBQI5AYNUGwUGKwMCBAQFDAGDKgSCXZJakmg X-IronPort-AV: E=Sophos;i="4.73,428,1325462400"; d="scan'208,217";a="66284791" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Feb 2012 11:48:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1GBm7Y8004744; Thu, 16 Feb 2012 11:48:07 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q1GBm6MR004467; Thu, 16 Feb 2012 11:48:07 GMT Message-ID: <4F3CECF5.5020806@cisco.com> Date: Thu, 16 Feb 2012 11:48:05 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" , "iesg@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040602080900040000010009" Cc: "pwe3@ietf.org" , "ietf@ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 11:48:40 -0000 This is a multi-part message in MIME format. --------------040602080900040000010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Having spoken to a number of the authors at length I think the text changes that Matthew has proposed are correct (with Greg's change) and thank the authors for picking this up. I propose to let this sit until a week tomorrow (23/Feb) and provided that there are no technical issues with the proposed changes I will ask the RFC Editor to make the changes and to publish the RFC. - Stewart On 16/02/2012 10:02, Bocci, Matthew (Matthew) wrote: > Greg, > > That is fine with me. > > Best regards > > Matthew > > On 15/02/2012 22:14, "Gregory Mirsky" > wrote: > > Dear Matthew, Authors, et al., > I think that new text of fourth para in Section 5.3 adds some > confusion. If intension is to stop sending 'all clear' after three > one-second intervals went unacknowledged but before refresh timer > expires then perhpas new text can be more explicit: > NEW: > To clear a particular status fault, the PE need only send an > updated message with the corresponding bit cleared. If the PW status > code is zero, the PW OAM message will be sent like any other PW OAM > status message using the procedures described above; however, > transmission will cease after 3 PW status messages have been > sent/_at one second intervals and before refresh timer expires_/. A PW > status message of zero MAY be acknowledged as per the procedures > described > in Section 5.3.1. If it is acknowledged, then a timer > value of zero MUST be used. This SHOULD cause the PE sending the > PW status > notification message with a PW status code equal to zero to stop > sending > and to continue normal operation. > Regards, > Greg > > ------------------------------------------------------------------------ > *From:* pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Bocci, Matthew (Matthew) > *Sent:* Wednesday, February 15, 2012 7:10 AM > *To:* pwe3@ietf.org ; ietf@ietf.org > > *Cc:* pwe3-chairs@tools.ietf.org > ; Stewart Bryant > *Subject:* [PWE3] Auth48 comments on > draft-ietf-pwe3-static-pw-status-10 > > During Auth 48, the authors of draft-ietf-pwe3-static-pw-status > found some issues with the acknowledgement procedures in Section > 5.3 of the draft that we feel should be addressed before > publication. Since the draft has already been through WG and IETF > last call, we would like to highlight the proposed changes to the > working group and solicit feedback. > > Best regards, > > Matthew > > Section 5.3, 3rd paragraph: > Reason for change: > The current suggested default refresh timer value is too short to > allow scaling > to very large numbers of PWs while minimising the overhead. It is > also inconsistent > with the suggested default requested in an ACK packet. Therefore > we suggest increasing > the default to 600secs. > > OLD: The suggested default value for the refresh timer is 30 seconds. > > NEW: The suggested default value for the refresh timer is 600 seconds. > > > > Section 5.3, 4th paragraph: > Reason for change: > The current text requires that a receiving PE must acknowledge a > PW status message > of 'clear all faults' in order to force a transmitter to stop > sending PW status > messages at 1 second intervals. We are concerned that a mandatory > acknowledgement > adds an unnecessary complexity to the protocol which is > inconsistent with > the use of the acknowledgement as per the following section > (5.3.1). Additionally, > we are also concerned that this may cause problems if a transmitter > is flapping between 'clear all faults' and a non-zero value, and > if the > acknowledgement is lost. We therefore suggest that the > acknowledgement to > 'clear all faults' be made optional, and that the transmitter > behavior be changed so > that it sends up to 3 status messages of zero in a row, and then > goes silent. > > OLD: > To clear a particular status fault, the PE need only send an > updated message with the corresponding bit cleared. If the PW status > code is zero, the PW OAM message will be sent like any other PW OAM > status message using the procedures described above; however, it > MUST be > acknowledged with a packet with a timer value of zero. This will > cause > the PE sending the PW status notification message with a PW status > code > equal to zero to stop sending and to continue normal operation. > > > NEW: > To clear a particular status fault, the PE need only send an > updated message with the corresponding bit cleared. If the PW status > code is zero, the PW OAM message will be sent like any other PW OAM > status message using the procedures described above; however, > transmission will cease after 3 PW status messages have been sent. > A PW > status message of zero MAY be acknowledged as per the procedures > described > in Section 5.3.1. If it is acknowledged, then a timer > value of zero MUST be used. This SHOULD cause the PE sending the > PW status > notification message with a PW status code equal to zero to stop > sending > and to continue normal operation. > > > Section 5.3.1, 1st paragraph: > Reason for change: > The procedures currently defined in this paragraph can lead to a > receiver > of the static status message timing out if it requests, throught > the use of the > ACK mechanism, a longer refresh timer from the transmitter. This > is because the > current text implies that the transmitter change its referesh > timer immediately > on receipt of the ack packet from the receiver. The new text > clarifies that > the refresh timer be updated at the end of the current refresh > interval, as > well as making some other editorial clarifications. > > OLD: > The PE receiving a PW OAM message containing a PW status message > can acknowledge the PW status message by simply building an almost > identical reply packet with the A bit set, and transmitting it on > the PW > ACH back to the source of the PW status message. The timer value > set in > the reply packet SHOULD then be used by the PE as the new transmit > interval. If the transmitting PE does not want to use the new timer > value (for local policy reasons, or because it simply cannot support > it), it MUST refresh the PW OAM message with the timer value it > desires. > The receiving PE will then set its timeout timer according to the > timer > value that is in the packet received, regardless of what timer > value it > sent. The receiving PE MUST NOT retry to set the timer value more > than > once per timer value. > > NEW: > A PE receiving a PW OAM message containing a PW status message MAY > acknowledge the PW status message by simply building a reply packet > with the same format and status code as the received PW OAM message, > but with the A bit set, and transmitting it on the PW ACh back > to the source of the PW OAM message. The receiving PE MAY use the > refresh timer field in the acknowledgement packet to request a new > refresh interval from the originator of the PW OAM message. The timer > value set in the reply packet SHOULD then be used by the originator of > the PW OAM message as the new transmit interval. If the requested > refresh timer value is used, the PW OAM message transmission > interval is > only set to the new value and the new value sent in the next PW OAM > message, when the current timer expires. If the transmitting PE > does not > want to use the new timer value (for local policy reasons, or > because it > simply cannot support it), it MUST refresh the PW OAM message with the > timer value it desires. The receiving PE will then set its timeout > timer > according to the new refresh timer value that is in the packet > received, > regardless of what timer value it requested. The receiving PE > MUST NOT > request a new refresh timer value more than once per refresh interval. > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040602080900040000010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Having spoken to a number of the authors at length
    I think  the text changes that Matthew has proposed
    are correct (with Greg's change) and thank the authors
    for picking this up.

    I propose to let this sit until a week tomorrow (23/Feb)
    and provided that there are no technical issues with the
    proposed changes I will ask the RFC Editor to make
    the changes and to publish the RFC.

    - Stewart


    On 16/02/2012 10:02, Bocci, Matthew (Matthew) wrote:
    Greg,

    That is fine with me.

    Best regards

    Matthew

    On 15/02/2012 22:14, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote:

    Dear Matthew, Authors, et al.,
    I think that new text of fourth para in Section 5.3 adds some confusion. If intension is to stop sending 'all clear' after three one-second intervals went unacknowledged but before refresh timer expires then perhpas new text can be more explicit:
    NEW: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however,
    transmission will cease after 3 PW status messages have been sent at one second intervals and before refresh timer expires. A PW
    status message of zero MAY be acknowledged as per the procedures described 
    in Section 5.3.1. If it is acknowledged, then a timer
    value of zero MUST be used.  This SHOULD cause the PE sending the PW status
    notification message with a PW status code equal to zero to stop sending
     and to continue normal operation.
     
        Regards,
            Greg

    From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
    Sent: Wednesday, February 15, 2012 7:10 AM
    To: pwe3@ietf.org; ietf@ietf.org
    Cc: pwe3-chairs@tools.ietf.org; Stewart Bryant
    Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10

    During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some issues with the acknowledgement procedures in Section 5.3 of the draft that we feel should be addressed before publication. Since the draft has already been through WG and IETF last call, we would like to highlight the proposed changes to the working group and solicit feedback.

    Best regards,

    Matthew

    Section 5.3, 3rd paragraph:
    Reason for change:
    The current suggested default refresh timer value is too short to allow scaling 
    to very large numbers of PWs while minimising the overhead. It is also inconsistent
    with the suggested default requested in an ACK packet. Therefore we suggest increasing
    the default to 600secs.

    OLD: The suggested default value for the refresh timer is 30 seconds.

    NEW: The suggested default value for the refresh timer is 600 seconds.



    Section 5.3, 4th paragraph:
    Reason for change:
    The current text requires that a receiving PE must acknowledge a PW status message
    of 'clear all faults' in order to force a transmitter to stop sending PW status
    messages at 1 second intervals.  We are concerned that a mandatory acknowledgement
    adds an unnecessary complexity to the protocol which is inconsistent with
    the use of the acknowledgement as per the following section (5.3.1). Additionally,
    we are also concerned that this may cause problems if a transmitter 
    is flapping between 'clear all faults' and a non-zero value, and if the 
    acknowledgement is lost. We therefore suggest that the acknowledgement to 
    'clear all faults' be made optional, and that  the transmitter behavior be changed so 
    that it sends up to 3 status messages of zero in a row, and then goes silent.

    OLD: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however, it MUST be
    acknowledged with a packet with a timer value of zero.  This will cause
    the PE sending the PW status notification message with a PW status code
    equal to zero to stop sending and to continue normal operation.


    NEW: 
    To clear a particular status fault, the PE need only send an
    updated message with the corresponding bit cleared.  If the PW status
    code is zero, the PW OAM message will be sent like any other PW OAM
    status message using the procedures described above; however,
    transmission will cease after 3 PW status messages have been sent. A PW
    status message of zero MAY be acknowledged as per the procedures described 
    in Section 5.3.1. If it is acknowledged, then a timer
    value of zero MUST be used.  This SHOULD cause the PE sending the PW status
    notification message with a PW status code equal to zero to stop sending
     and to continue normal operation.


    Section 5.3.1, 1st paragraph:
    Reason for change:
    The procedures currently defined in this paragraph can lead to a receiver
    of the static status message timing out if it requests, throught the use of the
    ACK mechanism, a longer refresh timer from the transmitter. This is because the
    current text implies that the transmitter change its referesh timer immediately
    on receipt of the ack packet from the receiver. The new text clarifies that 
    the refresh timer be updated at the end of the current refresh interval, as 
    well as making some other editorial clarifications.

    OLD: 
    The PE receiving a PW OAM message containing a PW status message
    can acknowledge the PW status message by simply building an almost
    identical reply packet with the A bit set, and transmitting it on the PW
    ACH back to the source of the PW status message.  The timer value set in
    the reply packet SHOULD then be used by the PE as the new transmit
    interval.  If the transmitting PE does not want to use the new timer
    value (for local policy reasons, or because it simply cannot support
    it), it MUST refresh the PW OAM message with the timer value it desires.
    The receiving PE will then set its timeout timer according to the timer
    value that is in the packet received, regardless of what timer value it
    sent.  The receiving PE MUST NOT retry to set the timer value more than
    once per timer value.

    NEW: 
    A PE receiving a PW OAM message containing a PW status message MAY
    acknowledge the PW status message by simply building a reply packet 
    with the same format and status code as the received PW OAM message,
    but with the A bit set, and transmitting it on the PW ACh back
    to the source of the PW OAM message.  The receiving PE MAY use the
    refresh timer field in the acknowledgement packet to request a new
    refresh interval from the originator of the PW OAM message. The timer
    value set in the reply packet SHOULD then be used by the originator of
    the PW OAM message as the new transmit interval.  If the requested
    refresh timer value is used, the PW OAM message transmission interval is
    only set to the new value and the new value sent in the next PW OAM
    message, when the current timer expires. If the transmitting PE does not
    want to use the new timer value (for local policy reasons, or because it
    simply cannot support it), it MUST refresh the PW OAM message with the
    timer value it desires. The receiving PE will then set its timeout timer
    according to the new refresh timer value that is in the packet received,
    regardless of what timer value it requested.  The receiving PE MUST NOT
    request a new refresh timer value more than once per refresh interval.

     


    -- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
    --------------040602080900040000010009-- From internet-drafts@ietf.org Thu Feb 16 08:12:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D5321F86E0; Thu, 16 Feb 2012 08:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 M+XlQVYtFZTO; Thu, 16 Feb 2012 08:12:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A72621F8839; Thu, 16 Feb 2012 08:12:24 -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.64p2 Message-ID: <20120216161224.32434.6930.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 08:12:24 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:12:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Redundancy Author(s) : Praveen Muley Mustapha Aissaoui Matthew Bocci Filename : draft-ietf-pwe3-redundancy-06.txt Pages : 15 Date : 2012-02-16 This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single segment PW applications, or between Terminating PE nodes in Multi-Segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-06.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-pwe3-redundancy-06.txt From pabloisnot@gmail.com Thu Feb 16 08:22:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0DD21F8833; Thu, 16 Feb 2012 08:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.309, 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 T2SJKEiynQaj; Thu, 16 Feb 2012 08:22:06 -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 E444D21F8830; Thu, 16 Feb 2012 08:22:05 -0800 (PST) Received: by ggnq2 with SMTP id q2so1523850ggn.31 for ; Thu, 16 Feb 2012 08:22:05 -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=SjNc7nZnYigSwOntli3uKdN6KVAWzoF8V2QrjV2XfsY=; b=msbj2zkadn/heBL3jnoyWxfigBK1JaTzVxwYrUC6aO7QjtOUH6dmeMv0cYH/XcGsjk TshZ+zmrDp7qRRqsCT1nLQ7BbPAFVlfeucCJ0a9nvxVC61iHGqUus8nwht6Qq8AxN+nO 19bQ//KQOrCkVRmdwDFqcVxaqqPM9kM1JynPY= MIME-Version: 1.0 Received: by 10.60.1.230 with SMTP id 6mr1116051oep.42.1329409325420; Thu, 16 Feb 2012 08:22:05 -0800 (PST) Received: by 10.182.42.137 with HTTP; Thu, 16 Feb 2012 08:22:05 -0800 (PST) In-Reply-To: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Thu, 16 Feb 2012 11:22:05 -0500 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8fb1ffa49a52a604b9173ab8 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:22:07 -0000 --e89a8fb1ffa49a52a604b9173ab8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think there's still a bit of awkwardness around implementing this. Both the original entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL, or any other reserved label gets thrown into the mix, the label disposition logic gets suddenly more complex. Instead of pop-pop, the hardware will have to do more complicated logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very programmable hardware at my disposal, I prefer elegant and simple and this feels wrong. It sounds like the authors of the entropy label draft have recognized this problem and are now moving towards mandating the use of a reserved ELI which unambiguously implies that the next label is entropy (so the hardware can go back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation is unambiguous. If I encounter any of these types of PWEs with flow-enabled, I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and dispose of the GAL and flow label correctly. A reserved ELI could help disambiguate the situation in this case but this makes running type-4 VCCV with flow labels unattractive compared to type-1 VCCV. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Pablo, John and all, > A couple of comments: > > > 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 > has relaxed the original requirement for GAL being at the bottom of > stack that have been defined in RFC 5586. > 2. My reading of RFC 6391 is that it mandates the flow label to be at > the bottom of the label stack for PW packets carrying user data. And > it does not provide for ELI usage anywhere, be it a reserved label or = a > signaled one. > 3. To the best of my understanding, the situation when GAL is used for > fat PWs is not explicitly defined. Inserting GAL between the PW label = and > flow label (with the ACH header immediately following the label stack) > seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe th= is > format should be explicitly defined as the correct one? > > Regards, > > Sasha > > > > > > > > > > ------------------------------ > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo > Frank [pabloisnot@gmail.com] > *Sent:* Thursday, February 16, 2012 12:24 AM > *To:* John E Drake > *Cc:* mpls@ietf.org; pwe3@ietf.org > *Subject:* Re: [mpls] Question about Entropy labels + GAL > > Ah, good. That certainly makes things more deterministic. > > I guess the question now becomes how will this affect type-4 VCCV on fat > pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs > when flow labels are present? That seems too bad since the main advantag= e > of type-4 VCCV seems to be to save a few bytes on the wire. This puts th= e > overhead right back in so it may be more attractive to run fat PWEs with > type-1 VCCV... > > Pablo > > On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote: > >> Pablo,**** >> >> **** >> >> Based upon Kireeti=92s update in Taipei, we seem to going towards using = a >> reserved label for ELI and making it always required.**** >> >> **** >> >> Thanks,**** >> >> **** >> >> John **** >> >> **** >> >> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf >> Of *Pablo Frank >> *Sent:* Wednesday, February 15, 2012 7:30 AM >> *To:* mpls@ietf.org >> *Subject:* [mpls] Question about Entropy labels + GAL**** >> >> **** >> >> I'm working on implementation for entropy labels and I have a question >> about draft-ietf-mpls-entropy-label-01. Consider a scenario where I hav= e >> received the following:**** >> >> **** >> >> ... | LSP label x | Entropy label | IPv4 payload | ...**** >> >> **** >> >> Assume that I've signaled that the LSP label wants entropy and an ELI is >> unnecessary. Following the procedures detailed in 4.3, the datapath wou= ld >> lookup label x and see that it is expecting a possible entropy label and >> since x is not BOS, it pops the next label and then begins processing th= e >> IPv4 payload. So far, so good. **** >> >> **** >> >> However, I believe the following is legal as well:**** >> >> **** >> >> ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** >> >> **** >> >> Alternatively, an equally vexing scenario is:**** >> >> **** >> >> ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | >> ...**** >> >> **** >> >> There are probably other reserved labels that are applicable as well.***= * >> >> **** >> >> In either case, the draft doesn't clearly state what's supposed to >> happen. If I follow the procedures in 4.3, the datapath would end up >> popping the GAL or the explicit NULL label (thinking they are entropy >> labels) and would then attempt to lookup the entropy label (which would >> result in erroneous behaviour). The only additional guidance that the >> draft gives is in section 6 where it suggests that GAL could be treated = as >> an application label. But that doesn't seem helpful since the LSP label >> must *also *be an application label (to handle the non-GAL case) and >> will always be encountered first during label disposition. Also, >> presumably I don't want all GALs to expect entropy so there's an implied >> scoping of GAL.**** >> >> **** >> >> It seems to me that when a datapath encounters an entropy-enabled >> application label or an ELI, that it essentially must do a "deferred pop= of >> BOS label". In other words, if the datapath encounters an entropy-enabl= ed >> AL or an ELI, it must make a note of it and continue processing labels >> until it hits the BOS label, which it must pop. While certainly possibl= e, >> this is a lot more convoluted and difficult to implement than what is >> specified in the draft. Is this really the desired behaviour?**** >> >> **** >> >> The same question applies to type-4 VCCV with flow labels.**** >> >> **** >> >> regards,**** >> >> Pablo**** >> >> **** >> > > 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 u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --e89a8fb1ffa49a52a604b9173ab8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Sasha. =A0I completely concur with your points 1 and 2.

    As for point #3, that seems like the logical conclusion. =A0However,= I think there's still a bit of awkwardness around implementing this. = =A0Both the original entropy-label draft and RFC 6391 have assumed a simple= pop-pop logic when you encounter an entropy-enabled AL or a flow-enabled P= W. =A0The moment GAL, or any other reserved label gets thrown into the mix,= the label disposition logic gets suddenly more complex. =A0Instead of pop-= pop, the hardware will have to do more complicated logic like "IF this= is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF .= .., etc.". =A0While I have very programmable hardware at my disposal, = I prefer elegant and simple and this feels wrong.

    It sounds like the authors of the entropy label draft h= ave recognized this problem and are now moving towards mandating the use of= a reserved ELI which unambiguously implies that the next label is entropy = (so the hardware can go back to having simple pop-pop logic when it sees a = reserved ELI).

    Which brings me back to VCCV. =A0If I'm doing type-= 1,2,3 VCCV, the situation is unambiguous. =A0If I encounter any of these ty= pes of PWEs with flow-enabled, I can do a pop-pop. =A0If for type-4 VCCV, w= e assume that the GAL is between the PW label and flow label (which I think= was the intent), we're back to having ugly logic to try and dispose of= the GAL and flow label correctly. =A0A reserved ELI could help disambiguat= e the situation in this case but this makes running type-4 VCCV with flow l= abels unattractive compared to type-1 VCCV.

    regards,
    Pablo

    On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein <Alexander.= Vainshtein@ecitele.com> wrote:
    Pablo, John and all,
    A couple of comments:
    =A0
    1. Following a=A0long discussion on the PWE3 WG mailing list RFC 6423 has = relaxed the original=A0requirement for GAL being at the bottom of st= ack that have been defined in RFC 5586.
    2. My reading of=A0RFC 6391 is that it mandates the flow label to be = at the bottom of the label stack for PW packets=A0carrying user data= . And it does not provide for ELI usage anywhere, be it a reserved label or= a signaled one.
    3. To the best of my understanding, the situation when GAL is used fo= r fat PWs is not explicitly defined.=A0Inserting GAL between the PW label a= nd flow label (with the ACH header immediately following the label stack) s= eems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the c= orrect one?

    Regards,

    =A0=A0=A0=A0 Sasha

    =A0

    =A0
    =A0
    =A0
    =A0
    =A0
    =A0
    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] = On Behalf Of Pablo Frank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 12:24 AM
    To: John E Drake
    Cc: mpls@ietf.org= ; pwe3@ietf.org<= br> Subject: Re: [mpls] Question about Entropy labels + GAL

    Ah, good. =A0That certainly makes things more deterministic. =A0

    I guess the question now becomes how will this affect type-4 VCCV on f= at pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mandate the use of E= LIs when flow labels are present? =A0That seems too bad since the main adva= ntage of type-4 VCCV seems to be to save a few bytes on the wire. =A0This puts the overhead right back in so i= t may be more attractive to run fat PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.= net> wrote:

    Pablo,

    =A0

    Based upon Kireeti=92s update i= n Taipei, we seem to going towards using a reserved label for ELI and makin= g it always required.

    =A0

    Thanks,

    =A0

    John =A0

    =A0

    From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org=
    Subject: [mpls] Question about Entropy labels + GAL

    =A0

    I'm working on implementation for entropy labels= and I have a question about=A0draft-ietf-mpls-entropy-label-01. =A0Conside= r a scenario where I have received the following:

    =A0

    ... | LSP label x | Entropy label | IPv4 payload | .= ..

    =A0

    Assume that I've signaled that the LSP label wan= ts entropy and an ELI is unnecessary. =A0Following the procedures detailed = in 4.3, the datapath would lookup label x and see that it is expecting a po= ssible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 payload. = =A0So far, so good. =A0

    =A0

    However, I believe the following is legal as well:

    =A0

    ... | LSP label x | GAL label | Entropy label | BFD = payload | ...

    =A0

    Alternatively, an equally vexing scenario is:=

    =A0

    ... | LSP label x | IPv4 explicit NULL | Entropy lab= el | IPv4 payload | ...

    =A0

    There are probably other reserved labels that are ap= plicable as well.

    =A0

    In either case, the draft doesn't clearly state = what's supposed to happen. =A0If I follow the procedures in 4.3, the da= tapath would end up popping the GAL or the explicit NULL label (thinking th= ey are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous behaviour). = =A0 The only additional guidance that the draft gives is in section 6 where= it suggests that GAL could be treated as an application label. =A0But that= doesn't seem helpful since the LSP label must also be an application label (to handle the non-GAL case) and = will always be encountered first during label disposition. =A0Also, presuma= bly I don't want all GALs to expect entropy so there's an implied s= coping of GAL.

    =A0

    It seems to me that when a datapath encounters an en= tropy-enabled application label or an ELI, that it essentially must do a &q= uot;deferred pop of BOS label". =A0In other words, if the datapath enc= ounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels until it hits the BOS lab= el, which it must pop. =A0While certainly possible, this is a lot more conv= oluted and difficult to implement than what is specified in the draft. =A0I= s this really the desired behaviour?

    =A0

    The same question applies to type-4 VCCV with flow l= abels.

    =A0

    regards,

    Pablo

    =A0


    This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof.


    --e89a8fb1ffa49a52a604b9173ab8-- From Alexander.Vainshtein@ecitele.com Thu Feb 16 10:21:42 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4311E8083 for ; Thu, 16 Feb 2012 10:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=0.646, 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 L-kEoCs26t5a for ; Thu, 16 Feb 2012 10:21:40 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 6A48121F85D0 for ; Thu, 16 Feb 2012 10:21:39 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1329416495!11847677!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 20460 invoked from network); 16 Feb 2012 18:21:36 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-21.messagelabs.com with SMTP; 16 Feb 2012 18:21:36 -0000 X-AuditID: 93eaf2e7-b7f7e6d000000e6e-21-4f3d54f3fbf0 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 6A.E9.03694.3F45D3F4; Thu, 16 Feb 2012 21:11:47 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 16 Feb 2012 20:21:34 +0200 From: Alexander Vainshtein To: Pablo Frank Date: Thu, 16 Feb 2012 20:19:49 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AczsxuMbq96bWAYQQmuyXUacvdqK9wADhOgx Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> , 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_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLsWRmVeSWpSXmKPExsUy+dWnL7qfQ2z9DU7tU7CYc9fZ4tbSlawW 018fZ7Po+7SFxYHFY+esu+weS5b8ZPK43nSVPYA5qoHRJjEvL78ksSRVISW1ONlWKaAosywx uVJJITPFVslQSaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++ta WJha6hoq2akpGxpbc4VkZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBnHLu0g7Wgfz9jxc63G5gb GH/PZ+xi5OSQEDCR+L/7NBuELSZx4d56IJuLQ0hgL6PE5v+rWCGcKYwSfR++M4NUsQnYSmxa fResQ0RATWLdxJlgk5gFMiWeLP/OBGKzCKhK/D7cDGRzcAgLmEssm1wPUW4hseDuLWYI20ji d+cEMJtXIFCi5+Q3FhBbSOAZk8TrRY4gNidQ/Of8JWBxRqDjvp9awwSxSlzi1pP5TBBHC0gs 2XOeGcIWlXj5+B8rRL2oxJ329VCn5Uu8ePiEEWKXoMTJmU9YIOolJQ6uuMEygVFsFpKxs5C0 zELSAhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMyOILGNlXMYpm5hSUJOWmGxjqpSZnlqTmpOol 5+duYoSkpec7GH/NVznEKMDBqMTDW2Bv6y/EmlhWXJl7iFGSg0lJlHeWO1CILyk/pTIjsTgj vqg0J7X4EKMEB7OSCG++DFCONyWxsiq1KB8m5QoM/InMUtzJ+cBUm1cSb2xggJujJM77NPmN r5BAOjBtZqemFqQWwcyR4eBQkuAN9gBaIViUmp5akZaZU4KQZuLgBDmDB+iMKJAa3uKCxNzi zHSI/ClGXY5pH55fYBRiycvPS5US560BKRIAKcoozYObA8pR9f///3/FKA4MAGHeKpAqHmB+ g5v0CmgJE9AS8xdWIEuAeQguJdXAuEo1J3UP11pj/9uXLRXftiu3L3vQfLv2ieXR89d2BC4/ GKolFtjjPytsR5G56RuPzTvbut1nOLT1HudsYXt2sITdvpjfdqnFrf5WdaYYI43VIc59ay+I XZjvcSxO+OBm8dkxKQt/XBeIZ9ObOilDesm3x/Lnu/VszIqr0sWuVG75fevmpusblFiKMxIN tZiLihMB9XgS9SwEAAA= Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:21:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and f= low label is much simpler than what you have described. This logic is based= on the fact "application labels" can be easily recognized as such by the LS= R that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW forw= arder, VRF etc.) for handling. The data for this application directly follow= s the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV-= 4" handler, The data for the "VCCV-4 handler" application directly follows t= he label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "fl= ow label", i.e. pass to the corresponding application (may include CW in the= case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully co= nsistent with RFC 6073 which explains that if you want an S-PE to handle a V= CCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined with= VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think t= here's still a bit of awkwardness around implementing this. Both the origin= al entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when= you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL,= or any other reserved label gets thrown into the mix, the label disposition= logic gets suddenly more complex. Instead of pop-pop, the hardware will ha= ve to do more complicated logic like "IF this is a flow-enabled label AND th= e next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very pr= ogrammable hardware at my disposal, I prefer elegant and simple and this fee= ls wrong. It sounds like the authors of the entropy label draft have recognized this p= roblem and are now moving towards mandating the use of a reserved ELI which= unambiguously implies that the next label is entropy (so the hardware can g= o back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation i= s unambiguous. If I encounter any of these types of PWEs with flow-enabled,= I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between= the PW label and flow label (which I think was the intent), we're back to h= aving ugly logic to try and dispose of the GAL and flow label correctly. A= reserved ELI could help disambiguate the situation in this case but this ma= kes running type-4 VCCV with flow labels unattractive compared to type-1 VCC= V. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Pablo Frank [pabloisnot@gma= il.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo 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. 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_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
    Pablo,
    Lots of thanks for a prompt response.
     
    I think that the situation with GAL betw= een the PW (application label) and flow label is much simpler than what you= have described. This logic is based on the fact "application labels&qu= ot; can be easily recognized as such by the LSR that examines them during label stack parsing.
     
    When an application label is encountered= , there are just three cases:
    1. It is BoS - nothing ne= w, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows= the label stack (may include CW in the case of PW or VPLS)
    2. Not BoS<= a> and the next label is GAL - stop parsing and pass to the "= ;VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
    3. Not BoS and the n= ext label is not GAL - treat the next label as the "flow label", i= .e. pass to the corresponding application (may include CW in the= case of PW or VPLS).

    In the case of MS-PWs, only T-PEs would tr= eat the PW labels as "application labels", S-PEs would treat them= as non-application labels. This is fully consistent with RFC 6073 which exp= lains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined wi= th VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

     

    In other words, there is no need for ELI w= ith the flow label.

     

    Did I miss something?

     

    My 2c,

    Sasha

     

    From: Pablo Frank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 6:22 PM
    To: Alexander Vainshtein
    Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels += GAL

    Thanks Sasha.  I completely concur with your points 1 and 2.

    As for point #3, that seems like the logical conclusion.  However,= I think there's still a bit of awkwardness around implementing this.  = Both the original entropy-label draft and RFC 6391 have assumed a simple pop= -pop logic when you encounter an entropy-enabled AL or a flow-enabled PW.  The moment GAL, or any other reserved label= gets thrown into the mix, the label disposition logic gets suddenly more co= mplex.  Instead of pop-pop, the hardware will have to do more complicat= ed logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". &nb= sp;While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

    It sounds like the authors of the entropy label draft have recognized t= his problem and are now moving towards mandating the use of a reserved ELI w= hich unambiguously implies that the next label is entropy (so the hardware c= an go back to having simple pop-pop logic when it sees a reserved ELI).

    Which brings me back to VCCV.  If I'm doing type-1,2,3 VCCV, the s= ituation is unambiguous.  If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop.  If for type-4 VCCV, we assume that= the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and= dispose of the GAL and flow label correctly.  A reserved ELI could hel= p disambiguate the situation in this case but this makes running type-4 VCCV= with flow labels unattractive compared to type-1 VCCV.

    regards,
    Pablo

    On Thu, Feb 16, 2012 at 1:22 AM, Alexander V= ainshtein <Al= exander.Vainshtein@ecitele.com> wrote:
    Pablo, John and all,
    A couple of comments:
     
    1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
    2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
    3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

    Regards,

         Sasha

     

     
     
     
     
     
     
     
    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo F= rank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 12:24 AM
    To: John E Drake
    Cc: mpls@ietf.org;= pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels += GAL

    Ah, good.  That certainly makes things more deterministic.  

    I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to= mandate the use of ELIs when flow labels are present?  That seems too= bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right b= ack in so it may be more attractive to run fat PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:

    Pablo,

     

    Based upon Kireeti=92s up= date in Taipei, we seem to going towards using a reserved label for ELI and= making it always required.

     

    Thanks,

     

    John  

     

    From: mpl= s-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org<= br> Subject: [mpls] Question about Entropy labels + GAL=

     

    I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

     

    ... | LSP label x | Entropy label | IPv4 payload | ..= .

     

    Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 pa= yload.  So far, so good.  

     

    However, I believe the following is legal as well:=

     

    ... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

     

    Alternatively, an equally vexing scenario is:<= u>

     

    ... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

     

    There are probably other reserved labels that are app= licable as well.

     

    In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (= thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous b= ehaviour).   The only additional guidance that the draft= gives is in section 6 where it suggests that GAL could be treated as an app= lication label.  But that doesn't seem helpful since the LSP label must also be an application label (to ha= ndle the non-GAL case) and will always be encountered first during label dis= position.  Also, presumably I don't want all GALs to expect entropy so= there's an implied scoping of GAL.

     

    It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essenti= ally must do a "deferred pop of BOS label".  In other words,= if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unti= l it hits the BOS label, which it must pop.  While certainly possible,= this is a lot more convoluted and difficult to implement than what is speci= fied in the draft.  Is this really the desired behaviour?

     

    The same question applies to type-4 VCCV with flow la= bels.

     

    regards,

    Pablo

     


    This e-mail message is intended for the recipient only and contains infor= mation 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, p= hone or fax, and then delete the original and all copies thereof.


    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_A3C5DF08D38B6049839A6F553B331C76011659266625ILPTMAIL02e_-- From pabloisnot@gmail.com Fri Feb 17 08:39:42 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89A621F8847; Fri, 17 Feb 2012 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.265, 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 GZyR0c0KiZTa; Fri, 17 Feb 2012 08:39:40 -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 98BC021F87A3; Fri, 17 Feb 2012 08:39:40 -0800 (PST) Received: by ggnq2 with SMTP id q2so2167712ggn.31 for ; Fri, 17 Feb 2012 08:39:40 -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=vhX/MZZvvSciaqLgikLP71a1wF1ssj8yzCvzcLA4FIU=; b=Ut5MuFYJyXa2nILk3zlSczHGS4CGa6bd5zDx5bW4dpeYMo0Ua3lZoWJt+oNDxO+o+3 lETQ27b1rVhNIT07l0q8HHEszzeSrjFJMCaQ1RJ/KhuH5twJVXXup1IEUW8qT6a2mmF/ 9ajLOvUN0a7b/SGyWOCVntWH6pGPIBWpilBX4= MIME-Version: 1.0 Received: by 10.60.13.129 with SMTP id h1mr2683282oec.62.1329496780159; Fri, 17 Feb 2012 08:39:40 -0800 (PST) Received: by 10.182.42.137 with HTTP; Fri, 17 Feb 2012 08:39:40 -0800 (PST) In-Reply-To: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> Date: Fri, 17 Feb 2012 11:39:40 -0500 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8f8397674fbb2004b92b97ed Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:39:42 -0000 --e89a8f8397674fbb2004b92b97ed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha, Even the relatively simple set of rules that you've defined below glosses over a some added complexity in trying to do a hardware implementation. I think we can at least agree that this is not nearly as simple as using reserved ELI (which a dumb parser can dispose of without needing to even look anything up). I guess I'm just nervous about the lookup context of a label affecting the disposition of a label that is not necessarily next in the stack. To me this feels like a slippery slope. What if, in the future, we come up with more "stuff" that goes between the AL and the EL? The permutations quickly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 VCCV should probably explicitly address how they expect it to interact with flow labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Pablo, > Lots of thanks for a prompt response. > > I think that the situation with GAL between the PW (application label) an= d > flow label is much simpler than what you have described. This logic is > based on the fact "application labels" can be easily recognized as such b= y > the LSR that examines them during label stack parsing. > > When an application label is encountered, there are just three cases: > > 1. It is BoS - nothing new, pass to the corresponding application (PW > forwarder, VRF etc.) for handling. The data for this application > directly follows the label stack (may include CW in the case of PW or = VPLS) > 2. Not BoS and the next label is GAL - stop parsing and pass to the > "VCCV-4" handler, The data for the "VCCV-4 handler" application direct= ly > follows the label stack and starts with the ACH header. > 3. Not BoS and the next label is not GAL - treat the next label as the > "flow label", i.e. pass to the corresponding application (may include > CW in the case of PW or VPLS). > > In the case of MS-PWs, only T-PEs would treat the PW labels as > "application labels", S-PEs would treat them as non-application labels. > This is fully consistent with RFC 6073 which explains that if you want an > S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) > possibly combined with VCCV Type 1 (if the PWE has been using a CW) or VC= CV > Type 4. > > > > In other words, there is no need for ELI with the flow label. > > > > Did I miss something? > > > > My 2c, > > Sasha > > > ------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Thursday, February 16, 2012 6:22 PM > *To:* Alexander Vainshtein > *Cc:* John E Drake; mpls@ietf.org; pwe3@ietf.org > > *Subject:* Re: [mpls] Question about Entropy labels + GAL > > Thanks Sasha. I completely concur with your points 1 and 2. > > As for point #3, that seems like the logical conclusion. However, I > think there's still a bit of awkwardness around implementing this. Both > the original entropy-label draft and RFC 6391 have assumed a simple pop-p= op > logic when you encounter an entropy-enabled AL or a flow-enabled PW. The > moment GAL, or any other reserved label gets thrown into the mix, the lab= el > disposition logic gets suddenly more complex. Instead of pop-pop, the > hardware will have to do more complicated logic like "IF this is a > flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., > etc.". While I have very programmable hardware at my disposal, I prefer > elegant and simple and this feels wrong. > > It sounds like the authors of the entropy label draft have recognized > this problem and are now moving towards mandating the use of a reserved E= LI > which unambiguously implies that the next label is entropy (so the hardwa= re > can go back to having simple pop-pop logic when it sees a reserved ELI). > > Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the > situation is unambiguous. If I encounter any of these types of PWEs with > flow-enabled, I can do a pop-pop. If for type-4 VCCV, we assume that the > GAL is between the PW label and flow label (which I think was the intent)= , > we're back to having ugly logic to try and dispose of the GAL and flow > label correctly. A reserved ELI could help disambiguate the situation in > this case but this makes running type-4 VCCV with flow labels unattractiv= e > compared to type-1 VCCV. > > regards, > Pablo > > On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > >> Pablo, John and all, >> A couple of comments: >> >> >> 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 >> has relaxed the original requirement for GAL being at the bottom of >> stack that have been defined in RFC 5586. >> 2. My reading of RFC 6391 is that it mandates the flow label to be at >> the bottom of the label stack for PW packets carrying user data. And >> it does not provide for ELI usage anywhere, be it a reserved label or= a >> signaled one. >> 3. To the best of my understanding, the situation when GAL is used >> for fat PWs is not explicitly defined. Inserting GAL between the PW l= abel >> and flow label (with the ACH header immediately following the label s= tack) >> seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe t= his >> format should be explicitly defined as the correct one? >> >> Regards, >> >> Sasha >> >> >> >> >> >> >> >> >> >> ------------------------------ >> *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo >> Frank [pabloisnot@gmail.com] >> *Sent:* Thursday, February 16, 2012 12:24 AM >> *To:* John E Drake >> *Cc:* mpls@ietf.org; pwe3@ietf.org >> *Subject:* Re: [mpls] Question about Entropy labels + GAL >> >> Ah, good. That certainly makes things more deterministic. >> >> I guess the question now becomes how will this affect type-4 VCCV on >> fat pseudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of >> ELIs when flow labels are present? That seems too bad since the main >> advantage of type-4 VCCV seems to be to save a few bytes on the wire. T= his >> puts the overhead right back in so it may be more attractive to run fat >> PWEs with type-1 VCCV... >> >> Pablo >> >> On Wed, Feb 15, 2012 at 4:26 PM, John E Drake wrote= : >> >>> Pablo,**** >>> >>> **** >>> >>> Based upon Kireeti=92s update in Taipei, we seem to going towards using= a >>> reserved label for ELI and making it always required.**** >>> >>> **** >>> >>> Thanks,**** >>> >>> **** >>> >>> John **** >>> >>> **** >>> >>> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf >>> Of *Pablo Frank >>> *Sent:* Wednesday, February 15, 2012 7:30 AM >>> *To:* mpls@ietf.org >>> *Subject:* [mpls] Question about Entropy labels + GAL**** >>> >>> **** >>> >>> I'm working on implementation for entropy labels and I have a question >>> about draft-ietf-mpls-entropy-label-01. Consider a scenario where I ha= ve >>> received the following:**** >>> >>> **** >>> >>> ... | LSP label x | Entropy label | IPv4 payload | ...**** >>> >>> **** >>> >>> Assume that I've signaled that the LSP label wants entropy and an ELI i= s >>> unnecessary. Following the procedures detailed in 4.3, the datapathwou= ld lookup label x and see that it is expecting a possible entropy label >>> and since x is not BOS, it pops the next label and then begins processi= ng >>> the IPv4 payload. So far, so good. **** >>> >>> **** >>> >>> However, I believe the following is legal as well:**** >>> >>> **** >>> >>> ... | LSP label x | GAL label | Entropy label | BFD payload | ...**** >>> >>> **** >>> >>> Alternatively, an equally vexing scenario is:**** >>> >>> **** >>> >>> ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | >>> ...**** >>> >>> **** >>> >>> There are probably other reserved labels that are applicable as well.**= * >>> * >>> >>> **** >>> >>> In either case, the draft doesn't clearly state what's supposed to >>> happen. If I follow the procedures in 4.3, the datapath would end up >>> popping the GAL or the explicit NULL label (thinking they are entropy >>> labels) and would then attempt to lookup the entropy label (which would >>> result in erroneous behaviour). The only additional guidance that the >>> draft gives is in section 6 where it suggests that GAL could be treated= as >>> an application label. But that doesn't seem helpful since the LSP labe= l >>> must *also *be an application label (to handle the non-GAL case) and >>> will always be encountered first during label disposition. Also, >>> presumably I don't want all GALs to expect entropy so there's an implie= d >>> scoping of GAL.**** >>> >>> **** >>> >>> It seems to me that when a datapath encounters an entropy-enabled >>> application label or an ELI, that it essentially must do a "deferred po= p of >>> BOS label". In other words, if the datapath encounters an >>> entropy-enabled AL or an ELI, it must make a note of it and continue >>> processing labels until it hits the BOS label, which it must pop. Whil= e >>> certainly possible, this is a lot more convoluted and difficult to >>> implement than what is specified in the draft. Is this really the desi= red >>> behaviour?**** >>> >>> **** >>> >>> The same question applies to type-4 VCCV with flow labels.**** >>> >>> **** >>> >>> regards,**** >>> >>> Pablo**** >>> >>> **** >>> >> >> 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. >> > > 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 u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --e89a8f8397674fbb2004b92b97ed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha,

    Even the relatively simple set of rules that y= ou've defined below glosses over a some added complexity in trying to d= o a hardware implementation. =A0I think we can at least agree that this is = not nearly as simple as using reserved ELI (which a dumb parser can dispose= of without needing to even look anything up). =A0I guess I'm just nerv= ous about the lookup context of a label affecting the disposition of a labe= l that is not necessarily next in the stack. =A0To me this feels like a sli= ppery slope. =A0What if, in the future, we come up with more "stuff&qu= ot; that goes between the AL and the EL? =A0The permutations quickly multip= ly and this will ultimately impact the cost of hardware.

    Just something to keep in mind as we go forward.
    <= div>
    In any case, I think there's enough uncertainty that= the authors of type-4 VCCV should probably explicitly address how they exp= ect it to interact with flow labels.

    Pablo

    On Thu, Feb 16,= 2012 at 1:19 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt; wrote:
    Pablo,
    Lots of thanks for a prompt response.
    =A0
    I think that the situation with GAL bet= ween the PW (application label) and flow label is much simpler than what yo= u have described. This logic is based on the fact "application labels&= quot; can be easily recognized as such by the LSR that examines them during label stack parsing.
    =A0
    When an application label is encountere= d, there are just three cases:
    1. It is=A0BoS - nothing new,= pass to the=A0corresponding application (PW forwarder, VRF e= tc.) for handling. The data for this application directly follows th= e label stack (may include CW in=A0the case of PW or VPLS)
    2. Not=A0BoS= and the next label is GAL - stop parsing and pass to the "= VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
    3. Not=A0BoS and the nex= t label is not GAL - treat the next label as the "flow label", i.= e. pass to the=A0corresponding application (may include CW in the ca= se of PW or VPLS).

    In the case of MS-PWs, only T-PEs would t= reat the PW labels as "application labels", S-PEs would treat the= m as non-application labels. This is fully consistent with RFC 6073 which e= xplains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined w= ith VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

    =A0

    In other words, there is no need for ELI = with the flow label.

    =A0

    Did I miss something?

    =A0

    My 2c,

    Sasha

    =A0

    Fro= m: Pablo Frank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 6:22 PM
    To: Alexander Vainshtein
    Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org

    Subject: Re: [mpls] Question about Entropy labels + GA= L

    Thanks Sasha. =A0I completely concur with your points 1 and 2.

    As for point #3, that seems like the logical conclusion. =A0However, I= think there's still a bit of awkwardness around implementing this. =A0= Both the original entropy-label draft and RFC 6391 have assumed a simple po= p-pop logic when you encounter an entropy-enabled AL or a flow-enabled PW. =A0The moment GAL, or any other reserved label ge= ts thrown into the mix, the label disposition logic gets suddenly more comp= lex. =A0Instead of pop-pop, the hardware will have to do more complicated l= ogic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". = =A0While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

    It sounds like the authors of the entropy label draft have recognized = this problem and are now moving towards mandating the use of a reserved ELI= which unambiguously implies that the next label is entropy (so the hardwar= e can go back to having simple pop-pop logic when it sees a reserved ELI).

    Which brings me back to VCCV. =A0If I'm doing type-1,2,3 VCCV, the= situation is unambiguous. =A0If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop. =A0If for type-4 VCCV, we assume that t= he GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try= and dispose of the GAL and flow label correctly. =A0A reserved ELI could h= elp disambiguate the situation in this case but this makes running type-4 V= CCV with flow labels unattractive compared to type-1 VCCV.

    regards,
    Pablo

    On Thu, Feb 16, 2012 at 1:22 AM, Alexander=A0Vai= nshtein <Alexander.Vainshtein@ecitele.com> wrote:
    Pablo, John and all,
    A couple of comments:
    =A0
    1. Following a=A0long discussion on the PWE3 WG mailing list RFC 6423 has = relaxed the original=A0requirement for GAL being at the bottom of st= ack that have been defined in RFC 5586.
    2. My reading of=A0RFC 6391 is that it mandates the flow label to be = at the bottom of the label stack for PW packets=A0carrying user data= . And it does not provide for ELI usage anywhere, be it a reserved label or= a signaled one.
    3. To the best of my understanding, the situation when GAL is used fo= r fat PWs is not explicitly defined.=A0Inserting GAL between the PW label a= nd flow label (with the ACH header immediately following the label stack) s= eems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the c= orrect one?

    Regards,

    =A0=A0=A0=A0 Sasha

    =A0

    =A0
    =A0
    =A0
    =A0
    =A0
    =A0
    From:=A0mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo Frank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 12:24 AM
    To: John E Drake
    Cc: mpls@ietf.org= ; pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels + GA= L

    Ah, good. =A0That certainly makes things more deterministic. =A0

    I guess the question now becomes how will this affect type-4 VCCV on f= at=A0pseudowires (RFC 6391)? =A0Will type-4 VCCV have to mand= ate the use of ELIs when flow labels are present? =A0That seems too bad sin= ce the main advantage of type-4 VCCV seems to be to save a few bytes on the wire. =A0This puts the overhead right bac= k in so it may be more attractive to run fat PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.= net> wrote:

    Pablo,

    =A0

    Based upon=A0Kireeti=92s= update in Taipei, we seem to going towards using a reserved label f= or ELI and making it always required.

    =A0

    Thanks,

    =A0

    John =A0

    =A0

    From:=A0mpls-bounces@ietf.org [mailto:mp= ls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org=
    Subject: [mpls] Question about Entropy labels + GAL=

    =A0

    I'm working on implementation for entropy labels= and I have a question about=A0draft-ietf-mpls-entropy-label-01. =A0Conside= r a scenario where I have received the following:

    =A0

    ... | LSP label x | Entropy label | IPv4 payload | .= ..

    =A0

    Assume that I've signaled that the LSP label wan= ts entropy and an ELI is unnecessary. =A0Following the procedures detailed = in 4.3, the=A0datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 p= ayload. =A0So far, so good. =A0

    =A0

    However, I believe the following is legal as well:

    =A0

    ... | LSP label x | GAL label | Entropy label | BFD = payload | ...

    =A0

    Alternatively, an equally vexing scenario is:=

    =A0

    ... | LSP label x | IPv4 explicit NULL | Entropy lab= el | IPv4 payload | ...

    =A0

    There are probably other reserved labels that are ap= plicable as well.

    =A0

    In either case, the draft doesn't clearly state = what's supposed to happen. =A0If I follow the procedures in 4.3, the=A0= datapath would end up popping the GAL or the explicit NULL la= bel (thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous = behaviour). =A0 The only additional guidance that the draft g= ives is in section 6 where it suggests that GAL could be treated as an appl= ication label. =A0But that doesn't seem helpful since the LSP label must also be an application label (to h= andle the non-GAL case) and will always be encountered first during label d= isposition. =A0Also, presumably I don't want all GALs to expect entropy= so there's an implied scoping of GAL.

    =A0

    It seems to me that when a=A0datapath = encounters an entropy-enabled application label or an ELI, that it essentia= lly must do a "deferred pop of BOS label". =A0In other words, if = the=A0datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unt= il it hits the BOS label, which it must pop. =A0While certainly possible, t= his is a lot more convoluted and difficult to implement than what is specif= ied in the draft. =A0Is this really the desired behaviour?

    =A0

    The same question applies to type-4 VCCV with flow l= abels.

    =A0

    regards,

    Pablo

    =A0


    This e-mail message is intended for the recipient only and contains info= rmation 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.


    This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof.


    --e89a8f8397674fbb2004b92b97ed-- From jdrake@juniper.net Fri Feb 17 09:17:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537721F856C; Fri, 17 Feb 2012 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.672 X-Spam-Level: X-Spam-Status: No, score=-4.672 tagged_above=-999 required=5 tests=[AWL=1.926, 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 SA396db830aA; Fri, 17 Feb 2012 09:17:34 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7821F8565; Fri, 17 Feb 2012 09:17:33 -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 DSNKTz6LqsrhBxKR4PLnnoFb3+Xx6II7KNJj@postini.com; Fri, 17 Feb 2012 09:17:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Feb 2012 09:14:44 -0800 From: John E Drake To: Pablo Frank , Alexander Vainshtein Date: Fri, 17 Feb 2012 09:14:40 -0800 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: Acztkr/ZfcakB5fsRVC53QNq6RQsEQABBVdg Message-ID: <5E893DB832F57341992548CDBB333163A55C914900@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f8e27f27-03b2-4c3e-9447-119194e72cb6 Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:17:40 -0000 --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pablo, These are some of the same conclusions to which the EL authors came. The d= eployment environment for FAT labels, pt-2-pt, is more constrained than the= deployment environment for ELs, any- 2-any, so presumably some of these ca= ses could be handled in signaling, such that both endpoints know what to ex= pect before packets start to flow. However, it might be nice to use a rese= rved ELI for FAT labels in order to have a consistent data plane for both. Thanks, John From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, February 17, 2012 8:40 AM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Hi Sasha, Even the relatively simple set of rules that you've defined below glosses o= ver a some added complexity in trying to do a hardware implementation. I t= hink we can at least agree that this is not nearly as simple as using reser= ved ELI (which a dumb parser can dispose of without needing to even look an= ything up). I guess I'm just nervous about the lookup context of a label a= ffecting the disposition of a label that is not necessarily next in the sta= ck. To me this feels like a slippery slope. What if, in the future, we co= me up with more "stuff" that goes between the AL and the EL? The permutati= ons quickly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 = VCCV should probably explicitly address how they expect it to interact with= flow labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein > wrote: Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and = flow label is much simpler than what you have described. This logic is base= d on the fact "application labels" can be easily recognized as such by the = LSR that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW for= warder, VRF etc.) for handling. The data for this application directly foll= ows the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV= -4" handler, The data for the "VCCV-4 handler" application directly follows= the label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "f= low label", i.e. pass to the corresponding application (may include CW in t= he case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully c= onsistent with RFC 6073 which explains that if you want an S-PE to handle a= VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined w= ith VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think = there's still a bit of awkwardness around implementing this. Both the orig= inal entropy-label draft and RFC 6391 have assumed a simple pop-pop logic w= hen you encounter an entropy-enabled AL or a flow-enabled PW. The moment G= AL, or any other reserved label gets thrown into the mix, the label disposi= tion logic gets suddenly more complex. Instead of pop-pop, the hardware wi= ll have to do more complicated logic like "IF this is a flow-enabled label = AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have = very programmable hardware at my disposal, I prefer elegant and simple and = this feels wrong. It sounds like the authors of the entropy label draft have recognized this = problem and are now moving towards mandating the use of a reserved ELI whic= h unambiguously implies that the next label is entropy (so the hardware can= go back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation = is unambiguous. If I encounter any of these types of PWEs with flow-enable= d, I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is betwe= en the PW label and flow label (which I think was the intent), we're back t= o having ugly logic to try and dispose of the GAL and flow label correctly.= A reserved ELI could help disambiguate the situation in this case but thi= s makes running type-4 VCCV with flow labels unattractive compared to type-= 1 VCCV. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has r= elaxed the original requirement for GAL being at the bottom of stack that h= ave been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does n= ot provide for ELI usage anywhere, be it a reserved label or a signaled one= . 3. To the best of my understanding, the situation when GAL is used for fa= t PWs is not explicitly defined. Inserting GAL between the PW label and flo= w label (with the ACH header immediately following the label stack) seems t= o be fully compatible with both RFC 6423 and RFC 6391. Maybe this format sh= ould be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of Pablo Frank [pabloisnot@g= mail.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat ps= eudowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs whe= n flow labels are present? That seems too bad since the main advantage of = type-4 VCCV seems to be to save a few bytes on the wire. This puts the ove= rhead right back in so it may be more attractive to run fat PWEs with type-= 1 VCCV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti's update in Taipei, we seem to going towards using a res= erved label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question abou= t draft-ietf-mpls-entropy-label-01. Consider a scenario where I have recei= ved the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is un= necessary. Following the procedures detailed in 4.3, the datapath would lo= okup label x and see that it is expecting a possible entropy label and sinc= e x is not BOS, it pops the next label and then begins processing the IPv4 = payload. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the G= AL or the explicit NULL label (thinking they are entropy labels) and would = then attempt to lookup the entropy label (which would result in erroneous b= ehaviour). The only additional guidance that the draft gives is in sectio= n 6 where it suggests that GAL could be treated as an application label. B= ut that doesn't seem helpful since the LSP label must also be an applicatio= n label (to handle the non-GAL case) and will always be encountered first d= uring label disposition. Also, presumably I don't want all GALs to expect = entropy so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicati= on label or an ELI, that it essentially must do a "deferred pop of BOS labe= l". In other words, if the datapath encounters an entropy-enabled AL or an= ELI, it must make a note of it and continue processing labels until it hit= s the BOS label, which it must pop. While certainly possible, this is a lo= t more convoluted and difficult to implement than what is specified in the = draft. Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Pablo,

     

    =

    These are some of the same conclusions to which= the EL authors came.  The deployment environment for FAT labels, pt-2= -pt, is more constrained than the deployment environment for ELs, any- 2-an= y, so presumably some of these cases could be handled in signaling, such th= at both endpoints know what to expect before packets start to flow.  H= owever, it might be nice to use a reserved ELI for FAT labels in order to h= ave a consistent data plane for both.

     

    Thanks,=

     <= /p>

    John

     

    From: Pablo Frank [mailto:pabloisnot@gmail.com]
    Sent: Friday= , February 17, 2012 8:40 AM
    To: Alexander Vainshtein
    Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
    Subject: Re: [mpls] = Question about Entropy labels + GAL

     

    Hi Sasha,

     

    Even the relatively simple set of rules that you've defined below= glosses over a some added complexity in trying to do a hardware implementa= tion.  I think we can at least agree that this is not nearly as simple= as using reserved ELI (which a dumb parser can dispose of without needing = to even look anything up).  I guess I'm just nervous about the lookup = context of a label affecting the disposition of a label that is not necessa= rily next in the stack.  To me this feels like a slippery slope.  = ;What if, in the future, we come up with more "stuff" that goes b= etween the AL and the EL?  The permutations quickly multiply and this = will ultimately impact the cost of hardware.

     

    Just s= omething to keep in mind as we go forward.

     

    In any c= ase, I think there's enough uncertainty that the authors of type-4 VCCV sho= uld probably explicitly address how they expect it to interact with flow la= bels.

     

    Pablo

    On Thu, Feb 16, 2012 at 1:19 PM, Alexander = Vainshtein <Alexande= r.Vainshtein@ecitele.com> wrote:

    Pablo,

    Lots of= thanks for a prompt response.

     

    I think that the sit= uation with GAL between the PW (application label) and flow label is much s= impler than what you have described. This logic is based on the fact "= application labels" can be easily recognized as such by the LSR that e= xamines them during label stack parsing.

     

    When an a= pplication label is encountered, there are just three cases:

    =
    1. It is BoS= - nothing new, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows the l= abel stack (may include CW in the case of PW or VPLS)
      2. =
    2. Not BoS and the next label is GAL - st= op parsing and pass to the "VCCV-4" handler, The data for the &qu= ot;VCCV-4 handler" application directly follows the label stack and st= arts with the ACH header.
    3. N= ot BoS and the next label is not GAL - treat the next label as the &qu= ot;flow label", i.e. pass to the corresponding application (may i= nclude CW in the case of PW or VPLS).

    In the case of= MS-PWs, only T-PEs would treat the PW labels as "application labels&q= uot;, S-PEs would treat them as non-application labels. This is fully consi= stent with RFC 6073 which explains that if you want an S-PE to handle a VCC= V packet, you must use VCCV Type 3 (TTL expiration) possibly combined with = VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

    =

     

    In other words, there is no need for ELI with th= e flow label.

     

    Did I miss something= ?

     

    My 2c,

    Sasha

     

    =

    From: Pablo Frank [pabloisnot@gmail.com]
    Sent: Thurs= day, February 16, 2012 6:22 PM
    To: Alexander Vainshtein
    Cc:= John E Drake; mpls@= ietf.org; pwe3@ietf.= org


    Subject: Re: [mpl= s] Question about Entropy labels + GAL

     

    Thanks Sasha.  I completely concur with your points 1 and 2.

     

    As for point #3, that seems like the logical conclusion. &n= bsp;However, I think there's still a bit of awkwardness around implementing= this.  Both the original entropy-label draft and RFC 6391 have assume= d a simple pop-pop logic when you encounter an entropy-enabled AL or a flow= -enabled PW.  The moment GAL, or any other reserved label gets thrown = into the mix, the label disposition logic gets suddenly more complex.  = ;Instead of pop-pop, the hardware will have to do more complicated logic li= ke "IF this is a flow-enabled label AND the next label is ! GAL THEN p= op-pop ELSE IF ..., etc.".  While I have very programmable hardwa= re at my disposal, I prefer elegant and simple and this feels wrong.

     

    It sounds like the authors of the entropy label draft hav= e recognized this problem and are now moving towards mandating the use of a= reserved ELI which unambiguously implies that the next label is entropy (s= o the hardware can go back to having simple pop-pop logic when it sees a re= served ELI).

     

    Which brings me back to VCCV.  If= I'm doing type-1,2,3 VCCV, the situation is unambiguous.  If I encoun= ter any of these types of PWEs with flow-enabled, I can do a pop-pop.  = ;If for type-4 VCCV, we assume that the GAL is between the PW label and flo= w label (which I think was the intent), we're back to having ugly logic to = try and dispose of the GAL and flow label correctly.  A reserved ELI c= ould help disambiguate the situation in this case but this makes running ty= pe-4 VCCV with flow labels unattractive compared to type-1 VCCV.=

     

    regards,

    Pablo<= o:p>

     

    On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtei= n <Alexander.Vainshtein@ecitele.com> wrote:

    Pablo, John and all,

    A couple of comments:

     

    1. Following a long discussion on the PWE3 WG mailing lis= t RFC 6423 has relaxed the original requirement for GAL being at the b= ottom of stack that have been defined in RFC 5586.
    2. My reading of RFC 6391 is that it mandates the= flow label to be at the bottom of the label stack for PW packets carr= ying user data. And it does not provide for ELI usage anywhere, be it a res= erved label or a signaled one.
    3. To the best of my understanding, the situation when GAL is used for fa= t PWs is not explicitly defined. Inserting GAL between the PW label an= d flow label (with the ACH header immediately following the label stack) se= ems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this form= at should be explicitly defined as the correct one?

    = Regards,

         Sasha

    &= nbsp;

     

     

     

     

     

     

     

    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of P= ablo Frank [pablo= isnot@gmail.com]
    Sent: Thursday, February 16, 2012 12:24 AMTo: John E Drake
    Cc: mpls@ietf.org; pwe3@ietf.org
    Subject: Re: [mpls] Question about = Entropy labels + GAL

    Ah, good.  That certainly makes things more deterministic. &n= bsp;

     

    I guess the question now becomes how will this affe= ct type-4 VCCV on fat pseudowires (RFC 6391)?  Will type-4 VCCV h= ave to mandate the use of ELIs when flow labels are present?  That see= ms too bad since the main advantage of type-4 VCCV seems to be to save a fe= w bytes on the wire.  This puts the overhead right back in so it may b= e more attractive to run fat PWEs with type-1 VCCV...

    <= div>

     

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:<= /o:p>

    Pablo,

     <= o:p>

    Based upon Kireeti’s update in Taipe= i, we seem to going towards using a reserved label for ELI and making it al= ways required.

     

    Thanks,

     

    J= ohn  

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pabl= o Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: = mpls@ietf.org
    = Subject: [mpls] Question about Entropy labels + GAL

     

    I'm working on i= mplementation for entropy labels and I have a question about draft-iet= f-mpls-entropy-label-01.  Consider a scenario where I have received th= e following:

     

    ... | LSP label x | Entropy label | IPv4 payload | ...

     

    Assume that I've si= gnaled that the LSP label wants entropy and an ELI is unnecessary.  Fo= llowing the procedures detailed in 4.3, the datapath would lookup labe= l x and see that it is expecting a possible entropy label and since x is no= t BOS, it pops the next label and then begins processing the IPv4 payload. =  So far, so good.  

     

    However, I believe the following is legal as well= :

     

    .= .. | LSP label x | GAL label | Entropy label | BFD payload | ...=

     

    Alternatively,= an equally vexing scenario is:

     =

    ... | LSP label x | IPv4 explicit NULL | E= ntropy label | IPv4 payload | ...

     

    There are probably other reserved labels that= are applicable as well.

     <= /p>

    In either case, the draft doesn't clearly state what's= supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (thinking they= are entropy labels) and would then attempt to lookup the entropy label (wh= ich would result in erroneous behaviour).   The only additional guidan= ce that the draft gives is in section 6 where it suggests that GAL could be= treated as an application label.  But that doesn't seem helpful since= the LSP label must also be an application label (to handle the non-= GAL case) and will always be encountered first during label disposition. &n= bsp;Also, presumably I don't want all GALs to expect entropy so there's an = implied scoping of GAL.

     

    It seems to me that when a datapath encounte= rs an entropy-enabled application label or an ELI, that it essentially must= do a "deferred pop of BOS label".  In other words, if the&n= bsp;datapath encounters an entropy-enabled AL or an ELI, it must make a not= e of it and continue processing labels until it hits the BOS label, which i= t must pop.  While certainly possible, this is a lot more convoluted a= nd difficult to implement than what is specified in the draft.  Is thi= s really the desired behaviour?

     =

    The same question applies to type-4 VCCV with f= low labels.

     

    regards,

    Pablo

    =

     

    =

     

    = This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof.

     

    This e-mail message is intended for the recipie= nt only and contains information which is CONFIDENTIAL and which may be pro= prietary to ECI Telecom. If you have received this transmission in error, p= lease inform us by e-mail, phone or fax, and then delete the original and a= ll copies thereof.

     

    = --_000_5E893DB832F57341992548CDBB333163A55C914900EMBX01HQjnprn_-- From Alexander.Vainshtein@ecitele.com Fri Feb 17 22:24:32 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7CF21F85B4 for ; Fri, 17 Feb 2012 22:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[AWL=0.634, 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 blVGAYitpeHX for ; Fri, 17 Feb 2012 22:24:30 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 8F0C621F86B5 for ; Fri, 17 Feb 2012 22:24:28 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1329546193!63364284!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 31716 invoked from network); 18 Feb 2012 06:23:14 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-27.messagelabs.com with SMTP; 18 Feb 2012 06:23:14 -0000 X-AuditID: 93eaf2e7-b7f7e6d000000e6e-d2-4f3f4fd82830 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 72.B7.03694.8DF4F3F4; Sat, 18 Feb 2012 09:14:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 18 Feb 2012 08:24:25 +0200 From: Alexander Vainshtein To: Pablo Frank Date: Sat, 18 Feb 2012 08:22:37 +0200 Thread-Topic: [mpls] Question about Entropy labels + GAL Thread-Index: AcztkoEAOL8ckp+uTiiyc1IWsA6d5gAcCfB4 Message-ID: References: <5E893DB832F57341992548CDBB333163A55C7056F0@EMBX01-HQ.jnpr.net> , 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_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTuzoy74+bEtGrettcylUSxtauWG7UaSWQPWCMxCMrG3dvu4O7s tjOJG1ESQWVkLZXmUllgL3tsipVF5Wo/ej+gonwVlg+yJ2pYBtlMYyZE99d3z/ed8517OYfE tYfUOpLjReTjWRej0hD7u7p7DS+tqVZjzxWd+XBLmrnxxJkIc8n72ypzUXc1sYBIvxpsUaeX l3/H0l9se67OwFcXgPksz3tEVkR6OxJsFibDx+WxNj+j5+wWxsTovS7WhtyIFy0M6/Ui3s6k aPT/nPmSjOP1iLd57BzvsDBLVloNZvPsuQYTkxI/2ZQ4T5Pp5AQ9MrhZzqV3I0FgHUgvRdZV 485wyWJvxw4s/2PgBlEAXjeBQhBJQjoJbu+vGsRj4JNXIVUh0JBauhbAD427I5RLMYAd7QFC VqloC6w626KScQwdDy8ESn9n4zQH2071YTIm6KnwdtEtdSEgyWg6GZ7cv1WRm+GxlkZcDsfQ CfBiyC+HKXoF/P7sOFCsvuLwQF2PWiYiJWJPxbXftkBqru/eOUyxioONbWWY0jQNy68/xhUc C9+9/Rmh6GNh847QYGseeDAUBorZaHi3tI1Q9GNh3emXxD4wJjisbHBYSnBYihI3ws+PynAF z4Anj78fxLNgZe9DMDx+DKgrQCzn8oo5bofRNBPZOBG50Eybx10FlFHqrAH9ZVPqAU0CJopy 9qdYtRFsnuB314OxJMbEUlULU63aUTkeu9/JCs5s30YXEuoBJHEmhlraLMkpO+vfhHyeP9Qi 6fMDuG6kzSMNLS9mJxqN/78wcVQFKxWhHdJo5iLkRb4/dcaTJAOpzWmS/WgfcqD89ZxL/Etj ZKTcRpTUxl5ZQwle1i1wDoW/Bwxk8ZfOJ0BL8B4e6eKoXFlEyyLnRn6ojrxQWwcGBrpAnPQB 0VSRrIqS1m2oUpdkgkkmlFZ+qyCt0BClKwBZ3+o+zckKByfabl1Z/gPTpLdNWp42bcS41LWB A4kvcovhpA1Lm0582NQQ3T0tyTw9v3Vzdnj79YSahEtHhNIH4QZTSdmWyszaO62Xl9FnOm/u TNmzbFzCt7zaJiZ0vzI04VFmsj/H0Dl+zfk3q+IzQlkFyVPVj3uqj16cU6N6Ku562M4QgpM1 Tcd9AvsLBclp2isEAAA= Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Question about Entropy labels + GAL X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 06:24:32 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Pablo hi, Lots of thanks for a prompt response. Regarding "added complexity in trying to do a hardware implementation": I th= ink whatever complexity is there has been added by GAL following the AL, not= by the flow label (with or without ELI). This has been my main point for ob= jecting to what has become RFC 6423. Prior to that, you could handle an AL= exactly as you would handle any other label according to RFC 3031 - look i= t up in the ILM and perform the corresponding action which would be "pop and= forward an unlabeled (because your AL has been always BoS) packet to a non-= MPLS forwarder defined by the AL". And yes, I know that some implementations= did it differently - but the naive processing I've defined before had worke= d OK for PWs, VPLS and IP VPN. And RFC 6391 did not really change that: you could still forward a (possibly labeled) packet to a suitable non-MPLS f= orwarder, and the only change you needed would be for this forwarder to ign= ore the remainder of the label stack whatever it happened to be if it receiv= ed a labeled packet. GAL following the AL has changed this simple logic. You really had to distin= guish between ALs and "regular" labels in your MPLS forwarder. This means th= at your ILM lookup must now return a "this is an AL" indication to the forwa= rding HW. I do not see how this can be avoided if you want to support RFC 64= 23 - please consider the difference between the T-PE and S-PE operation in M= S-PWs as an example. At the same time once you implement that, support of flow labels on top of s= upporting GAL becomes trivial because, since RFC 6391, reserved labels (incl= uding GAL) MUST NOT be used as flow labels. I.e., a dumb parser would know t= hat if it has found an AL that is not BoS, it should only check for the next= label for being a reserved one. Having an ELI at this point would only make= life more complicated, because you would then to distinguish specifically b= etween GAL, ELI and, possibly, other reserved labels... My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Friday, February 17, 2012 6:39 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Hi Sasha, Even the relatively simple set of rules that you've defined below glosses ov= er a some added complexity in trying to do a hardware implementation. I thi= nk we can at least agree that this is not nearly as simple as using reserved= ELI (which a dumb parser can dispose of without needing to even look anythi= ng up). I guess I'm just nervous about the lookup context of a label affect= ing the disposition of a label that is not necessarily next in the stack. T= o me this feels like a slippery slope. What if, in the future, we come up w= ith more "stuff" that goes between the AL and the EL? The permutations quic= kly multiply and this will ultimately impact the cost of hardware. Just something to keep in mind as we go forward. In any case, I think there's enough uncertainty that the authors of type-4 V= CCV should probably explicitly address how they expect it to interact with f= low labels. Pablo On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainshtein > wrote: Pablo, Lots of thanks for a prompt response. I think that the situation with GAL between the PW (application label) and f= low label is much simpler than what you have described. This logic is based= on the fact "application labels" can be easily recognized as such by the LS= R that examines them during label stack parsing. When an application label is encountered, there are just three cases: 1. It is BoS - nothing new, pass to the corresponding application (PW forw= arder, VRF etc.) for handling. The data for this application directly follow= s the label stack (may include CW in the case of PW or VPLS) 2. Not BoS and the next label is GAL - stop parsing and pass to the "VCCV-= 4" handler, The data for the "VCCV-4 handler" application directly follows t= he label stack and starts with the ACH header. 3. Not BoS and the next label is not GAL - treat the next label as the "fl= ow label", i.e. pass to the corresponding application (may include CW in the= case of PW or VPLS). In the case of MS-PWs, only T-PEs would treat the PW labels as "application= labels", S-PEs would treat them as non-application labels. This is fully co= nsistent with RFC 6073 which explains that if you want an S-PE to handle a V= CCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined with= VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4. In other words, there is no need for ELI with the flow label. Did I miss something? My 2c, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Thursday, February 16, 2012 6:22 PM To: Alexander Vainshtein Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Thanks Sasha. I completely concur with your points 1 and 2. As for point #3, that seems like the logical conclusion. However, I think t= here's still a bit of awkwardness around implementing this. Both the origin= al entropy-label draft and RFC 6391 have assumed a simple pop-pop logic when= you encounter an entropy-enabled AL or a flow-enabled PW. The moment GAL,= or any other reserved label gets thrown into the mix, the label disposition= logic gets suddenly more complex. Instead of pop-pop, the hardware will ha= ve to do more complicated logic like "IF this is a flow-enabled label AND th= e next label is ! GAL THEN pop-pop ELSE IF ..., etc.". While I have very pr= ogrammable hardware at my disposal, I prefer elegant and simple and this fee= ls wrong. It sounds like the authors of the entropy label draft have recognized this p= roblem and are now moving towards mandating the use of a reserved ELI which= unambiguously implies that the next label is entropy (so the hardware can g= o back to having simple pop-pop logic when it sees a reserved ELI). Which brings me back to VCCV. If I'm doing type-1,2,3 VCCV, the situation i= s unambiguous. If I encounter any of these types of PWEs with flow-enabled,= I can do a pop-pop. If for type-4 VCCV, we assume that the GAL is between= the PW label and flow label (which I think was the intent), we're back to h= aving ugly logic to try and dispose of the GAL and flow label correctly. A= reserved ELI could help disambiguate the situation in this case but this ma= kes running type-4 VCCV with flow labels unattractive compared to type-1 VCC= V. regards, Pablo On Thu, Feb 16, 2012 at 1:22 AM, Alexander Vainshtein > wrote: Pablo, John and all, A couple of comments: 1. Following a long discussion on the PWE3 WG mailing list RFC 6423 has re= laxed the original requirement for GAL being at the bottom of stack that hav= e been defined in RFC 5586. 2. My reading of RFC 6391 is that it mandates the flow label to be at the= bottom of the label stack for PW packets carrying user data. And it does no= t provide for ELI usage anywhere, be it a reserved label or a signaled one. 3. To the best of my understanding, the situation when GAL is used for fat= PWs is not explicitly defined. Inserting GAL between the PW label and flow= label (with the ACH header immediately following the label stack) seems to= be fully compatible with both RFC 6423 and RFC 6391. Maybe this format shou= ld be explicitly defined as the correct one? Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Pablo Frank [pabloisnot@gma= il.com] Sent: Thursday, February 16, 2012 12:24 AM To: John E Drake Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Question about Entropy labels + GAL Ah, good. That certainly makes things more deterministic. I guess the question now becomes how will this affect type-4 VCCV on fat pse= udowires (RFC 6391)? Will type-4 VCCV have to mandate the use of ELIs when= flow labels are present? That seems too bad since the main advantage of ty= pe-4 VCCV seems to be to save a few bytes on the wire. This puts the overhe= ad right back in so it may be more attractive to run fat PWEs with type-1 VC= CV... Pablo On Wed, Feb 15, 2012 at 4:26 PM, John E Drake > wrote: Pablo, Based upon Kireeti=92s update in Taipei, we seem to going towards using a re= served label for ELI and making it always required. Thanks, John From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, February 15, 2012 7:30 AM To: mpls@ietf.org Subject: [mpls] Question about Entropy labels + GAL I'm working on implementation for entropy labels and I have a question about= draft-ietf-mpls-entropy-label-01. Consider a scenario where I have receive= d the following: ... | LSP label x | Entropy label | IPv4 payload | ... Assume that I've signaled that the LSP label wants entropy and an ELI is unn= ecessary. Following the procedures detailed in 4.3, the datapath would look= up label x and see that it is expecting a possible entropy label and since x= is not BOS, it pops the next label and then begins processing the IPv4 payl= oad. So far, so good. However, I believe the following is legal as well: ... | LSP label x | GAL label | Entropy label | BFD payload | ... Alternatively, an equally vexing scenario is: ... | LSP label x | IPv4 explicit NULL | Entropy label | IPv4 payload | ... There are probably other reserved labels that are applicable as well. In either case, the draft doesn't clearly state what's supposed to happen. = If I follow the procedures in 4.3, the datapath would end up popping the GA= L or the explicit NULL label (thinking they are entropy labels) and would th= en attempt to lookup the entropy label (which would result in erroneous beha= viour). The only additional guidance that the draft gives is in section 6= where it suggests that GAL could be treated as an application label. But t= hat doesn't seem helpful since the LSP label must also be an application lab= el (to handle the non-GAL case) and will always be encountered first during= label disposition. Also, presumably I don't want all GALs to expect entrop= y so there's an implied scoping of GAL. It seems to me that when a datapath encounters an entropy-enabled applicatio= n label or an ELI, that it essentially must do a "deferred pop of BOS label"= . In other words, if the datapath encounters an entropy-enabled AL or an EL= I, it must make a note of it and continue processing labels until it hits th= e BOS label, which it must pop. While certainly possible, this is a lot mor= e convoluted and difficult to implement than what is specified in the draft.= Is this really the desired behaviour? The same question applies to type-4 VCCV with flow labels. regards, Pablo 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. 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. 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_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
    Pablo hi,
    Lots of thanks for a prompt response.
     
    Regarding "added complexity in= trying to do a hardware implementation": I think whatever complex= ity is there has been added by GAL following the AL, not by the flow label (= with or without ELI). This has been my main point for objecting to what has become RFC 6423.  Prior to that, you c= ould handle an  AL exactly as you would handle  any other lab= el according to RFC 3031 - look it up in the ILM and perform the corres= ponding action which would be "pop and forward an unlabeled (because your AL has been always BoS) packet to a non-MPLS fo= rwarder defined by the AL". And yes, I know that some implementations d= id it differently - but the naive processing I've defined before had worked= OK for PWs, VPLS and IP VPN.  And RFC 6391 did not really change that:
    you could still forward a (possibly labe= led) packet to a suitable non-MPLS forwarder, and  the only change you= needed would be for this forwarder to ignore the remainder of the label sta= ck whatever it happened to be if it received a labeled packet.
     
    GAL following the AL has changed this si= mple logic. You really had to distinguish between ALs and "regular"= ; labels in your MPLS forwarder. This means that your ILM lookup must now re= turn a "this is an AL" indication to the forwarding HW. I do not see how this can be avoided if you want to support= RFC 6423 - please consider the difference between the T-PE and= S-PE operation in MS-PWs as an example.
     
    At the same time once y= ou implement that, support of flow labels on top of supporting GAL beco= mes trivial because, since RFC 6391, reserved labels (including GAL) MU= ST NOT be used as flow labels. I.e., a dumb parser would know that if it has found an AL that is not BoS, it sho= uld only check for the next label for being a reserved one. Having an ELI at= this point would only make life more complicated, because you would then to= distinguish specifically between GAL, ELI and, possibly, other reserved labels...
     
    My 2c,
         Sasha
     
    From: Pablo Frank= [pabloisnot@gmail.com]
    Sent: Friday, February 17, 2012 6:39 PM
    To: Alexander Vainshtein
    Cc: John E Drake; mpls@ietf.org; pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels + GAL

    Hi Sasha,

    Even the relatively simple set of rules that you've defined below gloss= es over a some added complexity in trying to do a hardware implementation. &= nbsp;I think we can at least agree that this is not nearly as simple as usin= g reserved ELI (which a dumb parser can dispose of without needing to even look anything up).  I guess I'm= just nervous about the lookup context of a label affecting the disposition= of a label that is not necessarily next in the stack.  To me this feel= s like a slippery slope.  What if, in the future, we come up with more "stuff" that goes between the AL and= the EL?  The permutations quickly multiply and this will ultimately im= pact the cost of hardware.

    Just something to keep in mind as we go forward.

    In any case, I think there's enough uncertainty that the authors of typ= e-4 VCCV should probably explicitly address how they expect it to interact w= ith flow labels.

    Pablo

    On Thu, Feb 16, 2012 at 1:19 PM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
    Pablo,
    Lots of thanks for a prompt response.
     
    I think that the situation with GAL betw= een the PW (application label) and flow label is much simpler than what you= have described. This logic is based on the fact "application labels&qu= ot; can be easily recognized as such by the LSR that examines them during label stack parsing.
     
    When an application label is encountered= , there are just three cases:
    1. It is BoS - nothing ne= w, pass to the corresponding application (PW forwarder, V= RF etc.) for handling. The data for this application directly follows= the label stack (may include CW in the case of PW or VPLS)
    2. Not BoS<= a> and the next label is GAL - stop parsing and pass to the "= ;VCCV-4" handler, The data for the "VCCV-4 handler" applicati= on directly follows the label stack and starts with the ACH header.
    3. Not BoS and the n= ext label is not GAL - treat the next label as the "flow label", i= .e. pass to the corresponding application (may include CW in the= case of PW or VPLS).

    In the case of MS-PWs, only T-PEs would tr= eat the PW labels as "application labels", S-PEs would treat them= as non-application labels. This is fully consistent with RFC 6073 which exp= lains that if you want an S-PE to handle a VCCV packet, you must use VCCV Type 3 (TTL expiration) possibly combined wi= th VCCV Type 1 (if the PWE has been using a CW) or VCCV Type 4.

     

    In other words, there is no need for ELI w= ith the flow label.

     

    Did I miss something?

     

    My 2c,

    Sasha

     

    Fro= m: Pablo Frank [pabloisnot@gmail= .com]
    Sent: Thursday, February 16, 2012 6:22 PM
    To: Alexander Vainshtein
    Cc: John E Drake; mpls@ietf.org<= a>; pwe3@ietf.org

    Subject: Re: [mpls] Question about Entropy labels += GAL

    Thanks Sasha.  I completely concur with your points 1 and 2.

    As for point #3, that seems like the logical conclusion.  However,= I think there's still a bit of awkwardness around implementing this.  = Both the original entropy-label draft and RFC 6391 have assumed a simple pop= -pop logic when you encounter an entropy-enabled AL or a flow-enabled PW.  The moment GAL, or any other reserved label= gets thrown into the mix, the label disposition logic gets suddenly more co= mplex.  Instead of pop-pop, the hardware will have to do more complicat= ed logic like "IF this is a flow-enabled label AND the next label is ! GAL THEN pop-pop ELSE IF ..., etc.". &nb= sp;While I have very programmable hardware at my disposal, I prefer elegant= and simple and this feels wrong.

    It sounds like the authors of the entropy label draft have recognized t= his problem and are now moving towards mandating the use of a reserved ELI w= hich unambiguously implies that the next label is entropy (so the hardware c= an go back to having simple pop-pop logic when it sees a reserved ELI).

    Which brings me back to VCCV.  If I'm doing type-1,2,3 VCCV, the s= ituation is unambiguous.  If I encounter any of these types of PWEs wit= h flow-enabled, I can do a pop-pop.  If for type-4 VCCV, we assume that= the GAL is between the PW label and flow label (which I think was the intent), we're back to having ugly logic to try and= dispose of the GAL and flow label correctly.  A reserved ELI could hel= p disambiguate the situation in this case but this makes running type-4 VCCV= with flow labels unattractive compared to type-1 VCCV.

    regards,
    Pablo

    On Thu, Feb 16, 2012 at 1:22 AM, Alexander V= ainshtein <Al= exander.Vainshtein@ecitele.com> wrote:
    Pablo, John and all,
    A couple of comments:
     
    1. Following a long discussion on the PWE3 WG mailing list RFC 6423 ha= s relaxed the original requirement for GAL being at the bottom o= f stack that have been defined in RFC 5586.
    2. My reading of RFC 6391 is that it mandates the flow label to b= e at the bottom of the label stack for PW packets carrying user= data. And it does not provide for ELI usage anywhere, be it a reserved labe= l or a signaled one.
    3. To the best of my understanding, the situation when GAL is used for= fat PWs is not explicitly defined. Inserting GAL between the PW label= and flow label (with the ACH header immediately following the label stack)= seems to be fully compatible with both RFC 6423 and RFC 6391. Maybe this format should be explicitly defined as the co= rrect one?

    Regards,

         Sasha

     

     
     
     
     
     
     
     
    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Pablo F= rank [pabloisnot@gmail.com]
    Sent: Thursday, February 16, 2012 12:24 AM
    To: John E Drake
    Cc: mpls@ietf.org;= pwe3@ietf.org
    Subject: Re: [mpls] Question about Entropy labels += GAL

    Ah, good.  That certainly makes things more deterministic.  

    I guess the question now becomes how will this affect type-4 VCCV on fa= t pseudowires (RFC 6391)?  Will type-4 VCCV have to= mandate the use of ELIs when flow labels are present?  That seems too= bad since the main advantage of type-4 VCCV seems to be to save a few bytes on the wire.  This puts the overhead right b= ack in so it may be more attractive to run fat PWEs with type-1 VCCV...

    Pablo

    On Wed, Feb 15, 2012 at 4:26 PM, John E Drake <jdrake@juniper.net> wrote:

    Pablo,

     

    Based upon Kireeti=92s up= date in Taipei, we seem to going towards using a reserved label for ELI and= making it always required.

     

    Thanks,

     

    John  

     

    From: mpl= s-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Wednesday, February 15, 2012 7:30 AM
    To: mpls@ietf.org<= br> Subject: [mpls] Question about Entropy labels + GAL=

     

    I'm working on implementation for entropy labels and= I have a question about draft-ietf-mpls-entropy-label-01.  Consid= er a scenario where I have received the following:

     

    ... | LSP label x | Entropy label | IPv4 payload | ..= .

     

    Assume that I've signaled that the LSP label wants en= tropy and an ELI is unnecessary.  Following the procedures detailed in= 4.3, the datapath would lookup label x and see that it i= s expecting a possible entropy label and since x is not BOS, it pops the next label and then begins processing the IPv4 pa= yload.  So far, so good.  

     

    However, I believe the following is legal as well:=

     

    ... | LSP label x | GAL label | Entropy label | BFD p= ayload | ...

     

    Alternatively, an equally vexing scenario is:<= u>

     

    ... | LSP label x | IPv4 explicit NULL | Entropy labe= l | IPv4 payload | ...

     

    There are probably other reserved labels that are app= licable as well.

     

    In either case, the draft doesn't clearly state what'= s supposed to happen.  If I follow the procedures in 4.3, the data= path would end up popping the GAL or the explicit NULL label (= thinking they are entropy labels) and would then attempt to lookup the entropy label (which would result in erroneous b= ehaviour).   The only additional guidance that the draft= gives is in section 6 where it suggests that GAL could be treated as an app= lication label.  But that doesn't seem helpful since the LSP label must also be an application label (to ha= ndle the non-GAL case) and will always be encountered first during label dis= position.  Also, presumably I don't want all GALs to expect entropy so= there's an implied scoping of GAL.

     

    It seems to me that when a datapath encounters an entropy-enabled application label or an ELI, that it essenti= ally must do a "deferred pop of BOS label".  In other words,= if the datapath encounters an entropy-enabled AL or an ELI, it must make a note of it and continue processing labels unti= l it hits the BOS label, which it must pop.  While certainly possible,= this is a lot more convoluted and difficult to implement than what is speci= fied in the draft.  Is this really the desired behaviour?

     

    The same question applies to type-4 VCCV with flow la= bels.

     

    regards,

    Pablo

     


    This e-mail message is intended for the recipient only and contains infor= mation 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, p= hone or fax, and then delete the original and all copies thereof.


    This e-mail message is intended for the recipient only and contains infor= mation 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, p= hone or fax, and then delete the original and all copies thereof.


    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_A3C5DF08D38B6049839A6F553B331C76011659266629ILPTMAIL02e_-- From adrian@olddog.co.uk Wed Feb 22 07:16:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4287E21F87B3 for ; Wed, 22 Feb 2012 07:16:55 -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 SPcyILyRqai8 for ; Wed, 22 Feb 2012 07:16:51 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id F026021F87A5 for ; Wed, 22 Feb 2012 07:16:50 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1MFGnCK028375 for ; Wed, 22 Feb 2012 15:16:49 GMT Received: from 950129200 (42-177.79-83.cust.bluewin.ch [83.79.177.42]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q1MFGj93028327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 Feb 2012 15:16:47 GMT From: "Adrian Farrel" To: References: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> In-Reply-To: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 15:16:45 -0000 Message-ID: <039f01ccf174$fe79d780$fb6d8680$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdS0dQFbRu6GyAeWPtVTnp+xX6JJaoU1aw Content-Language: en-gb Subject: [PWE3] FW: Last Call: (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:16:55 -0000 Hi PWE3 WG, You will want to be aware of this IETF Last Call. Please send any comments as per the instructions for IETF Last Call (i.e., see below) and not to the MPLS mailing list. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 22 February 2012 15:13 > To: IETF-Announce > Subject: Last Call: (Allocation of an > Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to > Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Allocation of an Associated Channel Code Point for Use by ITU-T > Ethernet based OAM' > 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 2012-03-21. 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 > > This document assigns an Associated Channel Type code point for > carrying Ethernet based Operations, Administration, and Management > messages in the MPLS Generic Associated Channel (G-ACh). > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From david.sinicrope@ericsson.com Fri Feb 24 00:11:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFC21E803C for ; Fri, 24 Feb 2012 00:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 y-kgB4E114Ow for ; Fri, 24 Feb 2012 00:11:52 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAF821E801E for ; Fri, 24 Feb 2012 00:11:47 -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 q1O8BjQD030965 for ; Fri, 24 Feb 2012 02:11:47 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.46]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 24 Feb 2012 03:11:38 -0500 From: David Sinicrope To: "IETF.PWE3" Date: Fri, 24 Feb 2012 03:11:36 -0500 Thread-Topic: PWE3 IETF 83 Slot Requests Thread-Index: Aczyy+68Co7CT8NAT9CNA+8GVz8ohA== Message-ID: <5F95DE27-BD4D-414A-BD1E-A2969CD7EA2B@ericsson.com> References: <98A0061D0243EA4B980DE1BEADCE398A2D2B274511@FHDP1LUMXC7V22.us.one.verizon.com> In-Reply-To: <98A0061D0243EA4B980DE1BEADCE398A2D2B274511@FHDP1LUMXC7V22.us.one.verizon.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [PWE3] PWE3 IETF 83 Slot Requests X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:11:55 -0000 SGkgQWxsLA0KSWYgeW91IG5lZWQgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgdGhlIElFVEYgODMg UFdFMyBzZXNzaW9uLCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCAoc3ViamVjdCBpbnRhY3Qp IHdpdGg6DQotdG9waWMNCi1kcmFmdCBuYW1lDQotcmVxdWVzdGVkIGR1cmF0aW9uDQotc3BlYWtl cg0KDQpUaGFua3MsDQpEYXZlDQoNCg0KT24gRmViIDIzLCAyMDEyLCBhdCAzOjQ1IFBNLCAiTWFs aXMsIEFuZHJldyBHIChBbmR5KSIgPGFuZHJldy5nLm1hbGlzQHZlcml6b24uY29tPG1haWx0bzph bmRyZXcuZy5tYWxpc0B2ZXJpem9uLmNvbT4+IHdyb3RlOg0KDQoNCg0KQ2hlZXJzLA0KQW5keQ0K U2VudCBmcm9tIG15IFZlcml6b24gRFJPSUQgMw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiAiSUVURiBTZWNyZXRhcmlhdCIgW2FnZW5kYUBpZXRmLm9yZzxtYWlsdG86YWdl bmRhQGlldGYub3JnPl0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxMiAwMzo0MyBQ TSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20+DQpDYzogcHdlMy1h ZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnB3ZTMtYWRzQHRvb2xzLmlldGYub3JnPjsgcHdlMy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnB3ZTMtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsg d2xvQGFtc2wuY29tPG1haWx0bzp3bG9AYW1zbC5jb20+DQpTdWJqZWN0OiBwd2UzIC0gUmVxdWVz dGVkIHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZvciBJRVRGIDgzDQoNCg0KRGVhciBNYXR0 aGV3IEJvY2NpLA0KDQpUaGUgc2Vzc2lvbnMgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQgaGF2ZSBi ZWVuIHNjaGVkdWxlZC4NCkJlbG93IGlzIHRoZSBzY2hlZHVsZWQgc2Vzc2lvbiBpbmZvcm1hdGlv biBmb2xsb3dlZCBieQ0KdGhlIG9yaWdpbmFsIHJlcXVlc3QuDQoNCnB3ZTMgU2Vzc2lvbiAxICgy LjUgaG91cnMpDQogICAgVGh1cnNkYXksIE1vcm5pbmcgU2Vzc2lvbiBJIDA5MzAtMTEzMA0KICAg IFJvb20gTmFtZTogMjQyQUINCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNClJlcXVlc3QgSW5mb3JtYXRpb246DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV29ya2luZyBHcm91 cCBOYW1lOiBQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVkZ2UNCkFyZWEgTmFtZTogUm91 dGluZyBBcmVhDQpTZXNzaW9uIFJlcXVlc3RlcjogV2FuZGEgTG8NCg0KTnVtYmVyIG9mIFNlc3Np b25zOiAxDQpMZW5ndGggb2YgU2Vzc2lvbihzKTogIDIuNSBob3Vycw0KTnVtYmVyIG9mIEF0dGVu ZGVlczogMTIwDQpDb25mbGljdHMgdG8gQXZvaWQ6DQogRmlyc3QgUHJpb3JpdHk6ICBjY2FtcCAg bDJ2cG4gbDN2cG4gbXBscyB0aWN0b2MgYW5jcCBydGdhcmVhIHJ0Z3dnDQogU2Vjb25kIFByaW9y aXR5OiAgaW50YXJlYQ0KDQoNCg0KDQpTcGVjaWFsIFJlcXVlc3RzOg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From amalis@gmail.com Fri Feb 24 01:01:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612DD21F87C5 for ; Fri, 24 Feb 2012 01:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-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 hOViyyXYO-Kz for ; Fri, 24 Feb 2012 01:01:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BD21F871C for ; Fri, 24 Feb 2012 01:01:23 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1309283wgb.13 for ; Fri, 24 Feb 2012 01:01:23 -0800 (PST) Received-SPF: pass (google.com: domain of amalis@gmail.com designates 10.180.80.71 as permitted sender) client-ip=10.180.80.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of amalis@gmail.com designates 10.180.80.71 as permitted sender) smtp.mail=amalis@gmail.com; dkim=pass header.i=amalis@gmail.com Received: from mr.google.com ([10.180.80.71]) by 10.180.80.71 with SMTP id p7mr2930733wix.10.1330074083298 (num_hops = 1); Fri, 24 Feb 2012 01:01:23 -0800 (PST) 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 :content-type; bh=pCvwZHjoYWhR9DM3t+8jZIq7LwAbkGXIaHrQe7z9kwM=; b=WHk0R/JBWdNpo3toZKbK4qa/Lgv4BdOEUmn7WWWKZ2Y64p8xmvst/iTl4LYAs1Vp5r adjBr0YpoHwkU+AfGBYaL2SDsYeif/C2uNqAunkCcs/4QkO7ZfI6ExGhy5MedXg0rtnt BU91Lf2/1ykkAV+B0nBOUedUW6WHgticE3pFY= Received: by 10.180.80.71 with SMTP id p7mr2344135wix.10.1330074083196; Fri, 24 Feb 2012 01:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.106.1 with HTTP; Fri, 24 Feb 2012 01:01:03 -0800 (PST) In-Reply-To: <5F95DE27-BD4D-414A-BD1E-A2969CD7EA2B@ericsson.com> References: <98A0061D0243EA4B980DE1BEADCE398A2D2B274511@FHDP1LUMXC7V22.us.one.verizon.com> <5F95DE27-BD4D-414A-BD1E-A2969CD7EA2B@ericsson.com> From: "Andrew G. Malis" Date: Fri, 24 Feb 2012 10:01:03 +0100 Message-ID: To: "IETF.PWE3" Content-Type: multipart/alternative; boundary=f46d0442887c41003f04b9b201d4 Subject: Re: [PWE3] PWE3 IETF 83 Slot Requests X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:01:25 -0000 --f46d0442887c41003f04b9b201d4 Content-Type: text/plain; charset=ISO-8859-1 Note that regardless of the secretariat's email below, the session will be starting at 09:00, not 09:30. The online agenda has this correct. Cheers, Andy On Fri, Feb 24, 2012 at 9:11 AM, David Sinicrope < david.sinicrope@ericsson.com> wrote: > Hi All, > If you need a presentation slot for the IETF 83 PWE3 session, please reply > to this email (subject intact) with: > -topic > -draft name > -requested duration > -speaker > > Thanks, > Dave > > -----Original Message----- > From: "IETF Secretariat" [agenda@ietf.org] > Sent: Thursday, February 23, 2012 03:43 PM Eastern Standard Time > To: matthew.bocci@alcatel-lucent.com matthew.bocci@alcatel-lucent.com> > Cc: pwe3-ads@tools.ietf.org; > pwe3-chairs@tools.ietf.org; > wlo@amsl.com > Subject: pwe3 - Requested session has been scheduled for IETF 83 > > > Dear Matthew Bocci, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > pwe3 Session 1 (2.5 hours) > Thursday, Morning Session I 0930-1130 > Room Name: 242AB > --------------------------------------------- > > > > Request Information: > > --------------------------------------------------------- > Working Group Name: Pseudowire Emulation Edge to Edge > Area Name: Routing Area > Session Requester: Wanda Lo > > Number of Sessions: 1 > Length of Session(s): 2.5 hours > Number of Attendees: 120 > Conflicts to Avoid: > First Priority: ccamp l2vpn l3vpn mpls tictoc ancp rtgarea rtgwg > Second Priority: intarea > > > > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --f46d0442887c41003f04b9b201d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note that regardless of the secretariat's email below, the session will= be starting at 09:00, not 09:30. The online agenda has this correct.
    Cheers,
    Andy

    On Fri, Feb 24, 2012 at= 9:11 AM, David Sinicrope <david.sinicrope@ericsson.com> wrote:
    Hi All,
    If you need a presentation slot for the IETF 83 PWE3 session, please reply = to this email (subject intact) with:
    -topic
    -draft name
    -requested duration
    -speaker

    Thanks,
    Dave

    -----Original Message-----
    From: "IETF Secretariat" [agen= da@ietf.org<mailto:agenda@ietf.or= g>]
    Sent: Thursday, February 23, 2012 03:43 PM Eastern Standard Time
    To: matthew.bocci@alcat= el-lucent.com<mailto:matthew.bocci@alcatel-lucent.com>
    Cc: pwe3-ads@tools.ietf.org&= lt;mailto:pwe3-ads@tools.ietf.or= g>; pwe3-chairs@tools.= ietf.org<mailto:pwe3-c= hairs@tools.ietf.org>; wlo@amsl.com<= /a><mailto:wlo@amsl.com>
    Subject: pwe3 - Requested session has been scheduled for IETF 83


    Dear Matthew Bocci,

    The sessions that you have requested have been scheduled.
    Below is the scheduled session information followed by
    the original request.

    pwe3 Session 1 (2.5 hours)
    =A0 =A0Thursday, Morning Session I 0930-1130
    =A0 =A0Room Name: 242AB
    =A0 =A0---------------------------------------------



    Request Information:

    ---------------------------------------------------------
    Working Group Name: Pseudowire Emulation Edge to Edge
    Area Name: Routing Area
    Session Requester: Wanda Lo

    Number of Sessions: 1
    Length of Session(s): =A02.5 hours
    Number of Attendees: 120
    Conflicts to Avoid:
    =A0First Priority: =A0ccamp =A0l2vpn l3vpn mpls tictoc ancp rtgarea rtgwg =A0Second Priority: =A0intarea




    Special Requests:

    ---------------------------------------------------------

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

    --f46d0442887c41003f04b9b201d4-- From iesg-secretary@ietf.org Fri Feb 24 11:40:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3582521F86F3; Fri, 24 Feb 2012 11:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 yOHpuj1otcfr; Fri, 24 Feb 2012 11:40:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CD521F8664; Fri, 24 Feb 2012 11:40:03 -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.64p2 Message-ID: <20120224194003.12381.14102.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 11:40:03 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Packet Pseudowire Encapsulation over an MPLS PSN) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:40:06 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Packet Pseudowire Encapsulation over an MPLS PSN' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-09. 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 This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/ No IPR declarations have been submitted directly on this I-D. From chao.fu.a@gmail.com Sun Feb 26 17:59:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C421F84EA for ; Sun, 26 Feb 2012 17:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 JaXT8DwLkjJG for ; Sun, 26 Feb 2012 17:59:14 -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 AC27F21F84E4 for ; Sun, 26 Feb 2012 17:59:14 -0800 (PST) Received: by vbbez10 with SMTP id ez10so763549vbb.31 for ; Sun, 26 Feb 2012 17:59:14 -0800 (PST) Received-SPF: pass (google.com: domain of chao.fu.a@gmail.com designates 10.52.88.103 as permitted sender) client-ip=10.52.88.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of chao.fu.a@gmail.com designates 10.52.88.103 as permitted sender) smtp.mail=chao.fu.a@gmail.com; dkim=pass header.i=chao.fu.a@gmail.com Received: from mr.google.com ([10.52.88.103]) by 10.52.88.103 with SMTP id bf7mr5741604vdb.72.1330307954279 (num_hops = 1); Sun, 26 Feb 2012 17:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=uH25iM6dhVKSzaAd/30vl9RKOqX59IyaQorUVozam6Y=; b=p9lnniN1FWy2ysIcI5+wCp/XwrezC9BSXvjMdoOeyAo4OKU4kEur0qKZh4xu85sk50 dY1rHmuKq33GcPRnZ4VY9Fd3Q67Fo/SGtLlu7IXAli01wHXIxf44l0td6pQSJg7RdZ87 Wv53xj7uInUckhYsLeCDarY2CdOQnTKEmL91k= Received: by 10.52.88.103 with SMTP id bf7mr4621462vdb.72.1330307954212; Sun, 26 Feb 2012 17:59:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.177.68 with HTTP; Sun, 26 Feb 2012 17:58:54 -0800 (PST) From: Chao Fu Date: Mon, 27 Feb 2012 09:58:54 +0800 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3c040d7ea304b9e875db Subject: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 01:59:15 -0000 --20cf307f3c040d7ea304b9e875db Content-Type: text/plain; charset=ISO-8859-1 Hi all, In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, but in Figure3, the Emulated Service is ended between PE2 and CE2, not at CE2. So which one is correct? I think in Figure 2 the Emulated Service should be between ACs. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | Native service Native service Figure 2. PWE3 Network Reference Model PW End Service | |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | V V V V PW +-----+----+ +----+ End Service +-----+ |PREP | PE1|==================| PE2| | +-----+ | | | |............PW1.............|----------| | | CE1 |----| | | | | | | CE2 | | | ^ | |............PW2.............|----------| | +-----+ | | | |==================| | | ^ +-----+ | +-----+----+ +----+ | | | ^ | | | | | | | |<------- Emulated Service ------->| | | | | | Virtual physical | | termination | | ^ | CE1 native | CE2 native service | service | CE2 native service Figure 3. Pre-processing within the PWE3 Network Reference Model Regards Chao Fu --20cf307f3c040d7ea304b9e875db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

    In RFC 3985, the=A0Emulated Service in Figure2 i= s from CE1 to CE2, but in Figure3, the=A0Emulated Service is ended between = PE2 and CE2, not at CE2. So which one is correct? I think in Figure 2 the= =A0Emulated Service
    =A0should be between ACs.
    =A0
    =A0
                |<-------------- Emulated Service -------------=
--->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

                   Figure 2.  PWE3 Network Reference Model



                 =
          PW
                    End Service
                        |
                        |<------- Pseudo Wire ------>|
                        |                            |
                        |    |<-- PSN Tunnel -->|    |
                        V    V                  V    V     PW
                  +-----+----+                  +----+ End Service
       +-----+    |PREP | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D| PE2|     |    +-----+
       |     |    |     |............PW1.............|----------|     |
       | CE1 |----|     |    |                  |    |     |    | CE2 |
       |     | ^  |     |............PW2.............|----------|     |
       +-----+ |  |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D|    |     | ^  +-----+
               |  +-----+----+                  +----+     | |
               |        ^                                  | |
               |        |                                  | |
               |        |<------- Emulated Service ------->| |
               |        |                                    |
               | Virtual physical                            |
               |  termination                                |
               |        ^                                    |
          CE1 native    |                                CE2 native
           service      |                                service
                        |
                   CE2 native
                    service

       Figure 3.  Pre-processing within the PWE3 Network Reference Model


    Regards
    Chao Fu
    --20cf307f3c040d7ea304b9e875db-- From binnyjeshan@gmail.com Sun Feb 26 20:47:13 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0FB21E8019 for ; Sun, 26 Feb 2012 20:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NoLpTwhDOBQ for ; Sun, 26 Feb 2012 20:47:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1393C21E800F for ; Sun, 26 Feb 2012 20:47:11 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so910647wgb.13 for ; Sun, 26 Feb 2012 20:47:11 -0800 (PST) Received-SPF: pass (google.com: domain of binnyjeshan@gmail.com designates 10.180.94.68 as permitted sender) client-ip=10.180.94.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of binnyjeshan@gmail.com designates 10.180.94.68 as permitted sender) smtp.mail=binnyjeshan@gmail.com; dkim=pass header.i=binnyjeshan@gmail.com Received: from mr.google.com ([10.180.94.68]) by 10.180.94.68 with SMTP id da4mr24143066wib.22.1330318031363 (num_hops = 1); Sun, 26 Feb 2012 20:47:11 -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=sUdZC3dKrtQtbNBA95EHPneI0mHAoUFB3YO02arbmA0=; b=YzpdE9Z0gshXCPyFCcHQGT0CgSAWQUOS+9EWVFIAVNm0aJvpRmPW2qmwcNyL5kPkka SvO/OZo0ixJNPR8kKQ7SquYq8qlkhFBx5uSt+qdRcQnCtMGwywUyakd+6G9LN4DzOzJN qGbldMnMqNSOL/2KHIgHv2STNrW2gI/msBVww= MIME-Version: 1.0 Received: by 10.180.94.68 with SMTP id da4mr19216051wib.22.1330318031249; Sun, 26 Feb 2012 20:47:11 -0800 (PST) Received: by 10.223.116.193 with HTTP; Sun, 26 Feb 2012 20:47:11 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 10:17:11 +0530 Message-ID: From: binny jeshan To: Chao Fu Content-Type: multipart/alternative; boundary=f46d04428690b0e21204b9eacd8c Cc: pwe3@ietf.org Subject: Re: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 04:47:13 -0000 --f46d04428690b0e21204b9eacd8c Content-Type: text/plain; charset=ISO-8859-1 Hi Chao, As per my understanding, Figure 3 meant it correct. From PW3 service perspective, service starts from the TPE only. Regards, Binny. On 27 February 2012 07:28, Chao Fu wrote: > Hi all, > > In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, but in > Figure3, the Emulated Service is ended between PE2 and CE2, not at CE2. So > which one is correct? I think in Figure 2 the Emulated Service > should be between ACs. > > > > |<-------------- Emulated Service ---------------->| > | | > | |<------- Pseudo Wire ------>| | > | | | | > | | |<-- PSN Tunnel -->| | | > | V V V V | > V AC +----+ +----+ AC V > +-----+ | | PE1|==================| PE2| | +-----+ > | |----------|............PW1.............|----------| | > | CE1 | | | | | | | | CE2 | > | |----------|............PW2.............|----------| | > +-----+ ^ | | |==================| | | ^ +-----+ > ^ | +----+ +----+ | | ^ > | | Provider Edge 1 Provider Edge 2 | | > | | | | > Customer | | Customer > Edge 1 | | Edge 2 > | | > | | > Native service Native service > > Figure 2. PWE3 Network Reference Model > > > > PW > End Service > | > |<------- Pseudo Wire ------>| > | | > | |<-- PSN Tunnel -->| | > V V V V PW > +-----+----+ +----+ End Service > +-----+ |PREP | PE1|==================| PE2| | +-----+ > | | | |............PW1.............|----------| | > | CE1 |----| | | | | | | CE2 | > | | ^ | |............PW2.............|----------| | > +-----+ | | | |==================| | | ^ +-----+ > | +-----+----+ +----+ | | > | ^ | | > | | | | > | |<------- Emulated Service ------->| | > | | | > | Virtual physical | > | termination | > | ^ | > CE1 native | CE2 native > service | service > | > CE2 native > service > > Figure 3. Pre-processing within the PWE3 Network Reference Model > > > Regards > > Chao Fu > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --f46d04428690b0e21204b9eacd8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0Hi Chao,

    As per my understanding, Figure 3 meant it c= orrect. From PW3 service perspective, service starts from the TPE only.

    Regards,
    Binny.

    On 27 February 2012 07:28, Chao Fu <chao.fu.a@gmail.com> wrote:
    Hi all,

    In RFC 3985, the=A0Emulated Service in Figure2 i= s from CE1 to CE2, but in Figure3, the=A0Emulated Service is ended between = PE2 and CE2, not at CE2. So which one is correct? I think in Figure 2 the= =A0Emulated Service
    =A0should be between ACs.
    =A0
    =A0
          =
      |<-------------- Emulated Service ---------------->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

                   Figure 2.  PWE3 Network Reference Model



                           PW
                    End Service
                        |
                        |<------- Pseudo Wire ------>|
                        |                            |
                        |    |<-- PSN Tunnel -->|    |
                        V    V                  V    V     PW
                  +-----+----+                  +----+ End Service
       +-----+    |PREP | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D| PE2|     |    +-----+
       |     |    |     |............PW1.............|----------|     |
       | CE1 |----|     |    |                  |    |     |    | CE2 |
       |     | ^  |     |............PW2.............|----------|     |
       +-----+ |  |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D|    |     | ^  +-----+
               |  +-----+----+                  +----+     | |
               |        ^                                  | |
               |        |                                  | |
               |        |<------- Emulated Service ------->| |
               |        |                                    |
               | Virtual physical                            |
               |  termination                                |
               |        ^                                    |
          CE1 native    |                                CE2 native
           service      |                                service
                        |
                   CE2 native
                    service

       Figure 3.  Pre-processing within the PWE3 Network Reference Model


    Regards
    Chao Fu

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


    --f46d04428690b0e21204b9eacd8c-- From mjethanandani@gmail.com Sun Feb 26 21:01:12 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6343D21E8015 for ; Sun, 26 Feb 2012 21:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 icDZEGyV45ns for ; Sun, 26 Feb 2012 21:01:11 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF9421E800F for ; Sun, 26 Feb 2012 21:01:06 -0800 (PST) Received: by dakl33 with SMTP id l33so368615dak.31 for ; Sun, 26 Feb 2012 21:01:05 -0800 (PST) Received-SPF: pass (google.com: domain of mjethanandani@gmail.com designates 10.68.225.229 as permitted sender) client-ip=10.68.225.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mjethanandani@gmail.com designates 10.68.225.229 as permitted sender) smtp.mail=mjethanandani@gmail.com; dkim=pass header.i=mjethanandani@gmail.com Received: from mr.google.com ([10.68.225.229]) by 10.68.225.229 with SMTP id rn5mr3555279pbc.32.1330318865962 (num_hops = 1); Sun, 26 Feb 2012 21:01:05 -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=1fRl6MW2/2EaDJqSTw2p51QSMOaEhltuiS2l5dYig5c=; b=iFgZLTIDYtXAhNxoXeYjZ+2IUvDnqMHbaqd5sFJh3+2c2n/2yQpbv2lmF87veAHJqM KsHV/Ee6SOkc/Bp6hJB49fOE1RLs8N/qTwnVSwuaH/HHywSbZX/ASiTnp8kjd1ogsn4u LHSqZOvAmn9hm/dpp/fEtWqPKtGjKbK3JA//Q= Received: by 10.68.225.229 with SMTP id rn5mr3048263pbc.32.1330318865887; Sun, 26 Feb 2012 21:01:05 -0800 (PST) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id l1sm11649790pbe.54.2012.02.26.21.01.02 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 21:01:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-95--175657046 From: Mahesh Jethanandani In-Reply-To: Date: Sun, 26 Feb 2012 21:01:01 -0800 Message-Id: References: To: Chao Fu X-Mailer: Apple Mail (2.1084) Cc: pwe3@ietf.org Subject: Re: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 05:01:12 -0000 --Apple-Mail-95--175657046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chao, The PW as indicated in the diagram is configured on the PE router. The = Emulated Service can be seen to be configured between the AC, or between = the outgoing interface of the CEs or the incoming interface on the PEs - = take your pick. If your question is where does the encapsulation of the native packet = happens, it happens in the PE router. On Feb 26, 2012, at 5:58 PM, Chao Fu wrote: > Hi all, >=20 > In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, but = in Figure3, the Emulated Service is ended between PE2 and CE2, not at = CE2. So which one is correct? I think in Figure 2 the Emulated Service > should be between ACs. > =20 > =20 > |<-------------- Emulated Service ---------------->| > | | > | |<------- Pseudo Wire ------>| | > | | | | > | | |<-- PSN Tunnel -->| | | > | V V V V | > V AC +----+ +----+ AC V > +-----+ | | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| PE2| | +-----+ > | |----------|............PW1.............|----------| | > | CE1 | | | | | | | | CE2 | > | |----------|............PW2.............|----------| | > +-----+ ^ | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| | | ^ +-----+ > ^ | +----+ +----+ | | ^ > | | Provider Edge 1 Provider Edge 2 | | > | | | | > Customer | | Customer > Edge 1 | | Edge 2 > | | > | | > Native service Native service >=20 > Figure 2. PWE3 Network Reference Model >=20 >=20 > PW > End Service > | > |<------- Pseudo Wire ------>| > | | > | |<-- PSN Tunnel -->| | > V V V V PW > +-----+----+ +----+ End Service > +-----+ |PREP | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D| PE2| | +-----+ > | | | |............PW1.............|----------| = | > | CE1 |----| | | | | | | CE2 = | > | | ^ | |............PW2.............|----------| = | > +-----+ | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D| | | ^ +-----+ > | +-----+----+ +----+ | | > | ^ | | > | | | | > | |<------- Emulated Service ------->| | > | | | > | Virtual physical | > | termination | > | ^ | > CE1 native | CE2 native > service | service > | > CE2 native > service >=20 > Figure 3. Pre-processing within the PWE3 Network Reference = Model >=20 > Regards > Chao Fu > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-95--175657046 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Chao,

    The PW as indicated in the diagram is configured on the PE router. The Emulated Service can be seen to be configured between the AC, or between the outgoing interface of the CEs or the incoming interface on the PEs - take your pick.

    If your question is where does the encapsulation of the native packet happens, it happens in the PE router.

    On Feb 26, 2012, at 5:58 PM, Chao Fu wrote:

    Hi all,

    In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, but in Figure3, the Emulated Service is ended between PE2 and CE2, not at CE2. So which one is correct? I think in Figure 2 the Emulated Service
     should be between ACs.
     
     
                |<-------------- Emulated Service ---------------->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

                   Figure 2.  PWE3 Network Reference Model



                           PW
                    End Service
                        |
                        |<------- Pseudo Wire ------>|
                        |                            |
                        |    |<-- PSN Tunnel -->|    |
                        V    V                  V    V     PW
                  +-----+----+                  +----+ End Service
       +-----+    |PREP | PE1|==================| PE2|     |    +-----+
       |     |    |     |............PW1.............|----------|     |
       | CE1 |----|     |    |                  |    |     |    | CE2 |
       |     | ^  |     |............PW2.............|----------|     |
       +-----+ |  |     |    |==================|    |     | ^  +-----+
               |  +-----+----+                  +----+     | |
               |        ^                                  | |
               |        |                                  | |
               |        |<------- Emulated Service ------->| |
               |        |                                    |
               | Virtual physical                            |
               |  termination                                |
               |        ^                                    |
          CE1 native    |                                CE2 native
           service      |                                service
                        |
                   CE2 native
                    service

       Figure 3.  Pre-processing within the PWE3 Network Reference Model


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

    --Apple-Mail-95--175657046-- From Alexander.Vainshtein@ecitele.com Sun Feb 26 21:46:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D695A21F8499 for ; Sun, 26 Feb 2012 21:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=0.631, 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 DUhD0ZNxaD89 for ; Sun, 26 Feb 2012 21:46:13 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id D52D721F8491 for ; Sun, 26 Feb 2012 21:45:43 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1330321523!12816467!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 27880 invoked from network); 27 Feb 2012 05:45:24 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-14.tower-21.messagelabs.com with SMTP; 27 Feb 2012 05:45:24 -0000 X-AuditID: 93eaf2e7-b7f976d000000ef3-f8-4f4b23fb0480 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id CD.EA.03827.BF32B4F4; Mon, 27 Feb 2012 08:34:35 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 27 Feb 2012 07:45:22 +0200 From: Alexander Vainshtein To: Chao Fu Date: Mon, 27 Feb 2012 07:43:18 +0200 Thread-Topic: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture) Thread-Index: Acz08yJd8yz9cnvtTfywAed4FipraAAG40vA 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_A3C5DF08D38B6049839A6F553B331C76011659266656ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTNmyllQIaMpdAHGjIMKAZTbAVMjVaNgkEb0xqJJhoDQ/tsJ3am TacY6o+4EvxQCRJZNGDE3YSEEEHFD2tc2HH5wA33sKoJIcEVnOlEJDG+r/POPefe+17uJXDN T3UCwQl+5BNYN6OOVFWMjE/ofyRbrIaJJ2mmyx8PYqZj482qNVjujZpX4bkNDd8wG7a9BKxk BcHjZ/2IdiDRbmZsPm4Paw8wNOcwM0aG9rpZO+KR4DczrNeLBAezKpL+56yUZJxAI8HucXCC 08xs2GLVm0xZy/VGZtXCZGPGisg8FyfSSM+znJvmkSiyTkRLTEEz7np3q1HlrSoovtBUjZWA Z8uPgggCUpnw28RomILjYN9Ao/ooiCQ01G0Ah7taceVyEsDvD4/jskpNmWHT1VdqGWupJNhy aX+Ix6lk2FJ7UOIJQkUtgGXnNsgwhnLAljO8okZwqO9TuIKXwsp7YyEnSW2G9W8GQ7yGssHz rVMhHCHxQ73vMRkDqbfJjmuYUkkHn3+ow5SeKdjQ1osrOBYOv58KU/Sx8GVpI1D0HvjgVHeY UmsubK/+oFL08fDOpX7VCRBXMyttzSxLzSyLwqfD/sqTagUvhhfOjuIK1sOqqaBqNl8Pwq+A WM7t9RfyToMxHdk5P3KjdLuHbwLK6Ay2gu91KUFAEYCJIlu/brRqwtg9YoAPgngCY2LJRzqL VRNd6HEEXKzoyvcVuZEYBJDAGS2ZapHkpIMN7EU+z59QjvT35XjCHLtHGlLBn59hMPz/wujI 1B3rrRrKKQ3mboS8yPcnz3yCYCD5Uy4/14ecqHgX5/b/DWNEhNxGlNRGPJQ0pOhleZFzKvEO kJSgIz/LZkoOuIqEGa+8NPump6dHgE56dAw5T7ZHSSs14x6REmNSYltEKLG0NDOhhBJATeZQ 6xIPV6VFd2ZfKf3YPXw1pzbTRE/GbRsoe51461pQ/1lf2W3oU3eWt6UVfVm4rF1bmnLTos13 XKzQvnjQc6B89fX+Xvxxxtuekrv82SUdxsGsvJcgZYAdI4St051lN23ZzYcCXb/IX/cTdy3a aTkCnxYXHMhdez3xdH0TsYlRiS7WmIb7RPY3FQoTdQ8EAAA= Cc: "pwe3@ietf.org" Subject: Re: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 05:46:20 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011659266656ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi, Please note that Figure 3 in RFC 3985 appears in Section 4.2 "PWE3 Pre-proce= ssing" It illustrates the case when the native interface between CE1 and PE1 underg= oes some kind of processing within PE2 prior to some packets being encapsula= ted into the PW between PE1 and PE2. Two kinds of Pre-processing further discussed in this section are Forwarders= and Native Service Processors (NSPs) discussed in Section 4.2.1 and 4.2.2 r= espectively. The Tagged mode Ethernet PW in RFC 4448 represents a simple example of this= operation kind of operation. If the native Ethernet AC between CE1 and PE1= uses untagged Ethernet, the NSP in PE1 would add an appropriate VLAN tag to= each Ethernet frame prior to encapsulating it in a Tagged mode Ethernet PW;= in the reverse direction, VLAN tags received in the PW packets from CE2 wou= ld be stripped prior to sending them to CE1. I would also like to add that multi-segment PWs have not yet been invented a= t the time when RFC 3985 has been written, so the distinctions between T-PE= and S-PE are not related to this thread. Hopefully these notes would be useful. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Chao Fu [ch= ao.fu.a@gmail.com] Sent: Monday, February 27, 2012 3:58 AM To: pwe3@ietf.org Subject: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-Edge (P= WE3) Architecture) Hi all, In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, but in Figu= re3, the Emulated Service is ended between PE2 and CE2, not at CE2. So which= one is correct? I think in Figure 2 the Emulated Service should be between ACs. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | Native service Native service Figure 2. PWE3 Network Reference Model PW End Service | |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | V V V V PW +-----+----+ +----+ End Service +-----+ |PREP | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| PE2| | +-----+ | | | |............PW1.............|----------| | | CE1 |----| | | | | | | CE2 | | | ^ | |............PW2.............|----------| | +-----+ | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| | | ^ +-----+ | +-----+----+ +----+ | | | ^ | | | | | | | |<------- Emulated Service ------->| | | | | | Virtual physical | | termination | | ^ | CE1 native | CE2 native service | service | CE2 native service Figure 3. Pre-processing within the PWE3 Network Reference Model Regards Chao Fu 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_A3C5DF08D38B6049839A6F553B331C76011659266656ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    Hi,
    Please note that Figure 3 in RFC 3985 ap= pears in Section 4.2 "PWE3 Pre-processing"
     
    It illustrates the case when the na= tive interface between CE1 and PE1 undergoes some kind of processing within= PE2 prior to some packets being encapsulated into the PW between PE1 and PE= 2.
     
    Two kinds of Pre-processing further disc= ussed in this section are Forwarders and Native Service Processors (NSPs) di= scussed in Section 4.2.1 and 4.2.2 respectively.
     
    The Tagged mode Ethernet PW in RFC 4448= represents a simple example of this operation kind of operation. If= the native Ethernet AC between CE1 and PE1 uses untagged Ethernet, the NSP&= nbsp;in PE1 would add an appropriate VLAN tag to each Ethernet frame prior to encapsulating it in a Tagged mode= Ethernet PW; in the reverse direction, VLAN tags received in= the PW packets from CE2 would be stripped prior to sending them to CE1.
     
    I would also like to add that multi= -segment PWs have not yet been invented at the time when RFC 3985 has b= een written, so the distinctions between T-PE and S-PE are not rel= ated to this thread.
     
    Hopefully these notes would be useful.
     
    Regards,
         Sasha&nb= sp;
     
     
     
    From: pwe3-bounces= @ietf.org [pwe3-bounces@ietf.org] On Behalf Of Chao Fu [chao.fu.a@gmail.com]=
    Sent: Monday, February 27, 2012 3:58 AM
    To: pwe3@ietf.org
    Subject: [PWE3] One doubt in RFC 3985 (Pseudo Wire Emulation Edge-to-= Edge (PWE3) Architecture)

    Hi all,

    In RFC 3985, the Emulated Service in Figure2 is from CE1 to CE2, b= ut in Figure3, the Emulated Service is ended between PE2 and CE2, not a= t CE2. So which one is correct? I think in Figure 2 the Emulated Servic= e
     should be between ACs.
     
     
                |<-------------- Emulated Service ----=
------------>|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC=
   V
      +-----+    |     | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D|    |     | ^  +-----+
            ^  |       +----+                  +----+     |=
 |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

                   Figure 2.  PWE3 Network Reference Model



                           PW
                    End Service
                        |
                        |<------- Pseudo Wire ------>|
                        |                            |
                        |    |<-- PSN Tunnel -->|    |
                        V    V                  V    V     PW
                  +-----+----+                  +----+ E=
nd Service
       +-----+    |PREP | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D| PE2|     |    +-----+
       |     |    |     |............PW1.............|----------|     |
       | CE1 |----|     |    |                  |    |     |    | CE2 |
       |     | ^  |     |............PW2.............|----------|     |
       +-----+ |  |     |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D|    |     | ^  +-----+
               |  +-----+----+                  +----+ =
    | |
               |        ^                                  | |
               |        |                                  | |
               |        |<------- Emulated Service ------->| |
               |        |                                    |
               | Virtual physical                            |
               |  termination                                |
               |        ^                                    |
          CE1 native    |                                CE2 native
           service      |                                service
                        |
                   CE2 native
                    service

       Figure 3.  Pre-processing within the PWE3 Network Reference Model


    Regards
    Chao Fu

    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_A3C5DF08D38B6049839A6F553B331C76011659266656ILPTMAIL02e_-- From stbryant@cisco.com Mon Feb 27 06:27:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032121F8730 for ; Mon, 27 Feb 2012 06:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5a+uCdnSMAeU for ; Mon, 27 Feb 2012 06:27:47 -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 EF3D321F872F for ; Mon, 27 Feb 2012 06:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2481; q=dns/txt; s=iport; t=1330352867; x=1331562467; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=PWdRdNbj9mD7/aM7GTXbJuWPmLuj3nbqiK4QYYOB8sU=; b=mRIAfgwx+thoieJtpesFwWZ4zVtjgYbVyUWxPK3jkRd1Dad/T7/C2fE7 iy1Kzwo++K6CItRkYqVcEUwtaCFIEZSpOcqGZZhIi6Q7Mc2xeZqkGlvr5 CDHPYTwKC9OgXcWds92u09heBiE9jrC3IP1SW+FY1fg5HCM2cuKclv7cz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN6RS0+Q/khN/2dsb2JhbABCsyaBB4FzAQEBBAEBAQ8BAgEiNgoNBAsRBAEBAQkWBAQHCQMCAQIBFR8IAQgTBgIBAR6HZAuYcQGDMQ8BmxeMewcGEwILBAICBwYEAwQDCAQKBw8BCgkChRgBAQ0BAQQBCwoBBQMFBwEDBgQKCAQOgx4ElT2Sbg X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="67162411" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 27 Feb 2012 14:27:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1RERjVs013879 for ; Mon, 27 Feb 2012 14:27:45 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q1RERiu6004797; Mon, 27 Feb 2012 14:27:45 GMT Message-ID: <4F4B92E0.4010907@cisco.com> Date: Mon, 27 Feb 2012 14:27:44 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pwe3@ietf.org References: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> <039f01ccf174$fe79d780$fb6d8680$@olddog.co.uk> In-Reply-To: <039f01ccf174$fe79d780$fb6d8680$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] FW: Last Call: (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 14:27:48 -0000 My understanding is that the Recommendation called up by this draft proposes this as a new OAM be used for PWs. I do not think that PWE3 has considered the implications of adding this OAM in a PW context. - Stewart On 22/02/2012 15:16, Adrian Farrel wrote: > Hi PWE3 WG, > > You will want to be aware of this IETF Last Call. > > Please send any comments as per the instructions for IETF Last Call (i.e., see > below) and not to the MPLS mailing list. > > Thanks, > Adrian > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >> bounces@ietf.org] On Behalf Of The IESG >> Sent: 22 February 2012 15:13 >> To: IETF-Announce >> Subject: Last Call: (Allocation of > an >> Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to >> Informational RFC >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Allocation of an Associated Channel Code Point for Use by ITU-T >> Ethernet based OAM' >> 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 2012-03-21. 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 >> >> This document assigns an Associated Channel Type code point for >> carrying Ethernet based Operations, Administration, and Management >> messages in the MPLS Generic Associated Channel (G-ACh). >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Mon Feb 27 06:58:52 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97521F8717; Mon, 27 Feb 2012 06:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 f6YZOcO2umvr; Mon, 27 Feb 2012 06:58:51 -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 6EC1021F8700; Mon, 27 Feb 2012 06:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2752; q=dns/txt; s=iport; t=1330354731; x=1331564331; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KhlJZJa0sbJUdr07hkR00mNdh6znAnT56bhFmbSPIwU=; b=StaJS9oEij4Tp2wcHto78PzgWI+CRGOdOlsOVPeeqr2mm0aKVkY4ZYvt 2tnoVcMz6j9XtNka76LMFhgV3obJdfNlh9y93PJAO85nQiDs0uruNZRtJ Gi27dzkuOKwixQsv5VdLdC8hoBYd4UxtBwUJDaf1iYaZAI2yuQL2VPDaI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACGZS0+Q/khL/2dsb2JhbABCsyaBB4FzAQEBBAEBAQ8BAgEiNgoBDAQLEQQBAQEJFgQEBwkDAgECARUfCAEIEwEFAgEBHodkC5kAAYMxDwGbGox5AgsCEwILBAICBwYEAwQDCAQKBw8BCgkChRgBAQ0BAQQBCwoBBQMFBwEDBgQKCAQOgx4ElT2Sbg X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="67167014" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 27 Feb 2012 14:58:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1REwjHZ013243; Mon, 27 Feb 2012 14:58:45 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q1REwet3006673; Mon, 27 Feb 2012 14:58:41 GMT Message-ID: <4F4B9A20.9010909@cisco.com> Date: Mon, 27 Feb 2012 14:58:40 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pwe3@ietf.org References: <20120222151252.32262.82157.idtracker@ietfa.amsl.com> <039f01ccf174$fe79d780$fb6d8680$@olddog.co.uk> <4F4B92E0.4010907@cisco.com> In-Reply-To: <4F4B92E0.4010907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org >> IETF Discussion" Subject: Re: [PWE3] FW: Last Call: (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 14:58:52 -0000 PWE3 WG Please see the note further down the thread requesting that any discussion take place on ietf@ietf.org Stewart On 27/02/2012 14:27, Stewart Bryant wrote: > > My understanding is that the Recommendation called up by > this draft proposes this as a new OAM be used for PWs. > > I do not think that PWE3 has considered the implications > of adding this OAM in a PW context. > > - Stewart > > On 22/02/2012 15:16, Adrian Farrel wrote: >> Hi PWE3 WG, >> >> You will want to be aware of this IETF Last Call. >> >> Please send any comments as per the instructions for IETF Last Call >> (i.e., see >> below) and not to the MPLS mailing list. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >>> bounces@ietf.org] On Behalf Of The IESG >>> Sent: 22 February 2012 15:13 >>> To: IETF-Announce >>> Subject: Last Call: >>> (Allocation of >> an >>> Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to >>> Informational RFC >>> >>> >>> The IESG has received a request from an individual submitter to >>> consider >>> the following document: >>> - 'Allocation of an Associated Channel Code Point for Use by ITU-T >>> Ethernet based OAM' >>> 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 2012-03-21. 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 >>> >>> This document assigns an Associated Channel Type code point for >>> carrying Ethernet based Operations, Administration, and Management >>> messages in the MPLS Generic Associated Channel (G-ACh). >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Mon Feb 27 07:41:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD0D21F879A for ; Mon, 27 Feb 2012 07:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 SfePUbED142t for ; Mon, 27 Feb 2012 07:41:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C38D521F879B for ; Mon, 27 Feb 2012 07:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=884; q=dns/txt; s=iport; t=1330357305; x=1331566905; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=KGVohluqQ3eev7t8Rp4C/0LaPxG8IX7LRZ4eteSQOuU=; b=Df7SekEtRHmr+qNC656f+C/bafMMfi5F0Mr+hEbdqZ76d7XWA2Se7dH6 CqRr1YxlssfpJNbY6/GV+QOPwh2xYCbKMxU66KSYKQu2upfgCK1Qb64n7 Z5rBregacNtFtVghlZrNpS9zIwU1pWv0dEve3Zbt+tV2vn7Rx26w5Eb0j 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADOjS0+Q/khR/2dsb2JhbABDsziBB4F0AQEEEgECASJAER0PFg8JAwIBAgE3BAoGAQwIAQEeh2ShIAGDMQ8Bk0KMeBYOAQ8CAgcGBAMEAwgECgcPAQoDAwMChRgBAhwBg3AElT2Sbg X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="130726394" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Feb 2012 15:41:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1RFfeZh025262; Mon, 27 Feb 2012 15:41:40 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q1RFfd0X009455; Mon, 27 Feb 2012 15:41:39 GMT Message-ID: <4F4BA433.6060804@cisco.com> Date: Mon, 27 Feb 2012 15:41:39 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jounay_Fr=E9d=E9ric?= , draft-ietf-pwe3-p2mp-pw-requirements@tools.ietf.org, pwe3 , "pwe3-chairs@tools.ietf.org" References: <4F44D3C5.1010004@cisco.com> In-Reply-To: <4F44D3C5.1010004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] Fwd: draft-ietf-pwe3-p2mp-pw-requirements will be returned to the WG X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 15:41:46 -0000 I reviewed draft-ietf-pwe3-p2mp-pw-requirements-05 It is my view that this draft falls short of the bar and that we can do a lot better in terms of crisply defining the requirements and the architecture. I am concerned that the approach was to bolt p2mp onto the two PWE3 framework RFCs without standing back and considering the problem on its own merits. The way that p2p links are used in the draft is in my view clumsy compared to the way that it is added in RFC5331/2. In particular we should be relying heavily on RFC5331 and RFC5332 at both the LSP and the PW level. Using those RFCs as a base, PWE3 should be able to produce a much shorter simpler framework. The OAM architecture also needs to be fully described and the design needs to lean heavily on the MPLS P2MP OAM work. With regret I am therefore return the draft to the WG. - Stewart From tnadeau@lucidvision.com Mon Feb 27 13:13:23 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5987521E8047 for ; Mon, 27 Feb 2012 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=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 9C6nNKdrRnLp for ; Mon, 27 Feb 2012 13:13:22 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64021E8040 for ; Mon, 27 Feb 2012 13:13:22 -0800 (PST) Received: from [192.168.1.53] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2E8C6153718 for ; Mon, 27 Feb 2012 16:13:22 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary="Apple-Mail=_B445EC41-7A0A-49E2-ADAB-A87D7FBB97EC" Date: Mon, 27 Feb 2012 16:13:22 -0500 Message-Id: <340C50A7-B675-42EE-ABCA-14F9E92F73CB@lucidvision.com> To: pwe3@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [PWE3] The MPLS 2012 International Conference Call For Papers X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 21:13:23 -0000 --Apple-Mail=_B445EC41-7A0A-49E2-ADAB-A87D7FBB97EC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. On behalf of the Technical Planning Committee --Apple-Mail=_B445EC41-7A0A-49E2-ADAB-A87D7FBB97EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The MPLS 2012 International = Conference, the 15th Annual International
    31, 2012, in Washington, DC. The Technical Program = Committee is
    soliciting abstracts summarizing a = proposed presentation representing
    original/unpublished = work covering cutting-edge topics.

    Presentations covering new technologies and = operational experience are
    solicited from network = equipment vendors, service/transport providers,
    government = agencies, the research community, and enterprise users.
    The deadline for submission of presentation = proposals is April 30, 2012.
    If you want further = information on MPLS 2012 or want to submit a
    presentation = abstract, please see the following URL:

    Many of these topics have = been of interest to members of <this community>

    On behalf of the Technical Planning = Committee
    = --Apple-Mail=_B445EC41-7A0A-49E2-ADAB-A87D7FBB97EC-- From internet-drafts@ietf.org Mon Feb 27 15:10:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70221E8029; Mon, 27 Feb 2012 15:10:09 -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 m9xlxAO73xWJ; Mon, 27 Feb 2012 15:10:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E549B21F857A; Mon, 27 Feb 2012 15:09:48 -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: 4.00 Message-ID: <20120227230948.14014.47483.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 15:09:48 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-bit-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 23:10:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Preferential Forwarding Status Bit Author(s) : Praveen Muley Mustapha Aissaoui Filename : draft-ietf-pwe3-redundancy-bit-06.txt Pages : 35 Date : 2012-02-27 This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-bit-06.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-pwe3-redundancy-bit-06.txt From amalis@gmail.com Tue Feb 28 04:59:10 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2D21F8629 for ; Tue, 28 Feb 2012 04:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 TdvwOsqBe61u for ; Tue, 28 Feb 2012 04:59:10 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF05721F8627 for ; Tue, 28 Feb 2012 04:59:09 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1865064wgb.13 for ; Tue, 28 Feb 2012 04:59:09 -0800 (PST) Received-SPF: pass (google.com: domain of amalis@gmail.com designates 10.216.131.6 as permitted sender) client-ip=10.216.131.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of amalis@gmail.com designates 10.216.131.6 as permitted sender) smtp.mail=amalis@gmail.com; dkim=pass header.i=amalis@gmail.com Received: from mr.google.com ([10.216.131.6]) by 10.216.131.6 with SMTP id l6mr9691918wei.45.1330433948994 (num_hops = 1); Tue, 28 Feb 2012 04:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=guBddsr39EH1LIOVBlMJHO2x0F3az8jklPD3ABmvzUM=; b=kHg6i9rXRd9PEjUpd3BKLE0p6znc04XKfRTORnTkydeMjTbORnfgvdGl3zhjV661c5 FwiDMB65ObjxZaVijACMw/OAPwCwz7nuvJUGi0w3inN/dR6bZux+Q67+NGnzyX3Cmddv jkVi7sMoxDJSvQNl5+rIN/y6BlC3inXzc6vbg= Received: by 10.216.131.6 with SMTP id l6mr7664042wei.45.1330433948874; Tue, 28 Feb 2012 04:59:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.106.1 with HTTP; Tue, 28 Feb 2012 04:58:48 -0800 (PST) From: "Andrew G. Malis" Date: Tue, 28 Feb 2012 07:58:48 -0500 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=0016e6d77c43eb76bc04ba05ca74 Cc: draft-boutros-pwe3-mpls-tp-mac-wd@tools.ietf.org Subject: [PWE3] Ending WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 12:59:10 -0000 --0016e6d77c43eb76bc04ba05ca74 Content-Type: text/plain; charset=ISO-8859-1 Well, this has taken a bit longer than two weeks, and for that we apologize, but based on the comments received on the PWE3 list, the PWE3 co-chairs, L2VPN co-chairs, and the routing ADs discussed the draft and we all agree that this draft is better suited for L2VPN than PWE3. This ends the PWE3 call for adoption, the authors should consider updating the draft based on received comments (including updating the draft name to include l2vpn rather than pwe3), and then work through the usual process in the L2VPN WG. This does not begin any actions in the L2VPN WG, any such actions will need to be requested on that group's list. Thanks, Andy On Mon, Jan 23, 2012 at 3:19 PM, Andrew G. Malis wrote: > This begins a two-week PWE3 WG adoption call for > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > February 6. Please respond with your approval, disapproval, and other > comments to the PWE3 list. If you don't support the adoption, providing a > reason would be useful to the authors and the working group, but is not > required. Of course, the reason why you support the draft is also welcome, > but also optional. This request will be a part of PWE3 WG adoption calls > going forward. > > Thanks, > Andy and Matthew > > --0016e6d77c43eb76bc04ba05ca74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, this has taken a bit longer than two weeks, and for that we apologize= , but based on the comments received on the PWE3 list, the PWE3 co-chairs, = L2VPN co-chairs, and the routing ADs discussed the draft and we all agree t= hat this draft is better suited for L2VPN than PWE3.

    This ends the PWE3 call for adoption, the authors should consider updat= ing the draft based on received comments (includi= ng updating the draft name to include l2vpn rather than pwe3), and then wor= k through the usual process in the L2VPN WG. This does not begin any action= s in the L2VPN WG, any such actions will need to be requested on that group= 's list.

    Thanks,
    Andy

    On Mon, Jan 23, 2012 = at 3:19 PM, Andrew G. Malis <amalis@gmail.com> wrote:
    This begins a two-week PWE3 WG adoption call for https:= //tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending Feb= ruary 6. Please respond with your approval, disapproval, and other comments= to the PWE3 list. If you don't support the adoption, providing a reaso= n would be useful to the authors and the working group, but is not required= . Of course, the reason why you support the draft is also welcome, but also= optional. This request will be a part of PWE3 WG adoption calls going forw= ard.

    Thanks,
    Andy and Matthew


    --0016e6d77c43eb76bc04ba05ca74--